Datagram Congestion Control

Protocol (DCCP)

CISC 856 - TCP/IP and Upper Layer Protocols

Presented by
Ke Li ([email protected])
2007/12/4

Thanks to Prof Amer, Kireeti Valicherla, and Xiaofeng Han

Overview

 Motivation

 Connections

 Unreliable datagram transfer

 Modular congestion control

 Miscellaneous issues

2
DCCP: Which Layer?

DCCP SCTP

3
Adapted from Figure 2-11 TCP/IP Protocol Suite, Behrouz A. Forouzan
Streaming Media

•What streaming media needs?

Source: http://streaming.wisconsin.edu/Accessible_Tutorials/Tutorial1/p1-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

D12

A12

D13

D14 - D16

A12

Data is not
Retransmit D13 useful now

D: data TCP-PDU
5
A: ack TCP-PDU
Streaming Media Over UDP
Server Client

No congestion
control in UDP
flows

Harmful to Internet
health

6
Streaming Media with SCTP

IP B2 IP B1
IP A1
IP B3
IP A2

IP network
 Multi-streams over a single association
 Uses TCP-like congestion control
 Retransmission
 Partial Reliability: require at least 1 RTT
7
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
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

9
DCCP connections
DCCP A DCCP B
 Full-duplex bi-directional connection
 Two logical half connections Data
 A-to-B half connection:
 Application data sent from A to B Ack

 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
DCCP Connection Initiation

Client Server

CLOSED
CLOSED
DCCP R LISTEN
REQUEST
equest

esp o nse RESPOND

R
DCCP
PARTOPEN DCCP A
ck
OPEN

11
DCCP Data Transfer Phase
Client Server

DCCP A DCCP B
PARTOPEN OPEN

P Data
DCC

OPEN DCCP
Ack

P Data
DCC
DCCP
DataA
ck
…

12
 DCCP Connection Termination
Client Server Client Server

OPEN OPEN OPEN

DCC
eq P Clos OPEN
l o seR CLOSEREQ
CLOSING e
C
CP
DC e t
P Res CLOSED
CLOSING
DCC
P DCC
Clos
e
TIMEWAIT
et
P Res CLOSED
DCC

CLOSED
TIMEWAIT Wait 2
MSL

CLOSED Wait 2
MSL

13
DCCP Data Transfer Example
1. without loss
DCCP A DCCP B

Data(seq #1)
 Seq # on DCCP-PDU, not byte
10, ack #
1 )  Each PDU carries a Seq #
Ac k (s eq #
 Seq # increases per PDU
Data(seq
# 2)  detect loss – congestion control

 network duplicate – ignored

2 )
c k (s eq # 11, ack #  Pure acks also consume Seq #
A
 possible to detect ack loss

 No cum ack – ack # is the Greatest

Seq # Received (GSR) normally

14
DCCP Data Transfer Example
2. non-large burst of loss
DCCP A DCCP B

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

15
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

W/4 3W/4 W

16
GSR GSS
DCCP Data Transfer Example
3. large burst of loss
DCCP A DCCP B
Exp ack# Exp seq#
Data(seq #20
[13, 20] GSS=20 )

Data(seq
[14, 21] GSS=21 #21)
…
Data(seq #30 Sync.ack# =
[23, 30] GSS=30 ) out-of-sync
seq# recvd
Data(seq #
31)
[24, 31] GSS=31

[25, 32] GSS=32

If Sync is If valid ack#:

ackable, update GSR,
SyncAck.ack# = back to sync
Sync.seq#
 GSR – Greatest Sequence number Received
 GSS – Greatest Sequence number Sent 17

 Window Size = 8
DCCP Data Transfer Example
4. slight reordering
DCCP A DCCP B
Exp ack# Exp seq#
Data (seq #20
[13, 20] GSS=20 )

Data (seq
[14, 21] GSS=21 #21)

Data (seq #2
[15, 22] GSS=22 2)

Data may be
delivered
Data (seq out-of-order
#23)
[16, 23] GSS=23

 GSR – Greatest Sequence number Received

 GSS – Greatest Sequence number Sent 18

 Window Size = 8
DCCP Data Transfer Example
5. medium reordering
DCCP A DCCP B
Exp ack# Exp seq#
Data (seq
#18)

Data (seq #2
[15, 22] GSS=22 2)

[16, 23] GSS=23

If Sync is If valid ack#:

ackable, update GSR,
SyncAck.ack# = back to sync
Sync.seq#

 GSR – Greatest Sequence number Received

 GSS – Greatest Sequence number Sent 19

 Window Size = 8
6. significant reordering (or blind
attack)
DCCP A DCCP B
Exp ack# Exp seq#
Data (seq
#10)

Data (seq #2
[15, 22] GSS=22 2)

Data (seq
#23)
[16, 23] GSS=23

 GSR – Greatest Sequence number Received

 GSS – Greatest Sequence number Sent 20

 Window Size = 8
DCCP PDU Types
DCCP-Request
Connection
DCCP-Response Initialization
DCCP-Ack
Data
DCCP-Data Transfer
DCCP-DataAck
DCCP-CloseReq
Connection
DCCP-Close Termination
DCCP-Reset
DCCP-Sync, DCCP-SyncAck Resynchronization

21
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 22
DCCP Generic Header

0 8 16 24
Source Port Destination Port

Data Offset CCVal CsCov Checksum

(4bit)
Res Type 1 Reserved Sequence Number (high bits)
(4bit)
Sequence Number (low bits)

X =1

23
DCCP Generic Header: short

0 8 16 24
Source Port Destination Port

Data Offset CCVal CsCov Checksum

Res Type 0 Sequence Number

X =0

24
Acknowledgement Sub-Header
0 8 16 24
Reserved Acknowledgement Number
(high bits)

Acknowledgement Number (low bits)

X =1

Reserved Acknowledgement Number(low bits) X =0

25
DCCP Checksum
0 4 31
CsCov 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

26
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

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

28
CCID 2: TCP-like Congestion Control
[RFC4341]

cwnd(initial) ssthresh
 Applications using this:
Loss
 Respond quickly to changes in available bandwidth

 Must tolerate abrupt rate changes -- sawtooth

Online interactive games prefer this kind of congestion control

29
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

30
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

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

32
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

33
F/X Notation

Feature
location
Feature for all
location B F/B
A
for all
F/A Change L (Local)
Change R (Remote)
Confirm L (Local)
Confirm R (Remote)
Feature
Remote Feature
for all Remote
F/B for all
F/A
34
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)

35
Feature Negotiation Example 1
Client
Server
CCID/Server
agreed as 2 Change R (CCID, 2)

Confirm L (CCID, 2)

CCID/Server Change L (CCID, 3 4)

agreed as 4
Confirm R (CCID, 4, 4 2)

36
 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

37
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

38
DCCP: Summary

 Transport layer protocol

 Unreliable datagrams

 Modular congestion control

 Negotiable features

39
Implementation
 Linux Kernel Version 2.6.14
 Preliminary FreeBSD implementation
 tcpdump 3.9.4 and later includes DCCP
support

40
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/

41
Questions and Comments ?
Thank you!

Have a nice holiday!

42