12.01.06

Review of “Designing DCCP: Congestion Control Without Reliability”

Posted in Paper reviews, congestion control at 8:00 pm by BrandonHeller

As a network application developer, you have only two realistic choices for your application’s transport layer. You could pick UDP (User Datagram Protocol), which provides unreliable, connectionless data transport, for applications where timeliness is the primary data-delivery concern. You’d be forced to implement congestion control yourself, and one bug could render the network unusable.

Alternately, you could pick TCP (Transport Control Protocol), which provides reliable, connection-oriented data transport plus congestion control. However, TCP’s delay variation and insistence on sending old packets can cause perceptible blips in an audio or video stream.

The authors of “Designing DCCP: Congestion Control Without Reliability” argue that a new protocol is needed to accommodate increasingly popular apps, in a way that protects the network and does not burden the application developer. These apps include Internet telephony, interactive videoconferencing, streaming media, and interactive games. They’re all the kind of long-lived UDP flows for which congestion control is most needed, and if the replacement protocol were sufficiently easy to use, developers would jump on them. Datagram Congestion Control Protocol (DCCP) is one solution. It saves developers from the risk and effort of doing congestion control on a per-application basis. It also has the potential to improve speed; by operating within the OS, DCCP can respond faster to congestion. This review will cover the design of DCCP, evaluate its potential for widespread deployment, and summarize the real contributions.

Design Goals

Designing a new protocol, especially one for network use, requires care. The right interface is crucial. If a protocol doesn’t do enough for developers, they may not use it. If it tries to do too much, slower adoption, security concerns, and speed issues may result. The authors identify the following as design goals:

• minimalism
• robustness
• framework for modern congestion control
• self-sufficiency
• support timing-reliability tradeoffs

Note that some of these goals are in opposition. For example, minimalism conflicts with supporting timing-reliability tradeoffs. Most of the design goals are generic and self-explanatory, but “framework for modern congestion control” should be highlighted. This refers to creating a protocol that supports the congestion control features of today’s TCP, yet has the capability to evolve over time, as new methods of congestion control are developed.

DCCP Protocol Design

DCCP is connection-oriented, uses standard ports, has explicit synchronization, and works on bidirectional data flows. It has no explicit provisions for flow control, selective reliability, streams, or multicast. Much of the design effort is focused on sequence numbers.

Where TCP has byte-oriented sequence numbers and cumulative acks, DCCP has a packet-oriented sequence number and most-recent acks. A major difference here is that every packet, including acks, occupies sequence space in DCCP. Another is how ack numbers represent the most recent packet received, as opposed to the last packet not yet received. Without cumulative acks, it would seem as if much of the ack-carried info would vanish. This missing info is included in the Ack Vector, a TCP SACK relative that enables DCCP to report the specific packets received. Other sequence-number-related features include explicit synchronization and a 48bit sequence number space for added security against brute-force injection and hijacking attacks. Unlike UDP, DCCP has a setup process to negotiate the congestion control mechanism used, thus providing a smooth upgrade mechanism. Also notable about the protocol is the mobility/multihoming support, and resistance to TCP-style SYN floods.

The state machine for the protocol has been formally modeled, a process which revealed potential bugs. This result supports the authors’ argument that leaving congestion control to developers may be asking too much, due to inherent complexity. The fact that formal modeling caught a number of bugs raises confidence in the protocol, but it’s just a first step.

Two congestion control methods have been developed. One is just like TCP, and rapidly changes its rates to take advantage of available bandwidth. Acknowledgements are also congestion-controlled, via the ack ratio parameter, which adjust how many acks go out for every datagram received. The other method is based on TCP-Friendly Rate Control (TFRC), which uses receiver feedback rather than a congestion window. TFRC results in smoother changes in sending rates.

Not all issues have been solved. One issue relates to whether Internet routers drop packets per byte or per packet. There may be no right answer here, because router behavior is underspecified. The answer affects the congestion control method that should be used – with small-packet TFRC, TCP traffic may starve. But maybe that’s OK, for now, because TCP is inherently less real-time than UDP or DCCP traffic.

Critical Evaluation

There are a few signs that DCCP is gaining traction, but it is still an infant niece in the eyes of a TCP uncle. Implementations are available for a wide range of platforms, and the most recent RFC came out last October.

The authors deserve credit for writing an unusual paper, in that it focuses on design decisions and their qualitative impact, rather than purely quantitative effects. We as readers get a sense of why every decision was made, and can always refer to the RFC for more details. This approach, however, leaves out the application performance and resource requirements that are critical components of the sales pitch for the protocol. It brings up a famous Knuth quote – “I have only proven it correct, not tested it”.

At this point, the real success of DCCP may not even be within the developer’s control. Everyone knows about UDP and TCP. Who has heard of the alternatives mentioned in the paper, including SCTP, RTP, RTSP, and UDP-Lite? Of these, I have only heard of SCTP. For real-time applications, UDP plus a custom protocol works well enough, like for Skype. TCP only implemented congestion control back in 1989 when the Internet was “on the verge of collapse” [Ref]. Fair queuing, increasingly being adopted in routers, along with cheap, plentiful bandwidth and greater commercial support, may delay or prevent this from ever happening again.

Consider that UDP traffic is still a small fraction of total Internet traffic, that UDP is generally used for somewhat lower-speed flows (mainly voice), that most users see “good enough” speeds, and that Internet capacity is continually expanding, and the case for DCCP just doesn’t seem so convincing, at least for the next 5 years. Add in the fact that NATs and other middleboxes may drop DCCP packets that they don’t recognize, that applications must be rewritten, however mild those changes are, and that few people have heard of the protocol. It may also have real-world correctness or performance issues that we only discover from a wider-scale implementation.

The case for DCCP would be so much stronger if the authors had demonstrated its viability on one application, and shown some benefit, either in lines of code required or network performance under heavy load. How can you sell a protocol without having an application run on it? Wouldn’t that be the natural thing?

I’m also not convinced that DCCP even should be an Internet draft. Since congestion control can be implemented over UDP, maybe the DCCP developers should have treated it as a layer 4.5 protocol. Then they’re no longer selling the idea to the network world, but instead selling it to application developers. DCCP really can be just a well-tested library of code, with the correctness guarantees of formal modeling maintained. This approach would avoid potentially crippling middlebox issues

The last criticism is one of philosophy. Congestion control treats the symptoms of Internet congestion rather than the cause. Better QoS mechanisms, and especially a more circuit-oriented model with admission control, would remove the need for congestion control for reasonably low-bandwidth flows. Interactive games and voice, which are typically less than 100 kbps, are sufficiently long-lived to amortize the connection-setup overhead. A DCCP developer would correctly argue that QoS requires universal cooperation and unresolved scaling issues, but the benefits make it worth pursuing.

Conclusion

DCCP is a new protocol for applications that prioritize timeliness over reliability, and enables easy, evolvable congestion control for long-lived datagram applications. The authors’ contributions include an example of modular congestion control and a discussion of issues affecting transport-layer protocol design.

Would the Internet be better with applications implementing it? Yes. Will it matter? Maybe. If long-lived unregulated UDP flows become a large portion of Internet traffic, the case for DCCP becomes much stronger. If they don’t, and TCP web, email, and file-sharing traffic continue to dominate the links, then I don’t expect it to succeed. UDP is good enough, and the benefits of DCCP don’t smack you in the face. Instead, they casually approach and ask for your help with improving a situation that may or may not exist five years from now.

Good luck, DCCP. We wish you the best on your journey.

Permalink