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]