Problem Statement for the Datagram Congestion Control Protocol (DCCP)
RFC 4336

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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 new