--- 1/draft-ietf-tsvwg-quickstart-05.txt 2006-08-31 22:12:43.000000000 +0200 +++ 2/draft-ietf-tsvwg-quickstart-06.txt 2006-08-31 22:12:43.000000000 +0200 @@ -1,17 +1,19 @@ Internet Engineering Task Force S. Floyd INTERNET-DRAFT M. Allman -draft-ietf-tsvwg-quickstart-05.txt ICIR -Expires: January 2007 A. Jain +draft-ietf-tsvwg-quickstart-06.txt ICIR +Expires: February 2007 A. Jain F5 Networks P. Sarolahti Nokia Research Center + 30 August 2006 + 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering @@ -23,21 +25,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 January 2007. + This Internet-Draft will expire on February 2007. 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 @@ -56,20 +58,48 @@ 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-05: + + * Minor editing in response to AD feedback from + Lars Eggert. + This includes changing one "should" to "SHOULD", + and changing formating of the IANA Considerations + section. + + * Clarifying in the Introduction that the QS router + does not give preferential treatment to QS packets. + In response to email from Fil Dickinson. + + * Added a discussion of interactions between + Quick-Start and draft-ietf-pmtud-method. In + response to AD Feedback from Lars Eggert. + + * Deleted Appendix F on "Feedback from Bob Briscoe". + From AD feedback about deleting unnecessary + appendices. + + * Added a paragraph to the Introduction about which + sections contain normative references, and which + sections are general discussion. From AD feedback. + + * Added a discussion about congestion control for + TCP's reverse-path traffic. From feedback from + Mitchell Erblich. + Changes from draft-ietf-tsvwg-quickstart-04: * Reformatted references so that "[RFC2581, RFC3390]" is instead "([RFC2581], [RFC3390])", to eliminate bug reports from the idnits tool. From feedback from Dan Romascanu. * Rephrased beginning of second paragraph in the Abstract. From feedback from James Polk. @@ -212,21 +241,21 @@ - Section 4.4, revised the explanation for reducing the congestion window when the first ACK for a Quick-Start packet is received. - Section 6.4, deleted the last sentence. - Minor editing changes. - Revised Section 4.6.2 to say that sender SHOULD send one packet with an initial RTO of three seconds. - Revised Section 4.6.3 to say that the TCP sender SHOULD use an initial RTO setting of three seconds. - Added text to Section 6.2 on Multiple Paths, discussing - multi-path routing. + multipath routing. - Clarified about GPRS round-trip times. - Clarified about PMTUD and the first window of data. - A small reorganization, rearranging sections. * Changes from feedback from Martin Duke: - Revised text about the size of QS requests. - Added some text to Section 4.1, about when to send QS requests. Changes from draft-amit-quick-start-04.txt: * A significant amount of general editing. * Because the Rate Request field only uses four bits, specified @@ -294,138 +322,133 @@ * Added a section on "The Quick-Start Request: Packets or Bytes?" Changes from draft-amit-quick-start-00.txt: * The addition of a citation to [KHR02]. * The addition of a Related Work section. * Deleted the QS Nonce, in favor of a random initial value for the QS TTL. Table of Contents - 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 11 - 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 12 - 2. Assumptions and General Principles. . . . . . . . . . . . . . 12 - 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 13 - 3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 16 - 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 16 - 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 20 + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 12 + 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 14 + 2. Assumptions and General Principles. . . . . . . . . . . . . . 14 + 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 15 + 3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 17 + 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17 + 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21 3.3. Processing the Quick-Start Request at - Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 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 + Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24 + 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26 + 4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27 4.2. The Quick-Start Response Option in the TCP - header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 29 + header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 30 4.4. TCP: Receiving and Using the Quick-Start - Response Packet . . . . . . . . . . . . . . . . . . . . . . . 29 - 4.5. TCP: Responding to a Loss of a Quick-Start - Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 4.6. TCP: A Quick-Start Request for a Larger Ini- - tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . 36 - 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 37 + Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30 + 4.5. TCP: Controlling Acknowledgement Traffic on + the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 33 + 4.6. TCP: Responding to a Loss of a Quick-Start + Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 4.7. TCP: A Quick-Start Request for a Larger Ini- + tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 4.7.1. Interactions with Path MTU Discovery. . . . . . . . 35 + 4.7.2. Quick-Start Request Packets that are + Discarded by Routers or Middleboxes. . . . . . . . . . . . 36 + 4.8. TCP: A Quick-Start Request in the Middle of + a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 37 + 4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 38 + 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 39 + 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39 6.1. Simple Tunnels That Are Compatible with - Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 39 + Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.1.1. Simple Tunnels that are Aware of Quick- - Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.2. Simple Tunnels That Are Not Compatible with - Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 41 - 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 42 + Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43 + 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44 7. The Quick-Start Mechanism in other Transport Pro- - tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 - 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 43 - 8.1. Determining the Rate to Request. . . . . . . . . . . . . 43 + tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 46 + 8.1. Determining the Rate to Request. . . . . . . . . . . . . 46 8.2. Deciding the Permitted Rate Request at a - 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 + Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 47 + 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 47 + 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 48 + 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49 + 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 50 + 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 50 9.4.2. Receivers Lying about Whether the - Request was Approved . . . . . . . . . . . . . . . . . . . 49 + Request was Approved . . . . . . . . . . . . . . . . . . . 51 9.4.3. Receivers Lying about the Approved - 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 . . . . . . . . . . . . . . 53 - 10. Implementation and Deployment Issues . . . . . . . . . . . . 53 + Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 + 9.4.4. Collusion between Misbehaving Routers . . . . . . . 53 + 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54 + 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 55 + 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55 + 10. Implementation and Deployment Issues . . . . . . . . . . . . 56 10.1. Implementation Issues for Sending Quick- - Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54 + Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56 10.2. Implementation Issues for Processing Quick- - Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 54 - 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 55 + Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 57 + 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57 10.4. A Comparison with the Deployment Problems - of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 - 11. Security Considerations. . . . . . . . . . . . . . . . . . . 57 - 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 58 - 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 58 - 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 58 - 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 58 - 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 - A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 59 + of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 + 11. Security Considerations. . . . . . . . . . . . . . . . . . . 59 + 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60 + 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60 + 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 61 + 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61 + A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62 A.1. Fast Start-ups without Explicit Information - from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 59 + from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 63 A.2. Optimistic Sending without Explicit Informa- - tion from Routers . . . . . . . . . . . . . . . . . . . . . . 61 + tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64 A.3. Fast Start-ups with other Information from - Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 + Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 A.4. Fast Start-ups with more Fine-Grained Feed- - back from Routers . . . . . . . . . . . . . . . . . . . . . . 63 + back from Routers . . . . . . . . . . . . . . . . . . . . . . 66 A.5. Fast Start-ups with Lower-Than-Best-Effort - Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 - B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 64 + Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 + B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 67 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 + Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67 + B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67 + B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 69 + B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 70 + B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71 B.4. Quick-Start Semantics: Total Rate or Addi- - tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 69 + tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 73 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 + Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 74 + B.6. Why Not Include More Functionality?. . . . . . . . . . . 74 + B.7. Alternate Implementations for a Quick-Start + Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 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 + Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 + B.7.2. The Earlier Request-Approved Quick- + Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 + C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79 + D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 81 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 + Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 + Normative References . . . . . . . . . . . . . . . . . . . . . . 84 + Informative References . . . . . . . . . . . . . . . . . . . . . 84 + AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 91 + Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 91 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 @@ -438,58 +461,87 @@ networks with large bandwidth or long delays. It may take a number of RTTs in slow-start before the TCP connection begins to fully use the available bandwidth of the network. For instance, it takes log_2(N) - 2 round-trip times to build cwnd up to N segments, assuming an initial congestion window of 4 segments. This time in slow-start is not a problem for large file transfers, where the slow-start stage is only a fraction of the total transfer time. However, in the case of moderate-sized transfers the connection might carry out its entire transfer in the slow-start phase, taking many round-trip times, where one or two RTTs might have been - appropriate in the current network conditions. + sufficient when using the currently available bandwidth along the + path. A fair amount of work has already been done to address the issue of choosing the initial congestion window for TCP, with RFC 3390 allowing an initial window of up to four segments based on the MSS used by the connection [RFC3390]. Our underlying premise is that explicit feedback from all of the routers along the path would be required, in the current architecture, for best-effort connections to use initial windows significantly larger than those allowed by [RFC3390], in the absence of other information about the path. In using Quick-Start, a TCP host, say, host A, would indicate its - desired sending rate in bytes per second, using a Quick Start option + desired sending rate in bytes per second, using a Quick-Start option in the IP header of a TCP packet. Each 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. (We note that the `routers' referred to in this document also include the IP-layer processing of the Quick-Start request at the sender.) - If the Quick-Start request is not approved, then the sender would - use the default congestion control mechanisms. The Quick-Start - mechanism can determine if there are routers along the path that do - not understand the Quick-Start option, or have not agreed to the - Quick-Start rate request. TCP host B communicates the final rate - request to TCP host A in a transport-level Quick-Start Response in - an answering TCP packet. + In approving a Quick-Start request, a router does not give + preferential treatment to subsequent packets from that connection; + the router is only asserting that it is currently underutilized and + believes there is sufficient available bandwidth to accommodate the + sender's requested rate. The Quick-Start mechanism can determine if + there are routers along the path that do not understand the Quick- + Start option, or have not agreed to the Quick-Start rate request. + TCP host B communicates the final rate request to TCP host A in a + transport-level Quick-Start Response in an answering TCP packet. + + If the Quick-Start request is approved by all routers along the + path, then the TCP host can send at up to the approved rate for a + window of data. Subsequent transmissions will be governed by the + default TCP congestion control mechanisms of that connection. If + the Quick-Start request is not approved, then the sender would use + the default congestion control mechanisms. Quick-Start would not be the first mechanism for explicit communication from routers to transport protocols about sending rates. Explicit Congestion Notification (ECN) gives explicit congestion control feedback from routers to transport protocols, based on the router detecting congestion before buffer overflow [RFC3168]. In contrast, routers would not use Quick-Start to give congestion information, but instead would use Quick-Start as an optional mechanism to give permission to transport protocols to use higher sending rates, based on the ability of all the routers along the path to determine if their respective output links are significantly underutilized. + Section 2 gives an overview of Quick-Start. The formal + specifications for Quick-Start are contained in Sections 3, 4, + 6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4 + and for IPv6 in Section 3, and is specified for TCP in Section 4. + Section 6 consists mostly of a non-normative discussion of + interactions of Quick-Start with IP tunnels and MPLS; however, + Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware + of Quick-Start. + + The rest of the document is non-normative, as follows. Section 5 + shows that Quick-Start is compatible with IPsec AH (Authentication + Header). Section 7 gives a non-normative set of guidelines for + specifying Quick-Start in other transport protocols, and Section 8 + discusses using Quick-Start in transport end-nodes and in routers. + Section 9 gives an evaluation of the costs and benefits of Quick- + Start, and Section 10 discusses implementation and deployment + issues. The appendices discuss related work, Quick-Start design + decisions, and possible router algorithms. + 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Assumptions and General Principles This section describes the assumptions and general principles behind the design of the Quick-Start mechanism. @@ -915,20 +967,24 @@ connection will not change the current under-utilized state of the router. A non-participating router forwards the Quick-Start Request unchanged, without decrementing the QS TTL. The non-participating router still decrements the TTL field in the IP header, as is required for all routers [RFC1812]. As a result, the sender will be able to detect that the Quick-Start Request had not been understood or approved by all of the routers along the path. + A router that uses multipath routing for packets within a single + connection MUST NOT approve a Quick-Start request. This is + discussed in more detail in Section 9.2. + 3.3.1. Processing the Report of Approved Rate If the Quick-Start Option has the Function field set to "1000", then this is a Report of Approved Rate, rather than a Rate Request. The router MAY ignore such an option, and in any case it MUST NOT modify the contents of the option for a Report of Approved Rate. However, the router MAY use the Approved Rate report to check that the sender is not lying about the approved rate. If the reported Approved Rate is higher than the rate that the router actually approved for this connection in the previous round-trip time, then the router may @@ -944,25 +1000,21 @@ 3.4. The QS Nonce The QS Nonce gives the Quick-Start sender some protection against receivers lying about the value of the received Rate Request. This is particularly important if the receiver knows the original value of the Rate Request (e.g., when the sender always requests the same value, and the receiver has a long history of communication with that sender). Without the QS Nonce, there is nothing to prevent the receiver from reporting back to the sender a Rate Request of K, when - the received Rate Request was in fact less than K. This version of - the nonce is based on a proposal from Guohan Lu [L05]. Initial - versions of this document contained an eight-bit QS Nonce, and - subsequent versions discussed the possibility of a four-bit QS - Nonce. + the received Rate Request was in fact less than K. Table 2 gives the format for the 30-bit QS Nonce. Bits Purpose --------- ------------------ Bits 0-1: Rate 15 -> Rate 14 Bits 2-3: Rate 14 -> Rate 13 Bits 4-5: Rate 13 -> Rate 12 Bits 6-7: Rate 12 -> Rate 11 Bits 8-9: Rate 11 -> Rate 10 @@ -1035,48 +1087,48 @@ This section describes how the Quick-Start mechanism would be used in TCP. We first sketch the procedure and then tightly define it in the subsequent subsections. If a TCP sender, say host A, would like to use Quick-Start, the TCP sender puts the requested sending rate in bits per second, appropriately formatted, in the Quick-Start option in the IP header of the TCP packet, called the Quick-Start request packet. (We will be somewhat loose in our use of "packet" vs. "segment" in this section.) When used for initial start-up, the Quick-Start request - packet can be either the SYN or SYN/ACK packet, as described above. - The requested rate includes an estimate for the transport and IP - header overhead. The TCP receiver, say host B, returns the Quick- - Start Response option in the TCP header in the responding SYN/ACK - packet or ACK packet, called the Quick-Start response packet, - informing host A of the results of their request. + packet can be either the SYN or SYN/ACK packet, as illustrated in + Figure 1. The requested rate includes an estimate for the transport + and IP header overhead. The TCP receiver, say host B, returns the + Quick-Start Response option in the TCP header in the responding + SYN/ACK packet or ACK packet, called the Quick-Start response + packet, informing host A of the results of their request. If the acknowledging packet does not contain a Quick-Start Response, or contains a Quick-Start Response with the wrong value for the TTL Diff or the QS Nonce, then host A MUST assume that its Quick-Start request failed. In this case, host A sends a Report of Approved Rate with a Rate Report of zero, and uses TCP's default congestion control procedure. For initial start-up, host A uses the default - initial congestion window [RFC2581]. + initial congestion window ([RFC2581], [RFC3390]). If the returning packet contains a valid Quick-Start Response, then host A uses the information in the response, along with its measurement of the round-trip time, to determine the Quick-Start congestion window (QS-cwnd). Quick-Start data packets are defined as data packets sent as the result of a successful Quick-Start request, up to the time when the first Quick-Start packet is acknowledged. The sender also sends a Report of Approved Rate. In - order to use Quick-Start, the TCP host MUST use rate-based pacing to - transmit Quick-Start packets at the rate indicated in the Quick- - Start Response, at the level of granularity possible by the sending - host. We note that the limitations of interrupt timing on computers - can limit the ability of the TCP host in rate-pacing the outgoing - packets. + order to use Quick-Start, the TCP host MUST use rate-based pacing + [VH97] to transmit Quick-Start packets at the rate indicated in the + Quick-Start Response, at the level of granularity possible by the + sending host. We note that the limitations of interrupt timing on + computers can limit the ability of the TCP host in rate-pacing the + outgoing packets. The two TCP end-hosts can independently decide whether to request Quick-Start. For example, host A could sent a Quick-Start Request in the SYN packet, and host B could also send a Quick-Start Request in the SYN/ACK packet. 4.1. Sending the Quick-Start Request When sending a Quick-Start Request, the TCP sender SHOULD send the request on a packet that requires an acknowledgement, such as a SYN, @@ -1135,29 +1187,31 @@ Of the above, this document recommends that a TCP sender MAY attempt to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that a TCP sender use Quick-Start for case (3) at the current time. Case (3) requires external notifications not presently defined for TCP or other transport protocols. Finally, a TCP SHOULD NOT use Quick- Start for case (4) at the current time. Case (4) requires further thought and investigation with regard to how the transport protocol could determine it was in a situation that would warrant transmitting a Quick-Start Request. - As a general guideline, a TCP sender SHOULD NOT send a Quick-Start - request until it has confirmed that is ready to transmit enough data - to use the requested rate over the round-trip time of the connection - (or over 100 ms, if the round-trip time is not known). In any - circumstances, the sender MUST NOT make a QS request if it has made - a QS request within the most recent round-trip time. + As a general guideline, a TCP sender SHOULD NOT request a sending + rate larger than it is able to use over the next round-trip time of + the connection (or over 100 ms, if the round-trip time is not + known), except as required to round up the desired sending rate to + the next-highest allowable request. - Section 4.6 discusses some of the issues of using Quick-Start at - connection initiation, and Section 4.7 discusses issues that arise + In any circumstances, the sender MUST NOT make a QS request if it + has made a QS request within the most recent round-trip time. + + Section 4.7 discusses some of the issues of using Quick-Start at + connection initiation, and Section 4.8 discusses issues that arise when Quick-Start is used to request a larger sending rate after an idle period. 4.2. The Quick-Start Response Option in the TCP header In order to approve the use of Quick-Start, the TCP receiver 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: @@ -1226,33 +1280,33 @@ Start Request. 4.4. TCP: Receiving and Using the Quick-Start Response Packet A TCP host, say TCP host A, that sent a Quick-Start Request and receives a Quick-Start Response in an acknowledgement first checks that the Quick-Start Response is valid. The Quick-Start Response is valid if it contains the correct value for the TTL Diff, and an equal or lesser value for the Rate Request than that transmitted in the Quick-Start Request. In addition, if the received Rate Request - is K, then the the rightmost 2K bits of the QS Nonce must match - those bits in the QS Nonce sent in the Quick-Start Request. If - these checks are not successful, then the Quick-Start request - failed, and the TCP host MUST use the default TCP congestion window - that it would have used without Quick-Start. If the rightmost 2K - bits of the QS Nonce do not match those bits in the QS Nonce sent in - the Quick-Start Request, for a received Rate Request of K, then the - TCP host MUST NOT send additional Quick-Start requests during the - life of the connection. Whether the Quick-Start request was - successful or not, the host receiving the Quick-Start Response MUST - send a Report of Approved Rate. Similarly, if the packet containing - the Quick-Start Request is acknowledged, but the acknowledgement - does not include a Quick-Start Response, then the sender MUST send a + is K, then the rightmost 2K bits of the QS Nonce must match those + bits in the QS Nonce sent in the Quick-Start Request. If these + checks are not successful, then the Quick-Start request failed, and + the TCP host MUST use the default TCP congestion window that it + would have used without Quick-Start. If the rightmost 2K bits of + the QS Nonce do not match those bits in the QS Nonce sent in the + Quick-Start Request, for a received Rate Request of K, then the TCP + host MUST NOT send additional Quick-Start requests during the life + of the connection. Whether the Quick-Start request was successful + or not, the host receiving the Quick-Start Response MUST send a + Report of Approved Rate. Similarly, if the packet containing the + Quick-Start Request is acknowledged, but the acknowledgement does + not include a Quick-Start Response, then the sender MUST send a Report of Approved Rate. If the checks of the TTL Diff and the Rate Request are successful, and the TCP host is going to use the Quick-Start Request, it MUST start using it within one round-trip time of receiving the Quick- Start Response, or within three seconds, whichever is smaller. To use the Quick-Start Request, the host sets its Quick-Start congestion window (in terms of MSS-sized segments), QS-cwnd, as follows: @@ -1328,21 +1382,88 @@ any packet marks or losses have been reported, the TCP host MAY use the reported Rate Request to set the slow-start threshold to a desired value, e.g., to some small multiple of the congestion window. A possible future research topic is how the sender might modify the show-start threshold at the beginning of a connection to avoid overshooting the path capacity. (The initial value of ssthresh is allowed to be arbitrarily high, and some TCP implementations use the size of the advertised window for ssthresh [RFC2581].) -4.5. TCP: Responding to a Loss of a Quick-Start Packet +4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path + + When a Quick-Start Request is approved for a TCP sender, the + resulting Quick-Start data traffic can result in a sudden increase + in traffic for pure ACK packets on the reverse path. For example, + for the largest Quick-Start request of 1.3 Gbps, given a TCP sender + with 1500-byte packets and a TCP receiver with delayed + acknowledgements acking every other packet, this could result in + 17.3 Mbps of acknowledgement traffic on the reverse path. + + One possibility, in cases with large Quick-Start requests, would be + for TCP receivers to send Quick-Start requests to request bandwidth + for the acknowledgement traffic on the reverse path. However, in + our view, a better approach would be for TCP receivers to simply + control the rate of sending acknowledgement traffic. The optimal + future solution would involve the explicit use of congestion control + for TCP acknowledgement traffic, as is done now for the + acknowledgement traffic in DCCP's CCID2 [RFC4341]. + + In the absence of congestion control for acknowledgement traffic, + the TCP receiver could limit its sending rate for ACK packets sent + in response to Quick-Start data packets. The following information + is needed by the TCP receiver: + + * The RTT: TCP naturally measures the RTT of the path and therefore + should have a sample of the RTT. If the TCP receiver does not + have a measurement of the round-trip time, it can use the time + between the receipt of the Quick-Start Request and the Quick-Start + Response packets. + + * The Approved Rate Request (R): When the TCP receiver receives the + Quick-Start Response packet, the receiver knows the value of the + approved Rate Request. + + * The MSS: TCP advertises the MSS during the initial three-way + handshake and therefore the receiver should have an understanding + of the packet size the sender will be using. If the receiver does + not have such an understanding or wishes to confirm the negotiated + MSS, the size of the first data packet can be used. + + With this set of information the TCP receiver can restrict its + sending rate for pure acknowledgment traffic to at most 100 pure ACK + packets per RTT by sending at most one ACK for every K data packets, + for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would + acknowledge the first Quick-Start data packet, and every succeeding + K data packets. Thus, for a somewhat extreme case of R=1.3 Gbps, + RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the + receiver would acknowledge every 216 data packets. From [RFC2581], + the ACK Ratio K should have a minimum value of two. When the ACK + Ratio is greater than two, and the TCP sender receives + acknowledgements each acknowledging more than two data packets, the + TCP sender may want to use rate-based pacing to control the + burstiness of its outgoing data traffic. + + In the absence of explicit congestion control mechanisms, the TCP + end nodes cannot determine the packet drop rate for pure + acknowledgement traffic. This is true with or without Quick-Start. + However, the TCP receiver could limit its increase in the sending + rate for pure ACK packets by at most doubling the sending rate for + pure ACK packets from one round-trip time to the next. The TCP + receiver would do this by halving the ACK Ratio each round-trip + time. + + Note that the above is one particular mechanism that could be used + to control the ACK stream. Future work that investigates this + scheme and others in detail is encouraged. + +4.6. TCP: Responding to a Loss of a Quick-Start Packet For TCP, we have defined a ``Quick-Start packet'' as one of the packets sent in the window immediately following a successful Quick- Start request. After detecting the loss or ECN-marking of a Quick- 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 @@ -1355,61 +1476,70 @@ 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. -4.6. TCP: A Quick-Start Request for a Larger Initial Window +4.7. TCP: A Quick-Start Request for a Larger Initial Window Some of the issues of using Quick-Start are related to the specific scenario in which Quick-Start is used. This section discusses the following issues that arise when Quick-Start is used by TCP to request a larger initial window: (1) interactions with Path MTU Discovery (PMTUD); and (2) Quick-Start request packets that are discarded by middleboxes. -4.6.1. Interactions with Path MTU Discovery +4.7.1. Interactions with Path MTU Discovery One issue when Quick-Start is used to request a large initial window concerns the interactions between the large initial window and Path MTU Discovery. Some of the issues are discussed in RFC 3390: "When larger initial windows are implemented along with Path MTU Discovery [RFC1191], alternatives are to set the "Don't Fragment" (DF) bit in all segments in the initial window, or to set the "Don't Fragment" (DF) bit in one of the segments. It is an open question as to which of these two alternatives is best." If the sender knows the Path MTU when the initial window is sent (e.g., from a PMTUD cache or from some other IETF-approved method), - then the sender should use that MTU for segments in the initial + then the sender SHOULD use that MTU for segments in the initial window. Unfortunately, the sender doesn't necessarily know the Path MTU when it sends packets in the initial window. In this case, the sender should be conservative in the packet size used. Sending a large number of overly-large packets with the DF bit set is not desirable, but sending a large number of packets that are fragmented in the network can be equally undesirable. - The sender SHOULD send one large packet in the initial window with - the DF bit set, and send the remaining packets in the initial window - with a smaller MTU of 576 bytes (or 1280 bytes with IPv6). + If the sender doesn't know the Path MTU when the initial window is + sent, the sender SHOULD send one large packet in the initial window + with the DF bit set, and send the remaining packets in the initial + window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6). A second possibility would be for the sender to delay sending the Quick-Start Request for one round-trip time, sending the Quick-Start Request with the first window of data while also doing Path MTU Discovery. -4.6.2. Quick-Start Request Packets that are Discarded by Routers or + The sender may be using an iterative approach such as Packetization + Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery, + where the sender tests successively larger MTUs. If a probe is + successfully delivered then the MTU can be raised to reflect the + value used in that probe. We would note that PLPMTUD does not allow + the sender to determine the Path MTU before sending the initial + window of data. + +4.7.2. Quick-Start Request Packets that are Discarded by Routers or Middleboxes It is always possible for a TCP SYN packet carrying a Quick-Start request to be dropped in the network due to congestion, or to be blocked due to interactions with routers or middleboxes, where a middlebox is defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host [RFC3234]. Measurement studies of interactions between transport protocols and middleboxes [MAF04] show that for 70% of the web servers @@ -1442,21 +1572,21 @@ In this case, the sender could resend the dropped packet without either the Quick-Start or the ECN requests. Alternately, the sender could resend the dropped packet with only the ECN request in the TCP header, resending the TCP SYN packet without either the Quick-Start or the ECN requests if the second TCP SYN packet is dropped. The second choice seems reasonable, given that a TCP SYN packet today is more likely to be blocked due to policies that discard packets with IP Options than due to policies that discard packets with ECN requests in the TCP header [MAF04]. -4.7. TCP: A Quick-Start Request in the Middle of a Connection +4.8. TCP: A Quick-Start Request in the Middle of a Connection This section discusses the following issues that arise when Quick- Start is used by TCP to request a larger window in the middle of a connection, such as after an idle period: (1) determining the rate to request; (2) when to make a request; and (3) the response if Quick-Start packets are dropped; (1) Determining the rate to request: For a connection that has not yet had a congestion event (that is, a marked or dropped packet), the TCP sender is not restricted in the @@ -1473,27 +1603,27 @@ was reduced, for example during an idle period. A Quick-Start Request sent in the middle of a TCP connection SHOULD be sent on a data packet. (2) When to make a request: A TCP connection MAY make a Quick-Start request before the connection has experienced a congestion event, or after an idle period of at least one RTO. - (2) Response if Quick-Start packets are dropped: + (3) Response if Quick-Start packets are dropped: If Quick-Start packets are dropped in the middle of connection, then the sender MUST revert to half of the Quick-Start window, or to the congestion window that the sender would have used if the Quick-Start request had not been approved, whichever is smaller. -4.8. An Example Quick-Start Scenario with TCP +4.9. An Example Quick-Start Scenario with TCP The following is an example scenario in the case when both hosts request Quick-Start for setting their initial windows. This is similar to Figures 1 and 2 in Section 2.1, except that it illustrates a TCP connection with both TCP hosts sending Quick-Start Requests. * The TCP SYN packet from Host A contains a Quick-Start Request in the IP header. @@ -1527,21 +1657,21 @@ congestion window appropriately, and sets up rate-based pacing to be used with its initial window. If the Quick-Start Response is not valid, then Host B uses TCP's default initial window. In either case, Host B sends a Report of Approved Rate. 5. Quick-Start and IPsec AH This section shows that Quick-Start is compatible with IPsec AH (Authentication Header). AH uses an Integrity Check Value (ICV) in the IPsec Authentication Header to verify both message - authentication and integrity ([RFC2402], [2402bis]). Changes to the + authentication and integrity ([RFC2402], [RFC4302]). Changes to the Quick-Start option in the IP header do not affect this AH ICV. The tunnel considerations in Section 6 below apply to all IPsec tunnels, regardless of what IPsec headers or processing are used in conjunction with the tunnel. Because the contents of the Quick-Start option can change along the path, it is important that these changes not affect the IPsec Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC 2402 requires that unrecognized IPv4 options be zeroed for AH ICV computation purposes, so Quick-Start IP Option data changing en @@ -1552,21 +1682,21 @@ indicate whether the option is mutable; the 3rd highest order bit in the IANA-allocated option type has the value 1 to indicate that the Quick-Start option data can change en route. RFC 2402 requires that the option data of any such option be zeroed for AH ICV computation purposes. Therefore changes to the Quick-Start option in the IP header do not affect the calculation of the AH ICV. 6. Quick-Start in IP Tunnels and MPLS This section considers interactions between Quick-Start and IP - tunnels, including IPsec ([RFC2401], [2401bis]), IP in IP [RFC2003], + tunnels, including IPsec ([RFC2401], [RFC4301]), IP in IP [RFC2003], GRE [RFC2784], and others. This section also considers interactions between Quick-Start and MPLS [RFC3031]. In the discussion, we use TTL Diff, defined earlier as the difference between the IP TTL and the Quick-Start TTL, mod 256. Recall that the sender considers the Quick-Start request approved only if the value of TTL Diff for the packet entering the network is the same as the value of TTL Diff for the packet exiting the network. @@ -1860,26 +1991,21 @@ appropriately. For example, the sender might have information about the bandwidth of the last-mile hop, the size of the local socket buffer, or of the TCP receive window, and could use this information in determining the rate to request. Web servers that mostly have small objects to transfer might decide not to use Quick-Start at all, since Quick-Start would be of little benefit to them. Quick-Start will be more effective if Quick-Start requests are not larger than necessary; every Quick-Start request that is approved but not used (or not fully used) takes away from the bandwidth pool - available for granting successive Quick-Start requests. Following - Section 4.1, the sender SHOULD NOT request a sending rate larger - than it is able to use over the round-trip time of the connection - (or over 100 ms, if the round-trip time is not known), except as - required to round up the desired sending rate to the next-highest - allowable request. + available for granting successive Quick-Start requests. 8.2. Deciding the Permitted Rate Request at a Router In this section we briefly outline how a router might decide whether or not to approve a Quick-Start Request. The router should ask the following questions: * Has the router's output link been underutilized for some time (e.g., several seconds). @@ -1900,21 +2026,21 @@ 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 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 + 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 whether to approve a Quick-Start request. In order to explore the limits of the possible functionality at routers, [SAF06] also discusses Extreme Quick-Start mechanisms at routers, where the router would keep per-flow state concerning approved Quick-Start @@ -1979,25 +2104,26 @@ prevent the addition of other competing functionality to routers. Thus, careful thought would have to be given to the addition of Quick-Start to IP. The slow path in routers: Another drawback of Quick-Start is that packets containing the Quick-Start Request message might not take the fast path in routers, particularly in the beginning of Quick-Start's deployment in the Internet. This would mean some extra delay for the end hosts, and extra processing burden for the routers. However, as discussed in - Sections 4.1 and 4.6, not all packets would carry the Quick-Start + Sections 4.1 and 4.7, not all packets would carry the Quick-Start option. In addition, for the underutilized links where Quick-Start Requests could actually be approved, or in typical environments where most of the packets belong to large flows, the burden of the Quick-Start Option on routers would be considerably reduced. + Nevertheless, it is still conceivable, in the worst case, that many packets would carry Quick-Start requests; this could slow down the processing of Quick-Start packets in routers considerably. As discussed in Section 9.6, routers can easily protect against this by enforcing a limit on the rate at which Quick-Start requests will be considered. [RW03] and [RW04] contain measurements of the impact of IP Option Processing on packet round-trip times. Multiple paths: One limitation of Quick-Start is that it presumes that the data @@ -2007,28 +2133,28 @@ path that was already congested, or that became congested as a result of this connection. Thus, Quick-Start could give poor performance when there is a routing change immediately after the Quick-Start request is approved, and the Quick-Start data packets follow a different path from that of the original Quick-Start Request. This is, however, similar to what would happen, for a connection with sufficient data, if the connection's path was changed in the middle of the connection, when the connection had already established the allowed initial rate. - A router that uses multipath routing for packets within a single - connection MUST NOT approve a Quick-Start request. Quick-Start - would not perform robustly in an environment with multipath routing, - where different packets in a connection routinely follow different - paths. In such an environment, the Quick-Start request and some - fraction of the packets in the connection might take an - underutilized path, while the rest of the packets take an alternate, - congested path. + As specified in Section 3.3, a router that uses multipath routing + for packets within a single connection must not approve a Quick- + Start request. Quick-Start would not perform robustly in an + environment with multipath routing, where different packets in a + connection routinely follow different paths. In such an + environment, the Quick-Start request and some fraction of the + packets in the connection might take an underutilized path, while + the rest of the packets take an alternate, congested path. Non-IP queues: A problem of any mechanism for feedback from routers at the IP level is that there can be queues and bottlenecks in the end-to-end path that are not in IP-level routers. As an example, these include queues in layer-two Ethernet or ATM networks. One possibility would be that an IP-level router adjacent to such a non-IP queue or bottleneck would be configured to reject Quick-Start requests if that was appropriate. One would hope that in general, IP networks are configured so that non-IP queues between IP routers do not end @@ -2076,21 +2202,21 @@ required to use Approved Rate reports to check if senders are cheating; this is at the discretion of the router. If a router sees a Report of Approved Rate, and did not see an earlier Quick-Start request, then either the sender could be cheating, or the connection's path could have changed since the Quick-Start request was sent. In either case, the router could decide to deny future Quick-Start requests for this connection. In particular, it is reasonable for the router to deny a Quick-Start request if either the sender is cheating, or if the connection path - suffers from path changes or multi-pathing. + suffers from path changes or multipathing. If a router approved a Quick-Start Request, but does not see a subsequent Approved Rate report, then there are several possibilities: (1) the request was denied and/or dropped downstream and the sender did not send a Report of Approved Rate; (2) the request was approved but the sender did not send a Report of Approved Rate; (3) the Approved Rate report was dropped in the network; or (4) the Approved Rate report took a different path from the Quick-Start Request. In any of these cases, the router would be justified in denying future Quick-Start Requests for this @@ -2339,21 +2465,21 @@ This section discusses some of the implementation issues with Quick- Start. This section also discusses some of the key deployment issues, such as the chicken-and-egg deployment problems of mechanisms that have to be deployed in both routers and end nodes in order to work, and the problems posed by the wide deployment of middleboxes today that block the use of known or unknown IP Options. 10.1. Implementation Issues for Sending Quick-Start Requests - Section 4.6 discusses some of the issues with deciding the initial + Section 4.7 discusses some of the issues with deciding the initial sending rate to request. Quick-Start raises additional issues about the communication between the transport protocol and the application, and about the use of the past history with Quick-Start in the end node. One possibility is that a protocol implementation could provide an API for applications to indicate when they want to request Quick- Start, and what rate they would like to request. In the conventional socket API this could be a socket option that is set before a connection is established. Some applications, such as @@ -2496,31 +2622,31 @@ congestion could also be part of a Denial of Service attack. Section 9.6 discusses a potential attack on the routers' processing and state load from an attack of Quick-Start Requests. Section 9.6 also discusses a potential attack on the available Quick-Start bandwidth by sending bogus Quick-Start requests for bandwidth that will not in fact be used. While this impacts the global usability of Quick-Start it does not endanger the network as a whole since TCP uses standard congestion control if Quick-Start is not available. - Section 4.6.2 discusses the potential problem of packets with Quick- + Section 4.7.2 discusses the potential problem of packets with Quick- Start Requests dropped by middleboxes along the path. As discussed in Section 5, for IPv4 IPsec Authentication Header Integrity Check Value (AH ICV) calculation, the Quick-Start option - MUST be treated as a mutable IPv4 option, and hence completely - zeroed for AH ICV calculation purposes; this is also the treatment - required by RFC 2402 for unrecognized IPv4 options. The IPv6 Quick- - Start option's IANA-allocated option type indicates that it is a - mutable option, hence, according to RFC 2402, its option data MUST - be zeroed for AH ICV computation purposes. See RFC 2402 for further + is a mutable IPv4 option, and hence completely zeroed for AH ICV + calculation purposes; this is also the treatment required by RFC + 2402 for unrecognized IPv4 options. The IPv6 Quick-Start option's + IANA-allocated option type indicates that it is a mutable option, + hence, according to RFC 2402, its option data is required to be + zeroed for AH ICV computation purposes. See RFC 2402 for further explanation. Section 6.2 discusses possible problems of Quick-Start used by connections carried over simple tunnels that are not compatible with Quick-Start. In this case it is possible that a Quick-Start Request is erroneously considered approved by the sender without the routers in the tunnel having individually approved the request, causing a false positive. We note two high-order points here. First, the Quick-Start Nonce @@ -2530,37 +2656,54 @@ Quick-Start does not remove TCP's basic congestion control mechanisms and these will kick in when the network is heavily loaded, relegating any Quick-Start mistake to a transient. 12. IANA Considerations Quick-Start requires an IP Option and a TCP Option. 12.1. IP Option - Quick-Start requires that both an IPv4 and an IPv6 Option Number be - allocated. The IPv4 Option would have a copied flag of 0, a class - field of 00, and the assigned five-bit option number. The IPv6 - Option would have the first three bits of "001" [RFC2460, Section - 4.2], with the first two bits indicating that the IPv6 node skip - over this option and continue processing the header if it doesn't - recognize the option type, and the third bit indicating that the - Option Data may change en-route. + Quick-Start requires both an IPv4 Option Number (Section 3.1) and an + IPv6 Option Number (Section 3.2). - In both cases the name of the option would be "QS - Quick-Start", - with this document as the reference document. + IPv4 Option Number: + + Copy Class Number Value Name + ---- ----- ------ ----- ---- + 0 00 TBD1 TBD2 QS - Quick-Start + + IPv6 Option Number [RFC2460]: + + HEX act chg rest + --- --- --- ----- + TBD3 00 1 TBD4 Quick-Start + + For the IPv6 Option Number, the first two bits indicate that the + IPv6 node skip over this option and continue processing the header + if it doesn't recognize the option type, and the third bit indicates + that the Option Data may change en-route. + + In both cases this document should be listed 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. + Quick-Start requires a TCP Option Number (Section 4.2). + + TCP Option Number: + + Kind Length Meaning + ---- ------ ------------------------------ + TBD5 8 Quick-Start Response + + This document should be listed as the reference document. 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 @@ -2571,28 +2714,35 @@ 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 + Touch for extensive feedback on Quick-Start 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. + Dunigan, Mitchell Erblich, 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. + + The version of the QS Nonce in this document is based on a proposal + from Guohan Lu [L05]. Earlier versions of this document contained + an eight-bit QS Nonce, and subsequent versions discussed the + possibility of a four-bit QS Nonce. + + 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 @@ -3122,21 +3272,21 @@ 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 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. 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 + Section 4.6 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 whole. The packet loss in the initial window indicates that Quick- Start failed in finding an appropriate congestion window, meaning @@ -3215,21 +3365,21 @@ We would argue that even if more fine-grained per-packet feedback from routers was implemented, it is reasonable to have a separate mechanism such as Quick-Start for indicating an allowed initial sending rate, or an allowed total sending rate after an idle or underutilized period. One difference between Quick-Start and current proposals for fine- grained per-packet feedback such as XCP is that XCP is designed to give robust performance even in the case where different packets within a connection routinely follow different paths. XCP achieves - relatively robust performance in the presence of multi-path routing + relatively robust performance in the presence of multipath routing by using per-packet feedback, where the feedback carried in a single packet is about the relative increase or decrease in the rate or window to take effect when that particular packet is acknowledged, not about the allowed sending rate for the connection as a whole. In contrast, Quick-Start sends a single Quick-Start request, and the answer to that request gives the allowed sending rate for an entire window of data. As a result, Quick-Start could be problematic in an environment where some fraction of the packets in a window of data take path A, and the rest of the packets take path B; for example, @@ -3303,23 +3453,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. -B.7. Alternate Implementations for a QuickStart Nonce +B.7. Alternate Implementations for a Quick-Start Nonce -B.7.1. An Alternate Proposal for the QuickStart Nonce +B.7.1. An Alternate Proposal for the Quick-Start 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 @@ -3332,40 +3482,40 @@ 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. -B.7.2. The Earlier Request-Approved QuickStart Nonce +B.7.2. The Earlier Request-Approved Quick-Start Nonce An earlier version of this document included a Request-Approved - QuickStart Nonce (QS Nonce) that was initialized by the sender to a + Quick-Start 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 + Request-Approved Quick-Start 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 Nonce was included to provide some protection against broken downstream routers, or against misbehaving TCP receivers that might be inclined to lie about whether the Rate Request was approved. This protection is now provided by the QS Nonce, by the use of a random initial value for the QS TTL field, and by Quick-Start- capable routers hopefully either deleting the Quick-Start Option or zeroing the QS TTL and QS Nonce fields when they deny a request. - With the old Request-Approved QuickStart Nonce, along with the QS + With the old Request-Approved Quick-Start Nonce, along with the QS TTL field set to the same value as the TTL field in the IP header, the Quick-Start Request mechanism would have been self-terminating; the Quick-Start Request would terminate at the first participating router after a non-participating router had been encountered on the path. This minimizes unnecessary overhead incurred by routers 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 @@ -3376,21 +3526,21 @@ 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 + [RFC4340] for a more detailed description of DCCP, and of the congestion control mechanisms. Because CCID 3 uses a rate-based congestion control mechanism, it raises some new issues about the use of Quick-Start with transport protocols. In this document we don't attempt to specify the use of Quick-Start with DCCP. However, we do discuss some of the issues that might arise. In considering the use of Quick-Start with CCID 3 for requesting a higher initial sending rate, the following questions arise: @@ -3544,23 +3694,23 @@ Report of Current Sending Rate: A Quick-Start Request with the `Report of Current Sending Rate' codepoint set in the Function field would be using the Rate Request field to report the current estimated sending rate for that connection. This could accompany a second Quick-Start Request in the same packet containing a standard rate request, for a connection that is using Quick-Start to increase its current sending rate. Request to Increase Sending Rate: A codepoint for `Request to Increase Sending Rate' in the Function field would indicate that the - connection is not idle or just starting up, but is attemmpting to - use Quick-Start to increase its current sending rate. This - codepoint would not change the semantics of the Rate Request field. + connection is not idle or just starting up, but is attempting to use + Quick-Start to increase its current sending rate. This codepoint + would not change the semantics of the Rate Request field. RTT Estimate: If a codepoint for `RTT Estimate' was used, a field for the RTT Estimate would contain one or more bits giving the sender's rough estimate of the round-trip time, if known. E.g., the sender could estimate whether the RTT was greater or less than 200 ms. Alternately, if the sender had an estimate of the RTT when it sends the Rate Request, the two-bit Reserved field at the end of the Quick-Start Option could be used for a coarse-grained encoding of the RTT. @@ -3585,204 +3735,20 @@ 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. -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. - -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 - part of Quick-Start, and discussed ways that this could be used by - routers or by traffic policers, if desired, to check on the use of - Quick-Start by senders. We also note that senders can send at an - initial high rate even in the absence of Quick-Start, in the current - network; that is, in our view, Quick-Start does not change the - dangers to the network from malicious senders. Thus, while we are - 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.. - -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 - rejection of future Quick-Start requests. We have added text to - this document to make this quite explicit. - - [B05] discusses the dangers of sender spoofing and identity - splitting. Identify splitting would not be a problem with Quick- - Start, because Quick-Start requests apply to individual connections, - not to unique addresses or unique tuples of addresses. Because - Quick-Start does not allocate rates to senders, sender-spoofing is - also not a critical issue (except as it would make it more difficult - for those Quick-Start routers that maintain per-flow state to - identify senders that send Quick-Start requests that are not in fact - used, due either to malicious requests or due to requests denied - downstream). - - In Section 3.3, [B05] says that "the lack of a secure binding - between a request and subsequent traffic means that any other node - could send a burst of traffic and claim it requests it, with no-one - being able to prove it didn't." In the current Internet, any node - can send a burst of traffic any time it would like, even without - Quick-Start. However, in the absense of Quick-Start, sending at a - high rate is not always in the sender's interest, as the packets - that are sent might have a high probability of being dropped in the - network, particularly in the absense of Quick-Start. The addition - of the Report of Approved Rate to Quick-Start gives traffic policers - the ability to check on some of the potential abuses of Quick-Start, - if they so desire. - - In Section 3.8, [B05] states that "not only do Quick-Start senders - have to be trusted, but also other senders who could claim their - data had been authorised by a Quick-Start response when it hadn't - (Section 3.3)." In response, we would again clarify that with Quick- - Start, the Quick-Start request makes no difference in how the - subsequent Quick-Start data packets are treated at the router, - 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. - -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 - 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 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. - -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. - -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 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. - -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 - sender is reporting correctly, and the impairment has not changed - significantly from one round-trip time to the next, the reported - impairment at the egress router should be close to zero. - Normative References [RFC793] J. Postel, Transmission Control Protocol, RFC 793, September 1981. [RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191, November 1990. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -3813,61 +3779,53 @@ [RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC 1812, June 1995. [RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, October 1996. [RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997. [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. - April 1997. [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. RFC 2205, September 1997. - [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), - RFC 2409, November 1998. - - [RFC2401] S. Kent and R. Atkinson. Security Architecture for the - Internet Protocol. RFC 2401, November 1998. - - [2401bis] S. Kent and K. Seo, Security Architecture for the Internet - Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work- - in-progress, March 2005. + [RFC2401] S. Kent and R. Atkinson, Security Architecture for the + Internet Protocol, RFC 2401, November 1998. [RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC 2402, November 1998. - [2402bis] S. Kent, IP Authentication Header, internet-draft draft- - ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005. + [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), + RFC 2409, November 1998. [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased Initial TCP Window Size. RFC 2415. September 1998. [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 2463, December 1998. [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over Satellite Channels using Standard Mechanisms. RFC 2488. January 1999. - [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, - Generic Routing Encapsulation (GRE), RFC 2784, March 2000. - [RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August 1999. - [RFC2960] R. Stewart, et. al. Stream Control Transmission Protocol. + [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, + Generic Routing Encapsulation (GRE), RFC 2784, March 2000. + + [RFC2960] R. Stewart, et al. Stream Control Transmission Protocol. RFC 2960, October 2000. [RFC3031] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label Switching Architecture. RFC 3031. January 2001. [RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC 3124. June 2001. [RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and Issues, RFC 3234, February 2002. @@ -3888,41 +3846,49 @@ [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775, June 2004. [RFC3819] P. Karn et al., "Advice for Internet Subnetwork Designers", July 2004. [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January 2005. + [RFC4301] S. Kent and K. Seo, Security Architecture for the Internet + Protocol, RFC 4301, December 2005. + + [RFC4302] S. Kent, IP Authentication Header, RFC 4302, December + 2005. + [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. + [RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion + Control Protocol (DCCP), RFC 4340, March 2006. + + [RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion + Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion + Control, RFC 4341, March 2006. + [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP with Larger Initial Windows. ACM Computer Communication Review, July 1998. [B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL "http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005. [BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion Response in an Internetwork Using Re-Feedback", SIGCOMM, August 2005. - [BJS05] Briscoe, B., Jacquet, A., and A. Salvatori, "Re-ECN: Adding - Accountability for Causing Congestion to TCP/IP", internet-draft - draft-briscoe-tsvwg-re-ecn-tcp-00.txt, work-in-progress, October - 2005. - [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of the new GSM Phase 2+ General Packet Radio Service. IEEE Communications Magazine, pages 94--104, August 1997. [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi- Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, September 2002. [H05] P. Hoffman, email, October 2005. Citation for acknowledgement @@ -3946,35 +3912,35 @@ Sterbenz. Explicit Transport Error Notification (ETEN) for Error- Prone Wireless and Satellite Networks. Technical Report No. 8333, BBN Technologies, March 2002. URL "http://www.icir.org/mallman/papers/". [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet Congestion Control for Future High Bandwidth-Delay Product Environments. ACM Sigcomm 2002, August 2002. URL "http://ana.lcs.mit.edu/dina/XCP/". - [KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion - Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt, - work in progress, March 2005. - [KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003. [KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig Partridge, Mark Allman. Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks. Computer Networks, 46(3), October 2004. [L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005. URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf". + [MH06] M. Mathis and J. Heffner, Packetization Layer Path MTU + Discovery, internet-draft draft-ietf-pmtud-method-07.txt, work in + progress, June 2006. + [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring Interactions Between Transport Protocols and Middleboxes, Internet Measurement Conference 2004, August 2004. URL "http://www.icir.org/tbit/". [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the Evolution of Transport Protocols in the Internet. Computer Communications Review, April 2005. [MaxNet] MaxNet Home Page, URL @@ -4012,26 +3978,30 @@ [SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work in Progress session , August 2005, https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf. [SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce, Washington, D.C. publication 180-1, April 1995. [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick - Start with NS-2. Class Project, December 2002. Not publically + Start with NS-2. Class Project, December 2002. Not publicly available; citation for acknowledgement purposes only. [V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A Mechanism for Background Transfers. OSDI 2002. + [VH97] V. Visweswaraiah and J. Heidemann, Improving Restart of Idle + TCP Connections, Technical Report 97-661, University of Southern + California, November 1997. + [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE International Performance, Computing, And Communications Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL "http://www.welzl.at/research/publications/". [ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001.