Internet Engineering Task Force                             Eddie Kohler   
INTERNET-DRAFT                                                      UCLA   
draft-ietf-dccp-spec-13.txt                                 Mark Handley 
draft-ietf-dccp-spec-12.txt                                 Mark Handley
Expires: 1 June 2006                                                 UCL 
Expires: 28 May 2006                                                 UCL
                                                             Sally Floyd   
                                                                    ICIR   
                                                         1 December 2005 
                                                        28 November 2005
                                                                           
                                                                           
              Datagram Congestion Control Protocol (DCCP)                  
                                                                           
                                                                           
Status of this Memo                                                        
                                                                           
    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 becomes     
    aware will be disclosed, in accordance with Section 6 of BCP 79.       
                                                                           
    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.                                       
                                                                           
    This Internet-Draft will expire on 1 June 2006.                      
    This Internet-Draft will expire on 28 May 2006.                   
                                                                           
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 1]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 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 2]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 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 3]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
                             Table of Contents                             
                                                                           
    1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   9   
    2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . .  10   
    3. Conventions and Terminology . . . . . . . . . . . . . . . . .  11   
       3.1. Numbers and Fields . . . . . . . . . . . . . . . . . . .  11   
       3.2. Parts of a Connection. . . . . . . . . . . . . . . . . .  12   
       3.3. Features . . . . . . . . . . . . . . . . . . . . . . . .  12   
       3.4. Round-Trip Times . . . . . . . . . . . . . . . . . . . .  13   
       3.5. Security Limitation. . . . . . . . . . . . . . . . . . .  13   
       3.6. Robustness Principle . . . . . . . . . . . . . . . . . .  13   
    4. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . .  14   
       4.1. Packet Types . . . . . . . . . . . . . . . . . . . . . .  14   
       4.2. Packet Sequencing. . . . . . . . . . . . . . . . . . . .  15   
       4.3. States . . . . . . . . . . . . . . . . . . . . . . . . .  16   
       4.4. Congestion Control Mechanisms. . . . . . . . . . . . . .  18   
       4.5. Connection Features. . . . . . . . . . . . . . . . . . .  19   
       4.6. Differences From TCP . . . . . . . . . . . . . . . . . .  20   
       4.7. Example Connection . . . . . . . . . . . . . . . . . . .  21   
    5. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . .  22   
       5.1. Generic Header . . . . . . . . . . . . . . . . . . . . .  23   
       5.2. DCCP-Request Packets . . . . . . . . . . . . . . . . . .  26   
       5.3. DCCP-Response Packets. . . . . . . . . . . . . . . . . .  27   
       5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets. . . . . .  28   
       5.5. DCCP-CloseReq and DCCP-Close Packets . . . . . . . . . .  29   
       5.6. DCCP-Reset Packets . . . . . . . . . . . . . . . . . . .  30   
       5.7. DCCP-Sync and DCCP-SyncAck Packets . . . . . . . . . . .  33   
       5.8. Options. . . . . . . . . . . . . . . . . . . . . . . . .  34   
          5.8.1. Padding Option. . . . . . . . . . . . . . . . . . .  35   
          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.1. Server-Priority . . . . . . . . . . . . . . . . . .  38   
          6.3.2. Non-Negotiable. . . . . . . . . . . . . . . . . . .  39   
       6.4. Feature Numbers. . . . . . . . . . . . . . . . . . . . .  39   
       6.5. Feature Negotiation Examples . . . . . . . . . . . . . .  40   
       6.6. Option Exchange. . . . . . . . . . . . . . . . . . . . .  41   
          6.6.1. Normal Exchange . . . . . . . . . . . . . . . . . .  42   
          6.6.2. Processing Received Options . . . . . . . . . . . .  42   
          6.6.3. Loss and Retransmission . . . . . . . . . . . . . .  44   
          6.6.4. Reordering. . . . . . . . . . . . . . . . . . . . .  45   
          6.6.5. Preference Changes. . . . . . . . . . . . . . . . .  46   
          6.6.6. Simultaneous Negotiation. . . . . . . . . . . . . .  46   
          6.6.7. Unknown Features. . . . . . . . . . . . . . . . . .  46   
          6.6.8. Invalid Options . . . . . . . . . . . . . . . . . .  47   
          6.6.9. Mandatory Feature Negotiation . . . . . . . . . . .  48   
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                                            [Page 4]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
    7. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . .  48   
       7.1. Variables. . . . . . . . . . . . . . . . . . . . . . . .  49   
       7.2. Initial Sequence Numbers . . . . . . . . . . . . . . . .  49   
       7.3. Quiet Time . . . . . . . . . . . . . . . . . . . . . . .  50   
       7.4. Acknowledgement Numbers. . . . . . . . . . . . . . . . .  51   
       7.5. Validity and Synchronization . . . . . . . . . . . . . .  51   
          7.5.1. Sequence and Acknowledgement Number                       
          Windows. . . . . . . . . . . . . . . . . . . . . . . . . .  52   
          7.5.2. Sequence Window Feature . . . . . . . . . . . . . .  53   
          7.5.3. Sequence-Validity Rules . . . . . . . . . . . . . .  53   
          7.5.4. Handling Sequence-Invalid Packets . . . . . . . . .  55   
          7.5.5. Sequence Number Attacks . . . . . . . . . . . . . .  56   
          7.5.6. Sequence Number Handling Examples . . . . . . . . .  58   
       7.6. Short Sequence Numbers . . . . . . . . . . . . . . . . .  58   
          7.6.1. Allow Short Sequence Numbers Feature. . . . . . . .  59   
          7.6.2. When to Avoid Short Sequence Numbers. . . . . . . .  60   
       7.7. NDP Count and Detecting Application Loss . . . . . . . .  60   
          7.7.1. NDP Count Usage Notes . . . . . . . . . . . . . . .  61   
          7.7.2. Send NDP Count Feature. . . . . . . . . . . . . . .  61   
    8. Event Processing. . . . . . . . . . . . . . . . . . . . . . .  62   
       8.1. Connection Establishment . . . . . . . . . . . . . . . .  62   
          8.1.1. Client Request. . . . . . . . . . . . . . . . . . .  62   
          8.1.2. Service Codes . . . . . . . . . . . . . . . . . . .  63   
          8.1.3. Server Response . . . . . . . . . . . . . . . . . .  65   
          8.1.4. Init Cookie Option. . . . . . . . . . . . . . . . .  66   
          8.1.5. Handshake Completion. . . . . . . . . . . . . . . .  67   
       8.2. Data Transfer. . . . . . . . . . . . . . . . . . . . . .  67   
       8.3. Termination. . . . . . . . . . . . . . . . . . . . . . .  68   
          8.3.1. Abnormal Termination. . . . . . . . . . . . . . . .  70   
       8.4. DCCP State Diagram . . . . . . . . . . . . . . . . . . .  70   
       8.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . .  71   
    9. Checksums . . . . . . . . . . . . . . . . . . . . . . . . . .  75   
       9.1. Header Checksum Field. . . . . . . . . . . . . . . . . .  76   
       9.2. Header Checksum Coverage Field . . . . . . . . . . . . .  77   
          9.2.1. Minimum Checksum Coverage Feature . . . . . . . . .  78   
       9.3. Data Checksum Option . . . . . . . . . . . . . . . . . .  78   
          9.3.1. Check Data Checksum Feature . . . . . . . . . . . .  79   
          9.3.2. Checksum Usage Notes. . . . . . . . . . . . . . . .  79   
    10. Congestion Control . . . . . . . . . . . . . . . . . . . . .  80   
       10.1. TCP-like Congestion Control . . . . . . . . . . . . . .  81   
       10.2. TFRC Congestion Control . . . . . . . . . . . . . . . .  81   
       10.3. CCID-Specific Options, Features, and Reset                    
       Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . .  81   
       10.4. CCID Profile Requirements . . . . . . . . . . . . . . .  84   
       10.5. Congestion State. . . . . . . . . . . . . . . . . . . .  84   
    11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  85   
       11.1. Acks of Acks and Unidirectional Connections . . . . . .  86   
       11.2. Ack Piggybacking. . . . . . . . . . . . . . . . . . . .  87   
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                                            [Page 5]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
       11.3. Ack Ratio Feature . . . . . . . . . . . . . . . . . . .  87   
       11.4. Ack Vector Options. . . . . . . . . . . . . . . . . . .  89   
          11.4.1. Ack Vector Consistency . . . . . . . . . . . . . .  91   
          11.4.2. Ack Vector Coverage. . . . . . . . . . . . . . . .  93   
       11.5. Send Ack Vector Feature . . . . . . . . . . . . . . . .  94   
       11.6. Slow Receiver Option. . . . . . . . . . . . . . . . . .  94   
       11.7. Data Dropped Option . . . . . . . . . . . . . . . . . .  95   
          11.7.1. Data Dropped and Normal Congestion                       
          Response . . . . . . . . . . . . . . . . . . . . . . . . .  98   
          11.7.2. Particular Drop Codes. . . . . . . . . . . . . . .  98   
    12. Explicit Congestion Notification . . . . . . . . . . . . . .  99   
       12.1. ECN Incapable Feature . . . . . . . . . . . . . . . . . 100   
       12.2. ECN Nonces. . . . . . . . . . . . . . . . . . . . . . . 100   
       12.3. Aggression Penalties. . . . . . . . . . . . . . . . . . 101   
    13. Timing Options . . . . . . . . . . . . . . . . . . . . . . . 102   
       13.1. Timestamp Option. . . . . . . . . . . . . . . . . . . . 102   
       13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . . 103   
       13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 104   
    14. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 105   
       14.1. Measuring PMTU. . . . . . . . . . . . . . . . . . . . . 105   
       14.2. Sender Behavior . . . . . . . . . . . . . . . . . . . . 107   
    15. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 108   
    16. Middlebox Considerations . . . . . . . . . . . . . . . . . . 108   
    17. Relations to Other Specifications. . . . . . . . . . . . . . 110   
       17.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 110   
       17.2. Congestion Manager and Multiplexing . . . . . . . . . . 111   
    18. Security Considerations. . . . . . . . . . . . . . . . . . . 111   
       18.1. Security Considerations for Partial                           
       Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 112   
    19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 113   
       19.1. Packet Types Registry . . . . . . . . . . . . . . . . . 113   
       19.2. Reset Codes Registry. . . . . . . . . . . . . . . . . . 113 
       19.2. Reset Codes Registry. . . . . . . . . . . . . . . . . . 114
       19.3. Option Types Registry . . . . . . . . . . . . . . . . . 114   
       19.4. Feature Numbers Registry. . . . . . . . . . . . . . . . 114   
       19.5. Congestion Control Identifiers Registry . . . . . . . . 114 
       19.5. Congestion Control Identifiers Registry . . . . . . . . 115
       19.6. Ack Vector States Registry. . . . . . . . . . . . . . . 115   
       19.7. Drop Codes Registry . . . . . . . . . . . . . . . . . . 115   
       19.8. Service Codes Registry. . . . . . . . . . . . . . . . . 115   
       19.9. Port Numbers Registry . . . . . . . . . . . . . . . . . 116   
    20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 
    20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
    A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 118   
       A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 120   
          A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 120 
          A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 121
          A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 121 
          A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 122
       A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 122   
       A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 123   
       A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 124   
    B. Appendix: Partial Checksumming Design Motivation. . . . . . . 125   
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                                            [Page 6]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
    Normative References . . . . . . . . . . . . . . . . . . . . . . 126 
    Normative References . . . . . . . . . . . . . . . . . . . . . . 127
    Informative References . . . . . . . . . . . . . . . . . . . . . 127   
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129   
    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 129 
    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 130
    Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 130   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                                            [Page 7]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
                               List of Tables                              
                                                                           
    Table 1: DCCP Packet Types . . . . . . . . . . . . . . . . . . .  25   
    Table 2: DCCP Reset Codes. . . . . . . . . . . . . . . . . . . .  32   
    Table 3: DCCP Options. . . . . . . . . . . . . . . . . . . . . .  34   
    Table 4: DCCP Feature Numbers. . . . . . . . . . . . . . . . . .  39   
    Table 5: DCCP Congestion Control Identifiers . . . . . . . . . .  80   
    Table 6: DCCP Ack Vector States. . . . . . . . . . . . . . . . .  90   
    Table 7: DCCP Drop Codes . . . . . . . . . . . . . . . . . . . .  96   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                                            [Page 8]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 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   
       (ECN) [RFC 3168] and the ECN Nonce [RFC 3540].                      
                                                                           
    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  Path Maximum Transmission Unit (PMTU) discovery [RFC 1191].         
                                                                           
    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 9]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 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      
    alternative, TCP-Friendly Rate Control (TFRC) [RFC 3448], a form of    
    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 10]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 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   
    in separate Congestion Control ID Profiles [CCID 2 PROFILE, CCID 3     
    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",    
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   
    document are to be interpreted as described in RFC 2119.               
                                                                           
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     
    SHOULD be chosen according to the guidelines in RFC 1750.              
                                                                           
    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.  Implementation         
    strategies for DCCP sequence numbers will resemble those for other     
    circular arithmetic spaces, including TCP's sequence numbers [RFC      
    793] and DNS's serial numbers [RFC 1982].  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            
    arithmetic, may be used for DCCP sequence numbers, provided they are   
    stored in the most significant 48 bits of 64-bit integers.             
                                                                           
    Reserved bitfields in DCCP packet headers MUST be set to zero by       
    senders, and MUST be ignored by receivers, unless otherwise            
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                             Section 3.1.  [Page 11]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
    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].                
                                                                           
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    
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                             Section 3.3.  [Page 12]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
    in use on the two half-connections.  The endpoints achieve agreement   
    through the exchange of feature negotiation options in DCCP headers.   
                                                                           
    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                                                 
                                                                           
    DCCP implementations will follow TCP's "general principle of           
    robustness": "be conservative in what you do, be liberal in what you   
    accept from others" [RFC 793].                                         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                             Section 3.6.  [Page 13]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
4.  Overview                                                               
                                                                           
    DCCP's high-level connection dynamics echo those of TCP.               
    Connections progress through three phases: initiation, including a     
    three-way handshake; data transfer; and termination.  Data can flow    
    both ways over the connection.  An acknowledgement framework lets      
    senders discover how much data has been lost, and thus avoid           
    unfairly congesting the network.  Of course, DCCP provides             
    unreliable datagram semantics, not TCP's reliable bytestream           
    semantics.  The application must package its data into explicit        
    frames, and must retransmit its own data as necessary.  It may be      
    useful to think of DCCP as TCP minus bytestream semantics and          
    reliability, or as UDP plus congestion control, handshakes, and        
    acknowledgements.                                                      
                                                                           
4.1.  Packet Types                                                         
                                                                           
    Ten packet types implement DCCP's protocol functions.  For example,    
    every new connection attempt begins with a DCCP-Request packet sent    
    by the client.  A DCCP-Request packet thus resembles a TCP SYN; but    
    DCCP-Request is a packet type, not a flag, so there's no way to send   
    an unexpected combination such as TCP's SYN+FIN+ACK+RST.               
                                                                           
    Eight packet types occur during the progress of a typical              
    connection, shown here.  Note the three-way handshakes during          
    initiation and termination.                                            
                                                                           
       Client                                      Server                  
       ------                                      ------                  
                        (1) Initiation                                     
       DCCP-Request -->                                                    
                                        <-- DCCP-Response                  
       DCCP-Ack -->                                                        
                        (2) Data transfer                                  
       DCCP-Data, DCCP-Ack, DCCP-DataAck -->                               
                    <-- DCCP-Data, DCCP-Ack, DCCP-DataAck                  
                        (3) Termination                                    
                                        <-- DCCP-CloseReq                  
       DCCP-Close -->                                                      
                                           <-- DCCP-Reset                  
                                                                           
    The two remaining packet types are used to resynchronize after         
    bursts of loss.                                                        
                                                                           
    Every DCCP packet starts with a 12-byte generic header.  Particular    
    packet types include additional fixed-size header data; for example,   
    DCCP-Acks include an Acknowledgement Number.  DCCP options and any     
    application data follow the fixed-size header.                         
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                             Section 4.1.  [Page 14]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
    The packet types are as follows:                                       
                                                                           
    DCCP-Request                                                           
        Sent by the client to initiate a connection (the first part of     
        the three-way initiation handshake).                               
                                                                           
    DCCP-Response                                                          
        Sent by the server in response to a DCCP-Request (the second       
        part of the three-way initiation handshake).                       
                                                                           
    DCCP-Data                                                              
        Used to transmit application data.                                 
                                                                           
    DCCP-Ack                                                               
        Used to transmit pure acknowledgements.                            
                                                                           
    DCCP-DataAck                                                           
        Used to transmit application data with piggybacked                 
        acknowledgements.                                                  
                                                                           
    DCCP-CloseReq                                                          
        Sent by the server to request that the client close the            
        connection.                                                        
                                                                           
    DCCP-Close                                                             
        Used by the client or the server to close the connection;          
        elicits a DCCP-Reset in response.                                  
                                                                           
    DCCP-Reset                                                             
        Used to terminate the connection, either normally or abnormally.   
                                                                           
    DCCP-Sync, DCCP-SyncAck                                                
        Used to resynchronize sequence numbers after large bursts of       
        loss.                                                              
                                                                           
4.2.  Packet Sequencing                                                    
                                                                           
    Each DCCP packet carries a sequence number, so that losses can be      
    detected and reported.  Unlike TCP sequence numbers, which are byte-   
    based, DCCP sequence numbers increment by one per packet.  For         
    example:                                                               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler/Handley/Floyd                             Section 4.2.  [Page 15]   
                                                                          
INTERNET-DRAFT            Expires: 1 June 2006             December 2005   
                                                                           
                                                                           
       DCCP A                                      DCCP B                  
       ------                                      ------                  
       DCCP-Data(seqno 1) -->                                              
       DCCP-Data(seqno 2) -->                                              
                          <-- DCCP-Ack(seqno 10, ackno 2)                  
       DCCP-DataAck(seqno 3, ackno 10) -->                                 
                                  <-- DCCP-Data(seqno 11)                  
                                                                           
    Every DCCP packet increments the sequence number, whether or not it    
    contains application data.  DCCP-Ack pure acknowledgements increment   
    the sequence number, for instance: DCCP B's second packet above uses