Master’s Project Presentation Datagram Congestion Control Protocol (DCCP) using TCP like congestion control By: Deval Mehta Instructor: Dr. Chang -E- Wang

Why DCCP? A steady growth of applications that generate long-lived flows of UDP datagrams Internet telephony, streaming video and on-line games TCP can introduce arbitrary delay because of its reliability and in-order delivery requirements Thus, these applications use non-congestion-controlled UDP instead This lack of congestion control poses a threat to the network New transport protocol that combines unreliable datagram delivery with built-in congestion control is needed

Features : An unreliable flow of datagrams, with acknowledgements. A reliable handshake for connection setup and teardown. Reliable negotiation of options, including negotiation of a suitable congestion control mechanism. Mechanisms allowing a server to avoid holding any state for unacknowledged connection attempts or already-finished connections. (Low Overhead) Optional mechanisms to indicate sent/received packets and whether those packets are ECN (Explicit Congestion Notification) marked, corrupted or dropped in the receive buffer.

Difference b/w TCP like and TFRC type congestion control Halves the congestion window in response to a packet drop or mark, as in TCP. A form of equation-based congestion control, minimizes abrupt changes in the sending rate while maintaining longer-term fairness with TCP.

Anatomy of a DCCP Connection Each DCCP connection runs between two endpoints, DCCP A and DCCP B. Data may pass over the connection in either or both directions. The DCCP connection between DCCP A and DCCP B consists of four sets of packets, as follows: Data packets from DCCP A to DCCP B. Acknowledgements from DCCP B to DCCP A. Data packets from DCCP B to DCCP A. Acknowledgements from DCCP A to DCCP B.

Packet format Generic packet header - CCval : sending CCID information - Data offset : padding - #NDP : Number of Non-Data Packets - CSLen : checksum length - Checksum

Packet types 16 types are possible (4bit) Currently 9 types are used DCCP-Request DCCP-Response DCCP-Data DCCP-Ack DCCP-DataAck : piggybacking DCCP-CloseReq DCCP-Close DCCP-Reset DCCP-move : for mobility, multihoming

DCCP Connection …….. Client Server DCCP- Request with ports and features negotiation including CCID DCCP- Response with agreement of feature and options DCCP-Ack for DCCP-Response OR DCCP-DataAck to piggyback the Data DCCP-CloseReq by server requesting close DCCP-Close by client Acknowledging the close DCCP-Reset with Reason field set to Closed to clear the state…..

Congestion Control………. Server continues sending DCCP-Data packets as controlled by the congestion window. Server examines the Ack vector to learn about marked or dropped data packets…. Adjusts its congestion window accordingly… Dose not send retransmit dropped packets.

Connection breakdown Two half-connections Data from A to B plus acks from B to A Data from B to A plus acks from A to B Ack piggybacking: a single packet relevant to both half-connections

Acknowledgements DataAck acks the largest received sequence number, Not the most recent sequence number Ack Vector option: Provides detailed loss information Which packets were received? ECN marked?

CCID2 : TCP like DCCP’s TCP-like congestion control framework differs from that of TCP Sender’s congestion window is still used But, it can not use a cumulative acknowledgement field to control this If packets are lost, the sender halves it’s sending rate appropriately DCCP can detect reverse-path congestion using per-packet sequence numbers, and respond to it appropriate

CCID 2 congestion control overview: Variables cwnd = congestion window Maximum number of data packets allowed in the network ssthresh = slow-start threshold Controls adjustments to cwnd pipe Sender's estimate of number of outstanding data packets MAY send data packets 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 each data packet newly acked Reduce pipe by 1 for each data packet inferred as lost “Retransmit" timeouts, in case a whole window lost Estimate RTT as TCP Set RTO as TCP (but minimum RTO not necessary) When RTO occurs, set pipe to 0

cwnd manipulation Congestion events halve cwnd, set ssthresh = new cwnd One or more packets lost or marked from a window of data Marked = Code 1; lost = inferred through Ack Vector Congestion window increases When cwnd < ssthresh, increase cwnd by 1 for every newly acknowledged data packet, up to some max Otherwise, increase by 1 for every window of data acknowledged without lost or marked packets

Sending acknowledgements Send about one ack per R data packets received R is the Ack Ratio Reasons to send more acks Delayed ack timer as TCP Ack piggybacking doesn't count towards R

Congestion control on acknowledgements For each cwnd of data with at least one lost or marked ack, double R (Ack Ratio) For each (cwnd/(R^2 - R)), cwnds of data with no lost or marked acks, decrease R by one

Example of DCCP connection A -> B 0: Request, Ask(CCID 2) B -> A 100: Response[0], Answer(CCID 2), Ask(CCID 0) A -> B 1: DataAck[100], Answer(CCID 0) B -> A 101: Data, [media data] B -> A 102: Data, [media data] A -> B 2: DataAck[102], Ack Vector(√102 √101)

Example of DCCP connection B -> A 103: Data, [media data] B -> A 104: Data, [media data] * LOST * B -> A 105: Data, [media data] B -> A 106: DataAck[2], [media data] A -> B 3: DataAck[103], Ack Vector(√103 √102 √101) A ->B 4: DataAck[106], Ack Vector(√106 √105 X104 √103)

Example of DCCP connection B à A 107: DataAck[4], [media data] B à A 108: Data, [media data] A à B 5: DataAck[108], Ack Vector(√108 √107) . . . B à A 200: CloseReq[80] A à B 81: Close[200] B à A 201: Reset[81]

Checksums Based on UDP-lite Purposes Suggestion To support applications that can deal with corrupt data Avoid congestion response to corruption Suggestion Complete checksum : CSLen = 1, DCCP packets + IP header Partial checksum : CSLen=0, DCCP/IP header, but not payload

Summary DCCP provides solution to unreliable dataflow without congestion control.. New datagram standards for applications which require in time delivery of data packets with congestion control… Provides option to congestion control…