The version of draft-ietf-dccp-spec-13.txt used to generate this diff is slightly different from the published version, in that we altered its margins and whitespace formatting in order to obtain a closer correspondence with the published RFC.

                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Network Working Group                                          E. Kohler 
Internet Engineering Task Force                             Eddie Kohler
Request for Comments: 4340                                          UCLA 
INTERNET-DRAFT                                                      UCLA
Category: Standards Track                                     M. Handley 
draft-ietf-dccp-spec-13.txt                                 Mark Handley
                                                                     UCL   
Expires: 3 October 2006                                              UCL
                                                                S. Floyd 
                                                             Sally Floyd
                                                                    ICIR   
                                                              March 2006 
                                                            3 April 2006
                                                                           
                                                                           
              Datagram Congestion Control Protocol (DCCP)                  
                                                                           
Status of This Memo                                                        
                                                                           
   This document specifies an Internet standards track protocol for the  
   By submitting this Internet-Draft, each author represents that any 
   Internet community, and requests discussion and suggestions for     
   applicable patent or other IPR claims of which he or she is aware  
   improvements.  Please refer to the current edition of the "Internet 
   have been or will be disclosed, and any of which he or she becomes 
   Official Protocol Standards" (STD 1) for the standardization state    
   aware will be disclosed, in accordance with Section 6 of BCP 79.   
   and status of this protocol.  Distribution of this memo is unlimited.
   Internet-Drafts are working documents of the Internet Engineering
                                                                           
   Task Force (IETF), its areas, and its working groups.  Note that 
Copyright Notice                                                         
   other groups may also distribute working documents as Internet-    
                                                                           
   Drafts.                                                            
   Copyright (C) The Internet Society (2006).                            
   Internet-Drafts are draft documents valid for a maximum of six months
                                                                           
   and may be updated, replaced, or obsoleted by other documents at any
Abstract                                                                   
   time.  It is inappropriate to use Internet-Drafts as reference   
                                                                           
   material or to cite them other than as "work in progress."         
   The Datagram Congestion Control Protocol (DCCP) is a transport          
   The list of current Internet-Drafts can be accessed at             
   protocol that provides bidirectional unicast connections of             
   http://www.ietf.org/ietf/1id-abstracts.txt.                        
   congestion-controlled unreliable datagrams.  DCCP is suitable for       
   The list of Internet-Draft Shadow Directories can be accessed at   
   http://www.ietf.org/shadow.html.                                   
   This Internet-Draft will expire on 3 October 2006.                 
   applications that transfer fairly large amounts of data and that can  
   applications that transfer fairly large amounts of data, but can   
   benefit from control over the tradeoff between timeliness and           
   reliability.                                                            
|| TEXT DELETED ||                                                         
   TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:                  
                                                                           
   Changes since draft-ietf-dccp-spec-08.txt:                         
Table of Contents                                                          
   * 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.                                           
   * 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.                                                     
                                                                           
   1. Introduction ....................................................5 
   1. Introduction ....................................................9
   2. Design Rationale ................................................6 
   2. Design Rationale ...............................................10
   3. Conventions and Terminology .....................................7 
   3. Conventions and Terminology ....................................11
      3.1. Numbers and Fields .........................................7 
      3.1. Numbers and Fields ........................................11
      3.2. Parts of a Connection ......................................8 
      3.2. Parts of a Connection .....................................12
      3.3. Features ...................................................9 
      3.3. Features ..................................................12
      3.4. Round-Trip Times ...........................................9 
      3.4. Round-Trip Times ..........................................13
      3.5. Security Limitation ........................................9 
      3.5. Security Limitation .......................................13
      3.6. Robustness Principle ......................................10 
      3.6. Robustness Principle ......................................13
   4. Overview .......................................................10 
   4. Overview .......................................................13
      4.1. Packet Types ..............................................10 
      4.1. Packet Types ..............................................14
      4.2. Packet Sequencing .........................................11 
      4.2. Packet Sequencing .........................................15
      4.3. States ....................................................12 
      4.3. States ....................................................16
      4.4. Congestion Control Mechanisms .............................14 
      4.4. Congestion Control Mechanisms .............................17
                                                                           
      4.5. Connection Features .......................................18
                                                                           
      4.6. Differences From TCP ......................................19
                                                                           
      4.7. Example Connection ........................................20
Kohler, et al.              Standards Track                     [Page 1]   
   5. Packet Formats .................................................22
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
      5.1. Generic Header ............................................22
                                                                           
      5.2. DCCP-Request Packets ......................................25
                                                                           
      5.3. DCCP-Response Packets .....................................26
      4.5. Connection Features .......................................15 
      5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets .............27
      4.6. Differences from TCP ......................................16
      5.5. DCCP-CloseReq and DCCP-Close Packets ......................28
      4.7. Example Connection ........................................17 
      5.6. DCCP-Reset Packets ........................................29
   5. Packet Formats .................................................18 
      5.7. DCCP-Sync and DCCP-SyncAck Packets ........................32
      5.1. Generic Header ............................................19 
      5.8. Options ...................................................33
      5.2. DCCP-Request Packets ......................................22 
           5.8.1. Padding Option .....................................34
      5.3. DCCP-Response Packets .....................................23 
           5.8.2. Mandatory Option ...................................35
      5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets .............23 
   6. Feature Negotiation ............................................35
      5.5. DCCP-CloseReq and DCCP-Close Packets ......................25 
      6.1. Change Options ............................................36
      5.6. DCCP-Reset Packets ........................................25 
      6.2. Confirm Options ...........................................36
      5.7. DCCP-Sync and DCCP-SyncAck Packets ........................28 
      6.3. Reconciliation Rules ......................................37
      5.8. Options ...................................................29 
           6.3.1. Server-Priority ....................................37
           5.8.1. Padding Option .....................................31 
           6.3.2. Non-Negotiable .....................................37
           5.8.2. Mandatory Option ...................................31 
      6.4. Feature Numbers ...........................................38
   6. Feature Negotiation ............................................32 
      6.5. Feature Negotiation Examples ..............................39
      6.1. Change Options ............................................32 
      6.6. Option Exchange ...........................................40
      6.2. Confirm Options ...........................................33 
           6.6.1. Normal Exchange ....................................40
      6.3. Reconciliation Rules ......................................33 
           6.6.2. Processing Received Options ........................41
           6.3.1. Server-Priority ....................................33 
           6.6.3. Loss and Retransmission ............................43
           6.3.2. Non-Negotiable .....................................34 
           6.6.4. Reordering .........................................44
      6.4. Feature Numbers ...........................................34 
           6.6.5. Preference Changes .................................45
      6.5. Sequence Number Handling Examples .........................35
           6.6.6. Simultaneous Negotiation ...........................45
      6.6. Option Exchange ...........................................36 
           6.6.7. Unknown Features ...................................45
           6.6.1. Normal Exchange ....................................37 
           6.6.8. Invalid Options ....................................46
           6.6.2. Processing Received Options ........................37 
           6.6.9. Mandatory Feature Negotiation ......................46
           6.6.3. Loss and Retransmission ............................39 
   7. Sequence Numbers ...............................................47
           6.6.4. Reordering .........................................40 
      7.1. Variables .................................................47
           6.6.5. Preference Changes .................................41 
      7.2. Initial Sequence Numbers ..................................48
           6.6.6. Simultaneous Negotiation ...........................41 
      7.3. Quiet Time ................................................49
           6.6.7. Unknown Features ...................................41 
      7.4. Acknowledgement Numbers ...................................49
           6.6.8. Invalid Options ....................................42 
      7.5. Validity and Synchronization ..............................50
           6.6.9. Mandatory Feature Negotiation ......................43 
           7.5.1. Sequence and Acknowledgement Number Windows ........50
   7. Sequence Numbers ...............................................43 
           7.5.2. Sequence Window Feature ............................51
      7.1. Variables .................................................43 
           7.5.3. Sequence-Validity Rules ............................52
      7.2. Initial Sequence Numbers ..................................44 
           7.5.4. Handling Sequence-Invalid Packets ..................53
      7.3. Quiet Time ................................................45 
           7.5.5. Sequence Number Attacks ............................54
      7.4. Acknowledgement Numbers ...................................46 
           7.5.6. Sequence Number Handling Examples ..................56
      7.5. Validity and Synchronization ..............................46 
      7.6. Short Sequence Numbers ....................................57
           7.5.1. Sequence and Acknowledgement Number Windows ........47 
           7.6.1. Allow Short Sequence Numbers Feature ...............57
           7.5.2. Sequence Window Feature ............................48 
           7.6.2. When to Avoid Short Sequence Numbers ...............58
           7.5.3. Sequence-Validity Rules ............................48 
      7.7. NDP Count and Detecting Application Loss ..................58
           7.5.4. Handling Sequence-Invalid Packets ..................50 
           7.7.1. NDP Count Usage Notes ..............................59
           7.5.5. Sequence Number Attacks ............................51 
           7.7.2. Send NDP Count Feature .............................60
           7.5.6. Examples ...........................................53 
   8. Event Processing ...............................................60
      7.6. Short Sequence Numbers ....................................54 
      8.1. Connection Establishment ..................................60
           7.6.1. Allow Short Sequence Numbers Feature ...............54 
           8.1.1. Client Request .....................................60
           7.6.2. When to Avoid Short Sequence Numbers ...............55 
           8.1.2. Service Codes ......................................61
      7.7. NDP Count and Detecting Application Loss ..................55 
           8.1.3. Server Response ....................................63
                                                                           
           8.1.4. Init Cookie Option .................................64
                                                                           
           8.1.5. Handshake Completion ...............................65
                                                                           
      8.2. Data Transfer .............................................66
Kohler, et al.              Standards Track                     [Page 2]   
      8.3. Termination ...............................................66
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
           8.3.1. Abnormal Termination ...............................68
                                                                           
      8.4. DCCP State Diagram ........................................68
                                                                           
      8.5. Pseudocode ................................................69
           7.7.1. NDP Count Usage Notes ..............................56 
   9. Checksums ......................................................73
           7.7.2. Send NDP Count Feature .............................56 
      9.1. Header Checksum Field .....................................74
   8. Event Processing ...............................................57 
      9.2. Header Checksum Coverage Field ............................75
      8.1. Connection Establishment ..................................57 
           9.2.1. Minimum Checksum Coverage Feature ..................76
           8.1.1. Client Request .....................................57 
      9.3. Data Checksum Option ......................................76
           8.1.2. Service Codes ......................................58 
           9.3.1. Check Data Checksum Feature ........................77
           8.1.3. Server Response ....................................60 
           9.3.2. Checksum Usage Notes ...............................78
           8.1.4. Init Cookie Option .................................61 
   10. Congestion Control ............................................78
           8.1.5. Handshake Completion ...............................62 
      10.1. TCP-like Congestion Control ..............................79
      8.2. Data Transfer .............................................62 
      10.2. TFRC Congestion Control ..................................79
      8.3. Termination ...............................................63 
      10.3. CCID-Specific Options, Features, and Reset Codes .........79
           8.3.1. Abnormal Termination ...............................65 
      10.4. CCID Profile Requirements ................................82
      8.4. DCCP State Diagram ........................................65 
      10.5. Congestion State .........................................82
      8.5. Pseudocode ................................................66 
   11. Acknowledgements ..............................................83
   9. Checksums ......................................................70 
      11.1. Acks of Acks and Unidirectional Connections ..............84
      9.1. Header Checksum Field .....................................71 
      11.2. Ack Piggybacking .........................................85
      9.2. Header Checksum Coverage Field ............................72 
      11.3. Ack Ratio Feature ........................................85
           9.2.1. Minimum Checksum Coverage Feature ..................73 
      11.4. Ack Vector Options .......................................87
      9.3. Data Checksum Option ......................................73 
           11.4.1. Ack Vector Consistency ............................89
           9.3.1. Check Data Checksum Feature ........................74 
           11.4.2. Ack Vector Coverage ...............................91
           9.3.2. Checksum Usage Notes ...............................75 
      11.5. Send Ack Vector Feature ..................................91
   10. Congestion Control ............................................75 
      11.6. Slow Receiver Option .....................................92
      10.1. TCP-like Congestion Control ..............................76 
      11.7. Data Dropped Option ......................................93
      10.2. TFRC Congestion Control ..................................76 
           11.7.1. Data Dropped and Normal Congestion Response .......95
      10.3. CCID-Specific Options, Features, and Reset Codes .........77 
           11.7.2. Particular Drop Codes .............................96
      10.4. CCID Profile Requirements ................................79 
   12. Explicit Congestion Notification ..............................97
      10.5. Congestion State .........................................79 
      12.1. ECN Incapable Feature ....................................97
   11. Acknowledgements ..............................................80 
      12.2. ECN Nonces ...............................................98
      11.1. Acks of Acks and Unidirectional Connections ..............81 
      12.3. Aggression Penalties .....................................99
      11.2. Ack Piggybacking .........................................82 
   13. Timing Options ...............................................100
      11.3. Ack Ratio Feature ........................................82 
      13.1. Timestamp Option ........................................100
      11.4. Ack Vector Options .......................................84 
      13.2. Elapsed Time Option .....................................100
      11.5. Send Ack Vector Feature ..................................89 
      13.3. Timestamp Echo Option ...................................101
      11.6. Slow Receiver Option .....................................89 
   14. Maximum Packet Size ..........................................102
      11.7. Data Dropped Option ......................................90 
      14.1. Measuring PMTU ..........................................103
           11.7.1. Data Dropped and Normal Congestion Response .......93 
      14.2. Sender Behavior .........................................104
           11.7.2. Particular Drop Codes .............................93 
   15. Forward Compatibility ........................................105
   12. Explicit Congestion Notification ..............................94 
   16. Middlebox Considerations .....................................106
      12.1. ECN Incapable Feature ....................................95 
   17. Relations to Other Specifications ............................107
      12.2. ECN Nonces ...............................................95 
      17.1. RTP .....................................................107
      12.3. Aggression Penalties .....................................97 
      17.2. Congestion Manager and Multiplexing .....................109
   13. Timing Options ................................................97 
   18. Security Considerations ......................................109
      13.1. Timestamp Option .........................................97 
      18.1. Security Considerations for Partial Checksums ...........110
      13.2. Elapsed Time Option ......................................98 
   19. IANA Considerations ..........................................110
      13.3. Timestamp Echo Option ....................................99 
      19.1. Packet Types Registry ...................................111
   14. Maximum Packet Size ..........................................100 
      19.2. Reset Codes Registry ....................................111
      14.1. Measuring PMTU ..........................................100 
      19.3. Option Types Registry ...................................111
      14.2. Sender Behavior .........................................102 
      19.4. Feature Numbers Registry ................................112
                                                                           
      19.5. Congestion Control Identifiers Registry .................112
                                                                           
      19.6. Ack Vector States Registry ..............................112
                                                                           
      19.7. Drop Codes Registry .....................................112
Kohler, et al.              Standards Track                     [Page 3]   
      19.8. Service Codes Registry ..................................113
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
      19.9. Port Numbers Registry ...................................113
                                                                           
   20. Thanks .......................................................115
                                                                           
   A. Appendix: Ack Vector Implementation Notes .....................115
   15. Forward Compatibility ........................................103 
      A.1. Packet Arrival ...........................................118
   16. Middlebox Considerations .....................................103 
           A.1.1. New Packets .......................................118
   17. Relations to Other Specifications ............................105 
           A.1.2. Old Packets .......................................119
      17.1. RTP .....................................................105 
      A.2. Sending Acknowledgements .................................119
      17.2. Congestion Manager and Multiplexing .....................106 
      A.3. Clearing State ...........................................120
   18. Security Considerations ......................................107 
      A.4. Processing Acknowledgements ..............................121
      18.1. Security Considerations for Partial Checksums ...........107 
   B. Appendix: Partial Checksumming Design Motivation ..............122
   19. IANA Considerations ..........................................108 
   Normative References .............................................123
      19.1. Packet Types Registry ...................................108 
   Informative References ...........................................124
      19.2. Reset Codes Registry ....................................109 
   Authors' Addresses ...............................................126
      19.3. Option Types Registry ...................................109 
   Full Copyright Statement .........................................127
      19.4. Feature Numbers Registry ................................109 
   Intellectual Property ............................................127
      19.5. Congestion Control Identifiers Registry .................110 
      19.6. Ack Vector States Registry ..............................110 
      19.7. Drop Codes Registry .....................................110 
      19.8. Service Codes Registry ..................................110 
      19.9. Port Numbers Registry ...................................111 
   20. Thanks .......................................................113 
   A.  Appendix: Ack Vector Implementation Notes ....................114 
       A.1. Packet Arrival ..........................................116 
            A.1.1. New Packets ......................................116 
            A.1.2. Old Packets ......................................117 
       A.2. Sending Acknowledgements ................................118 
       A.3. Clearing State ..........................................118 
       A.4. Processing Acknowledgements .............................120 
   B.  Appendix: Partial Checksumming Design Motivation .............120 
   Normative References .............................................122 
   Informative References ...........................................123 
                                                                           
List of Tables                                                             
                                                                           
   Table 1: DCCP Packet Types . . . . . . . . . . . . . . . . . . .  21  
   Table 1: DCCP Packet Types ........................................24
   Table 2: DCCP Reset Codes. . . . . . . . . . . . . . . . . . . .  28  
   Table 2: DCCP Reset Codes .........................................31
   Table 3: DCCP Options. . . . . . . . . . . . . . . . . . . . . .  30  
   Table 3: DCCP Options .............................................33
   Table 4: DCCP Feature Numbers. . . . . . . . . . . . . . . . . .  34  
   Table 4: DCCP Feature Numbers .....................................38
   Table 5: DCCP Congestion Control Identifiers . . . . . . . . . .  75  
   Table 5: DCCP Congestion Control Identifiers ......................78
   Table 6: DCCP Ack Vector States. . . . . . . . . . . . . . . . .  85  
   Table 6: DCCP Ack Vector States ...................................88
   Table 7: DCCP Drop Codes . . . . . . . . . . . . . . . . . . . .  91  
   Table 7: DCCP Drop Codes ..........................................94
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler, et al.              Standards Track                     [Page 4]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
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 the following:                                               
   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) [RFC3168] and the ECN Nonce [RFC3540].                     
      (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 [RFC1191].         
   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 [RFC4341] and
      are currently specified, TCP-like Congestion Control [CCID 2  
      TFRC (TCP-Friendly Rate Control) Congestion Control [RFC4342].     
      PROFILE] and TFRC (TCP-Friendly Rate Control) Congestion Control
      DCCP is easily extensible to further forms of unicast congestion     
      [CCID 3 PROFILE], but DCCP is easily extensible to further forms
      control.                                                             
      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,    
   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          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler, et al.              Standards Track                     [Page 5]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
   support, for unreliable datagram flows, avoiding the arbitrary delays   
   associated with TCP.  It also implements reliable connection 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       
   (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   
   changes in available bandwidth, but must tolerate the abrupt changes
   in congestion window typical of TCP.  A second alternative, TCP-        
   Friendly Rate Control (TFRC) [RFC3448], a form of equation-based      
   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 
   might not allow applications to set UDP packets as ECN-capable, since
   the API could not guarantee that the application would properly       
   the API could not guarantee the application would properly detect or 
   detect or respond to congestion.  DCCP kernel APIs will have no such    
   respond to congestion.  DCCP kernel APIs will have no such issues,   
   issues, since DCCP implements congestion control itself.                
   since DCCP implements congestion control itself.                     
                                                                           
   We chose not to require the use of the Congestion Manager [RFC 3124],
   We chose not to require the use of the Congestion Manager [RFC3124],  
   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   
   control mechanisms, or lend itself to the use of forms of TFRC where
                                                                           
                                                                           
                                                                           
Kohler, et al.              Standards Track                     [Page 6]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
   the state about past packet drops or marks is maintained at the         
   receiver rather than at the sender.  DCCP should be able to 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.  However, the congestion  
   controlled streams of unreliable datagrams.  The congestion control
   control mechanisms currently approved for use with DCCP, which are      
   mechanisms currently approved for use with DCCP, which are described 
   described in separate Congestion Control ID Profiles [RFC4341,        
   in separate Congestion Control ID Profiles [CCID 2 PROFILE, CCID 3 
   RFC4342], may cause problems for some applications, including high- 
   PROFILE], may, however, cause problems for some applications,      
   bandwidth interactive video.  These applications should be able to    
   including high-bandwidth interactive video.  These applications    
   use DCCP once suitable Congestion Control ID Profiles are               
   should be able to use DCCP once suitable Congestion Control ID       
   standardized.                                                           
   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 [RFC2119].             
   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     
   Random numbers in DCCP are used for their security properties, and 
   SHOULD be chosen according to the guidelines in RFC 4086.             
   SHOULD be chosen according to the guidelines in RFC 1750.          
                                                                           
   All operations on DCCP sequence numbers, and comparisons such as   
   All operations on DCCP sequence numbers and comparisons such as       
   "greater" and "greatest", use circular arithmetic modulo 2**48.  This
   "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 [RFC793] 
   circular arithmetic spaces, including TCP's sequence numbers [RFC  
   and DNS's serial numbers [RFC1982].  Note that the common technique   
   793] and DNS's serial numbers [RFC 1982].  Note that the common  
   for implementing circular comparison using twos-complement            
   technique for implementing circular comparison using two's-complement
   arithmetic, whereby A < B using circular arithmetic if and only if (A   
   arithmetic, whereby A < B using circular arithmetic if and only if   
   - B) < 0 using conventional twos-complement arithmetic, may be used   
   (A - B) < 0 using conventional two's-complement arithmetic, may be 
   for DCCP sequence numbers, provided that they are stored in the most  
   used for DCCP sequence numbers, provided they are stored in the most 
   significant 48 bits of 64-bit integers.                                 
                                                                           
                                                                           
                                                                           
                                                                           
Kohler, et al.              Standards Track                     [Page 7]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
   Reserved bitfields in DCCP packet headers MUST be set to zero by        
   senders and MUST be ignored by receivers, unless otherwise specified. 
   senders, and MUST be ignored by receivers, unless otherwise        
   This allows for future protocol extensions.  In particular, DCCP      
   specified.  This is to allow for future protocol extensions.  In   
   processors MUST NOT reset a DCCP connection simply because a Reserved   
   particular, DCCP processors MUST NOT reset a DCCP connection simply  
   field has non-zero value [RFC3360].                                   
   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   
   flow in both directions simultaneously.  Logically, however, a DCCP   
   be flowing in both directions simultaneously.  Logically, however, a
   connection consists of two separate unidirectional connections,         
   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-       
   acknowledgements, respectively.  For example, DCCP A is the HC-Sender
   Sender and DCCP B is the HC-Receiver in the A-to-B half-connection.   
   and DCCP B is the HC-Receiver in the A-to-B half-connection.         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler, et al.              Standards Track                     [Page 8]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
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.            
                                                                           
   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        
   available; this parameter should default to not less than          
   seconds, a reasonably conservative round-trip time for Internet TCP     
   0.2 seconds, a reasonably conservative round-trip time for Internet  
   connections.  Protocol behavior specified in terms of "round-trip       
   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   
   [RFC2401]; depending on the level of security required, application-  
   [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.                                       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
Kohler, et al.              Standards Track                     [Page 9]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
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" [RFC793].                                         
   accept from others" [RFC 793].                                     
                                                                           
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          
   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    
   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 is no way to send 
   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.             
   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.                                                                
                                                                           
                                                                           
                                                                           
Kohler, et al.              Standards Track                    [Page 10]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
   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.                          
                                                                           
   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      
   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, et al.              Standards Track                    [Page 11]   
                                                                          
RFC 4340      Datagram Congestion Control Protocol (DCCP)     March 2006   
                                                                           
                                                                           
      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