Problem Statement for the Datagram Congestion Control Protocol (DCCP)
RFC 4336
|
| Document |
Type |
|
RFC - Informational
(March 2006; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4336 (Informational)
|
|
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
Show full document text