Datagram Congestion Control Protocol (DCCP)
CISC 856 - TCP/IP and Upper Layer Protocols
Presented byKe Li ([email protected])
2007/12/4
Thanks to Prof Amer, Kireeti Valicherla, and Xiaofeng Han
2
Overview
Motivation
Connections
Unreliable datagram transfer
Modular congestion control
Miscellaneous issues
3Adapted from Figure 2-11 TCP/IP Protocol Suite, Behrouz A. Forouzan
DCCP: Which Layer?
SCTPDCCP
4
Streaming Media
Source: http://streaming.wisconsin.edu/Accessible_Tutorials/Tutorial1/p1-3.htm•What streaming media needs?
•Timeliness of data
•What streaming media doesn’t need?
•Retransmissions of lost/expired packets •Annoying “rebuffering…” – HOL blocking
5
D12
D13
A12
A12
D14 - D16
Retransmit D13Data is not useful now
Server Client
Streaming Media Over TCP
D: data TCP-PDUA: ack TCP-PDU
6
Streaming Media Over UDP
No congestion control in UDP
flows
Harmful to Internet health
Server Client
7
Streaming Media with SCTP
Multi-streams over a single association Uses TCP-like congestion control Retransmission Partial Reliability: require at least 1 RTT
IP network
IP A2
IP B2 IP B1
IP B3IP A1
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
8
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 controlor
= TCP – bytestream semantics – full reliability
DCCP connections
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
10
Data
Ack
DCCP A DCCP B
11
DCCP Response
DCCP Request
DCCP Ack
Client Server
DCCP Connection Initiation
CLOSED
LISTENREQUEST
PARTOPEN
RESPOND
CLOSED
OPEN
12
DCCP Data Transfer Phase
DCCP Data
DCCP Ack
DCCP DataAck
DCCP Data
OPEN
OPEN
DCCP A DCCP B
PARTOPEN
…
Client Server
13
DCCP Connection Termination
DCCP Close
DCCP Reset
Client Server
DCCP CloseReq
Wait 2 MSL
DCCP Close
DCCP Reset
Client Server
Wait 2 MSL
TIMEWAIT
CLOSED
TIMEWAIT
CLOSED
CLOSED
CLOSED
CLOSEREQ
CLOSING
CLOSING
OPENOPEN
OPEN
OPEN
14
DCCP Data Transfer Example 1. without loss
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)
Data(seq # 2)
Ack(seq # 11, ack # 2)
Ack(seq # 10, ack #1)
DCCP A DCCP B
15
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)
Data(seq # 2)
Ack(seq # 11, ack # 3)
Ack(seq # 10, ack #1)
DCCP Data Transfer Example 2. non-large burst of loss
Data(seq # 3)
Data(seq # 4)
Ack(seq # 12, ack # 4)
DCCP A DCCP B
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
16GSR
W/4 3W/4 W
GSS
17
DCCP Data Transfer Example 3. large burst of loss
Data(seq #20)
Data(seq #31)
Sync.ack# = out-of-sync seq# recvd
DCCP A DCCP B
Data(seq #21)
Data(seq #30)
…
[13, 20]
GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8
Exp ack#
GSS=20
Exp seq#
[14, 21] GSS=21
[23, 30] GSS=30
[24, 31] GSS=31
[25, 32] GSS=32
If Sync is ackable,
SyncAck.ack# = Sync.seq#
If valid ack#: update GSR, back to sync
18
DCCP Data Transfer Example 4. slight reordering
Data (seq #20)
Data (seq #23)
DCCP A DCCP B
Data (seq #21)
Data (seq #22)
[13, 20]
GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8
Exp ack#
GSS=20
Exp seq#
[14, 21] GSS=21
[15, 22] GSS=22
[16, 23] GSS=23
Data may be delivered
out-of-order
19
DCCP Data Transfer Example 5. medium reordering
DCCP A DCCP B
Data (seq #18)
Data (seq #22)
GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8
Exp ack# Exp seq#
[15, 22] GSS=22
…
[16, 23] GSS=23
If Sync is ackable,
SyncAck.ack# = Sync.seq#
If valid ack#: update GSR, back to sync
20
DCCP Data Transfer Example 6. significant reordering (or blind attack)
Data (seq #23)
DCCP A DCCP B
Data (seq #10)
Data (seq #22)
GSR – Greatest Sequence number Received GSS – Greatest Sequence number Sent Window Size = 8
Exp ack# Exp seq#
[15, 22] GSS=22
[16, 23] GSS=23
…
21
DCCP PDU Types
DCCP-Request
DCCP-Response
DCCP-Ack
DCCP-Data
DCCP-DataAck
DCCP-CloseReq
DCCP-Close
DCCP-Reset
DCCP-Sync, DCCP-SyncAck
Connection Initialization
Data Transfer
Connection Termination
Resynchronization
22
DCCP PDU Formats
Generic Header
Additional Fields (depending on type)
Options (optional )
Application Data Area
• 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
Source Port Destination Port
Data Offset CCVal CsCov (4bit)
Checksum
Res Type (4bit)
1 Reserved Sequence Number (high bits)
Sequence Number (low bits)
0 8 16 24
X =1
24
DCCP Generic Header: short
Source Port Destination Port
Data Offset CCVal CsCov Checksum
Res Type 0 Sequence Number
0 8 16 24
X =0
25
Acknowledgement Sub-Header
Reserved Acknowledgement Number (high bits)
Acknowledgement Number (low bits)
Reserved Acknowledgement Number(low bits)
X =1
X =0
0 8 16 24
26
DCCP Checksum
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
CsCov Checksum
0 4 31
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
Online interactive games prefer this kind of congestion control
cwnd
Loss
(initial) ssthresh
30
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 [RFC 4342]
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
A B
Feature location for all F/A
Feature location for all F/B
Feature Remote for all F/B
Feature Remote for all F/A
Change L (Local)
Change R (Remote)
Confirm L (Local)
Confirm R (Remote)
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
Type Length Feature # Value(s)
36
Feature Negotiation Example 1
Change R (CCID, 2)
Confirm L (CCID, 2)
Change L (CCID, 3 4)
Confirm R (CCID, 4, 4 2)
CCID/Server agreed as 2
CCID/Server agreed as 4
Client Server
37
Feature Negotiation Example 2
Change L(CCID, 3 2)
CCID/Client agreed as 3
Change L(CCID, 3 2)
Change L(CCID, 3 2)
Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2)
Client Server
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
Implementation
Linux Kernel Version 2.6.14 Preliminary FreeBSD implementation tcpdump 3.9.4 and later includes DCCP
support
40
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!
Top Related