Internet Engineering Task Force                             Eddie Kohler   

INTERNET-DRAFT                                                      UCLA   

                                                             Sally Floyd   

                                                                    ICIR   

              Datagram Congestion Control Protocol (DCCP)                  

Status of this Memo                                                        

    This document is an Internet-Draft and is subject to all provisions    

    of section 3 of RFC 3667.  By submitting this Internet-Draft, each     

    author represents that any applicable patent or other IPR claims of    

    which he or she is aware have been or will be disclosed, and any of    

    which he or she become aware will be disclosed, in accordance with     

    RFC 3668.                                                              

    Internet-Drafts are working documents of the Internet Engineering      

    Task Force (IETF), its areas, and its working groups.  Note that       

    other groups may also distribute working documents as Internet-        

    Drafts.                                                                

    Internet-Drafts are draft documents valid for a maximum of six         

    months and may be updated, replaced, or obsoleted by other documents   

    at any time.  It is inappropriate to use Internet-Drafts as            

    reference material or to cite them other than as "work in progress."   

    The list of current Internet-Drafts can be accessed at                 

    http://www.ietf.org/ietf/1id-abstracts.txt.                            

    The list of Internet-Draft Shadow Directories can be accessed at       

    http://www.ietf.org/shadow.html.                                       

Copyright Notice                                                           

    Copyright (C) The Internet Society (2004). All Rights Reserved.        

Kohler/Handley/Floyd                                            [Page 1]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

Abstract                                                                   

    The Datagram Congestion Control Protocol (DCCP) is a transport         

    protocol that provides bidirectional unicast connections of            

    congestion-controlled unreliable datagrams.  DCCP is suitable for      

    applications that transfer fairly large amounts of data, but can       

    benefit from control over the tradeoff between timeliness and          

    reliability.                                                           

Kohler/Handley/Floyd                                            [Page 2]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:                      

    Changes since draft-ietf-dccp-spec-08.txt:                             

    * Added minimum Sequence Window.                                       

    * Init Cookie implementation sketch.                                   

    * Include reasoning for ignoring options on DCCP-Data.                 

    * More Aggression Penalty explanation.                                 

    * More explanation on Ack Vectors that report information on packets   

    that haven't been sent.                                                

    Changes since draft-ietf-dccp-spec-07.txt:                             

    * Many changes, not listed here, for WGLC.                             

    * The more stringent Sequence Number checks on DCCP-Sync and DCCP-     

    SyncAck packets become SHOULD, not MAY.                                

    Changes since draft-ietf-dccp-spec-06.txt:                             

    * Change extended sequence numbers.  Now 48-bit sequence numbers are   

    MANDATORY, and all packet types except Data, Ack, and DataAck always   

    use 48-bit sequence numbers.  This change improves DCCP's robustness   

    against blind attacks.                                                 

    * Removed empty Change options.                                        

    * Allow preference list changes during feature negotiations (this      

    seems easier to implement than the alternative).  This required a      

    new feature negotiation state, UNSTABLE.                               

    * Add Minimum Checksum Coverage feature.                               

    * Add Reset Congestion State option.                                   

    * Simplify the implementation of CCID-specific option processing: no   

    need to check whether the CCID feature is being negotiated.            

    * Many more minor changes.                                             

    Changes since draft-ietf-dccp-spec-05.txt:                             

    * Organization overhaul.                                               

Kohler/Handley/Floyd                                            [Page 3]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    * Add pseudocode for event processing.                                 

    * Remove # NDP; replace with Ack Count.                                

    * Remove Identification, Challenge, ID Regime, and Connection Nonce.   

    * Data Checksum (formerly Payload Checksum) uses a 32-bit CRC.         

    * Switch location of non-negotiable features to clarify                

    presentation; now the feature location controls its value.             

    * Rename "value type" to "reconciliation rule".                        

    * Rename "Reset Reason" to "Reset Code".                               

    * Mobility ID becomes 128 bits long.                                   

    * Add probabilities to Mobility ID discussion.                         

    * Add SyncAck.                                                         

Kohler/Handley/Floyd                                            [Page 4]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

                             Table of Contents                             

    1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  10   

    2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . .  11   

    3. Conventions and Terminology . . . . . . . . . . . . . . . . .  12   

       3.1. Numbers and Fields . . . . . . . . . . . . . . . . . . .  12   

       3.2. Parts of a Connection. . . . . . . . . . . . . . . . . .  13   

       3.3. Features . . . . . . . . . . . . . . . . . . . . . . . .  13   

       3.4. Round-Trip Times . . . . . . . . . . . . . . . . . . . .  14   

       3.5. Security Limitation. . . . . . . . . . . . . . . . . . .  14   

       3.6. Robustness Principle . . . . . . . . . . . . . . . . . .  14   

    4. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . .  14   

       4.1. Packet Types . . . . . . . . . . . . . . . . . . . . . .  15   

       4.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . .  16   

       4.3. States . . . . . . . . . . . . . . . . . . . . . . . . .  17   

       4.4. Congestion Control . . . . . . . . . . . . . . . . . . .  18   

       4.5. Features . . . . . . . . . . . . . . . . . . . . . . . .  19   

       4.6. Differences From TCP . . . . . . . . . . . . . . . . . .  20   

       4.7. Example Connection . . . . . . . . . . . . . . . . . . .  21   

    5. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . .  23   

       5.1. Generic Header . . . . . . . . . . . . . . . . . . . . .  23   

       5.2. DCCP-Request Packets . . . . . . . . . . . . . . . . . .  27   

       5.3. DCCP-Response Packets. . . . . . . . . . . . . . . . . .  28   

       5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets. . . . . .  28   

       5.5. DCCP-CloseReq and DCCP-Close Packets . . . . . . . . . .  30   

       5.6. DCCP-Reset Packets . . . . . . . . . . . . . . . . . . .  30   

       5.7. DCCP-Sync and DCCP-SyncAck Packets . . . . . . . . . . .  33   

       5.8. Options. . . . . . . . . . . . . . . . . . . . . . . . .  34   

          5.8.1. Padding Option. . . . . . . . . . . . . . . . . . .  36   

          5.8.2. Mandatory Option. . . . . . . . . . . . . . . . . .  36   

    6. Feature Negotiation . . . . . . . . . . . . . . . . . . . . .  37   

       6.1. Change Options . . . . . . . . . . . . . . . . . . . . .  37   

       6.2. Confirm Options. . . . . . . . . . . . . . . . . . . . .  38   

       6.3. Reconciliation Rules . . . . . . . . . . . . . . . . . .  38   

          6.3.2. Non-Negotiable. . . . . . . . . . . . . . . . . . .  39   

       6.4. Feature Numbers. . . . . . . . . . . . . . . . . . . . .  39   

       6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . .  40   

          6.6.1. Normal Exchange . . . . . . . . . . . . . . . . . .  42   

          6.6.9. Mandatory Feature Negotiation . . . . . . . . . . .  48   

Kohler/Handley/Floyd                                            [Page 5]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

       7.4. Acknowledgement Numbers. . . . . . . . . . . . . . . . .  51   

          7.5.1. Sequence and Acknowledgement Number                       

          Windows. . . . . . . . . . . . . . . . . . . . . . . . . .  52   

          7.5.2. Sequence Window Feature . . . . . . . . . . . . . .  53   

       10.3. CCID-Specific Options, Features, and Reset                    

Kohler/Handley/Floyd                                            [Page 6]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

          11.7.1. Data Dropped and Normal Congestion                       

       18.1. Security Considerations for Partial                           

Kohler/Handley/Floyd                                            [Page 7]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

Kohler/Handley/Floyd                                            [Page 8]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

                               List of Tables                              

    Table 1: DCCP Packet Types . . . . . . . . . . . . . . . . . . .  25   

    Table 2: DCCP Reset Codes. . . . . . . . . . . . . . . . . . . .  33   

    Table 3: DCCP Options. . . . . . . . . . . . . . . . . . . . . .  35   

    Table 4: DCCP Feature Numbers. . . . . . . . . . . . . . . . . .  39   

Kohler/Handley/Floyd                                            [Page 9]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

1.  Introduction                                                           

    The Datagram Congestion Control Protocol (DCCP) is a transport         

    protocol that implements bidirectional, unicast connections of         

    congestion-controlled, unreliable datagrams.  Specifically, DCCP       

    provides:                                                              

    o  Unreliable flows of datagrams, with acknowledgements.               

    o  Reliable handshakes for connection setup and teardown.              

    o  Reliable negotiation of options, including negotiation of a         

       suitable congestion control mechanism.                              

    o  Mechanisms allowing servers to avoid holding state for              

       unacknowledged connection attempts and already-finished             

       connections.                                                        

    o  Congestion control incorporating Explicit Congestion Notification   

    o  Acknowledgement mechanisms communicating packet loss and ECN        

       information.  Acks are transmitted as reliably as the relevant      

       congestion control mechanism requires, possibly completely          

       reliably.                                                           

    o  Optional mechanisms that tell the sending application, with high    

       reliability, which data packets reached the receiver, and whether   

       those packets were ECN marked, corrupted, or dropped in the         

       receive buffer.                                                     

    o  A choice of modular congestion control mechanisms.  Two             

       mechanisms are currently specified, TCP-like Congestion Control     

       [CCID 2 PROFILE] and TFRC (TCP-Friendly Rate Control) Congestion    

       Control [CCID 3 PROFILE], but DCCP is easily extensible to          

       further forms of unicast congestion control.                        

    DCCP is intended for applications such as streaming media that can     

    benefit from control over the tradeoffs between delay and reliable     

    in-order delivery.  TCP is not well-suited for these applications,     

    since reliable in-order delivery and congestion control can cause      

    arbitrarily long delays.  UDP avoids long delays, but UDP              

    applications that implement congestion control must do so on their     

    own.  DCCP provides built-in congestion control, including ECN         

    support, for unreliable datagram flows, avoiding the arbitrary         

    delays associated with TCP.  It also implements reliable connection    

Kohler/Handley/Floyd                               Section 1.  [Page 10]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    setup, teardown, and feature negotiation.                              

2.  Design Rationale                                                       

    One DCCP design goal was to give most streaming UDP applications       

    little reason not to switch to DCCP, once it is deployed.  To          

    facilitate this, DCCP was designed to have as little overhead as       

    possible, both in terms of the packet header size and in terms of      

    the state and CPU overhead required at end hosts.  Only the minimal    

    necessary functionality was included in DCCP, leaving other            

    functionality, such as forward error correction (FEC), semi-           

    reliability, and multiple streams, to be layered on top of DCCP as     

    desired.                                                               

    Different forms of conformant congestion control are appropriate for   

    different applications.  For example, on-line games might want to      

    make quick use of any available bandwidth, while streaming media       

    might trade off this responsiveness for a steadier, less bursty        

    rate.  (Sudden rate changes can cause unacceptable UI glitches, such   

    as audible pauses or clicks in the playout stream.)  DCCP thus         

    allows applications to choose from a set of congestion control         

    mechanisms.  One alternative, TCP-like Congestion Control, halves      

    the congestion window in response to a packet drop or mark, as in      

    TCP.  Applications using this congestion control mechanism will        

    respond quickly to changes in available bandwidth, but must tolerate   

    the abrupt changes in congestion window typical of TCP.  A second      

    equation-based congestion control, minimizes abrupt changes in the     

    sending rate while maintaining longer-term fairness with TCP.  Other   

    alternatives can be added as future congestion control mechanisms      

    are standardized.                                                      

    DCCP also lets unreliable traffic safely use ECN.  A UDP kernel API    

    might not allow applications to set UDP packets as ECN-capable,        

    since the API could not guarantee the application would properly       

    detect or respond to congestion.  DCCP kernel APIs will have no such   

    issues, since DCCP implements congestion control itself.               

    We chose not to require the use of the Congestion Manager [RFC         

    3124], which allows multiple concurrent streams between the same       

    sender and receiver to share congestion control.  The current          

    Congestion Manager can only be used by applications that have their    

    own end-to-end feedback about packet losses, but this is not the       

    case for many of the applications currently using UDP.  In addition,   

    the current Congestion Manager does not easily support multiple        

    congestion control mechanisms, or lend itself to the use of forms of   

    TFRC where the state about past packet drops or marks is maintained    

    at the receiver rather than at the sender.  DCCP should be able to     

Kohler/Handley/Floyd                               Section 2.  [Page 11]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    make use of CM where desired by the application, but we do not see     

    any benefit in making the deployment of DCCP contingent on the         

    deployment of CM itself.                                               

    We intend for DCCP's protocol mechanisms, which are described in       

    this document, to suit any application desiring unicast congestion-    

    controlled streams of unreliable datagrams.  The congestion control    

    mechanisms currently approved for use with DCCP, which are described   

    PROFILE], may, however, cause problems for some applications,          

    including high-bandwidth interactive video.  These applications        

    should be able to use DCCP once suitable Congestion Control ID         

    Profiles are standardized.                                             

3.  Conventions and Terminology                                            

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    

3.1.  Numbers and Fields                                                   

    All multi-byte numerical quantities in DCCP, such as port numbers,     

    Sequence Numbers, and arguments to options, are transmitted in         

    network byte order (most significant byte first).                      

    We occasionally refer to the "left" and "right" sides of a bit         

    field.  "Left" means towards the most significant bit, and "right"     

    means towards the least significant bit.                               

    Random numbers in DCCP are used for their security properties, and     

    All operations on DCCP sequence numbers, and comparisons such as       

    "greater" and "greatest", use circular arithmetic modulo 2**48.        

    This form of arithmetic preserves the relationships between sequence   

    numbers as they roll over from 2**48 - 1 to 0.  Note that the common   

    technique for implementing circular comparison using two's-            

    complement arithmetic, whereby A < B using circular arithmetic if      

    and only if (A - B) < 0 using conventional two's-complement            

    Reserved bitfields in DCCP packet headers MUST be set to zero by       

    senders, and MUST be ignored by receivers, unless otherwise            

    specified.  This is to allow for future protocol extensions.  In       

    particular, DCCP processors MUST NOT reset a DCCP connection simply    

    because a Reserved field has non-zero value [RFC 3360].                

Kohler/Handley/Floyd                             Section 3.1.  [Page 12]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

3.2.  Parts of a Connection                                                

    Each DCCP connection runs between two hosts, which we often name       

    DCCP A and DCCP B.  Each connection is actively initiated by one of    

    the hosts, which we call the client; the other, initially passive      

    host is called the server.  The term "DCCP endpoint" is used to        

    refer to either of the two hosts explicitly named by the connection    

    (the client and the server).  The term "DCCP processor" refers more    

    generally to any host that might need to process a DCCP header; this   

    includes the endpoints and any middleboxes on the path, such as        

    firewalls and network address translators.                             

    DCCP connections are bidirectional: data may pass from either          

    endpoint to the other.  This means that data and acknowledgements      

    may be flowing in both directions simultaneously.  Logically,          

    however, a DCCP connection consists of two separate unidirectional     

    connections, called half-connections.  Each half-connection consists   

    of the application data sent by one endpoint and the corresponding     

    acknowledgements sent by the other endpoint.  We can illustrate this   

    as follows:                                                            

     +--------+  A-to-B half-connection:         +--------+                

     |        |    -->  application data  -->    |        |                

     |        |    <--  acknowledgements  <--    |        |                

     | DCCP A |                                  | DCCP B |                

     |        |  B-to-A half-connection:         |        |                

     |        |    <--  application data  <--    |        |                

     +--------+    -->  acknowledgements  -->    +--------+                

    Although they are logically distinct, in practice the half-            

    connections overlap; a DCCP-DataAck packet, for example, contains      

    application data relevant to one half-connection and acknowledgement   

    information relevant to the other.                                     

    In the context of a single half-connection, the terms "HC-Sender"      

    and "HC-Receiver" denote the endpoints sending application data and    

    acknowledgements, respectively.  For example, DCCP A is the HC-        

    Sender and DCCP B is the HC-Receiver in the A-to-B half-connection.    

3.3.  Features                                                             

    A DCCP feature is a connection attribute on whose value the two        

    endpoints agree.  Many properties of a DCCP connection are             

    controlled by features, including the congestion control mechanisms    

    in use on the two half-connections.  The endpoints achieve agreement   

    through the exchange of feature negotiation options in DCCP headers.   

Kohler/Handley/Floyd                             Section 3.3.  [Page 13]   

INTERNET-DRAFT          Expires: 7 September 2005             March 2005   

    DCCP features are identified by a feature number and an endpoint.      

    The notation "F/X" represents the feature with feature number F        

    located at DCCP endpoint X.  Each valid feature number thus            

    corresponds to two features, which are negotiated separately and       

    need not have the same value.  The two endpoints know, and agree on,   

    the value of every valid feature.  DCCP A is the "feature location"    

    for all features F/A, and the "feature remote" for all features F/B.   

3.4.  Round-Trip Times                                                     

    DCCP round-trip time measurements are performed by congestion          

    control mechanisms; different mechanisms may measure round-trip time   

    in different ways, or not measure it at all.  However, the main DCCP   

    protocol does use round-trip times occasionally, such as in the        

    initial values for certain timers.  Each DCCP implementation thus      

    defines a default round-trip time for use when no estimate is          

    available; this parameter should default to not less than              

    0.2 seconds, a reasonably conservative round-trip time for Internet    

    TCP connections.  Protocol behavior specified in terms of "round-      

    trip time" values actually refers to "a current round-trip time        

    estimate taken by some CCID, or, if no estimate is available, the      

    default round-trip time parameter".                                    

    The maximum segment lifetime, or MSL, is the maximum length of time    

    a packet can survive in the network.  The DCCP MSL should equal that   

    of TCP, which is normally two minutes.                                 

3.5.  Security Limitation                                                  

    DCCP provides no protection against attackers who can snoop on a       

    connection in progress, or who can guess valid sequence numbers in     

    other ways.  Applications desiring stronger security should use        

    IPsec [RFC 2401]; depending on the level of security required,         

    application-level cryptography may also suffice.  These issues are     

    discussed further in Sections 18 and 7.5.5.                            

3.6.  Robustness Principle