12.01.06
Review of “Designing DCCP: Congestion Control Without Reliability
Streaming media applications such as real-time video and telephony continue to grow and become a large component of Internet traffic. Since such applications favor low delay over reliable transmission they often opt for the unreliable transport protocol UDP. However, UDP lacks built-in congestion control mechanisms leaving applications on their own to implement congestion control, if at all. The other alternative to UDP is TCP which provides congestion control along with reliable transmission. However, applications tend to avoid TCP because delivery guarantees can delay packets to the point that they are unusable to the application and better off dropped. Without proper congestion control, high-bandwidth streaming applications will create havoc on the Internet.
The authors tackle this problem through the creation of a transport protocol that provides congestion control without reliability. The resulting Datagram Congestion Congestion Protocol (DCCP) provides a flexible framework for unreliable congestion control that can implement various congestion control mechanisms. The paper outlines the design process that went into developing this protocol because, as it turned out, it was not as easy as originally anticipated.
As the authors point out, the natural way to approach this problem would be to start with TCP which already provides congestion control and simply strip out the reliability mechanisms. However, TCP does not lend well to removing reliability because of the strong semantics provided by TCP’s sequence numbers. Also, in the time since TCP was created, we have come to recognize that there are some important features such as protection against attack that TCP lacks.
The authors go on to describe the individual design decisions made in the process. Foremost to the design are minimalism, robustness, and flexibility to be a framework for modern congestion control. I believe the real key to their design that will make it popular for implementation is the idea of creating a framework instead of a static protocol. The idea behind the framework is to provide the basic messaging and control structure for unreliable congestion control but allow for different congestion control mechanism to be dropped into the framework. This is a big departure from what we see in TCP which provides a single, saw-tooth like congestion control mechanism. Though TCP’s mechanism worked well for its designed purpose of large file transfers that take whatever bandwidth is available, it is tough on streaming applications that prefer a smoother rate curve. The extensibility of DCCP will allow new congestion control mechanisms to be implemented in the existing protocol as they are demanded by applications.
Deciding what features to leave out of a protocol is just as important as deciding what to include. As so, the authors make a strong case for the elements that are left out of the protocol. Again, one of the driving forces in these decisions was to allow for flexibility and ease in upgrading. I agree with the decisions made here. We’ve seen that once these middle-of-the-stack protocols such as IP, UDP, and TCP are adopted, they are exceedingly difficult to change. Allowing for so much flexibility will allow DCCP to evolve and grow along with the uses for unreliable transmission.
The resulting DCCP protocol described uses sequences numbers that correspond to packets not bytes as in TCP. In DCCP all packets are sequenced with a unique sequences number including pure acknowledgments. Since a sequence number does not necessarily reflect specific data sent and data is never resent, cumulative acknowledgments do not make sense in DCCP. Instead, DCCP makes use of an acknowledgment vector that acknowledges all packets received so a sender knows which packets were not delivered. With the same thoroughness, the authors also describe other essential features of the protocol including connection setup, synchronization, and robustness against attack.
Partly for comparison reasons and partly for evaluation purposes, the authors describe two unreliable congestion control mechanisms for DCCP that are similar to previous protocols. The first is TCP-like and the second is more like TCP Friendly Rate Control (TFRC). Brief simulation results are given for the different congestion control mechanisms discussed; however, little attempt is made to truly prove that DCCP performs well in real environments. I would have like to have seen more on how DCCP interacts when used along side other congestion control protocols.
All-in-all, this paper presents a well thought out and well designed unreliable, congestion control protocol. Because of this careful process combined with the fact that DCCP is already an IETF draft standard, I foresee DCCP becoming a major transport protocol on the Internet. It is now only a matter of convincing end users that the change is welcome.