12.01.06
Review of “Designing DCCP: Congestion Control Without Reliability”
This paper summarizes the design of Datagram Congestion Control Protocol (DCCP). DCCP is a congestion control protocol to be used with unreliable transfer protocols such as UDP. There are many applications such as streaming media or video conferencing that prefer timely data instead of reliable data. If these applications had the choice of either retransmitting a lost packet or transmitting a new packet, they would choose to transmit the new packet. By the time the old packet would arrive, it would be outdated and useless. In these cases, TCP is a poor choice because of its extra effort given to reliability.
The problem being there are not too many more choices. If the reliability of TCP is unwanted, the next easiest choice would be UDP. UDP does not have congestion control though. Without many options for a simple transport protocol with congestion control of unreliable datagrams, the authors set out to design their own. Their simple sounding task turned out to be not as easy as they had hoped.
The authors decided to design the protocol around Internet telephony, streaming media, and interactive games. First, they identified what each of the applications would need. From there they arrived at their primary goals: minimalism, robustness, a framework for modern congestion control, self-sufficiency, and support of timing/reliability tradeoffs. Basically they wanted to develop a simple protocol. They did this by picking out what mechanisms would provide the greatest benefit and implementing those. They did not want to implement anything that could be layered above it by the application. Any modern protocol need to be robust, so that was a must. They also wanted it to support the features of modern TCP congestion control without aid from the application, thus being self-sufficient.
With deciding on what to include in their protocol, they also decided what to deliberately leave out. This included flow control, selective reliability, streams, and multicast. Flow control is too non-trivial to include in a simple protocol. They decided not to implement selective reliability meaning when to retransmit an old packet verses transmitting a new one. They decided not to implement streams or multicast since they were both non-trivial for implementation.
DCCP is a connection-oriented protocol with many of its header fields and options representing those of TCP. DCCP must keep reliability out of the protocol while implementing TCP-like congestion control. It needs many of the TCP header fields and options to accomplish this. The authors now have a new respect for all the subtle aspects of TCP.
The paper goes on to mention specifics of the design: explicit synchronization, acknowledgements, and modular congestion control; how they differ from TCP while keeping much of the same capabilities. DCCP uses explicit synchronization. Basically, an endpoint that receives an unexpected sequence number or ACK will send out a Sync packet. The Sync will be processed and is replied to with a SyncAck. Once this is validated, with an ackno, it updates the sequence number. This is needed because DCCP does not support retransmissions, so the way TCP would deal with a network failure cannot be applied.
Acknowledgements also violate the unreliability semantics. The acknowledgments in DCCP never guarantee the packet will be delivered to the application. Instead DCCP’s acknowledgments report that a packet was received, processed, validated, and the data enqueued. The author’s implemented another option that indicated when an acknowledged packet was not delivered.
DCCP also supports modular congestion control. This deals with the proper response to non-congestion losses. TCP regards a lost packet as congestion when really it could be something like a lossy wireless link. DCCP plans on dealing with this issue, but protocols for this are new and most likely one protocol will not be optimal for every application. This is why modular congestion control is needed. They let the application pick which congestion control protocol best suits it.
This overview of DCCP really shows the detail needed to develop a new protocol. At first glance, this may seem easy, but when you get to implementation you realize how much effort it takes. The authors at first took the evolution of TCP for granted, but then came to appreciate the details of the protocol. They found that much of TCP’s congestion control was tied in with its reliability. This was the biggest challenge; taking TCP’s congestion control mechanism and applying them to an unreliable protocol.
DCCP provides optimism for network researcher. There are many researchers who spend hours of work on ideas to improve today’s Internet. There also can be much frustration because of the lack of deployment of these ideas. DCCP is currently an IETF Proposed Standard, which helps alleviate some of this frustration. This does not necessarily mean that this protocol will achieve widespread deployment, but they are one step closer.