1. Designing DCCP: Congestion Control Without Reliability
By Eddie Kohler, Mark Handley and Sally Floyd
Greg Kempe

2. Overview The need for Congestion Control
Protocol requirements and features
Security and mobility
The state of the art: implementations
References and discussion

3. The Need for Congestion Control
UDP used instead of TCP by applications that prefer timeliness over reliability
UDP lacks TCP’s congestion control
Especially a problem with long-lived flows and lots of traffic (streaming video, audio, internet telephony)
Greater use increases risk of congestion collapse
CC needed because:
useful to apps
also because UDP becoming more and more used
so need to prevent congestion interfering with health of internet

4. What can be done? Below UDP: too low
Above UDP: implement CC at application level
Lots of work, reinventing the wheel each time
CC is complex, might not be done correctly
New protocol more interoperable than a user-level library
(Alternatives: Congestion Manager)
Modify TCP, UDP, RTP, SCTP
Makes these protocols complex (feature bloat)
Not general enough
Forces a reasonably fundamental change
Also Above UDP:
App has too much control (misbehave to get better bandwidth)
Overhead in swapping to/from kernel
Both above and below don’t fix middle box issues. A new proto could.

5. What can be done? (cont’d)
Add new protocol alongside UDP and TCP
DCCP: Dynamic Congestion Control Protocol
Application
Network (IP)
TCP
UDP
DCCP
Transport

6. DCCP Requirements Designed for time-sensitive applications They need:
Choice of CC mechanism: TFRC vs. TCP-like
Low per-packet overhead
Buffering control: don’t deliver old data
Also nice:
Explicit Congestion Notification (ECN): mark congested packets
NAT and firewall support: TCP-style explicit connection setup and teardown

7. DCCP Requirements (cont’d)
Some features are “good ideas” and can be borrowed from TCP, UDP:
Port numbers, checksums, sequence numbers (with difficulty), acks (congestion and ECN info), piggybacked acks
Three-way handshake to set up, two-way with wait to tear down
New features/concepts:
Negotiate CC mechanism and parameters on setup
Two half-connections (A → B, B → A)
Sequence numbers:
can’t be ported directly from TCP since TCP’s are cumulative
UDP doesn’t have them
Half-connections
Better than two single connections (hard to tie together then, friendlier to firewalls)
CC mechanisms and params established at same time, saves overhead

8. Half connections
Separation is useful, since traffic is typically asymmetric
Different routes implies different congestion issues
Each half connection has own CC mechanism and parameters
Better than two one-way connections
Works better with firewalls and NAT
Can piggyback acks with data

9. Feature Selection Reliable feature selection:
A: change(f, α)
B: confirm(f, α) / prefer(f, β)
[A: confirm(f, β) ]
Selection for both half-connections done in parallel at startup
Generic, extensible

10. Issues with Acknowledgements (ACKs)
Acks must be at least partially reliable
TCP-style cumulative acks won’t work, so must ack everything (ack vector)
But ack state at receiver may grow without bound!
So sender occasionally acks the receiver’s acks
Receiver can throw away state for that ack
Acks take up sequence number space
Useful: can be used to detect reverse-path congestion

11. Packet Structure Basic packet similar to UDP Small (12 bytes)
Extensible for additional features instead of using a fixed-length flag field
CCval: CCID-based information (say, p in TRFC)
CsCov: how much the checksum covers
NDP: non-data packets (ack, req, close etc)
Tack ACK data, mechanism params etc. onto the end using
| Source Port | Dest Port |
| Data Offset | CCVal | CsCov | Checksum |
| Type |X|# NDP| Sequence Number |

12. “Plug ‘n Play” Congestion Control
CC mechanism and parameters (both ways) chosen during connection setup
Currently two mechanisms:
TFRC (control equation)
TCP-like (TCP with tweaked parameters)
Can add more later

13. Partial checksums From UDP-Lite
Checksum covers DCCP header and (optionally) any number of bytes into payload
Allows delivery of slightly damaged data
May be useful on error-prone links (eg. wireless)
Drawbacks:
Might conflict with IP-level authentication (eg. IPSec’s AH)
Still needs to be proven useful
Delivery of damaged data:
some of the mpeg codes we’ve discussed have used this
Error-prone links
wireless
not so useful on wired, more reliable networks
network layer often drops damaged packets in any case

14. When is a packet received?
TCP: acked packets must be delivered to application
DCCP: acked packet might be dropped from application’s queue (apps might favour new data over old)
So ack means received and placed into application queue
Can also use optional dropped from application queue message later

15. Security Assumption: hijacker can’t snoop packets
Start session at random sequence number
Sliding “valid sequence number” window, hijacker can’t throw in random packet
If out-of-window packet received, ask sender if it’s correct and tell them what receiver’s window is
This allows windows to be resynchronised
ECN nonce in packets to prevent misbehaving receiver
DOS attacks
TCP-style init cookies, don’t save state on server
Sequence number window:
since non-reliable, a packet may arrive _really_ late, ie. Out of sequence number window.
could be a hacker guessing sequence number. So check.
Misbehaving receiver:
easier to misbehave to get better bandwidth using DCCP than TCP (unreliable vs reliable)
DOS attacks:
servers usually target of DOS attacks.

16. Mobility Very basic “move endpoint to this IP” support
Ad-hoc, minimal support for something that is very complex
Is it necessary? Is it useful?
Push mobility to application layer?

17. History and state of the art
Initially Datagram Control Protocol (DCP)
July 2001: First Internet Draft
February 2002: DCCP Problem Statement
May 2002: Changed name to DCCP
October 2003: Latest Internet Draft
Implementations circa 2002 and late 2003
FreeBSD (kernel-level)
Linux (kernel-level and user-level)

18. References DCCP Homepage www.icir.org/kohler/dccp/
Internet Drafts, mailing lists, presentations
DCCP implementations
FreeBSD kernel-level implementation (Oct 2003)
University of Luleå, Sweden,
Linux kernel-level implementation (2002)
Linux user-level library (2002)
UC Berkeley,
Congestion Manager