Internet Engineering Task Force                         Gorry Fairhurst 
Internet Draft                                      Arjuna Sathiaseelan 
Document: draft-fairhurst-tsvwg-dccp-qs-00.txt   University of Aberdeen 
Expires: August 2007                             
                                                                        
                                                                        
Category: Draft intended for EXPERIMENTAL                 February 2007 
 
    
   Quick-Start for DCCP  
    
Status of this Draft 
    
   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/1id-abstracts.html  
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   This Internet-Draft will expire on August 31, 2007. 
    
    
Abstract 
    
   The Datagram Congestion Control Protocol (DCCP) is a transport 
   protocol that allows the transmission of congestion-controlled, 
   unreliable datagrams. It is intended for applications such as 
   streaming media, Internet telephony, and on-line games.  In DCCP, an 
   application has a choice of congestion control mechanisms, each 
   specified by a Congestion Control Identifier (CCID). This document 
   specifies a framework for the use of the Experimental Quick-Start 
   Mechanism by DCCP, and specific procedures for the use of Quick-
   Start with DCCP CCID-2 and CCID-3. 
    
    
    
    
    
    
    
    
    

  
Expires August 2007                                           [page 1] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
Table of Contents 
    
    
   1. Introduction 
    
   2. Quick-Start for DCCP 
        2.1 Sending a Quick-Start Request for a DCCP flow 
        2.2 Receiving a Quick-Start Request for a DCCP flow 
        2.2.1 The Quick-Start Response Option 
        2.3 Receiving a Quick-Start Response 
        2.4 Procedure when no response to a Quick-Start Request 
        2.5 Procedure when a Quick-Start packet is dropped 
        2.6 Interactions with Path MTU Discovery 
        2.7 Interactions with Middle boxes 
    
   3. Mechanisms for Specific CCIDs 
        3.1 Quick-Start for CCID-2 
        3.2 Quick-Start for CCID-3 
        3.2.1 The Quick-Start Request for CCID-3 
        3.2.2 Sending a Quick-Start Response 
        3.2.3 Using the Quick-Start Response with CCID-3 
        3.2.4 The Quick-Start Validation Phase 
        3.2.5 Reported Loss during Quick-Start Mode or Validation Phase 
        3.2.6 An Example Quick-Start Scenario with CCID-3 
        3.2.7 Controlling Acknowledgement Traffic on the Reverse Path 
    
   4. Discussion of Issues 
        4.1 Over-run and Quick-Start Validation  
 
   5. Summary 
    
   6. IANA Considerations 
    
   7. Acknowledgments 
    
   8. Security Considerations 
    
   9. References 
       9.1 Normative References 
       9.2 Informative References 
    
   10. Authors' Addresses 
    
   11. IPR Notices 
       11.1 Intellectual Property Statement 
       11.2 Disclaimer of Validity 
    
    
   12. Copyright Statement 
        
 
 

  
Expires August 2007                                           [page 2] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
1. Introduction 
    
    
   The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 
   transport protocol for congestion-controlled, unreliable datagrams, 
   intended for applications such as streaming media, Internet 
   telephony, and on-line games.   
    
   In DCCP, an application has a choice of congestion control 
   mechanisms, each specified by a Congestion Control Identifier (CCID) 
   [RFC4340]. There are general procedures applicable to all DCCP CCIDs 
   that are described in Section 2, and details that relate to how 
   individual CCIDs should operate, which are described in Section 3. 
   This separation of CCID-specific and DCCP general functions is in 
   the spirit of the modular approach adopted by DCCP. 
    
   Quick-Start [RFC4782] is an Experimental mechanism for transport 
   protocols. In cooperation with routers, it allows a sender to 
   determine an allowed sending rate at the start and at times in the 
   middle of a data transfer (e.g., after an idle period). 
    
   This document assumes that the reader is familiar with RFC4782 
   [RFC4782]. RFC4782 specifies the use of Quick-Start with IP and with 
   TCP. Section 7 of RFC4782 also provides guidelines for the use of 
   Quick-Start with other transport protocols, including DCCP. This 
   document answers some of the issues that were raised by RFC4782 and 
   provides a definition of how Quick-Start must be used with DCCP. 
 
   In using Quick-Start, the sending DCCP end host indicates the 
   desired sending rate in bytes per second, using a Quick-Start option 
   in the IP header of a DCCP packet.  Each Quick-Start capable router 
   along the path could, in turn, either approve the requested rate, 
   reduce the requested rate, or indicate that the Quick-Start request 
   is not approved. 
    
   If the Quick-Start Request is approved by all the routers along the 
   path, then the DCCP receiver returns an appropriate Quick-Start 
   Response. On receipt of this, the sending end host can send at up to 
   the approved rate for one round-trip time.  Subsequent transmissions 
   will be governed by the default CCID congestion control mechanisms 
   for that connection. If the Quick-Start Requestis not approved, then 
   the sender must use the default congestion control mechanisms. 
    
 
 
 
 
 
 
 
 
 
 
  
Expires August 2007                                           [page 3] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
2. Quick-Start for DCCP 
 
    
   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 [RFC2119]. 
    
   Unless otherwise specified, the DCCP end host follows the procedures 
   specified in Section 4 of [RFC4782], following the use specified for 
   Quick-Start with TCP.  
    
    
2.1 Sending a Quick-Start Request for a DCCP flow 
    
   A DCCP sender MAY use a Quick-Start Request during the start of a 
   connection, when the sender would prefer to have a larger initial 
   rate than allowed by [RFC3390].  
    
   A Quick-Start Request MAY be also used once a DCCP flow is connected 
   (in the middle of a DCCP flow). In standard operation, DCCP CCIDs 
   can constrain the sending rate (or window) to less than that desired 
   (e.g. when an application increases the rate at which it wishes to 
   send). A DCCP sender that has data to send after an idle period or 
   data-limited period (where the sender transmits at less than the 
   allowed sending rate) can send a Quick-Start Request using the 
   procedures defined in Section 3. 
 
   Excessive use of the Quick-Start mechanism is not recommended, end 
   hosts therefore MUST NOT therefore make a subsequent Quick-Start 
   Request within a period of four RTTs. 
    
   When sending a Quick-Start Request, the DCCP sender SHOULD send the 
   Request on a packet that requires an acknowledgement, such as a 
   DCCP-Request, DCCP-Response, or DCCP-Data. 
    
    
2.2 Receiving a Quick-Start Request for a DCCP flow 
    
   The procedure for processing a received Quick-Start Request is 
   normatively defined in [RFC4782], and summarised in this paragraph. 
   An end host that receives an IP packet containing a Quick-Start 
   Request passes the Quick-Start Request, along with the value in the 
   IP TTL field, to the receiving DCCP layer. If the receiving host is 
   willing to permit the Quick-Start Request, then a Quick-Start 
   Response option is included in the DCCP header of the corresponding 
   feedback packet.  The Rate Request in the Quick-Start Response 
   option is set to the received value of the Rate Request in the 
   Quick-Start option or to a lower value if the DCCP receiver is only 
   willing to allow a lower Rate Request.  The TTL Diff in the Quick-
   Start Response is set to the difference between the IP TTL value and 
   the QS TTL value.  The QS Nonce in the Response is set to the 
   received value of the QS Nonce in the Quick-Start option. 
  
Expires August 2007                                           [page 4] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
    
   On receipt of a Quick-Start Request, the receiver SHOULD respond 
   immediately by sending a packet that carries the Quick-Start 
   Response option using either DCCP-Ack packet or in a DCCP-DataAck 
   packet. 
 
   If an end host receives an IP packet with a Quick-Start Request with 
   a rate request of zero, then that host SHOULD NOT send a Quick-Start 
   Response [RFC4782]. 
    
   The Quick-Start Response MUST NOT be resent if it is lost in the 
   network [RFC4782]. Packet loss could be an indication of congestion 
   on the return path, in which case it is better not to approve the 
   Quick-Start Request. 
 
    
2.2.1 The Quick-Start Response Option 
    
   This section defines a DCCP Header Option to carry the Quick-Start 
   response, in a format that resembles that defined for TCP in 
   [RFC4782]. This header option is REQUIRED for end hosts to utilise 
   the Quick-Start mechanism for DCCP flows.  
    
   ### IANA ACTION, PLEASE REPLACE xQSOx with the assigned value ### 
    
   0                   1                   2                   3 
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  Type=xQSOx   |  Length=8     | Resv. | Rate  |   TTL Diff    | 
   |               |               |       |Request|               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                   QS Nonce                                | R | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
      Figure 1.  The Quick-Start Response option. 
    
   ### IANA ACTION, PLEASE REPLACE xQSOx with the assigned value ### 
    
   The first byte of the Quick-Start Response option contains the 
   option kind, identifying the DCCP option (xQSOx). 
    
   The second byte of the Quick-Start Response option contains the 
   option length in bytes.  The length field MUST be set to 8 bytes. 
    
   The third byte of the Quick-Start Response option contains a four-
   bit Reserved field, and the four-bit allowed Rate Request, formatted 
   as in the Quick-Start Rate Request option. 
    
   The fourth byte of the DCCP Quick-Start Response option contains the 
   TTL Diff.  The TTL Diff contains the difference between the IP TTL 
   and QS TTL fields in the received Quick-Start Request packet, as 
   calculated in [RFC4782]. 
    
  
Expires August 2007                                           [page 5] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
   Bytes 5-8 of the DCCP option contain the 30-bit QS Nonce and a two-
   bit Reserved field. 
    
    
2.3 Receiving a Quick-Start Response  
    
   The procedure for processing a Quick-Start Response packet is CCID-
   specific and described in Section 3. 
    
 
2.4 Procedure when no response to a Quick-Start Request 
    
   As in TCP, if a Quick-Start Request is dropped (i.e., the Request or 
   Response is not delivered by the network) the DCCP sender MUST 
   revert to the congestion control mechanisms it would have used if 
   the Quick-Start Request had not been approved.  
    
    
2.5 Procedure when a Quick-Start packet is dropped 
    
   While the sender is in the QS Mode, all sent packets are known as 
   Quick-Start Packets [RFC4782].  Loss of a Quick-Start Packet is an 
   indication of potential network congestion. The behaviour of a DCCP 
   sender following the loss of a Quick-Start Packet is specific to a 
   particular CCID (see section 3).  
 
 
2.6 Interactions with Path MTU Discovery 
    
   While DCCP implementations are encouraged to support PMTUD, the 
   protocol is datagram-based and therefore the size of the segments 
   that are sent is a function of application behaviour as well as 
   being constrained by the largest supported Path MTU.  
    
    
2.7 Interactions with Middle boxes 
    
   XXX Note: To be completed in a later revision of the document XXX 
    
    
    
    
    
    
    
    
    
    
    
    
    
    

  
Expires August 2007                                           [page 6] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
3. Mechanisms for Specific CCIDs 
 
    
3.1 Quick-Start for CCID-2 
    
   This section describes the Quick-Start mechanism to be used with 
   DCCP CCID-2 [RFC4341]. CCID-2 uses a TCP-like congestion control 
   mechanism. 
    
   XXX Note: This Section to be completed later XXX 
 
 
3.2 Quick-Start for CCID-3 
 
   This section describes the Quick-Start mechanism to be used with 
   DCCP CCID-3 [RFC4342]. The rate-based congestion control mechanism 
   used by CCID-3, leads to specific issues that need to be addressed 
   by Quick-Start. 
    
    
3.2.1 The Quick-Start Request for CCID-3 
    
   A Quick-Start Request MAY be sent to allow the sender to determine 
   if it is safe to use a larger initial sending sate. This permits a 
   faster start-up of a new DCCP flow.  
    
   A Quick-Start Request MAY be also sent to request a higher sending 
   rate after an idle period or data-limited period (as described in 
   section 2.1). This allows a receiver to increase the sending rate 
   faster than allowed with standard operation, where CCID-3 does not 
   allow the sender to send more than twice as fast as reported by the 
   receiver in the most recent feedback message. 
    
 
   An idle period is defined in this context as one in which the 
   nofeedback timer expires [ID.DCCP-FR].  
    
   XXX Note: Future drafts may use common terminology to DCCP FR draft 
   XXX 
 
   When resuming a flow that has been idle, the requested rate must 
   consider the current loss event rate (if any), either from 
   calculation at the sender or from feedback received from the 
   receiver. A sender MUST not request more than this upper bound 
   dictated by the loss event rate. 
    
   XXX Author comment: Is it appropriate to also ask using QS after 
   receiving a loss-event, as a way of getting more capacity than 
   allowed by the throughput equation ??? XXX 
    
   XXX Author comment:  One view is that under the current 
   circumstances, the sender does not have a proper knowledge of the 

  
Expires August 2007                                           [page 7] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
   network. So on that basis, the sender based on the current loss 
   event rate (current here means the loss event rate that was during 
   the start of the idle period), requests the rate. This MUST be an 
   upper bound. This is similar to asking for the last achieved rate 
   during slow start. This places an upper bound on the sending rate, 
   dictated by the loss event rate is an upper bound on the requested 
   Quick-Start rate. Later, mobility events can also be taken into 
   account. XXX 
    
 
3.2.2 Sending a Quick-Start Response 
    
   When processing a received Quick-Start Request, the receiver uses 
   the method described in Section 2.2. In addition, the DCCP receiver 
   MUST reset the CCID-3 feedback timer. This helps to align the timing 
   of feedback to the start and end of the period in which Quick-Start 
   Packets are sent, and will normally result in feedback at a time 
   that is approximately the end of the period when Quick-Start Packets 
   are received. 
    
 
3.2.3 Using the Quick-Start Response with CCID-3 
    
   The sender SHOULD NOT ignore a feedback packet containing a Quick-
   Start Response option.  
    
   On receipt of a valid Quick-Start Response option, the sender enters 
   the Quick-Start Mode. The sender continues in the Quick-Start Mode 
   for a maximum period of 1 RTT, during which it sends Quick-Start 
   Packets. 
 
   On receipt of a Quick-Start response, the sending host sets its 
   Quick-Start sending rate (QS-sendrate) as follows: 

       QS-sendrate = R * s/(s + H)                                (1) 
   where R the Rate Request in bytes per second, s is the packet size, 
   and H the estimated DCCP/IP header size in bytes (e.g., 32 bytes). 
   A CCID 3 host MAY then increase its sending rate (sendrate) to the 
   QS-sendrate, if the QS-sendrate is greater than sendrate. The rate 
   SHOULD NOT be reduced (i.e., a QS-sendrate lower than sendrate 
   should be ignored). CCID 3 is a rate-paced protocol. Therefore, if 
   the QS-sendrate is used, the sending host MUST pace the rate at 
   which the Quick-Start packets are sent over the next RTT. The 
   sending host SHOULD also record the previous congestion-controlled 
   rate and note that the new rate has been determined by Quick-Start 
   rather by other means (e.g. by setting a flag to indicate that it is 
   in Quick-Start Mode).  
    
   The sender MUST send a Quick-Start Approved option [RFC4782] on the 
   first Quick-Start packet or using a control packet if there are no 
   Quick-Start packets to be sent. 
    
   The sender exits the Quick-Start Mode after either: 
  
Expires August 2007                                           [page 8] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
    
   * A feedback packet acknowledging one or more Quick-Start Packets, 
   * A period of 1 RTT after receipt of a QS-Response, 
   or  
   * Detection of a loss event (see Section 3.2.5).  
    
   If no loss (or ECN marking) is reported, the sender then enters the 
   Quick-Start Validation Phase. 
 
    
3.2.4 The Quick-Start Validation Phase 
    
   After transmitting a set of Quick-Start Packets (and providing that 
   no loss or ECN marking is reported), the sender enters the Quick-
   Start Validation Phase. This phase comprises a period during which 
   the sender seeks to affirm that the capacity used by the Quick-Start 
   Packets did not introduce congestion. (This phase is introduced 
   because unlike TCP (and CCID-2), CCID-3 does not receive frequent 
   feedback that indicates the congestion state of the forward path). 
   While in the Quick-Start Validation Phase, the sender is tentatively 
   permitted to continue sending at the QS-sendrate. On conclusion of 
   the Validation Phase, the sender expects to find assurance that it 
   may safely use the current rate. 
    
   The sender MUST exit the Quick-Start Validation Phase on receipt of 
   feedback that reports a loss event (see Section 3.2.5). 
 
   The sender SHOULD exit the Quick-Start Validation Phase on receipt 
   of feedback that acknowledges all packets sent in the Quick-Start 
   Mode (i.e. all Quick-Start Packets). It MUST also exit this phase on 
   expiry of the Quick-Start validation time. The Quick-Start 
   Validation Phase is limited to a maximum of 1.5 RTTs, the Quick-
   Start Validation Time.  
    
   After completion of the Quick-Start Validation phase (with no 
   reported packet loss), the sender stops using the QS-sendrate and 
   MUST recalculate a suitable sending rate using the standard 
   congestion control mechanisms [RFC4342].  For example, if the DCCP 
   sender was in slow-start prior to the Quick-Start request, and no 
   packets were lost or marked since that time, then the sender 
   continues in slow-start after exiting Quick-Start Mode until the 
   sender sees a packet loss.  
 
   If no feedback is received within the Quick-Start Validation Phase, 
   the sender MUST return to the minimum of the original rate (at the 
   start of the Quick-Start Mode) and one half of the QS-sendrate.  
 
    
3.2.5 Reported Loss during Quick-Start Mode or Validation Phase 
 
   If a feedback packet arrives that reports a packet loss, the sender 
   MUST immediately leave the Quick-Start Mode or Validation Phase and 

  
Expires August 2007                                           [page 9] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
   enter the congestion avoidance phase [RFC4342].  This implies re-
   calculating the send rate X as follows: 
    
        X = max(min(X_calc, min(2*X_recv, 2* QS_recv-rate)), s/t_mbi); 
    
   where X_recv is the previously cached receiver rate and QS recv-rate 
   is the receiver rate reported by the feedback due to the arrival of 
   Quick-Start packets. 
    
    
3.2.6  An Example Quick-Start Scenario with CCID-3 
    
                      DCCP Sender                     DCCP Receiver 
    
   Quick-Start      +----------------------------------------------+ 
   Request/Response | Quick-Start Request -->                      | 
                    |                    <-- Quick-Start Response  | 
                    | Quick-Start Approve -->                      | 
                    +----------------------------------------------+ 
                    +----------------------------------------------+ 
   Quick-Start      | Quick-Start Packets -->                      | 
   Mode             |                                              | 
                    |                    <-- Feedback from Receiver| 
                    +----------------------------------------------+ 
                    +---------------------------------------------- 
   Quick-Start      | Packets -->                                  | 
   Validation Phase |                                              | 
                    |                    <-- Feedback from Receiver| 
                    +----------------------------------------------+ 
   CCID-3             Packets --> 
   Congestion 
   Control                               <-- Feedback from Receiver 
    
          Figure 2.  The Quick-Start Mode and Validation Phase. 
    
   Figure 2 shows an example of the use of Quick-Start with CCID-3. 
    
3.2.7 Controlling Feedback Traffic on the Reverse Path 
    
   A CCID-3 receiver sends feedback at least once each RTT. Using 
   Quick-Start would not significantly increase traffic on the reverse 
   path. 
 
 
4. Discussion of Issues 
 
   XXX Note: This Section to be completed later, please send issues to 
   the authors XXX 
 
   Quick-Start [RFC4782] describes many paths where Quick-Start 
   Requests would not be approved.  These paths include all paths 
   containing routers, IP tunnels, MPLS paths, and the like that do not 
   support Quick-Start.  These paths also include paths with routers or 
  
Expires August 2007                                          [page 10] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
   middleboxes that drop packets containing IP options.  Quick-Start 
   requests could be difficult to approve over paths that include 
   multi-access layer-two networks.  [RFC4782] also describes 
   environments where the Quick-Start process could fail with false 
   positives, with the sender incorrectly assuming that the Quick-Start 
   request had been approved by all of the routers along the path.  As 
   a result of these concerns, and as a result of the difficulties and 
   seeming absence of motivation for routers such as core routers to 
   deploy Quick-Start, Quick-Start has been proposed as a mechanism 
   that could be of use in controlled environments, and not as a 
   mechanism that would be intended or appropriate for ubiquitous 
   deployment in the global Internet. 
    
   XXX Note: Need to consider implications of alternate paths, etc and 
   examine if there are specific issues. XXX 
    
4.1 Over-run and Quick-Start Validation  
 
   CCID-3 raises an issue in that the sender may continue to use the 
   capacity allocated by Quick-Start for a period that exceeds that 
   which TCP would have used. This over-run is a result of the less 
   frequent feedback interval (once per RTT rather than once for a few 
   packets) used by TFRC (i.e. CCID-3), and is bounded by the Quick-
   Start Validation Time.   
    
   The currently selected value is chosen as a compromise that reflects 
   the need to terminate quickly following loss of a feedback packet, 
   and the need to allow sufficient time for end host and router 
   processing as well as the different perceptions of the path RTT held 
   at the sender and receiver. Any reported loss results in immediate 
   action without waiting for completion of the validation period. 
 
    
5. Summary 
    
   Quick-Start with TCP has been normatively defined in RFC 4782 
   [RFC4782]. The appendix in RFC 4782 also discusses some issues when 
   Quick-Start is used with other protocols including DCCP, but does 
   specify the mechanisms to be used.  
    
   This document specifies the operation of DCCP with Quick-Start and 
   defines how Quick-Start operates when using CCID-2 and CCID-3.   
    
    
    
    
    
    
    
    
    


  
Expires August 2007                                          [page 11] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
6. IANA Considerations  
    
   This document requires IANA involvement for the assignment of a DCCP 
   Option Type from the DCCP Option Types Registry. The Option is known 
   as the "Quick-Start Response" Option and is defined in Section 
   2.2.1. It specifies a length value in the format used for options 
   numbered 32-128. 
    
   XXX This option is DCCP-Specific, not CCID-Specific. XXX 
    
    
7. Acknowledgments 
    
   The author gratefully acknowledges the previous work by Sally Floyd 
   to identify issues that impact Quick-Start for DCCP, and her 
   comments to improve this document. 
    
    
8. Security Considerations 
    
   Security issues are discussed in [RFC4782]. No new security issues 
   are raised within this document. 
    
    
9. References 
 
 
9.1 Normative References  
    
   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 
   Requirement Levels", BCP 14, RFC 2119, 1997. 
 
   [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 
   Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 
    
   [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 
   Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion 
   Control", RFC 4341, March 2006. 
 
   [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 
   Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: 
   TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. 
    
   [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
   Start for TCP and IP", RFC 4782, January 2007. 
    
    
    
9.2 Informative References 
       
   [RFC3390] Allman, M., Floyd, S., Partridge, C., "Increasing TCP's  
   Initial Window", RFRC 3390, October 2002. 
    
  
Expires August 2007                                          [page 12] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
   [ID.DCCP-FR] Kohler, E., Floyd, F., "Faster Restart for TCP  
   Friendly Rate Control (TFRC) ", IETF Work In Progress, 2007.  
    
    
10. Authors' Addresses 
    
   Godred Fairhurst 
   Department of Engineering 
   University of Aberdeen 
   Aberdeen, AB24 3UE 
   UK 
   Email: gorry@erg.abdn.ac.uk 
   Web: http://www.erg.abdn.ac.uk/users/Gorry 
    
   Arjuna Sathiaseelan 
   Department of Engineering 
   University of Aberdeen 
   Aberdeen, AB24 3UE 
   UK 
   Email: arjuna@erg.abdn.ac.uk 
   Web: http://www.erg.abdn.ac.uk/users/arjuna 
    
    
11. IPR Notices 
    
    
11.1 Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed  
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such  
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights. 
   Information on the procedures with respect to rights in RFC  
   documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf- 
   ipr@ietf.org. 
    
    
11.2 Disclaimer of Validity 
    
  
Expires August 2007                                          [page 13] 
INTERNET DRAFT Quick-Start for DCCP                          Feb 2007  
 
 
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
   IETF TRUST AND  THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
   FOR A PARTICULAR PURPOSE. 
    
12. Copyright Statement 
    
   Copyright (C) The IETF Trust (2007).  
    
   This document is subject to the rights, licenses and restrictions  
   contained in BCP 78, and except as set forth therein, the authors  
   retain all their rights.  
    
   Acknowledgment  
    
   Funding for the RFC Editor function is currently provided by the  
   Internet Society.  
    
    
    
    
    
    
   ------------------------------------------------------------------- 
    
   [RFC EDITOR NOTE:  
   This section must be deleted prior to publication] 
    
   DOCUMENT HISTORY 
    
   Individual Draft 00 
   This is the first presentation of this document. 
    
   [END of RFC EDITOR NOTE]  
 
 
 
 
 
  









  
Expires August 2007                                          [page 14]