Designing DCCP: Congestion Control Without Reliability

Paper Review: Designing DCCP: Congestion Control Without Reliability

The paper proposes the Datagram Congestion Control Protocol (DCCP), a
novel congestion-controlled unreliable transport protocol. This is
motivated by the increase in applications, such as streaming media and
telephony, which utilize the UDP protocol. Application developers are
reluctant to implement their own congestion control as it is too
complex, but are willing to be subjected to it.

The paper begins by surveying the range of applications that use a
connectionless protocol, such as telephony, streaming media,
interactive games and examine the requirements of each. Based on
these requirements, the paper presents the following primary goals for
DCCP:

- Minimal in both functionality and mechanism
- Robust in the face of attackers, NATs and firewalls
- Support various application types and provide framework for development
- Must be self-sufficient by providing simple API without application
intervention
- Support applications requiring fine-grained control

Also, the designers decided to omit flow control, selective
reliability, streams and multicast.

The DCCP protocol begins with a three-way handshake similar to TCP.
DCCP makes use of sequence numbers; however, the numbers refer to
datagrams rather than bytes. A new sequence number is used for every
packet. Synchronization packets are used to handle the case where a
large amount of packet loss results in unexpected sequence numbers.
Acknowledgements are similar to TCP except that acknowledgments
themselves require acknowledgment from time to time. These acks of
acks can be piggybacked in data packets for two-way communications.
Also, acknowledgments do not guarantee delivery of data to the
application. 48-bit sequence numbers are used in their scheme, but
senders may optionally choose a 24-bit scheme to reduce overhead for
time-sensitive applications. DCCP is more robust to sequence number
attacks than TCP.

To avoid DOS attacks filling up memory on a server with half-open
connections, DCCP is designed so that state information is primarily
maintained on the client-side. DCCP allows the application to choose
between two types of congestion control, TCP-like and TFRC. The
TCP-like mode differs in that it also employs reverse-path congestion
control. It is achieved by continually changing the frequency of
acknowledgments the sender requires. The TFRC mode is a rate-based
mode rather than window-based. Acknowledgments are thus required once
per RTT and the rate is adjusted accordingly at the same frequency.
Several measures are included for misbehaving senders and receivers.

The paper brings up an interesting point when it is stated that
designing a congestion control mechanism is complex since Internet
router behaviour is not fully understood. Furthermore, it is
difficult to decouple reliability and congestion control which are
tightly intertwined in TCP. This paper overall is well-written and
presents some interesting ideas. They attempt to design an unreliable
version of TCP. Some of the ideas seem unnatural and perhaps they
should be building from scratch rather than building a ?TCP-lite?.
The key thing to take from this paper is that congestion control is
necessary for all Internet traffic, rather than just TCP. They do a
commendable job of presenting a new protocol which seems to have some
merits.

-- Nadeem Abji
Received on Tue Oct 10 2006 - 02:30:49 EDT