Datagram Congestion Control Protocol (DCCP)

Datagram Congestion Control Protocol (DCCP) Vinh Do CS529– Advance Computer Network California State University, Northridge May 16 2005

Introduction • TCP- Transport Control Protocol • Connection Oriented-provide reliable data transfer, flow control, congestion control • Guarantee data delivery • Delay tolerance • Files transfer, Web browsing, email apps • UDP- User Datagram Protocol • Connectionless • Guarantees nothing • No Congestion Control • DNS, SNMP, streaming media, telephony, on-line games

Introduction (Cont.) • Increasing long-lived applications using UDP • Streaming media-audio/video, Internet telephone, on-line games • Prefer timeliness over reliability-loss tolerance • TCP is not suitable- retransmission delay • Increase of long-lived non-congestion control traffic degrades the network’s performance; can cause collapse of the network

Solutions • Congestion Control at Application level • Reinventing the wheel each time • Difficult to implement • Issue of Interoperability • SCTP-Stream Control Transmission Protocol • unnecessary per-packet overhead • DCCP: Congestion Control for UDP • Simple packet header • TCP-like (CCID2): high throughput, abrupt rate change (games) • TFRC (CCID3): steadier rate, lower throughput (telephony)

cwnd rate = Bytes/sec RTT TCP Congestion Control • TCP senders change the sending rate: Window = min{ receiver Window, Congestion Window} Receiver Transmitter(“cwnd”) • Sender perceives congestion when: • loss event = timeout or 3 duplicate acks • TCP sender reduces rate after loss event • Three mechanisms: • additive increase/multiplicative decrease (AIMD), slow start, reaction to timeout events

multiplicative decrease: cut cwnd in half after loss event TCP AIMD additive increase: increase cwnd by 1 MSS every RTT in the absence of loss events: probing Long-lived TCP connection

When connection begins (cwnd = 1 MSS), increase rate exponentially until first loss event: double cwnd every RTT done by incrementing cwnd for every ACK received Initial rate is slow but ramps up exponentially fast time TCP Slow Start Host A Host B one segment RTT two segments four segments

Reaction to timeout events • After 3 duplicate acks • cwnd *= .5 • window then grows linearly • After timeout event • cwnd = 1MSS • window then grows exponentially to a threshold then grows linearly

When cwnd gets to 1/2 of its value before timeout the exponential increase switch to linear (congestion avoidance). Variable Threshold (initially set to a large value) At loss event, Threshold is set to 1/2 of cwnd just before loss event Reaction to timeout events (cont.)

TCP sender congestion control

DCCP: Datagram Congestion Control Protocol • Design for time-sensitive applications • Sender controls transmission rate • Different mechanisms for different type of traffic- currently TCP-like and TFRC • Support for ECN, ECN none, partial check sum,… • Features negotiations • Two half-connections

DCCP Packet types • 9 packet types defined • DCCP-Request client server: open connection • DCCP-Response server client: response • DCCP-Data transmit data • DCCP-Ack transmit ack info • DCCP-DataAck DCCP-Data + DCCP-Ack • DCCP-CloseReq server client: close connection • DCCP-Close close connection • DCCP-Reset destroy connection • DCCP-Move move IP address/port

Connection States • 8 states • CLOSED no connection • LISTEN server in passive listening state • REQUEST client beginning 3-way handshake • RESPONSE server responding to request • OPEN data transfer (connection established) • CLOSEREQ server asking client to close • CLOSING client waiting for final reset • TIMEWAIT 2MSL(max segment lifetime) wait(at receiver of reset)

Two half-connections • A Half-connection is data flowing in one direction plus the corresponding acks • DCCP contains 2 half-connections • A B data plus B A acks • B A data plus A B acks • Can also piggyback acks on data (DCCP-DataAck) • Each Half-connection may use different Congestion mechanism • HC-Sender is the endpoint sending data, HC-Receiver is the endpoint sending acks

Packet Formats +----------------------------------------------------------+ | Generic Header | +----------------------------------------------------------+ | Additional Fields (depending on type) | +----------------------------------------------------------+ | Options (optional) | +==================================+ | Application Data Area | +----------------------------------------------------------+

Options Option Length Type Meaning 0 1 Padding 2 1 Slow Receiver 32 3-4 Ignore 33 variable Change 34 variable Prefer 35 variable Confirm 36 variable Init Cookie 37 variable Ack Vector [Nonce 0] 38 variable Ack Vector [Nonce 1] 39 variable Data Dropped 40 6 Timestamp 41 6 – 10 Timestamp Echo 42 variable Identification 44 variable Challenge 45 4 Payload Checksum 46 4-6 Elapsed Time 128-255 variable CCID-specific options

Connection Control IDs (CCIDs) • Each congestion control mechanism supported by DCCP is assigned a CCID; a number from 0-255 • Each half-connection has a CCID feature CCID Meaning 0 Reserved 1 Unspecified Sender-Based Congestion Control 2 TCP-like Congestion Control 3 TFRC Congestion Control

Features • The first data byte of every Change, Confirm option is a feature number Number Meaning 1 Congestion Control (CC) 2 ECN Capable 3 Ack Ratio 4 User Ack Vector 5 Mobility Capable 6 Loss Window 7 Connection nonce 8 Identification Regime 128-255 CCID-Specific Features se Negotiable YYNYYNN Y ?

Feature Negotiation • At the beginning of connection the endpoints must agree on a set of parameters • The CCIDs, CCID-specific settings, Loss Window, Connection Nonces, … • Four DCCP options: Change L, Confirm L, Change R, Confirm R are used to negotiate feature values

Feature Negotiation Examples Example 2 DCCP A DCCP B Change L(Arc Ratio, 3) Confirm R(Arc Ratio, 3) • Agree that Ack Ratio/Server = 3 Example 1 DCCP A DCCP B Change R(CCID, 2 3 1) Confirm L(CCID,3, 3 2 1) • Client A: “2 3 1” is client’s preference list • Server B: 3 is the negotiate val; 3 2 1” is server preference list • Agree that CCID/Server = 3

Connection example

Connection example (Cont.)

Sequence Numbers • Per-packet sequence number • Increase by 1 on every packet sent including pure acks • DCCP checks packet’s Sequence and Acknowledgement Numbers for validity • Defense against delivery of old segments • Defense against half-open connections • Defense against attack • Sequence and Acknowledgement Window • Used for validity check

Sequence and Acknowledgement Window • HC-Sender decides on a Ws (Sequence Window width) for sequence numbers • HC-Receiver decides on a WA (Ack Window width) for ack numbers

Acknowledgements • Ack number is GSR (Greatest Sequence Number) • Different from TCP – cumulative ack meaningless in an reliable protocol • Different CCIDs requires differents acknowledgement formats • Generic ack option: Ack Vector-used to determine exactly which packets have been received • TFRC ack options: Receive rate, Loss Event Rate, Loss Intervals • Acknowledgements must be reliable- retransmit until received

Acks of Acks • Acknowledgement information represents state- Ack vector • Receiver must free the state once the sender receive ack • Sender must send ack to receiver’s ack State Meaning 0 Received 1 Received ECN marked 2 Reserved 3 Not Yet Received DCCP Ack vector

Acknowledgements Congestion Control • Per-packet seq # allow acknowledgement to be congestion controlled • CCID determines when HC-receiver can send acks • Ack ratio feature • Send one ack per R packets • R default is 2 • Higher ack ratios correspond to lower DCCP-Ack rates • Sender raises Ack-Ratio when the reverse path is congested and lowers Ack-Ratio when it is not

Mobility • Endpoint moves, send DCCP-Move to other from new address • DCCP-Move contains old address so flow can be identified • Stationary endpoint acknowledges with a DCCP-[Data]Ack • Attacker can guess seq number and might move a DCCP-connection to its own address • DCCP-Move security • Need security mechanism (Identification)- DCCP-Move packets carry valid id options (MD5 hash of two shared secret) • Ignore invalid sequence numbers, identification • Do not send ack or reset – lead to leak info • May ignore all moves for sometimes after receiving invalid move to prevent DoS attacks

CCID2-TCP-like Congestion Control • TCP-like congestion control • Utilize available bandwidth • Abrupt AIMD rate changes (like TCP) • Congestion control algorithm based on SACK TCP • Three variables: cwnd, ssthresh, pipe • RTT estimation • Acknowledgement use Ack-Vector • Acknowledge Congestion Control • Ack-Ratio manipulation

CCID2’s variables • cwnd (congestion window)- Maximum number of data packets allowed in a network • ssthresh (slow-start threshold)- control adjustment to cwnd • Pipe • Sender’s estimate of number of outstanding data packets in the network • May send data if pipe < cwnd • Increase pipe by 1 on every newly sent data packet

Pipe reduction • HC-Sender reduces pipe as it infers data packets have left the network • Reduce pipe by 1 for every packet newly acked as Ack-vector state 0 or state 1 • Reduce pipe by 1 for each packet infers as lost due to the DCCP equivalent of TCP’s “duplicate acks” • Packet P infers lost when at least NUMDUPACK (= 3) packets has been acked as Ack-vector state 0 or state 1 • NUMDUPACK packets need not be data packet specifically, can also be Ack packets or other none data packets • Transmit timeout • Handle like TCP’s retransmit timeout • Use TCP’s Estimate RTT • When timeout, set pipe to 0

CWND manipulation • Congestion events half cwnd, set ssthresh = new cwnd • One or more packets lost or marked from a window of data • Timeout events set ssthresh = ½ cwnd then set cwnd = 1 • Congestion window increases • when cwnd < ssthresh increases cwnd by 1 for every newly acked data packet • Else, increase by 1 for every window of data acked without lost or marked packets

Acknowledgements • Sender uses Ack-Ratio feature to influence the sending rate at which DCCP is generated • Receiver send one ack per R data packets received • Enable reverse path congestion control • For each cwnd of data with at least one lost or marked ack, double R (Ack Ratio) • For each cwnd/(R^2 – R) consecutive cwnds of data with no loss or marked DCCP-Ack packets, R is decrease by 1

Determining Quiescence • Definition: State at which one end point stops sending data packets for some amount of time (ie 2RTTs) • HC-Receiver detects that HC-Sender is quiescence when max(0.2sec, 2RTT) have passed without receiving data • When other CCID is quiescence, HC-Sender sends about one ack per cwnd

Explicit Congestion Notification • The sender use the ECN nonce for data packets and the receiver will echo those nonce in its Ack vectors • For unmarked data packets,The receiver computes the ECN Nonce Echo and returns it as part of its Ack vectors • The Sender should check the ECN nonce Echoes against unexpected values • protecting against the accidental or malicious concealment of marked packets

TFRC-CCID3 • TCP-friendly, but avoids abrupt rate changes • TFRC congestion control algorithms • Equation-based congestion control • Receiver calculates loss event rate, sender adjusts accordingly • Acknowledgements need not use Ack Vector

Overview of CCID3 • HC-Sender sends data packets at most at the rate specified by the throughput equation • Rate-based congestion control • Data packets include Window Counter (helps receiver distinguish packets sent in different RTTs); sent in Ccval in the header • HC-Sender updates rate based on the loss event rate specified on ack packets from the receiver or it can calculate that rate itself from Ack Vector or Loss Interval

Loss events • A Loss Interval: • Begins with a lost or marked packet • Continues for one RTT’s worth of packets (lost, marked, or not) • Concludes with an arbitrary-length tail of none-lost, non-marked packets • The Loss Event Rate: The inverse of a weighted average of the last 8 Loss Interval lengths

Acknowledgements • Elapsed Time and/or Timestamp Echo options • Aid RTT estimation • Feedback packets sent once per RTT, elapsed time may be large • Receive Rate option- Determine how fast the receiver has been receiving data • One or more options describing the loss event rate • Loss Event Rate: list rate explicitly • Loss Interval: the beginning and end of each loss interval • Ack Vector: Sender can calculate loss intervals

Loss Event Rate option 11000000 00000110 Loss Event Rate Type=192 Len=6 Used by Receiver for calculation of loss event rate

Loss Intervals option 11000001 Length Loss Interval More Loss Interval … Type=193 9 bytes • Receiver reports its observed loss intervals using loss interval options • Can report Up to 28 loss intervals • Currently TRRC lists the last 9 loss interval lengths • Sender can calculate Loss Rate • Sender can verify ECN Nonce Echo

Differences from TCP • Packet Stream, not byte stream protocol • Unreliability-never retransmit a datagram • Options are retransmitted to make feature and acknowledgement reliable • Packet sequence numbers • Feature negotiation • Choice of congestion control • No receive window-not a flow control protocol

Differences from TCP (cont.) • Different acknowledgement format, The CCID determine how much ack info is to be transmitted • CCID2: one ack per 2 packets, each ack must declare exactly which packets it receives (Ack vector option) • CCID3: one ack per RTT and acks must declare at minimum just the length of recent loss interval • Distinguish different kinds of loss: Data drop option declare a data packet is dropped because of received buffer flow or corruption

Datagram Congestion Control Protocol (DCCP)