--- 1/draft-ietf-tsvwg-quickstart-03.txt 2006-06-16 01:12:32.000000000 +0200 +++ 2/draft-ietf-tsvwg-quickstart-04.txt 2006-06-16 01:12:32.000000000 +0200 @@ -1,14 +1,14 @@ Internet Engineering Task Force S. Floyd INTERNET-DRAFT M. Allman -draft-ietf-tsvwg-quickstart-03.txt ICIR -Expires: October 2006 A. Jain +draft-ietf-tsvwg-quickstart-04.txt ICIR +Expires: December 2006 A. Jain F5 Networks P. Sarolahti Nokia Research Center Quick-Start for TCP and IP Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes @@ -23,21 +23,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 2006. + This Internet-Draft will expire on December 2006. Abstract This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, 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). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is @@ -55,20 +55,31 @@ 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 is being 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. TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: + Changes from draft-ietf-tsvwg-quickstart-03: + + * Added a discussion of the lower limit of the rate request + of 80 kbps, from feedback from Gorry Fairhurst. + + * Added the QS Nonce to the QS Approved Rate. + From feedback from Gorry Fairhurst. + + * Moved the Related Work section to the appendix. + From feedback from Gorry Fairhurst. + Changes from draft-ietf-tsvwg-quickstart-02: * Some general editing. * Said that if the receiver receives a Quick-Start Request with a rate of zero, then the receiver SHOULD NOT send a Quick-Start response. And that if the sender receives an acknowledgement of its packet with no Quick-Start response, then the sender MUST assume that the request was denied, and send a Report of Approved Rate @@ -116,54 +127,52 @@ * Clarified in Section 3.3 on "Processing the Quick-Start Request at Routers" that a router will have to consider the previous Quick-Start requests in approving a new one. * In Section 9.3 on "Quick-Start with QoS-enabled Traffic", which says that routers are free to take into account the diff-serv codepoint in considering QS requests, clarified that routers are also free to take into account their own understanding of priorities. - * Added the Temporary bit to Appendix D on "Possible Additional + * Added the Temporary bit to Appendix on "Possible Additional Uses for the Quick-Start Option". Clarified that the Quick-Start mechanism is not designed to help routers achieve full link utilization. * Editing from feedback from Gorry Fairhurst. Changes from draft-ietf-tsvwg-quickstart-01: * Added a citation to SPAND: Speeding Up Short Data Transfers. * Added a sentence in Section 8.1 on "Implementation Issues for Processing Quick-Start Requests" about multi-access links. - * Mentioned the IP Router Alert option, RFC 2113, in Appendix - A.1.1. + * Mentioned the IP Router Alert option, RFC 2113, in Appendix. * Added a discussion of lower-than-best-effort service. * Added a few sentences about the requirements for randomness in the nonce. * Changed the name of the option from the Quick-Start Request Option to the Quick-Start Option. * Changed the semantics of the Reserved field to the Function field, adding that a Quick-Start option is only interpreted as a request if this field is zero. * Changed the "Reporting Approved Rate" option from a - "Possible Use" in Appendix D to a required use in Section 3.1, + "Possible Use" in Appendix to a required use in Section 3.1, to allow routers and receivers some protection against misbehaving senders. * Changes from feedback from Bob Briscoe: - - Added Appendix E about Sections 1-3 of + - Added Appendix about Sections 1-3 of Bob Briscoe's document. - Added a clarification that the approval of a Quick-Start request at a router does not affect the treatment of the subsequent arriving Quick-Start data packets. - - Added the one-way hash function as an alternate implementation for the QS Nonce. - Clarified the phrase "incrementally deployable", adding the following: "We note that while Quick-Start is incrementally deployable in this sense, a Quick-Start request can not be approved for a particular connection unless both end-nodes and all of the routers along the path have been configured to support Quick-Start." - Clarified semantics about additional rate. @@ -287,123 +297,123 @@ 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 16 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 20 3.3. Processing the Quick-Start Request at Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.1. Processing the Report of Approved Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 23 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 25 4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 26 4.2. The Quick-Start Response Option in the TCP - header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 28 + header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29 4.4. TCP: Receiving and Using the Quick-Start Response Packet . . . . . . . . . . . . . . . . . . . . . . . 29 4.5. TCP: Responding to a Loss of a Quick-Start - Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.6. TCP: A Quick-Start Request for a Larger Ini- tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 4.6.1. Interactions with Path MTU Discovery. . . . . . . . 32 + 4.6.1. Interactions with Path MTU Discovery. . . . . . . . 33 4.6.2. Quick-Start Request Packets that are Discarded by Routers or Middleboxes. . . . . . . . . . . . 33 4.7. TCP: A Quick-Start Request in the Middle of a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 34 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 35 - 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 35 - 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 36 + 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 36 + 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 37 6.1. Simple Tunnels That Are Compatible with - Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 38 + Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.1.1. Simple Tunnels that are Aware of Quick- Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2. Simple Tunnels That Are Not Compatible with - Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 40 - 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 41 + Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 41 + 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 42 7. The Quick-Start Mechanism in other Transport Pro- - tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 - 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 42 - 8.1. Determining the Rate to Request. . . . . . . . . . . . . 42 + tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 43 + 8.1. Determining the Rate to Request. . . . . . . . . . . . . 43 8.2. Deciding the Permitted Rate Request at a - Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 44 - 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 44 - 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 44 - 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 46 + Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 45 + 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 45 + 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 45 + 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 47 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 47 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 47 9.4.2. Receivers Lying about Whether the - Request was Approved . . . . . . . . . . . . . . . . . . . 48 + Request was Approved . . . . . . . . . . . . . . . . . . . 49 9.4.3. Receivers Lying about the Approved - Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 - 9.4.4. Collusion between Misbehaving Routers . . . . . . . 50 - 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 51 + Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 9.4.4. Collusion between Misbehaving Routers . . . . . . . 51 + 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 52 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 52 - 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 52 + 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 53 10. Implementation and Deployment Issues . . . . . . . . . . . . 53 10.1. Implementation Issues for Sending Quick- - Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 53 + Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54 10.2. Implementation Issues for Processing Quick- Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54 - 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 54 + 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 55 10.4. A Comparison with the Deployment Problems of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 - 11. Security Considerations. . . . . . . . . . . . . . . . . . . 56 - 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 57 - 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 57 + 11. Security Considerations. . . . . . . . . . . . . . . . . . . 57 + 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 58 + 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 58 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 58 - 13. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 58 - 13.1. Fast Start-ups without Explicit Information - from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 58 - 13.2. Optimistic Sending without Explicit Infor- - mation from Routers . . . . . . . . . . . . . . . . . . . . . 60 - 13.3. Fast Start-ups with other Information from - Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 - 13.4. Fast Start-ups with more Fine-Grained Feed- - back from Routers . . . . . . . . . . . . . . . . . . . . . . 61 - 13.5. Fast Start-ups with Lower-Than-Best-Effort - Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 - 14. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 63 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 - A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 63 - A.1. Alternate Mechanisms for the Quick-Start - Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 63 - A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 64 - A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 65 - A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 66 - A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 67 - A.4. Quick-Start Semantics: Total Rate or Addi- - tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 68 - A.5. Alternate Responses to the Loss of a Quick- - Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 69 - A.6. Why Not Include More Functionality?. . . . . . . . . . . 70 - A.7. Alternate Implementations for a QuickStart - Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 - A.7.1. An Alternate Proposal for the Quick- - Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 73 - A.7.2. The Earlier Request-Approved QuickStart - Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . . 74 - B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 75 - C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 76 - D. Possible Additional Uses for the Quick-Start - Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 - E. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 79 - E.1. Potential Deployment Scenarios . . . . . . . . . . . . . 80 - E.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 80 - E.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 81 - E.4. Models of Under-Utilization. . . . . . . . . . . . . . . 82 - E.5. Router Algorithms as Local Policy. . . . . . . . . . . . 82 - E.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 83 - Normative References . . . . . . . . . . . . . . . . . . . . . . 83 - Informative References . . . . . . . . . . . . . . . . . . . . . 84 - AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 90 - Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 90 + 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 58 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 + A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 59 + A.1. Fast Start-ups without Explicit Information + from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 59 + A.2. Optimistic Sending without Explicit Informa- + tion from Routers . . . . . . . . . . . . . . . . . . . . . . 61 + A.3. Fast Start-ups with other Information from + Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 + A.4. Fast Start-ups with more Fine-Grained Feed- + back from Routers . . . . . . . . . . . . . . . . . . . . . . 63 + A.5. Fast Start-ups with Lower-Than-Best-Effort + Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 + B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 64 + B.1. Alternate Mechanisms for the Quick-Start + Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 64 + B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 64 + B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 65 + B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 66 + B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 68 + B.4. Quick-Start Semantics: Total Rate or Addi- + tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 69 + B.5. Alternate Responses to the Loss of a Quick- + Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 71 + B.6. Why Not Include More Functionality?. . . . . . . . . . . 71 + B.7. Alternate Implementations for a QuickStart + Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 + B.7.1. An Alternate Proposal for the Quick- + Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 75 + B.7.2. The Earlier Request-Approved QuickStart + Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . . 75 + C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 76 + D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 78 + E. Possible Additional Uses for the Quick-Start + Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 + F. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 81 + F.1. Potential Deployment Scenarios . . . . . . . . . . . . . 81 + F.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 81 + F.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 83 + F.4. Models of Under-Utilization. . . . . . . . . . . . . . . 83 + F.5. Router Algorithms as Local Policy. . . . . . . . . . . . 84 + F.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 84 + Normative References . . . . . . . . . . . . . . . . . . . . . . 85 + Informative References . . . . . . . . . . . . . . . . . . . . . 85 + AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 90 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 92 + Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 92 1. Introduction Each connection begins with a question: "What is the appropriate sending rate for the current network path?" The question is not answered explicitly, but each TCP connection determines the sending rate by probing the network path and altering the congestion window (cwnd) based on perceived congestion. Each TCP connection starts with a pre-configured initial congestion window (ICW). Currently, TCP allows an initial window of between one and four MSS-sized @@ -638,21 +648,21 @@ 3.1. The Quick-Start Option for IPv4 The Quick-Start Request for IPv4 is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option | Length=8 | Func. | Rate | QS TTL | | | | 0000 |Request| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | QS Nonce | | + | QS Nonce | R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. The Quick-Start Option for IPv4. A Quick-Start Request. The first byte contains the option field, which includes the one-bit copy flag, the 2-bit class field, and the 5-bit option number (to be assigned by IANA). The second byte contains the length field, indicating an option @@ -672,34 +682,35 @@ sender.) The QS TTL is used by the sender to detect if all of the routers along the path understood and approved the Quick-Start option. For a Rate Request, the transport sender MUST calculate and store the TTL Diff, the difference between the IP TTL value and the QS TTL value in the Quick-Start request packet, as follows: TTL Diff = ( IP TTL - QS TTL ) mod 256 (1) - For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce and a two- - bit Reserved field. The sender SHOULD set the reserved field to - zero, and routers and receivers SHOULD ignore the reserved field. - The sender SHOULD set the 30-bit QS Nonce to a random value. + For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed + in Section 3.4, and a two-bit Reserved field. The sender SHOULD set + the reserved field to zero, and routers and receivers SHOULD ignore + the reserved field. The sender SHOULD set the 30-bit QS Nonce to a + random value. The sender initializes the Rate Request to the desired sending rate, including an estimate of the transport and IP header overhead. The encoding function for the Rate Request sets the request rate to K*2^N bps (bits per second), for N the value in the Rate Request field, and for K set to 40,000. For N=0, the rate request would be set to zero, regardless of the encoding function. This is illustrated in Table 1 below. For the four-bit Rate Request field, the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings - that were considered for the Rate Request are given in Appendix A.2. + that were considered for the Rate Request are given in Appendix B.2. N Rate Request (in Kbps) --- ------------------- 0 0 1 80 2 160 3 320 4 640 5 1,280 6 2,560 @@ -720,47 +731,53 @@ discusses the Quick-Start Response from the TCP receiver to the TCP sender, and Section 4.4 discusses the TCP sender's mechanism for determining if a Quick-Start Request has been approved. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option | Length=8 | Func. | Rate | Not Used | | | | 1000 | Report| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Not Used | + | QS Nonce | R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. The Quick-Start Option for IPv4. Report of Approved Rate. If the Function field in the third byte of the Quick-Start Option is set to "1000", then the Quick-Start Option is a Report of Approved Rate. In this case the second four bits in the third byte are the Rate Report field, formatted exactly as in the Rate Request field in - a Rate Request. For a Report of Approved Rate, the last five bytes - of the Quick-Start Option are not used. + a Rate Request. For a Report of Approved Rate, the fourth byte of + the Quick-Start Option are not used. Bytes 5-8 contain a 30-bit QS + Nonce and a two- bit Reserved field. After an approved Rate Request, the sender MUST report the Approved Rate, using a Quick-Start Option configured as a Report of Approved - Rate with the Rate Report field set to the approved rate. The + Rate with the Rate Report field set to the approved rate, and the QS + Nonce set to the QS Nonce sent in the Quick-Start Request. The packet containing the Report of Approved Rate MUST be either a control packet sent before the first Quick-Start data packet, or a Quick-Start Option in the first data packet itself. The Report of Approved Rate does not have to be sent reliably; for example, if the approved rate is reported in a separate control packet, the sender does not necessarily know if the control packet has been dropped in the network. If the packet contained the Quick-Start Request is acknowledged, but the acknowledgement packet does not contain a Quick-Start Response, then the sender MUST assume that the Quick- Start Request was denied, and set a Report of Approved Rate with a - rate of zero. + rate of zero. Routers may choose to ignore the Report of Approved + Rate, or to use the Report of Approved Rate but ignore the QS Nonce. + Alternately, some routers that use the Report of Approved Rate may + choose to match the QS Nonce, masked by the approved rate, with the + QS Nonce seen in the original request. If the Rate Request is denied, the sender MUST sent a Report of Approved Rate with the Rate Report field set to zero. We note that unlike a Quick-Start Request sent at the beginning of a connection, when a Quick-Start Request is sent in the middle of a connection, the connection could already have an established congestion window or sending rate. The Rate Request is the requested total rate for the connection, including the current rate of the connection; the Rate Request is *not* a request for an @@ -1131,21 +1148,21 @@ responds to the receipt of a Quick-Start Request with a Quick-Start Response, using the Quick-Start Response Option in the TCP header. TCP's Quick-Start Response option is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length=8 | Resv. | Rate | TTL Diff | | | | |Request| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | QS Nonce | | + | QS Nonce | R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. The Quick-Start Response option in the TCP header. The first byte of the Quick-Start Response option contains the option kind, identifying the TCP option (to be assigned by IANA). The second byte of the Quick-Start Response option contains the option length in bytes. The length field MUST be set to 8 bytes. @@ -1314,21 +1331,21 @@ Start packet, TCP MUST revert to the default congestion control procedures that would have been used if the Quick-Start request had not been approved. For example, if Quick-Start is used for setting the initial window, and a packet from the initial window is lost or marked, then the TCP sender MUST then slow-start with the default initial window that would have been used if Quick-Start had not been used. In addition to reverting to the default congestion control mechanisms, the sender MUST take into account that the Quick-Start congestion window was too large. Thus, the sender SHOULD decrease ssthresh to at most half the number of Quick-Start packets that were - successfully transmitted. Section A.5 discusses possible + successfully transmitted. Section B.5 discusses possible alternatives in responding to the loss of a Quick-Start packet. If a Quick-Start packet is lost or ECN-marked, then the sender SHOULD NOT make future Quick-Start requests for this connection. We note that ECN [RFC3168] MAY be used with Quick-Start. As is always the case with ECN, the sender's congestion control response to an ECN-marked Quick-Start packet is the same as the response to a dropped Quick-Start packet, thus reverting to slow start in the case of Quick-Start packets marked as experiencing congestion. @@ -1867,21 +1884,21 @@ underutilized. A simple way for the router to keep track of the potential bandwidth from recently-approved requests is to maintain two counters, one for the total aggregate Rate Requests that have been approved in the current time interval [T1, T2], and one for the total aggregate Rate Requests approved over a previous time interval [T0, T1]. However, this document doesn't specify router algorithms for approving Quick- Start requests, or make requirements for the appropriate time intervals for remembering the aggregate approved Quick-Start - bandwidth. A possible router algorithm is given in Appendix D, and + bandwidth. A possible router algorithm is given in Appendix E, and more discussion of these issues is available in [SAF06].) * If the router's output link has been underutilized and the aggregate of the Quick Start Request Rate options granted is low enough to prevent a near-term bandwidth shortage, then the router could approve the Quick-Start Request. Section 10.2 discusses some of the implementation issues in processing Quick-Start requests at routers. [SAF06] discusses the range of possible Quick-Start algorithms at the router for deciding @@ -2519,41 +2536,76 @@ In both cases the name of the option would be "QS - Quick-Start", with this document as the reference document. 12.2. TCP Option Quick-Start also requires that a TCP Option Number be allocated. The Length would be 4, and the Meaning would be "Quick-Start Request", with this document as the reference document. -13. Related Work +13. Conclusions + + We are presenting the Quick-Start mechanism as a simple, + understandable, and incrementally-deployable mechanism that would be + sufficient to allow some connections to start up with large initial + rates, or large initial congestion windows, in overprovisioned, + high-bandwidth environments. We expect there will be an increasing + number of overprovisioned, high-bandwidth environments where the + Quick-Start mechanism, or another mechanism of similar power, could + be of significant benefit to a wide range of traffic. We are + presenting the Quick-Start mechanism as a request for the community + to provide feedback and experimentation on issues relating to Quick- + Start. + +14. Acknowledgements + + The authors wish to thank Mark Handley for discussions of these + issues. The authors also thank the End-to-End Research Group, the + Transport Services Working Group, and members of IPAM's program on + Large Scale Communication Networks for both positive and negative + feedback on this proposal. We thank Srikanth Sundarrajan for the + initial implementation of Quick-Start in the NS simulator, and for + the initial simulation study. Many thanks to David Black and Joe + Touch for extensive feedback on QuickStart and IP tunnels. We also + thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom + Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi + and Vern Paxson for feedback. Thanks also to Gorry Fairhurst for + the suggestion of adding the QS Nonce to the Report of Approved + Rate. This draft builds upon the concepts described in [RFC3390], + [AHO98], [RFC2415], and [RFC3168]. Some of the text on Quick-Start + in tunnels was borrowed directly from RFC 3168. + + This document is the development of a proposal originally by Amit + Jain for Initial Window Discovery. + +A. Related Work The Quick-Start proposal, taken together with HighSpeed TCP [RFC3649] or other transport protocols for high-bandwidth transfers, could go a significant way towards extending the range of performance for best-effort traffic in the Internet. However, there are many things that the Quick-Start proposal would not accomplish. Quick-Start is not a congestion control mechanism, and would not help in making more precise use of the available bandwidth, that is, of achieving the goal of high throughput with low delay and low packet loss rates. Quick-Start would not give routers more control over the decrease rates of active connections. In addition, any evaluation of Quick-Start must include a discussion of the relative benefits of approaches that use no explicit information from routers, and of approaches that use more fine- grained feedback from routers as part of a larger congestion control mechanism. We discuss several classes of proposals in the sections below. -13.1. Fast Start-ups without Explicit Information from Routers +A.1. Fast Start-ups without Explicit Information from Routers One possibility would be for senders to use information from the packet streams to learn about the available bandwidth, without explicit information from routers. These techniques would not allow a start-up as fast as that available from Quick-Start in an underutilized environment; one has to have sent some packets already to use the packet stream to learn about available bandwidth. However, these techniques could allow a start-up considerably faster than the current slow-start. While it seems clear that approaches *without* explicit feedback from the routers will be strictly less @@ -2618,21 +2670,21 @@ (2) Explicit feedback is more reliable than implicit feedback: Techniques that attempt to assess the available bandwidth at connection startup using implicit techniques are more error-prone than techniques that involve every element in the network path. While explicit information from the network can be wrong, it has a much better chance of being appropriate than an end-host trying to *estimate* an appropriate sending rate using "block box" probing techniques of the entire path. -13.2. Optimistic Sending without Explicit Information from Routers +A.2. Optimistic Sending without Explicit Information from Routers Another possibility that has been suggested [S02] is for the sender to start with a large initial window without explicit permission from the routers and without bandwidth estimation techniques, and for the first packet of the initial window to contain information such as the size or sending rate of the initial window. The proposal would be that congested routers would use this information in the first data packet to drop or delay many or all of the packets from that initial window. In this way a flow's optimistically-large initial window would not force the router to drop packets from @@ -2658,21 +2711,21 @@ (3) Distributed Denial of Service attacks: A third question would be the potential role of optimistic senders in amplifying the damage done by a Distributed Denial of Service (DDoS) attack (assuming attackers use conformant congestion control in the hopes of "flying under the radar"). (4) Performance hits if a packet is dropped: A fourth issue would be to quantify the performance hit to the connection when a packet is dropped from one of the initial windows. -13.3. Fast Start-ups with other Information from Routers +A.3. Fast Start-ups with other Information from Routers There have been several proposals somewhat similar to Quick-Start, where the transport protocol collects explicit information from the routers along the path. An IP Option about the free buffer size: In related work, [P00] investigates the use of a slightly different IP option for TCP connections to discover the available bandwidth along the path. In that proposal, the IP option would query the routers along the path about the smallest available free buffer @@ -2688,33 +2741,32 @@ bandwidth along a path. ETEN: Additional proposals for end nodes to collect explicit information from routers include one variant of Explicit Transport Error Notification (ETEN), which includes a cumulative mechanism to notify endpoints of aggregate congestion statistics along the path [KAPS02]. (A second variant in [KSEPA04] does not depend on cumulative congestion statistics from the network.) -13.4. Fast Start-ups with more Fine-Grained Feedback from Routers +A.4. Fast Start-ups with more Fine-Grained Feedback from Routers Proposals for more fine-grained congestion-related feedback from routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking - [K03]. Section A.6 discusses in more detail the relationship + [K03]. Section B.6 discusses in more detail the relationship between Quick-Start and proposals for more fine-grained per-packet feedback from routers. XCP: Proposals such as XCP for new congestion control mechanisms based on more feedback from routers are more powerful than Quick-Start, but also are more complex to understand and more difficult to deploy. - XCP routers maintain no per-flow state, but provide more fine- grained feedback to end-nodes than the one-bit congestion feedback of ECN. The per-packet feedback from XCP can be positive or negative, and specifies the increase or decrease in the sender's congestion window when this packet is acknowledged. XCP is a full- fledge congestion control scheme, whereas Quick-Start represents a quick check to determine if the network path is significantly underutilized such that a connection can start faster and then fall back to TCP's standard congestion control algorithms. @@ -2719,21 +2771,21 @@ back to TCP's standard congestion control algorithms. AntiECN: The AntiECN proposal is for a single bit in the packet header that routers could set to indicate that they are underutilized. For each TCP ACK arriving at the sender indicating that a packet has been received with the Anti-ECN bit set, the sender would be able to increase its congestion window by one packet, as it would during slow-start. -13.5. Fast Start-ups with Lower-Than-Best-Effort Service +A.5. Fast Start-ups with Lower-Than-Best-Effort Service There have been proposals for routers to provide a Lower Effort differentiated service that would be lower than best effort [RFC3662]. Such a service could carry traffic for which delivery is strictly optional, or could carry traffic that is important but that has low priority in terms of time. Because it does not interfere with best-effort traffic, Lower Effort services could be used by transport protocols that start-up faster than slow-start. For example, [SGF05] is a proposal for the transport sender to use low- priority traffic for much of the initial traffic, with routers @@ -2748,66 +2800,32 @@ TCP connections to use the bandwidth unused by TCP and other traffic in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use the default slow-start mechanisms of TCP. We note that Quick-Start is quite different from either a Lower Effort service or a below-best-effort variant of TCP. Unlike these proposals, Quick-Start is intended to be useful for best-effort traffic that wishes to receive at least as much bandwidth as competing best-effort connections. -14. Conclusions - - We are presenting the Quick-Start mechanism as a simple, - understandable, and incrementally-deployable mechanism that would be - sufficient to allow some connections to start up with large initial - rates, or large initial congestion windows, in overprovisioned, - high-bandwidth environments. We expect there will be an increasing - number of overprovisioned, high-bandwidth environments where the - Quick-Start mechanism, or another mechanism of similar power, could - be of significant benefit to a wide range of traffic. We are - presenting the Quick-Start mechanism as a request for the community - to provide feedback and experimentation on issues relating to Quick- - Start. - -15. Acknowledgements - - The authors wish to thank Mark Handley for discussions of these - issues. The authors also thank the End-to-End Research Group, the - Transport Services Working Group, and members of IPAM's program on - Large Scale Communication Networks for both positive and negative - feedback on this proposal. We thank Srikanth Sundarrajan for the - initial implementation of Quick-Start in the NS simulator, and for - the initial simulation study. Many thanks to David Black and Joe - Touch for extensive feedback on QuickStart and IP tunnels. We also - thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom - Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi - and Vern Paxson for feedback. This draft builds upon the concepts - described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of - the text on Quick-Start in tunnels was borrowed directly from RFC - 3168. - - This document is the development of a proposal originally by Amit - Jain for Initial Window Discovery. - -A. Design Decisions +B. Design Decisions -A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP +B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP This document has proposed using an IP Option for the Quick-Start Request from the sender to the receiver, and using transport mechanisms for the Quick-Start Response from the receiver back to the sender. In this section we discuss alternate mechanisms, and consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols could be used for delivering the Quick-Start Request. -A.1.1. ICMP +B.1.1. ICMP Being a control protocol used between Internet nodes, one could argue that ICMP is the ideal method for requesting a permission for faster startup from routers. The ICMP header is above the IP header. Quick-Start could be accomplished with ICMP as follows: If the ICMP protocol is used to implement Quick-Start, the equivalent of the Quick-Start IP option would be carried in the ICMP header of the ICMP Quick-Start Request. The ICMP Quick-Start Request would have to pass by the routers on the path to the receiver, possibly using the IP Router Alert option [RFC2113]. A router that approves @@ -2851,21 +2869,21 @@ correct operation of ICMP Quick-Start. Unauthenticated out-of-band ICMP messages could enable some types of attacks by third-party malicious hosts that are not possible when the control information is carried in-band with the IP packets that can only be altered by the routers on the connection path. Finally, as a minor concern, using ICMP would cause a small amount of additional traffic in the network, which is not the case when using IP options. -A.1.2. RSVP +B.1.2. RSVP With some modifications RSVP [RFC2205] could be used as a bearer protocol for carrying the Quick-Start Requests. Because routers are expected to process RSVP packets more extensively than the normal transport protocol IP packets, delivering a Quick-Start rate request using an RSVP packet would seem an appealing choice. However, Quick- Start with RSVP would require a few differences from the conventional usage of RSVP. Quick-Start would not require periodical refreshing of soft state, because Quick-Start does not require per- connection state in routers. Quick-Start Requests would be @@ -2898,21 +2916,21 @@ for making the Quick-Start Request also applies to the RSVP case. If the Quick-Start Request was transmitted in a separate packet instead of as an IP option, the transport protocol packet delivery would not be delayed due to IP option processing at the routers, and the initial transport packets would reach their destination more reliably. The possible disadvantages of using ICMP and RSVP are also expected to be similar: middleboxes in the network may not be able to forward the Quick-Start Request messages, and the IP tunnels might cause problems for processing the Quick-Start Requests. -A.2. Alternate Encoding Functions +B.2. Alternate Encoding Functions In this section we look at alternate encoding functions for the Rate Request field in the Quick-Start Request. The main requirements for this function is that it should have a sufficiently wide range for the requested rate. There is no need for overly-fine-grained precision in the requested rate. Similarly, while it would be attractive for the encoding function to be easily computable, it is also possible for end-nodes and routers to simply store the table giving the mapping between the value N in the Rate Request field, and the actual rate request f(N). In this section we consider @@ -2937,20 +2955,39 @@ unnecessarily large request range. For a four-bit Rate Request field, the upper limit on the rate request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps would be fine for the Quick-Start rate request, and that connections wishing to start up with a higher initial sending rate should be encouraged to use other mechanisms, such as the explicit reservation of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, then five or six bits could be used for the Rate Request field. + The lower limit of 80 Kbps could be useful for flows with round-trip + times of a second or more. For a flow with a round-trip time of one + second, as is typical in some wireless networks, the TCP initial + window of 4380 bytes allowed by RFC 3390 (given appropriate packet + sizes) would translate to an initial sending rate of 35 Kbps. Thus, + for TCP flows, a rate request of 80 Kbps could be useful for some + flows with large round-trip times. + + The lower limit of 80 Kbps could also be useful for some non-TCP + flows that send small packets, with at most one small packet every + 10 ms. A rate request of 80 Kbps would translate to a rate of a + hundred 100-byte packets per second (including packet headers). + While some small-packet flows with large round-trip times might find + a smaller rate request of 40 Kbps to be useful, our assumption is + that a lower limit of 80 Kbps on the rate request will be generally + sufficient. Again, if the lower limit of 80 kbps was not + acceptable, then extra bits could be used for the Rate Request + field. + If the granularity of factors of two was too coarse, then the encoding function could use a base less than two. An alternate form for the encoding function would be to use a hybrid of linear and exponential functions. A mantissa and exponent representation: Section 4.4 of [B05] suggests a mantissa and exponent representation for the Quick-Start encoding function. With e and f as the binary numbers in the exponent and mantissa fields, and with 0 <= f < 1, this would represent the rate (1+f)*2^e. [B05] suggests a mantissa @@ -2959,21 +2996,21 @@ encoding that is less coarse than the powers-of-two encoding used in this document. Constraints of the transport protocol: We note that the Rate Request is also constrained by the abilities of the transport protocol. For example, for TCP with Window Scaling, the maximum window is at most 2**30 bytes. For a TCP connection with a long, 1 second round-trip time, this would give a maximum sending rate of 1.07 Gbps. -A.3. The Quick-Start Request: Packets or Bytes? +B.3. The Quick-Start Request: Packets or Bytes? One of the design questions is whether the Rate Request field should be in bytes per second or in packets per second. We discuss this separately from the perspective of the transport, and from the perspective of the router. For TCP, the results from the Quick-Start Request are translated into a congestion window in bytes, using the measured round-trip time and the MSS. This window applies only to the bytes of data payload, and does not include the bytes in the TCP or IP packet @@ -3023,21 +3060,21 @@ are discussed in more detail in RFC 3390 [RFC3390]. For a Quick-Start Request in bytes per second, the transport senders would have the additional complication of estimating the bandwidth usage added by the packet headers. We have chosen a Rate Request field in bytes per second rather than in packets per second because it seems somewhat more robust, particularly to routers. -A.4. Quick-Start Semantics: Total Rate or Additional Rate? +B.4. Quick-Start Semantics: Total Rate or Additional Rate? For a Quick-Start Request sent in the middle of a connection, there are two possible semantics for the Rate Request field, as follows: (1) Total Rate: The requested Rate Request is the requested total rate for the connection, including the current rate; or (2) Additional Rate: The requested Rate Request is the requested increase in the total rate for that connection, over and above the current sending rate. @@ -3067,25 +3104,25 @@ The Additional Rate semantics also lends itself to gaming by the connection, with senders sending frequent Quick-Start Requests in the hope of gaining a higher rate. If the router is granting the same maximum rate for all rate requests, then there is little benefit to a connection of sending a rate request over and over again. However, if the router is granting an *additional* rate with each rate request, over and above the current sending rate, then it is in a connection's interest to send as many rate requests as possible, even if very few of them are in fact granted. - Appendix D discusses a Report of Current Sending Rate as one + Appendix E discusses a Report of Current Sending Rate as one possible function in the Quick-Start Option. However, we have not standardized this possible use at this time. -A.5. Alternate Responses to the Loss of a Quick-Start Packet +B.5. Alternate Responses to the Loss of a Quick-Start Packet Section 4.5 discusses TCP's response to the loss of a Quick-Start packet in the initial window. This section discusses several alternate responses. One possible alternative to reverting to the default slow-start after the loss of a Quick-Start packet from the initial window would have been to halve the congestion window and continue in congestion avoidance. However, we note that this would not have been a desirable response for either the connection or for the network as a @@ -3108,28 +3145,28 @@ at the router, and we cannot recommend it at this time. Another drawback of approaches that don't revert back to slow-start when a Quick-Start packet in the initial window is dropped is that such approaches could give the TCP receiver a greater incentive to lie about the Quick-Start request. If the sender reverts to slow- start when a Quick-Start packet in the initial window is dropped, this diminishes the benefit a receiver would get from a Quick-Start request that resulted in a dropped or ECN-marked packet. -A.6. Why Not Include More Functionality? +B.6. Why Not Include More Functionality? This proposal for Quick-Start is a rather coarse-grained mechanism that would allow a connection to use a higher sending rate along underutilized paths, but that does not attempt to provide a next- generation transport protocol or congestion control mechanism, and does not attempt the goal of providing very high throughput with - very low delay. As Section 13.4 discusses, there are a number of + very low delay. As Section A.4 discusses, there are a number of proposals such as XCP, MaxNet, and AntiECN for more fine-grained per-packet feedback from routers than the current congestion control mechanisms, that do attempt these more ambitious goals. Compared to proposals such as XCP and AntiECN, Quick-Start offers much less control. Quick-Start does not attempt to provide a new congestion control mechanism, but simply to get permission from routers for a higher sending rate at start-up, or after an idle period. Quick-Start can be thought of as an "anti-congestion- control" mechanism, that is only of any use when all of the routers @@ -3254,23 +3291,23 @@ needs for new congestion control mechanisms. This could be viewed as a positive step towards meeting some of the more pressing current needs with a simple and reasonably deployable mechanism, or alternately, as a negative step of unnecessarily delaying more fundamental changes. Without answering this question, we would note that our own approach tends to favor the incremental deployment of relatively simple mechanisms, as long as the simple mechanisms are not short-term hacks but mechanisms that lead the overall architecture in the fundamentally correct direction. -A.7. Alternate Implementations for a QuickStart Nonce +B.7. Alternate Implementations for a QuickStart Nonce -A.7.1. An Alternate Proposal for the QuickStart Nonce +B.7.1. An Alternate Proposal for the QuickStart Nonce An alternate proposal for the Quick-Start Nonce from [B05] would be for an n-bit field for the QS Nonce, with the sender generating a random nonce when it generates a Quick-Start Request. Each router that reduces the Rate Request by r would hash the QS nonce r times, using a one-way hash function such as MD5 [RFC1321] or the secure hash 1 [SHA1]. The receiver returns the QS nonce to the sender. Because the sender knows the original value for the nonce, and the original rate request, the sender knows the total number of steps s that the rate has been reduced. The sender then hashes the original @@ -3283,21 +3320,21 @@ Quick-Start request, and from the sender in verifying the nonce returned by the receiver. As reported in [B05], routers could protect themselves from processor exhaustion attacks by limiting the rate at which they will approve reductions of Quick-Start requests. Both the Function field and the Reserved field in the Quick-Start Option would allow the extension of Quick-Start to use Quick-Start requests with the alternate proposal for the Quick-Start Nonce, if it was ever desired. -A.7.2. The Earlier Request-Approved QuickStart Nonce +B.7.2. The Earlier Request-Approved QuickStart Nonce An earlier version of this document included a Request-Approved QuickStart Nonce (QS Nonce) that was initialized by the sender to a non-zero, `random' eight-bit number, along with a QS TTL that was initialized to the same value as the TTL in the IP header. The Request-Approved QuickStart Nonce would have been returned by the transport receiver to the transport sender in the Quick-Start Response. A router could deny the Quick-Start request by failing to decrement the QS TTL field, by zeroing the QS Nonce field, or by deleting the Quick-Start Request from the packet header. The QS @@ -3318,21 +3355,21 @@ because of option processing for the Quick-Start Request. In the current specification, this "self-terminating" property is provided by Quick-Start-capable routers hopefully either deleting the Quick- Start Option or zeroing the Rate Request field when they deny a request. Because the current specification uses a random initial value for the QS TTL, Quick-Start-capable routers can't tell if the Quick-Start Request is invalid because of non-Quick-Start-capable routers upstream. This is the cost of using a design that makes it difficult for the receiver to cheat about the value of the QS TTL. -B. Quick-Start with DCCP +C. Quick-Start with DCCP DCCP is a new transport protocol for congestion-controlled, unreliable datagrams, intended for applications such as streaming media, Internet telephony, and on-line games. In DCCP, the application has a choice of congestion control mechanisms, with the currently-specified Congestion Control Identifiers (CCIDs) being CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an equation-based form of congestion control. We refer the reader to [KHF05] for a more detailed description of DCCP, and of the congestion control mechanisms. @@ -3396,21 +3433,21 @@ been requested. (3) When does the sender decide there has been no feedback from the receiver? As in the case of the initial sending rate, it would seem prudent to reduce the sending rate if no feedback is received from the receiver in at least two round-trip times. It seems likely that in this case, the sending rate should be reduced to the sending rate that would have been used if no Quick-Start request had been approved. -C. Possible Router Algorithm +D. Possible Router Algorithm This specification does not tightly define the algorithm a router uses when deciding whether to approve a Quick-Start Rate Request or whether and how to reduce a Rate Request. A range of algorithms is likely useful in this space and we consider the algorithm a particular router uses to be a local policy decision. In addition, we believe that additional experimentation with router algorithms is necessary to have a solid understanding of the dynamics various algorithms impose. However, we provide one particular algorithm in this appendix as an example and as a framework for thinking about @@ -3476,21 +3513,21 @@ Also note that given that Rate Requests are fairly coarse, the approved rate should be rounded down when it does not fall exactly on one of the rates allowed by the encoding scheme. Routers that wish to keep close track of the allocated Quick-Start bandwidth could use Approved Rate reports to learn when rate requests had been decremented downstream in the network, and also to learn when a sender begins to use the approved Quick-Start request. -D. Possible Additional Uses for the Quick-Start Option +E. Possible Additional Uses for the Quick-Start Option The Quick-Start Option contains a four-bit Function field in the third byte, enabling additional uses to be defined for the Quick- Start Option. In this section we discuss some of the possible additional uses that have been discussed for Quick-Start. The Function field makes it easy to add new functions for the Quick- Start Option. Report of Current Sending Rate: A Quick-Start Request with the `Report of Current Sending Rate' codepoint set in the Function field @@ -3536,30 +3573,30 @@ Do Not Decrement: A Do Not Decrement codepoint could be used for a Quick-Start request where the sender would rather have the request denied than to have the rate request decremented in the network. This could be used if the sender was only interested in using Quick- Start if the original rate request was approved. Temporary Bandwidth Use: A Temporary codepoint has been proposed to indicate that a connection would only use the requested bandwidth for a single time interval. -E. Feedback from Bob Briscoe +F. Feedback from Bob Briscoe [B05] is a review of an earlier version of the Quick-Start proposal that discusses a number of potential problems with Quick-Start, and argues for an alternate approach for policing congestion in networks using re-feedback [BJCG+05,BJS05]. However, [B05] didn't oppose the move to Quick-Start to experimental status as long as its applicability is made clear. -E.1. Potential Deployment Scenarios +F.1. Potential Deployment Scenarios [B05] argues that because the sender's trustworthiness is not necessarily verified, Quick-Start, if it is remain stateless, should be confined to environments where every source is trusted. Section 3.2 of [B05] argues that either (1) Quick-Start should be recommended for deployment only in trusted environments, or (2) Quick-Start could be recommended for deployment also in untrusted environments, with flow state required at some or all routers. Since [B05], we have added the Report of Approved Rate as a required @@ -3572,21 +3609,21 @@ clearly not recommending Quick-Start for widespread deployment in the global Internet, we also don't feel the need to explicitly restrict its deployment to environments where every source is trusted, or to explicitly require per-flow state at Quick-Start routers. We assume that Quick-Start will only be enabled at routers if the system administrators feel either that they have sufficient trust in senders, sufficient policing mechanisms for checking for misbehaving nodes, or sufficient oversite to disable Quick-Start if it is determined to be causisng problems.. -E.2. Misbehaving Senders and Receivers +F.2. Misbehaving Senders and Receivers Some of the criticisms of Quick-Start in [B05] are criticisms for mechanisms that allocate rates to senders, but this is not what Quick-Start does. Quick-Start requests apply to individual connections, not to unique addresses or unique tuples of addresses. Further, the approval by routers of Quick-Start requests does not result in an allocation of bandwidth for the sender making that request; the approval by routers does not result in any allocation of bandwidth at all. The state used by routers from past Quick- Start approvals is used only to guide the router in its approval or @@ -3626,21 +3663,21 @@ compared to non-Quick-Start data packets. Thus, a sender's claim that its data results from a previous Quick-Start request should make no difference in how those data packets are treated at routers. The approval of a Quick-Start request is not a promise by the router that the subsequent data packets will receive differential treatment at the router; it is only a statement from the router that the router believes that the Quick-Start data packets will not change the current under-utilized state of the router. We have clarified this in Section 3.3 of this document. -E.3. Fairness +F.3. Fairness In its abstract, [B05] says the following: "Because traffic variance will always blur the boundary, we argue that under-utilisation should be treated as the extreme of a spectrum where fairness is always an issue to some extent." The specification for Quick-Start now says in section 2 the following: "A router should only approve a Quick-Start request if the output link is underutilized, and if the router judges that the output link will continue to be underutilized if the request is @@ -3638,87 +3675,88 @@ In its abstract, [B05] says the following: "Because traffic variance will always blur the boundary, we argue that under-utilisation should be treated as the extreme of a spectrum where fairness is always an issue to some extent." The specification for Quick-Start now says in section 2 the following: "A router should only approve a Quick-Start request if the output link is underutilized, and if the router judges that the output link will continue to be underutilized if the request is approved." + We changed the quote "for a mechanism for requesting an initial sending rate in an underutilized environment, the fairness issues of a general congestion control mechanism go away" to the following: "because Quick-Start is a mechanism for requesting an initial sending rate in an underutilized environment, its fairness issues are less severe than those of a general congestion control - mechanism" in section A.6 However, we did not add the sentence + mechanism" in section B.6 However, we did not add the sentence recommended in section 3.4 of [B05], that "Quick-Start is targeted at an experimental environment where the more intractable issues can be set aside". In particular, we don't agree that Quick-Start needs to be targeted only for environments where fairness is not an issue. -E.4. Models of Under-Utilization +F.4. Models of Under-Utilization [B05] states that "One of the under-utilisation assumptions I had in my head while reading the paper was that any one host is generally able to over-fill available capacity, but that, given a high rate, the flow would end quickly." We are sorry that this is the model that the author inferred from the draft, but we can give assurances that this `one big flow at a time" model was *never* the implicit or explicit model underlying the Quick-Start design. (We would also note that every version of this document since the first version back in 2002 has discussed router responses when the router experiences a flood of Quick-Start requests.) [B05] also says the following: "By reverse engineering this algorithm, it was possible to guess that there was an assumption that host capacity was smaller than the network's, so meeting a request in full would still leave a lot of spare capacity for the next request." Again, we would like to clarify that there has been no such assumption underlying the Quick-Start design. -E.5. Router Algorithms as Local Policy +F.5. Router Algorithms as Local Policy [B05] recommends that either this document should set constraints on possible router algorithms, or say that experiments are needed "in order to establish constraints required on router algorithms for interworking, robustness, fairness etc." While it is possible that experiments will lead to an understanding of constraints that are needed on router algorithms, we think it is more likely that there will not be a need for explicit constraints on router algorithms for accepting or rejecting Quick-Start requests. Our approach is that, while the Quick-Start IETF documentation standardizes the semantics of Quick-Start and the format of the Quick-Start IP Option and the Quick-Start Response TCP Option, the IETF documentation should not and does not standardize the algorithms used at routers for approving or denying Quick-Start - request. Appendix D in this document has presented one possible + request. Appendix E in this document has presented one possible router algorithm for approving or denying Quick-Start requests, but further discussion of the range of possibilities in router algorithms is available elsewhere [SAF06]. As an example, the fairness criteria that routers might apply in granting or denying Quick-Start requests are discussed in [SAF06], but are not discussed in the same detail in this document. This document leaves routers free to apply any criteria they choose in accepting or denying Quick-Start requests, modulo the requirements given in Section 3.3 above. This approach of the Quick-Start router algorithm as a matter of local policy is consistent with the approach in RFC 3168 on standardizing Explicit Congestion Notification (ECN). RFC 3168 standardized the semantics of the ECN field, but did not standardize a router's Active Queue Management mechanisms for deciding when to set the Congestion Experienced codepoint in packets. -E.6. An Alternate Proposal +F.6. An Alternate Proposal [B05] proposes an alternate to Quick-Start where endpoints allocate rates to themselves. [B05] argues that adding rate allocation to interior routers is not the fundamentally correct direction. [B05] argues for an approach that associates senders with their ingress attachment point, with routers reporting their impairment status back to the sender [BJCG+05,BJS05]. The source declares the impairment that it believes it will accumulate along the path, and routers effectively subtract the local impairment status. If the @@ -4013,21 +4051,21 @@ Pasi Sarolahti Nokia Research Center P.O. Box 407 FI-00045 NOKIA GROUP Finland Phone: +358 50 4876607 Email: pasi.sarolahti@iki.fi Full Copyright Statement - Copyright (C) The Internet Society (2006). This document is subject + Copyright (C) The Internet Society 2006. 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. 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 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.