Designing DCCP: Congestion Control Without Reliability

1. Designing DCCP: Congestion ControlWithout 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

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

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

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)

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 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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

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

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 • Internet Drafts, mailing lists, presentations • www.icir.org/kohler/dccp/ • DCCPimplementations • FreeBSD kernel-level implementation (Oct 2003) • University of Luleå, Sweden, www.dccp.org • Linux kernel-level implementation (2002) • http://www.ducksong.com:81/dccp/ • Linux user-level library (2002) • UC Berkeley, www.cs.berkeley.edu/~laik/projects/dccp/ • Congestion Manager • http://nms.lcs.mit.edu/projects/cm/