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 TCPs 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
What can be done? (contd)

• 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 dont 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 (contd)

• 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, a)
• B confirm(f, a) / 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 wont work, so must ack
  everything (ack vector)
• But ack state at receiver may grow without bound!
• So sender occasionally acks the receivers 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.
  IPSecs 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
  applications 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 cant snoop packets
• Start session at random sequence number
• Sliding valid sequence number window, hijacker
  cant throw in random packet
• If out-of-window packet received, ask sender if
  its correct and tell them what receivers window
  is
• This allows windows to be resynchronised
• ECN nonce in packets to prevent misbehaving
  receiver
• DOS attacks
• TCP-style init cookies, dont 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/
• DCCP implementations
• FreeBSD kernel-level implementation (Oct 2003)
• University of Luleå, Sweden, www.dccp.org
• Linux kernel-level implementation (2002)
• http//www.ducksong.com81/dccp/
• Linux user-level library (2002)
• UC Berkeley, www.cs.berkeley.edu/laik/projects/dc
  cp/
• Congestion Manager
• http//nms.lcs.mit.edu/projects/cm/