Datagram Congestion Control Protocol DCCP CISC 856 TCPIP

Datagram Congestion Control Protocol (DCCP) CISC 856 - TCP/IP and Upper Layer Protocols Presented by Ke Li (kli@cis. udel. edu) 2007/12/4 Thanks to Prof Amer, Kireeti Valicherla, and Xiaofeng Han

Overview l Motivation l Connections l Unreliable datagram transfer l Modular congestion control l Miscellaneous issues

DCCP: Which Layer? DCCP SCTP Adapted from Figure 2 -11 TCP/IP Protocol Suite, Behrouz A. Forouzan 3

Streaming Media • What streaming media needs? Source: http: //streaming. wisconsin. edu/Accessible_Tutorials/Tutorial 1/p 1 -3. htm • Timeliness of data • What streaming media doesn’t need? • Retransmissions of lost/expired packets • Annoying “rebuffering…” – HOL blocking 4

Streaming Media Over TCP Server Client D 12 A 12 D 13 D 14 - D 16 A 12 Data is not useful now Retransmit D 13 D: data TCP-PDU A: ack TCP-PDU

Streaming Media Over UDP Server No congestion control in UDP flows Harmful to Internet health Client

Streaming Media with SCTP IP B 2 IP A 1 IP B 3 IP A 2 IP network l l Multi-streams over a single association Uses TCP-like congestion control Retransmission Partial Reliability: require at least 1 RTT

Other target applications l Internet Telephony l l l Constant-packet-rate sources Change data rate by adjusting packet size Extremely sensitive to delay Demands a slower congestion response Interactive games l l Can quickly make use of available bandwidth Prefers TCP-like sawtooth congestion response

Solution: DCCP l l provides unreliable flow of datagrams provides congestion control using l l does not provide l l Acknowledgment Sequence number Connection oriented Full reliability: no-loss & no-error & in-order & no-duplicate flow control streaming DCCP = UDP + congestion control or = TCP – bytestream semantics – full reliability

DCCP connections l Full-duplex bi-directional connection l l Two logical half connections A-to-B half connection: l Application data sent from A to B l Corresponding acks from B to A DCCP B Data Ack In practice overlapped: Data. Ack Each half connection can have independent features negotiated during connection initiation, e. g. , different congestion control mechanism

DCCP Connection Initiation Client Server CLOSED REQUEST DCCP R LISTEN equest se pon s e R CP RESPOND DC PARTOPEN DCCP A ck OPEN 11

DCCP Data Transfer Phase Client Server DCCP A DCCP B OPEN PARTOPEN Dat P C C D OPEN a DCCP A ck ata PD DCCP Data. A ck … 12

DCCP Connection Termination Client Server OPEN DC CLOSING CP eq se. R Clo OPEN CLOSING P ose C DC OPEN CLOSED TIMEWAIT DCC P Cl et P Cl ose et Res Server es PR DCC CLOSED CLOSEREQ Client Wait 2 MSL 13

DCCP Data Transfer Example 1. without loss DCCP A DCCP B Data(seq #1) # 10, a Ack(seq Data(seq # l ck #1) l 2) ) 1, ack # 2 1 Ack(seq # l l l Seq # on DCCP-PDU, not byte Each PDU carries a Seq # increases per PDU l detect loss – congestion control l network duplicate – ignored Pure acks also consume Seq # l possible to detect ack loss No cum ack – ack # is the Greatest Seq # Received (GSR) normally

DCCP Data Transfer Example 2. non-large burst of loss DCCP A DCCP B Data(seq #1) l k #1) l 2) l 10, ac Ack(seq # Data(seq # l Data(seq # 3) k # 3) 11, ac Ack(seq # Data(seq # 4) ) 2, ack # 4 1 Ack(seq # l Maybe loss: no data retransmissions Separate options indicate PDU loss or ECN info: Ack Vector (SACK-like) Ack of Ack: clear receiver’s state A PDU is ackable – its header has been successfully processed (e. g. , valid header checksum and seq #) Acked PDUs may be dropped -- no guarantee of data delivery l Due to receiver buffer overflow or corruption -- endpoint loss l Data dropped option

Sequence Validity Check l Both endpoints keep expected seq#/ack# -- in sync l l Sequence number variables l l To detect seq# attacks, significant reordering, or one endpoint crash Out of sync after large burst of loss No cum ack, use separate DCCP-Sync/Sync. Ack PDU to recover Maintained at each endpoint for each connection GSR – Greatest Seq# Received GSS – Greatest Seq# Sent Sequence validity windows l l Window width W: Seq Win feature Expected seq# [SWL, SWH], SWH=GSR+3 W/4 Expected ack# [AWL, AWH], AWH=GSS Seq#/ack# out of range – seq invalid PDU, ignore and send Sync PDU exp seq# window W/4 GSR 3 W/4 exp ack# window W GSS

DCCP Data Transfer Example 3. large burst of loss DCCP A Exp ack# [13, 20] GSS=20 [14, 21] GSS=21 [23, 30] [24, 31] GSS=30 GSS=31 DCCP B ) GSS=32 GSR=20 ack #20) , 0 6 # q e Ack(s Data(seq #21) Sync. ack# = out-of-sync seq# recvd Data(seq #30 ) Data(seq # 31) 1) , ack # 3 1 6 # q e (s seq# 31>26, out of range, send Sync. ack#=31 Sync. Ack(seq # 32, ack #61) GSR=32 If Sync is ackable, Sync. Ack. ack# = Sync. seq# [19, 26] … Sync [25, 32] Exp seq# Data(seq #20 [31, 38] If valid ack#: update GSR, back to sync l l l GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8

DCCP Data Transfer Example 4. slight reordering DCCP A Exp ack# [13, 20] GSS=20 [14, 21] GSS=21 [15, 22] GSS=22 DCCP B Exp seq# Data (seq #20 ) ) , ack #20 0 6 # q e s Ack ( Data (seq #21) GSS=23 ) 2) 1, ack #2 Data (seq # l l GSR=22 [21, 28] seq# 21 within range, Ack. ack# = GSR 23) ) , ack #23 #63 Ack (seq l [19, 26] Data (seq #22 #6 Ack (seq ck #22) a , 2 6 # q Ack (se [16, 23] GSR=20 GSR=23 [22, 29] GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8 Data may be delivered outof-order

DCCP Data Transfer Example 5. medium reordering DCCP A DCCP B Exp ack# Data (seq Exp seq# #18) … [15, 22] GSS=22 Data (seq #22 #6 Ack (seq [16, 23] GSS=23 ) 2) 1, ack #2 ck #18) a , 2 6 # q Sync (se Sync. Ack (seq # 23, GSR=22 [21, 28] seq#18<21, out of range, send Sync. ack#=18 ack #62) GSR=23 [22, 29] If Sync is ackable, Sync. Ack. ack# = Sync. seq# If valid ack#: update GSR, back to sync l l l GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8

6. significant reordering (or blind attack) DCCP A DCCP B Exp ack# Data (seq Exp seq# #10) … [15, 22] Data (seq #22 GSS=22 #6 Ack (seq ) 2) 1, ack #2 GSR=22 ) ack#10<15, out of range, nonackable Sync, ignored [16, 23] GSS=23 10 62, ack # # q e s ( nc Sy 23) ) , ack #23 l l seq#10<21, out of range, send Sync. ack#=10 Data (seq # #63 Ack (seq l [21, 28] GSR=23 [22, 29] GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8

DCCP PDU Types DCCP-Request DCCP-Response DCCP-Ack DCCP-Data. Ack DCCP-Close. Req DCCP-Close DCCP-Reset DCCP-Sync, DCCP-Sync. Ack Connection Initialization Data Transfer Connection Termination Resynchronization

DCCP PDU Formats Generic Header Additional Fields (depending on type) Options (optional ) Application Data Area • Generic header: 16 bytes (using 48 bits seq#) or 12 bytes (using short 24 bits seq#) • Additional fields: fixed length field, e. g. ack# (48 b, 24 b) • Options: variable length field up to 1008 bytes, e. g. Init Cookie, Ack Vector, Change, Confirm, Slow Receiver, Data Dropped 22

DCCP Generic Header 0 8 16 Source Port 24 Destination Port Data Offset CCVal Cs. Cov Checksum (4 bit) Res Type (4 bit) 1 Reserved Sequence Number (high bits) Sequence Number (low bits) X =1 23

DCCP Generic Header: short 0 8 Source Port Data Offset Res Type 16 24 Destination Port CCVal Cs. Cov Checksum 0 Sequence Number X =0 24

Acknowledgement Sub-Header 0 8 Reserved 16 24 Acknowledgement Number (high bits) Acknowledgement Number (low bits) Reserved Acknowledgement Number(low bits) X =1 X =0 25

DCCP Checksum 0 4 Cs. Cov l l Cs. Cov = 0: covers the DCCP header (generic, additional), DCCP options, network-layer pseudoheader, and all application data in the packet (possibly some padding) Cs. Cov = 1 -15: covers the DCCP header, DCCP options, network -layer pseudoheader, and the initial (Cs. Cov-1)*4 bytes of the packet's application data. Applications that can tolerate corruption can request header checksum only covers part or no app data at all l Corrupted data could be delivered, impact on congestion control l l Checksum Header Checksum Coverage (Cs. Cov): 4 bits l l 31 Improve delivery rate and perceived performance Data checksum option provides strong CRC checksum for all application data 26

Modular Congestion Control l l Each congestion control mechanism supported by DCCP is assigned a 1 -byte congestion control identifier, or CCID: a number from 0 to 255. l CCID 0 and CCID 1 are reserved l TCP-like congestion control – CCID 2 l TCP friendly rate control (TFRC) – CCID 3 l CCID 4 -255 are reserved CCID is a feature to be negotiated and agreed on both endpoints

CCID 2: TCP-like Congestion Control l Congestion control like TCP [RFC 4341] l l Ack contains Seq# of all received packets within some window Congestion event: packet loss, or ECN -> Halve congestion window Abrupt rate changes Reverse-path (Ack) congestion control: l l Ack Ratio R, integer, [2, cwnd/2] For each congestion window of data where at least one of the corresponding acks was lost or ECN-marked, R is doubled; For each cwnd/(R 2 -R) consecutive congestion window of data whose acks were not lost or ECN-marked, R is decreased by 1; The above formula comes from wanting to increase the number of acks per congestion window, namely cwnd/R, by 1 for every congestion-free window that passes.

CCID 2: TCP-like Congestion Control [RFC 4341] l Applications using this: cwnd (initial) ssthresh Loss l Respond quickly to changes in available bandwidth l Must tolerate abrupt rate changes -- sawtooth Online interactive games prefer this kind of congestion control

CCID 3: TCP Friendly Rate Control [RFC 4342] l l Receiver-based feedback mechanism Equation-based congestion control Minimizes abrupt changes in sending rate Maintains longer-term fairness with TCP Streaming Media prefer steadier and less bursty traffic as provided by TFRC

CCID 3: TCP Friendly Rate Control l The receiver measures the loss event rate and feeds this information back to the sender l The sender uses these feedback messages to measure the round-trip time (RTT) l The loss event rate and RTT are then fed into TFRC's throughput equation, giving the acceptable transmit rate l The sender then adjusts its transmit rate to match the calculated rate

Congestion related options l Slow receiver option l l l Receiver sends this option to its sender to indicate it is having trouble keeping up with the sender’s data Sender shouldn't increase sending rate for about 1 RTT time Data dropped option l indicates that a packet was dropped due to corruption, receiver buffer overflow, application requirement, or other non congestion reasons.

Feature Negotiation Options l DCCP features on what value two endpoints agree l Examples l l l DCCP features are identified by a feature number and an endpoint l l Congestion control identifier (CCID) ECN capable / incapable Ack Ratio Allow Short Seq# Notation “F/X” is used Use Change and Confirm options to negotiate

F/X Notation Feature location for all F/A Feature Remote for all F/B A B Feature location for all F/B Change L (Local) Change R (Remote) Confirm L (Local) Confirm R (Remote) Feature Remote for all F/A 34

Feature Negotiation l General-purpose reliable negotiating l Almost always during the connection initiation handshake, but it can begin at any time l Each happens in a single option exchange l Multiple values, preference order Type Length Feature # Value(s)

Feature Negotiation Example 1 Client CCID/Server agreed as 2 Server Change R (CCID, 2) Confirm L (CCID, 2) CCID/Server agreed as 4 Change L (CCID, 3 4) Confirm R (CCID, 4, 4 2) 36

Feature Negotiation Example 2 Client Server Change L(CCID, 3 2) Confirm R(CCID, 3, 3 2) CCID/Client agreed as 3 37

DCCP: Miscellaneous issues l Maximum Packet Size (MPS) l l l Maintained for each DCCP session Minimum of congestion control MPS (CCMPS) and path MTU Generally, DCCP should NOT fragment data – reduce robustness Applications can usually get better error tolerance by producing packets smaller than the PMTU Security Concerns l l Prevents SYN-flooding-like DDo. S attacks – init cookie Prevents Sequence Number Attack l Large Sequence Number l Sequence and Acknowledgement Number Windows

DCCP: Summary l Transport layer protocol l Unreliable datagrams l Modular congestion control l Negotiable features

Implementation l l l Linux Kernel Version 2. 6. 14 Preliminary Free. BSD implementation tcpdump 3. 9. 4 and later includes DCCP support

References l l Designing DCCP: Congestion Control Without Reliability, by Eddie Kohler, Mark Handley, and Sally Floyd. Proc. ACM SIGCOMM 2006, September 2006. RFC 4340 - Datagram Congestion Control Protocol (DCCP), Eddie Kohler, Mark Handley, and Sally Floyd, March 2006 DCCP Overview, Eddie Kohler and Sally Floyd, July 2003 DCCP link from one of the authors http: //www. read. cs. ucla. edu/dccp/

Questions and Comments ? Thank you! Have a nice holiday!