Problem Statement for the Datagram Congestion Control Protocol (DCCP)
RFC 4336
Document | Type | RFC - Informational (March 2006; No errata) | |
---|---|---|---|
Authors | Eddie Kohler , Mark Handley , Sally Floyd | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4336 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | (None) |
Network Working Group S. Floyd Request for Comments: 4336 ICIR Category: Informational M. Handley UCL E. Kohler UCLA March 2006 Problem Statement for the Datagram Congestion Control Protocol (DCCP) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games. Floyd, et al. Informational [Page 1] RFC 4336 Problem Statement for DCCP March 2006 Table of Contents 1. Introduction ....................................................2 2. Problem Space ...................................................3 2.1. Congestion Control for Unreliable Transfer .................4 2.2. Overhead ...................................................6 2.3. Firewall Traversal .........................................6 2.4. Parameter Negotiation ......................................7 3. Solution Space for Congestion Control of Unreliable Flows .......7 3.1. Providing Congestion Control Above UDP .....................8 3.1.1. The Burden on the Application Designer ..............8 3.1.2. Difficulties with ECN ...............................8 3.1.3. The Evasion of Congestion Control ..................10 3.2. Providing Congestion Control Below UDP ....................10 3.2.1. Case 1: Congestion Feedback at the Application .....11 3.2.2. Case 2: Congestion Feedback at a Layer Below UDP ...11 3.3. Providing Congestion Control at the Transport Layer .......12 3.3.1. Modifying TCP? .....................................12 3.3.2. Unreliable Variants of SCTP? .......................13 3.3.3. Modifying RTP? .....................................14 3.3.4. Designing a New Transport Protocol .................14 4. Selling Congestion Control to Reluctant Applications ...........15 5. Additional Design Considerations ...............................15 6. Transport Requirements of Request/Response Applications ........16 7. Summary of Recommendations .....................................17 8. Security Considerations ........................................18 9. Acknowledgements ...............................................18 Informative References ............................................19 1. Introduction Historically, the great majority of Internet unicast traffic has used congestion-controlled TCP, with UDP making up most of the remainder. UDP has mainly been used for short, request-response transfers, like DNS and SNMP, that wish to avoid TCP's three-way handshake, retransmission, and/or stateful connections. UDP also avoids TCP's built-in end-to-end congestion control, and UDP applications tended not to implement their own congestion control. However, since UDP traffic volume was small relative to congestion-controlled TCP flows, the network didn't collapse. Recent years have seen the growth of applications that use UDP in a different way. These applications, including streaming audio, Internet telephony, and multiplayer and massively multiplayer on-line games, share a preference for timeliness over reliability. TCP can introduce arbitrary delay because of its reliability and in-order delivery requirements; thus, the applications use UDP instead. This growth of long-lived non-congestion-controlled traffic, relative to Floyd, et al. Informational [Page 2] RFC 4336 Problem Statement for DCCP March 2006 congestion-controlled traffic, poses a real threat to the overall health of the Internet [RFC2914, RFC3714]. Applications could implement their own congestion control mechanisms on a case-by-case basis, with encouragement from the IETF. Some already do this. However, experience shows that congestion control is difficult to get right, and many application writers would like to avoid reinventing this particular wheel. We believe that a newShow full document text