1 / 42

Datagram Congestion Control Protocol (DCCP)

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. Motivation Connections Unreliable datagram transfer Modular congestion control

scottbraun
Télécharger la présentation

Datagram Congestion Control Protocol (DCCP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Overview • Motivation • Connections • Unreliable datagram transfer • Modular congestion control • Miscellaneous issues

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

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

  5. Streaming Media Over TCP Server Client D12 A12 D13 D14 - D16 A12 Data is not useful now Retransmit D13 D: data TCP-PDU A: ack TCP-PDU

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

  7. IP B2 IP B1 IP A1 IP B3 IP A2 IP network Streaming Media with SCTP • Multi-streams over a single association • Uses TCP-like congestion control • Retransmission • Partial Reliability: require at least 1 RTT

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

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

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

  11. DCCP Connection Initiation Client Server CLOSED CLOSED LISTEN DCCP Request REQUEST RESPOND DCCP Response PARTOPEN DCCP Ack OPEN

  12. DCCP Data Transfer Phase Client Server DCCP A DCCP B OPEN PARTOPEN DCCP Data OPEN DCCP Ack DCCP Data DCCP DataAck …

  13. DCCP Connection Termination Client Server Client Server OPEN OPEN OPEN OPEN DCCP Close DCCP CloseReq CLOSING CLOSEREQ DCCP Reset CLOSED CLOSING DCCP Close TIMEWAIT DCCP Reset CLOSED CLOSED Wait 2 MSL TIMEWAIT Wait 2 MSL CLOSED

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

  15. DCCP Data Transfer Example 2. non-large burst of loss DCCP A DCCP B • 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 • Due to receiver buffer overflow or corruption -- endpoint loss • Data dropped option Data(seq #1) Ack(seq # 10, ack #1) Data(seq # 2) Data(seq # 3) Ack(seq # 11, ack # 3) Data(seq # 4) Ack(seq # 12, ack # 4)

  16. Sequence Validity Check • Both endpoints keep expected seq#/ack# -- in sync • 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/SyncAck PDU to recover • Sequence number variables • Maintained at each endpoint for each connection • GSR – Greatest Seq# Received • GSS – Greatest Seq# Sent • Sequence validity windows • Window width W: Seq Win feature • Expected seq# [SWL, SWH], SWH=GSR+3W/4 • Expected ack# [AWL, AWH], AWH=GSS • Seq#/ack# out of range – seq invalid PDU, ignore and send Sync PDU exp seq# window exp ack# window W/4 3W/4 W GSR GSS

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

  18. DCCP Data Transfer Example 4. slight reordering DCCP A DCCP B Exp ack# Exp seq# Data (seq #20) [13, 20] GSS=20 [19, 26] GSR=20 Ack (seq #60, ack #20) Data (seq #21) [14, 21] GSS=21 Data (seq #22) [15, 22] GSS=22 [21, 28] GSR=22 Ack (seq #61, ack #22) seq# 21 within range, Ack.ack# = GSR Data may be delivered out-of-order Ack (seq #62, ack #22) Data (seq #23) [16, 23] GSS=23 Ack (seq #63, ack #23) GSR=23 [22, 29] • GSR – Greatest Sequence number Received • GSS – Greatest Sequence number Sent • Window Size = 8

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

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

  21. DCCP PDU Types Connection Initialization Data Transfer Connection Termination Resynchronization

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

  23. DCCP Generic Header 0 8 16 24 X =1

  24. DCCP Generic Header: short 0 8 16 24 X =0

  25. Acknowledgement Sub-Header 0 8 16 24 X =1 X =0

  26. DCCP Checksum 0 4 31 • Header Checksum Coverage (CsCov): 4 bits • CsCov = 0: covers the DCCP header (generic, additional), DCCP options, network-layer pseudoheader, and all application data in the packet (possibly some padding) • CsCov = 1-15: covers the DCCP header, DCCP options, network-layer pseudoheader, and the initial (CsCov-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 • Corrupted data could be delivered, impact on congestion control • Improve delivery rate and perceived performance • Data checksum option provides strong CRC checksum for all application data

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

  28. CCID 2: TCP-like Congestion Control • Congestion control like TCP [RFC4341] • 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: • 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/(R2-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.

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

  30. CCID 3: TCP Friendly Rate Control [RFC 4342] • 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

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

  32. Congestion related options • Slow receiver option • 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 • indicates that a packet was dropped due to corruption, receiver buffer overflow, application requirement, or other non congestion reasons.

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

  34. F/X Notation Feature location for all F/B Feature location for all F/A B A Feature Remote for all F/B Feature Remote for all F/A

  35. Feature Negotiation • General-purpose reliable negotiating • Almost always during the connection initiation handshake, but it can begin at any time • Each happens in a single option exchange • Multiple values, preference order

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

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

  38. DCCP: Miscellaneous issues • Maximum Packet Size (MPS) • 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 • Prevents SYN-flooding-like DDoS attacks – init cookie • Prevents Sequence Number Attack • Large Sequence Number • Sequence and Acknowledgement Number Windows

  39. DCCP: Summary • Transport layer protocol • Unreliable datagrams • Modular congestion control • Negotiable features

  40. Implementation • Linux Kernel Version 2.6.14 • Preliminary FreeBSD implementation • tcpdump 3.9.4 and later includes DCCP support

  41. References • 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/

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

More Related