180 likes | 193 Views
Designing DCCP: Congestion Control Without Reliability. By Eddie Kohler, Mark Handley and Sally Floyd. Greg Kempe. Overview. The need for Congestion Control Protocol requirements and features Security and mobility The state of the art: implementations References and discussion.
E N D
Designing DCCP: Congestion ControlWithout Reliability By Eddie Kohler, Mark Handley and Sally Floyd Greg Kempe
Overview • The need for Congestion Control • Protocol requirements and features • Security and mobility • The state of the art: implementations • References and discussion
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
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
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
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
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)
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
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
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
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
“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
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
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
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
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?
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)
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/