idnits 2.17.1 draft-ietf-tsvwg-quickstart-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3909. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([KHR02]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '... say that sender SHOULD send one packe...' RFC 2119 keyword, line 125: '... say that the TCP sender SHOULD use an...' RFC 2119 keyword, line 143: '... SHOULD delete the Quick-Start o...' RFC 2119 keyword, line 144: '... possible, SHOULD zero the QS TT...' RFC 2119 keyword, line 153: '... Added that "TCP SHOULD NOT use Quick-...' (67 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 March 2006) is 6624 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2460' is mentioned on line 727, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'T1' is mentioned on line 1771, but not defined == Missing Reference: 'T2' is mentioned on line 1770, but not defined == Missing Reference: 'T0' is mentioned on line 1771, but not defined == Unused Reference: 'RFC2246' is defined on line 3605, but no explicit reference was found in the text == Unused Reference: 'RFC2309' is defined on line 3607, but no explicit reference was found in the text == Unused Reference: 'RFC2416' is defined on line 3629, but no explicit reference was found in the text == Unused Reference: 'BJS05' is defined on line 3692, but no explicit reference was found in the text == Unused Reference: 'FF99' is defined on line 3701, but no explicit reference was found in the text == Unused Reference: 'PK98' is defined on line 3760, but no explicit reference was found in the text == Unused Reference: 'W03' is defined on line 3809, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Downref: Normative reference to an Experimental RFC: RFC 3742 -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2463 (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-09) exists of draft-briscoe-tsvwg-re-ecn-tcp-00 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Floyd 2 INTERNET-DRAFT M. Allman 3 draft-ietf-tsvwg-quickstart-02.txt ICIR 4 Expires: September 2006 A. Jain 5 F5 Networks 6 P. Sarolahti 7 Nokia Research Center 8 5 March 2006 10 Quick-Start for TCP and IP 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 2006. 37 Abstract 39 This document specifies an optional Quick-Start mechanism for 40 transport protocols, in cooperation with routers, to determine an 41 allowed sending rate at the start and at times in the middle of a 42 data transfer (e.g., after an idle period). While Quick-Start is 43 designed to be used by a range of transport protocols, in this 44 document we describe its use with TCP. By using Quick-Start, a TCP 45 host, say, host A, would indicate its desired sending rate in bytes 46 per second, using a Quick Start option in the IP header of a TCP 47 packet. Each router along the path could, in turn, either approve 48 the requested rate, reduce the requested rate, or indicate that the 49 Quick-Start request is not approved. If the Quick-Start request is 50 not approved, then the sender would use the default congestion 51 control mechanisms. The Quick-Start mechanism can determine if 52 there are routers along the path that do not understand the Quick- 53 Start option, or have not agreed to the Quick-Start rate request. 54 TCP host B communicates the final rate request to TCP host A in a 55 transport-level Quick-Start Response in an answering TCP packet. 56 Quick-Start is designed to allow connections to use higher sending 57 rates when there is significant unused bandwidth along the path, and 58 all of the routers along the path support the Quick-Start Request. 60 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 62 Changes from draft-ietf-tsvwg-quickstart-01: 63 * Added a citation to SPAND: Speeding Up Short Data Transfers. 64 * Added a sentence in Section 8.1 on "Implementation Issues for 65 Processing Quick-Start Requests" about multi-access links. 66 * Mentioned the IP Router Alert option, RFC 2113, in Appendix 67 A.1.1. 68 * Added a discussion of lower-than-best-effort service. 69 * Added a few sentences about the requirements for 70 randomness in the nonce. 71 * Changed the name of the option from the Quick-Start Request 72 Option to the Quick-Start Option. 73 * Changed the semantics of the Reserved field to the Function 74 field, adding that a Quick-Start option is only interpreted 75 as a request if this field is zero. 76 * Changed the "Reporting Approved Rate" option from a 77 "Possible Use" in Appendix D to a required use in Section 3.1, 78 to allow routers and receivers some protection against 79 misbehaving senders. 80 * Changes from feedback from Bob Briscoe: 81 - Added Appendix E with a response to Sections 1-3 of 82 Bob Briscoe's document. 83 - Added a clarification that the approval of a 84 Quick-Start request at a router does not affect 85 the treatment of the subsequent arriving 86 Quick-Start data packets. 87 - Added the one-way hash function as an alternate 88 implementation for the QS Nonce. 89 - Clarified the phrase "incrementally deployable", adding 90 the following: 91 "We note that while Quick-Start is incrementally deployable 92 in this sense, a Quick-Start request can not be approved 93 for a particular connection unless both end-nodes and all 94 of the routers along the path have been configured to 95 support Quick-Start." 96 - Clarified semantics about additional rate. 97 - Said that when denying a rate request, the router 98 may in the future use the QS Nonce field to report 99 an error code. 100 - Add Bob's suggestion from Section 4.4 as an alternate 101 possible rate encoding. 102 - Made changes suggested in Section 5.1.3 of Bob's paper, 103 including saying that the router should decrement the QS TTL 104 by the same amount that it decrements the IP TTL (on the 105 off chance that it decrements the IP TTL by more than one). 106 - Fixed nits. 108 Changes from draft-ietf-tsvwg-quickstart-00: 109 * Added a 30-bit QS Nonce. Based on feedback from Guohan Lu 110 and Gorry Fairhurst (and deleted the text about a possible 111 four-bit QS nonce). 112 * Added a new section "Quick-Start and IPsec AH", based on feedback 113 from Joe Touch and David Black. 114 * Revised "Quick-Start in IP Tunnels" Section, based on feedback 115 from Joe Touch and David Black. 116 * Added a section about "Possible Uses for the Reserved Fields". 117 * Changes from feedback from Gorry Fairhurst: 118 - Section 4.4, revised the explanation for reducing the 119 congestion window when the first ACK for a Quick-Start 120 packet is received. 121 - Section 6.4, deleted the last sentence. 122 - Minor editing changes. 123 - Revised Section 4.6.2 to say that sender SHOULD send one packet 124 with an initial RTO of three seconds. 125 - Revised Section 4.6.3 to say that the TCP sender SHOULD use an 126 initial RTO setting of three seconds. 127 - Added text to Section 6.2 on Multiple Paths, discussing 128 multi-path routing. 129 - Clarified about GPRS round-trip times. 130 - Clarified about PMTUD and the first window of data. 131 - A small reorganization, rearranging sections. 132 * Changes from feedback from Martin Duke: 133 - Revised text about the size of QS requests. 134 - Added some text to Section 4.1, about when to send QS requests. 136 Changes from draft-amit-quick-start-04.txt: 137 * A significant amount of general editing. 138 * Because the Rate Request field only uses four bits, specified 139 that the other four bits are reserved, and talked about a 140 possible use for them. This is discussed in a new section on 141 "A Rate-Reduced Nonce?" 142 * Specified that a Quick-Start-capable router denying a request 143 SHOULD delete the Quick-Start option, and if this is not 144 possible, SHOULD zero the QS TTL and the Rate Request fields. 145 * Made the following change: If the Quick-Start Response is lost 146 in the network, it is not retransmitted. 147 * For PMTUD, in Section 4.6, added a suggestion to send one large 148 packet in the initial window for PMTUD, and to send the other 149 packets at 576 bytes. 150 * Added a paragraph to Section 4.6.3 on retransmitted SYN packets, 151 saying they should use an RTO of three seconds and a new ISN 152 on the retransmitted SYN packet. 153 * Added that "TCP SHOULD NOT use Quick-Start" after an 154 application-limited period at this time, in Section 4.1, in 155 addition to the old sentence that this "requires further thought 156 and investigation". 157 * Added an appendix on "Possible Router Algorithm". 158 * Moved the section on "Quick-Start with DCCP" to the appendix. 159 * Name changed from draft-amit-quick-start-04.txt to 160 draft-tsvwg-quickstart-00.txt. 162 Changes from draft-amit-quick-start-03.txt: 163 * Added a citation to the paper on "Evaluating Quick-Start for 164 TCP", and added pointers to the work in that paper. 165 This work includes: 166 - Discussions of router algorithms. 167 - Discussions of sizing Quick-Start requests. 168 * Added sections on "Misbehaving Middleboxes", and on "Attacks on 169 Quick-Start". 171 Changes from draft-amit-quick-start-02.txt: 172 * Added a discussion on Using Quick-Start in the Middle of a 173 Connection. The request would be on the total rate, 174 not on the additional rate. 175 * Changed name "Initial Rate" to "Rate Request", and changed 176 the units from packets per second to bytes per second. 177 * The following sections are new: 178 - The Quick-Start Request Option for IPv6 179 - Quick-Start in IP Tunnels 180 - When to Use Quick-Start 181 - TCP: Responding to a Loss of a Quick-Start Packet 182 - TCP: A Quick-Start Request for a Larger Initial Window 183 - TCP: A Quick-Start Request after an Idle Period 184 - The Quick-Start Mechanisms in DCCP and other Transport 185 Protocols 186 - Quick-Start with DCCP 187 - Implementation and Deployment Issues 188 - Design Decisions 189 * Added a discussion of Kunniyur's Anti-ECN proposal. 190 * Added a section on simulations, with a brief discussion of the 191 simulations by Srikanth Sundarrajan. 193 Changes from draft-amit-quick-start-01.txt: 194 * Added a discussion in the related work section about the 195 possibility of optimistically sending a large initial window, 196 without explicit permission of routers. 197 * Added a discussion in the related work section about the 198 tradeoffs of XCP vs. Quick-Start. 199 * Added a section on "The Quick-Start Request: Packets or Bytes?" 201 Changes from draft-amit-quick-start-00.txt: 202 * The addition of a citation to [KHR02]. 203 * The addition of a Related Work section. 205 * Deleted the QS Nonce, in favor of a random initial value for the 206 QS TTL. 208 Table of Contents 210 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 10 211 2. Assumptions and General Principles. . . . . . . . . . . . . . 11 212 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 13 213 3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 15 214 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 15 215 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 18 216 3.3. Processing the Quick-Start Request at 217 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 218 3.3.1. Processing the Report of Approved 219 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 220 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 21 221 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 23 222 4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 24 223 4.2. The Quick-Start Response Option in the TCP 224 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 225 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 27 226 4.4. TCP: Receiving and Using the Quick-Start 227 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 27 228 4.5. TCP: Responding to a Loss of a Quick-Start 229 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 230 4.6. TCP: A Quick-Start Request for a Larger Ini- 231 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 30 232 4.6.1. Interactions with Path MTU Discovery. . . . . . . . 30 233 4.6.2. Quick-Start Request Packets that are 234 Discarded by Middleboxes . . . . . . . . . . . . . . . . . 31 235 4.7. TCP: A Quick-Start Request in the Middle of 236 a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 32 237 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 33 238 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 34 239 6. Quick-Start in IP Tunnels . . . . . . . . . . . . . . . . . . 34 240 6.1. Simple Tunnels That Are Compatible with 241 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 36 242 6.1.1. Simple Tunnels that are Aware of Quick- 243 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 37 244 6.2. Simple Tunnels That Are Not Compatible with 245 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 37 246 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 38 247 7. The Quick-Start Mechanism in other Transport Pro- 248 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 249 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 40 250 8.1. Determining the Rate to Request. . . . . . . . . . . . . 40 251 8.2. Deciding the Permitted Rate Request at a 252 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 253 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 42 254 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 42 255 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 42 256 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 44 257 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 44 258 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 44 259 9.4.2. Receivers Lying about Whether the 260 Request was Approved . . . . . . . . . . . . . . . . . . . 45 261 9.4.3. Receivers Lying about the Approved 262 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 263 9.4.4. Collusion between Misbehaving Routers . . . . . . . 47 264 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 49 265 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 49 266 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 50 267 10. Implementation and Deployment Issues . . . . . . . . . . . . 50 268 10.1. Implementation Issues for Sending Quick- 269 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 50 270 10.2. Implementation Issues for Processing Quick- 271 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 51 272 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 51 273 10.4. Would QuickStart packets take the slow path 274 in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 52 275 10.5. A Comparison with the Deployment Problems 276 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 277 11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 53 278 11.1. Fast Start-ups without Explicit Information 279 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 53 280 11.2. Optimistic Sending without Explicit Infor- 281 mation from Routers . . . . . . . . . . . . . . . . . . . . . 55 282 11.3. Fast Start-ups with other Information from 283 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 284 11.4. Fast Start-ups with more Fine-Grained Feed- 285 back from Routers . . . . . . . . . . . . . . . . . . . . . . 56 286 11.5. Fast Start-ups with Lower-Than-Best-Effort 287 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 288 12. Security Considerations. . . . . . . . . . . . . . . . . . . 58 289 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 58 290 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 291 A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 59 292 A.1. Alternate Mechanisms for the Quick-Start 293 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 59 294 A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 59 295 A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 61 296 A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 62 297 A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 63 298 A.4. Quick-Start Semantics: Total Rate or Addi- 299 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 64 300 A.5. Alternate Responses to the Loss of a Quick- 301 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 65 302 A.6. Why Not Include More Functionality?. . . . . . . . . . . 66 303 A.7. Alternate Implementations for a QuickStart 304 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 305 A.7.1. An Alternate Proposal for the Quick- 306 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 69 307 A.7.2. The Earlier Request-Approved QuickStart 308 Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . . 70 309 B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 71 310 C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 73 311 D. Possible Additional Uses for the Quick-Start 312 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 313 E. Feedback from Bob Briscoe . . . . . . . . . . . . . . . . . . 75 314 E.1. Potential Deployment Scenarios . . . . . . . . . . . . . 76 315 E.2. Misbehaving Senders and Receivers. . . . . . . . . . . . 76 316 E.3. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 77 317 E.4. Models of Under-Utilization. . . . . . . . . . . . . . . 78 318 E.5. Router Algorithms as Local Policy. . . . . . . . . . . . 78 319 E.6. An Alternate Proposal. . . . . . . . . . . . . . . . . . 79 320 Normative References . . . . . . . . . . . . . . . . . . . . . . 79 321 Informative References . . . . . . . . . . . . . . . . . . . . . 80 322 F. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 323 F.1. IP Option. . . . . . . . . . . . . . . . . . . . . . . . 85 324 F.2. TCP Option . . . . . . . . . . . . . . . . . . . . . . . 85 325 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 85 326 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 87 327 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 87 329 1. Introduction 331 Each connection begins with a question: "What is the appropriate 332 sending rate for the current network path?" The question is not 333 answered explicitly, but each TCP connection determines the sending 334 rate by probing the network path and altering the congestion window 335 (cwnd) based on perceived congestion. Each TCP connection starts 336 with a pre-configured initial congestion window (ICW). Currently, 337 TCP allows an initial window of between one and four MSS-sized 338 segments [RFC2581,RFC3390]. The TCP connection then probes the 339 network for available bandwidth using the slow-start procedure 340 [Jac88,RFC2581], doubling cwnd during each congestion-free round- 341 trip time (RTT). 343 The slow-start algorithm can be time-consuming --- especially over 344 networks with large bandwidth or long delays. It may take a number 345 of RTTs in slow-start before the TCP connection begins to fully use 346 the available bandwidth of the network. For instance, it takes 347 log_2(N) - 2 round-trip times to build cwnd up to N segments, 348 assuming an initial congestion window of 4 segments. This time in 349 slow-start is not a problem for large file transfers, where the 350 slow-start stage is only a fraction of the total transfer time. 351 However, in the case of moderate-sized transfers the connection 352 might carry out its entire transfer in the slow-start phase, taking 353 many round-trip times, where one or two RTTs might have been 354 appropriate in the current network conditions. 356 A fair amount of work has already been done to address the issue of 357 choosing the initial congestion window for TCP, with RFC 3390 358 allowing an initial window of up to four segments based on the MSS 359 used by the connection [RFC3390]. Our underlying premise is that 360 explicit feedback from all of the routers along the path would be 361 required, in the current architecture, for best-effort connections 362 to use initial windows significantly larger than those allowed by 363 [RFC3390], in the absence of other information about the path. 365 The Congestion Manager [RFC3124] and TCP control block sharing 366 [RFC2140] both propose sharing congestion information among multiple 367 TCP connections with the same endpoints. With the Congestion 368 Manager, a new TCP connection could start with a high initial cwnd 369 if it was sharing the path and the cwnd with a pre-existing TCP 370 connection to the same destination that had already obtained a high 371 congestion window. RFC 2140 discusses ensemble sharing, where an 372 established connection's congestion window could be `divided up' to 373 be shared with a new connection to the same host. However, neither 374 of these approaches addresses the case of a connection to a new 375 destination, with no existing or recent connection (and therefore 376 congestion control state) to that destination. 378 Quick-Start would not be the first mechanism for explicit 379 communication from routers to transport protocols about sending 380 rates. Explicit Congestion Notification (ECN) gives explicit 381 congestion control feedback from routers to transport protocols, 382 based on the router detecting congestion before buffer overflow 383 [RFC3168]. In contrast, routers would not use Quick-Start to give 384 congestion information, but instead would use Quick-Start as an 385 optional mechanism to give permission to transport protocols to use 386 higher sending rates, based on the ability of all the routers along 387 the path to determine if their respective output links are 388 significantly underutilized. 390 2. Assumptions and General Principles 392 This section describes the assumptions and general principles behind 393 the design of the Quick-Start mechanism. 395 Assumptions: 397 * The data transfer in the two directions of a connection traverses 398 different queues, and possibly even different routers. Thus, any 399 mechanism for determining the allowed sending rate would have to be 400 used independently for each direction. 402 * The path between the two endpoints is relatively stable, such that 403 the path used by the Quick-Start request is generally the same path 404 used by the Quick-Start packets one round-trip time later. [ZPS00] 405 shows this assumption should be generally valid, although [RFC3819] 406 discusses a range of Bandwidth on Demand subnets. 408 * Any new mechanism must be incrementally deployable, and might not 409 be supported by all of the routers and/or end-hosts. Thus, any new 410 mechanism must be able to accommodate non-supporting routers or end- 411 hosts without disturbing the current Internet semantics. We note 412 that while Quick-Start is incrementally deployable in this sense, a 413 Quick-Start request can not be approved for a particular connection 414 unless both end-nodes and all of the routers along the path have 415 been configured to support Quick-Start. 417 General Principles: 419 * Our underlying premise is that explicit feedback from all of the 420 routers along the path would be required, in the current 421 architecture, for best-effort connections to use initial windows 422 significantly larger than those allowed by [RFC3390], in the absence 423 of other information about the path. 425 * A router should only approve a request for a higher sending rate 426 if the output link is underutilized. Any other approach will result 427 in either per-flow state at the router, or the possibility of a 428 (possibly transient) queue at the router. 430 * No per-flow state should be required at the router. Note that 431 while per-flow state is not required, we also do not preclude a 432 router from storing per-flow state for making Quick-Start decisions 433 or for checking for misbehaving nodes. 435 There are also a number of questions regarding the Quick-Start 436 mechanism that are discussed later in this document. 438 Questions: 440 * Would the benefits of the Quick-Start mechanism be worth the added 441 complexity? 443 The benefits and drawbacks of Quick-Start are discussed in more 444 detail in Section 9 on "Evaluation of Quick-Start". 446 * One practical consideration is that packets with known and unknown 447 IP options are often dropped in the current Internet [MAF04]. 449 We note that this does not preclude using Quick-Start in Intranets. 450 Further, [MAF04] also shows that over time the blocking of packets 451 negotiating ECN has become less common, and therefore an incremental 452 deployment story for Quick-Start based on IP Options is not out of 453 the question for the Internet. Appendix A.1 on "Alternate 454 Mechanisms for the Quick-Start Request" discusses the possibility of 455 using RSVP or ICMP instead of IP Options for carrying Quick-Start 456 Requests to routers. 458 * A second practical consideration is that Quick-Start data packets 459 could be dropped at non-IP queues along the path, if the non-IP 460 queue is a point of congestion. This is discussed in more detail in 461 Section 9.2. 463 * Apart from the merits and shortcomings of the Quick-Start 464 mechanism, is there likely to be a compelling need to add explicit 465 congestion-related feedback from routers over and above the one-bit 466 feedback from ECN? 468 If the answer to the question above is yes, should we be considering 469 ways to incorporate Quick-Start in mechanisms that, while more 470 complex, are also sufficiently more powerful than Quick-Start, or 471 should Quick-Start be considered as orthogonal to such mechanisms? 472 This is discussed further in Appendix A.6 on "Why Not Include More 473 Functionality". 475 2.1. Overview of Quick-Start 477 In this section we give an overview of the use of Quick-Start with 478 TCP to request a higher congestion window. The description in this 479 section is non-normative; the normative description of Quick-Start 480 with IP and TCP follows in Sections 3 and 4. Quick-Start could be 481 used in the middle of a connection, e.g., after an idle or 482 underutilized period, as well as for the initial sending rate; these 483 uses of Quick-Start are discussed later in the document. 485 Quick-Start requires end-points and routers to work together, with 486 end-points requesting a higher sending rate in the Quick-Start (QS) 487 option in IP, and routers along the path approving, modifying, 488 discarding or ignoring (and therefore disallowing) the Quick-Start 489 Request. The receiver uses reliable, transport-level mechanisms to 490 inform the sender of the status of the Quick-Start Request. In 491 addition, Quick-Start assumes a unicast, congestion-controlled 492 transport protocol; we do not consider the use of Quick-Start for 493 multicast traffic. 495 When sent as a request, the Quick-Start Option includes a request 496 for a sending rate in bytes per second, and a Quick-Start TTL (QS 497 TTL) to be decremented by every router along the path that 498 understands the option and approves the request. The Quick-Start 499 TTL is initialized by the sender to a random value. The transport 500 receiver returns the rate and information about the TTL to the 501 sender using transport-level mechanisms. In particular, the 502 receiver computes the difference between the Quick-Start TTL and the 503 IP TTL (the TTL in the IP header) of the Quick-Start request packet, 504 and returns this in the Quick-Start response. The sender uses this 505 information to determine if all of the routers along the path 506 decremented the Quick-Start TTL, approving the Quick-Start Request. 508 If the request is approved by all of the routers along the path, 509 then the TCP sender combines this allowed rate with the measurement 510 of the round-trip time, and ends up with an allowed TCP congestion 511 window. This window is sent rate-paced over the next round-trip 512 time, or until an ACK packet is received. 514 Figure 1 shows a successful use of Quick-Start, with both routers 515 along the path approving the Quick-Start Request. In this example, 516 Quick-Start is used by TCP to establish the initial congestion 517 window. 519 Sender Router 1 Router 2 Receiver 520 ------ -------- -------- -------- 521 | 522 | 523 | 524 | Quick-Start Request 525 | in SYN or SYN/ACK --> 526 | 527 | Decrement 528 | QS TTL 529 | to approve 530 | request --> 531 | 532 | Decrement 533 | QS TTL 534 | to approve 535 | request --> 536 | 537 | 538 | 539 | 540 | Return Quick-Start 541 | info to sender in 542 | <-- TCP ACK packet. 543 | 544 | 545 | Quick-Start approved, 546 | translate to cwnd. 547 | Report Approved Rate. 548 V Send cwnd paced over one RTT. --> 550 Figure 1: A successful Quick-Start Request. 552 Figure 2 shows an unsuccessful use of Quick-Start, with one of the 553 routers along the path not approving the Quick-Start Request. If 554 the Quick-Start Request is not approved, then the sender uses the 555 default congestion control mechanisms for that transport protocol, 556 including the default initial congestion window, response to idle 557 periods, etc. 559 Sender Router 1 Router 2 Receiver 560 ------ -------- -------- -------- 561 | 562 | 563 | 564 | Quick-Start Request 565 | in SYN or SYN/ACK --> 566 | 567 | Decrement 568 | QS TTL 569 | to approve 570 | request --> 571 | 572 | Forward packet 573 | without modifying 574 | Quick-Start Option. --> 575 | 576 | 577 | 578 | 579 | Return Quick-Start 580 | info to sender in 581 | <-- TCP ACK packet. 582 | 583 | 584 | Quick-Start not approved. 585 | Report Approved Rate. 586 V Use default initial cwnd. --> 588 Figure 2: An unsuccessful Quick-Start Request. 590 3. The Quick-Start Option in IP 592 3.1. The Quick-Start Option for IPv4 594 The Quick-Start Request for IPv4 is defined as follows: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Option | Length=8 | Func. | Rate | QS TTL | 600 | | | 0000 |Request| | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | QS Nonce | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Figure 3. The Quick-Start Option for IPv4. 606 A Quick-Start Request. 608 The first byte contains the option field, which includes the one-bit 609 copy flag, the 2-bit class field, and the 5-bit option number (to be 610 assigned by IANA). 612 The second byte contains the length field, indicating an option 613 length of eight bytes. 615 The third byte includes a four-bit Function field. If the Function 616 field is set to "0000", then the Quick-Start Option is a Rate 617 Request. In this case, the second half of the third byte is a four- 618 bit Rate Request field. 620 For a Rate Request, the fourth byte contains the Quick-Start TTL (QS 621 TTL) field. The sender MUST set the QS TTL field to a random value. 622 Routers that approve the Quick-Start Request decrement the QS TTL 623 (mod 256) by the same amount that they decrement the IP TTL. The QS 624 TTL is used by the sender to detect if all of the routers along the 625 path understood and approved the Quick-Start option. 627 For a Rate Request, the transport sender MUST calculate and store 628 the TTL Diff, the difference between the IP TTL value and the QS TTL 629 value in the Quick-Start request packet, as follows: 631 TTL Diff = ( IP TTL - QS TTL ) mod 256 (1) 633 For a Rate Request, the second four bytes contain a 30-bit QS Nonce 634 and a two-bit Reserved field. The sender SHOULD set the reserved 635 field to zero, and routers SHOULD ignore the reserved field. The 636 sender SHOULD set the 30-bit QS Nonce to a random value. 638 The sender initializes the Rate Request to the desired sending rate, 639 including an estimate of the transport and IP header overhead. The 640 encoding function for the Rate Request sets the request rate to 641 K*2^N bps (bits per second), for N the value in the Rate Request 642 field, and for K set to 40,000. For N=0, the rate request would be 643 set to zero, regardless of the encoding function. This is 644 illustrated in Table 1 below. For the four-bit Rate Request field, 645 the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings 646 that were considered for the Rate Request are given in Appendix A.2. 648 N Rate Request (in Kbps) 649 --- ------------------- 650 0 0 651 1 80 652 2 160 653 3 320 654 4 640 655 5 1,280 656 6 2,560 657 7 5,120 658 8 10,240 659 9 20,480 660 10 40,960 661 11 81,920 662 12 163,840 663 13 327,680 664 14 655,360 665 15 1,310,720 667 Table 1: Mapping from Rate Request field to rate request in Kbps. 669 Routers can approve the Quick-Start Request for a lower rate by 670 decreasing the Rate Request in the Quick-Start Request. Section 4.2 671 discusses the Quick-Start Response from the TCP receiver to the TCP 672 sender, and Section 4.4 discusses the TCP sender's mechanism for 673 determining if a Quick-Start Request has been approved. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Option | Length=8 | Func. | Rate | Not Used | 679 | | | 1000 | Report| | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Not Used | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Figure 4. The Quick-Start Option for IPv4. 685 Report of Approved Rate. 687 If the Function field in the third byte of the Quick-Start Option is 688 set to "1000", then the Quick-Start Option is a Report of Approved 689 Rate. In this case the second four bits in the third byte are the 690 Rate Report field, formatted exactly as in the Rate Request field in 691 a Rate Request. For a Report of Approved Rate, the last five bytes 692 of the Quick-Start Option are not used. 694 After an approved Rate Request, the sender MUST report the Approved 695 Rate, using a Quick-Start Option configured as a Report of Approved 696 Rate with the Rate Report field set to the approved rate. The 697 packet containing the Report of Approved Rate MUST be either a 698 control packet sent before the first Quick-Start data packet, or a 699 Quick-Start Option in the first data packet itself. The Report of 700 Approved Rate does not have to be sent reliably; for example, if the 701 approved rate is reported in a separate control packet, the sender 702 does not necessarily know if the control packet has been dropped in 703 the network. 705 If the Rate Request is denied, the sender MUST sent a Report of 706 Approved Rate with the Rate Report field set to zero. 708 We note that unlike a Quick-Start Request sent at the beginning of a 709 connection, when a Quick-Start Request is sent in the middle of a 710 connection, the connection could already have an established 711 congestion window or sending rate. The Rate Request is the 712 requested total rate for the connection, including the current rate 713 of the connection; the Rate Request is *not* a request for an 714 additional sending rate over and above the current sending rate. If 715 the Rate Request is denied, or lowered to a value below the 716 connection's current sending rate, then the sender ignores the 717 request, and reverts to the default congestion control mechanisms of 718 the transport protocol. 720 We note that in IPv4, a change in IP options at routers requires 721 recalculating the IP header checksum. 723 3.2. The Quick-Start Option for IPv6 725 The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options 726 extension header that is processed at every network node along the 727 communication path [RFC 2460]. The option format following the 728 generic Hop-by-Hop Options header is identical to the IPv4 format, 729 with the exception that the Length field should exclude the common 730 type and length fields in the option format and be set to 6 bytes 731 instead of 8 bytes. 733 For a Quick-Start Request, the transport receiver compares the 734 Quick-Start TTL with the IPv6 Hop Limit field in order to calculate 735 the TTL Diff. (The Hop Limit in IPv6 is the equivalent of the TTL 736 in IPv4.) That is, TTL Diff MUST be calculated and stored as 737 follows: 739 TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2) 741 Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does 742 not require checksum re-calculation, because the IPv6 header does 743 not have a checksum field, and modifying the Quick-Start Request in 744 the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo- 745 header checksum used in upper-layer checksum calculations. 747 Note that [RFC2460] specifies that when a specific flow label has 748 been assigned to packets, the contents of the Hop-by-Hop options, 749 excluding the next header field, must originate with the same 750 contents throughout the IP flow lifetime. However, the Quick-Start 751 option would be included in only a small fraction of the packets 752 during a flow lifetime. Thus, Quick-Start SHOULD NOT be used in an 753 IPv6 connection that uses flow labels unless the experimental 754 specification of flow labels in Appendix A of RFC 2460 is changed. 755 We note that RFC 2460 states that the use of the flow label field in 756 IPv6 "is, at the time of writing, still experimental and subject to 757 change as the requirements for flow support in the Internet become 758 clearer" [RFC2460]. 760 3.3. Processing the Quick-Start Request at Routers 762 The Quick-Start Request does not report the current sending rate of 763 the connection sending the request; in the default case of a router 764 that does not maintain per-flow state, a router makes the 765 conservative assumption that the flow's current sending rate is 766 zero. Each participating router can either terminate or approve the 767 Quick-Start Request. A router should only approve a Quick-Start 768 request if the output link is underutilized, and if the router 769 judges that the output link will continue to be underutilized if the 770 request is approved. Otherwise, the router terminates the Quick- 771 Start Request. 773 A router that wishes to terminate the Quick-Start Request SHOULD 774 delete the Quick-Start Request from the IP header. This saves 775 resources as downstream routers will have no option to process. If 776 a Quick-Start-capable router wishes to deny the request but doesn't 777 delete the Quick-Start Request from the IP header, then the router 778 SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. Zeroing 779 the Rate Request field may be more efficient for routers to 780 implement than deleting the Quick-Start option. As suggested in 782 [B05], future additions to Quick-Start could define error codes for 783 routers to insert into the QS Nonce field to report back to the 784 sender the reason that the Quick-Start request was denied, e.g., 785 that the router is denying all Quick-Start requests at this time, or 786 that this router as a matter of policy does not grant Quick-Start 787 requests. A router that doesn't understand the Quick-Start option 788 will simply forward the packet with the Quick-Start Request 789 unchanged. 791 If the participating router has decided to approve the Quick-Start 792 Request, it does the following: 794 * The router MUST decrement the QS TTL by one. 796 * If the router is only willing to approve a Rate Request less than 797 that in the Quick-Start Request, then the router replaces the Rate 798 Request with a smaller value. The router MUST NOT increase the Rate 799 Request in the Quick-Start Request. If the router decreases the 800 Rate Request, the router MUST also modify the QS Nonce, as described 801 in Section 3.4. 803 * In IPv4, the router MUST update the IP header checksum. 805 If the router approves the Quick-Start request, this approval SHOULD 806 be taken into account in the router's decision to accept or reject 807 subsequent Quick-Start requests (e.g., in a variable that tracks the 808 recent aggregate of accepted Quick-Start bandwidth), but this 809 approval SHOULD NOT be used by the router to affect the treatment of 810 the data packets that arrive from this connection in the next few 811 round-trip times. That is, the approval by the router of a Quick- 812 Start request does not give differential treatment for Quick-Start 813 data packets at that router; it is only a statement from the router 814 that the router believes that the subsequent Quick-Start data 815 packets from this connection will not change the current under- 816 utilized state of the router. 818 A non-participating router forwards the Quick-Start Request 819 unchanged, without decrementing the QS TTL. The non-participating 820 router still decrements the TTL field in the IP header, as is 821 required for all routers [RFC1812]. As a result, the sender will be 822 able to detect that the Quick-Start Request had not been understood 823 or approved by all of the routers along the path. 825 3.3.1. Processing the Report of Approved Rate 827 If the Quick-Start Option has the Function field set to "1000", then 828 this is a Report of Approved Rate, rather than a Rate Request. The 829 router MAY ignore such an option, and in any case it MUST NOT modify 830 the contents of the option for a Report of Approved Rate. However, 831 the router MAY use the Approved Rate report to check that the sender 832 is not lying about the approved rate. If the reported Approved Rate 833 is higher than the rate that the router actually approved for this 834 connection in the previous round-trip time, then the router may 835 decide to deny future Quick-Start requests from this sender, 836 including, if desired, deleting Quick-Start requests from future 837 packets from this sender. Section 9.4.1 discusses misbehaving 838 senders in more detail. From the Report of Approved Rate, the 839 router can also learn if some of the downstream routers have 840 approved the Quick-Start request for a smaller rate, and adjust its 841 bandwidth allocations accordingly. From a Report of Approved Rate 842 with a Rate Report of zero, the router can learn if downstream 843 routers denied the earlier Quick-Start request. 845 3.4. The QS Nonce 847 The QS Nonce gives the Quick-Start sender some protection against 848 receivers lying about the value of the received Rate Request. This 849 is particularly important if the receiver knows the original value 850 of the Rate Request (e.g., when the sender always requests the same 851 value, and the receiver has a long history of communication with 852 that sender). Without the QS Nonce, there is nothing to prevent the 853 receiver from reporting back to the sender a Rate Request of K, when 854 the received Rate Request was in fact less than K. This version of 855 the nonce is based on a proposal from Guohan Lu [L05]. Initial 856 versions of this document contained an eight-bit QS Nonce, and 857 subsequent versions discussed the possibility of a four-bit QS 858 Nonce. 860 Table 2 gives the format for the 30-bit QS Nonce. 862 Bits Purpose 863 --------- ------------------ 864 Bits 0-1: Rate 15 -> Rate 14 865 Bits 2-3: Rate 14 -> Rate 13 866 Bits 4-5: Rate 13 -> Rate 12 867 Bits 6-7: Rate 12 -> Rate 11 868 Bits 8-9: Rate 11 -> Rate 10 869 Bits 10-11: Rate 10 -> Rate 9 870 Bits 12-13: Rate 9 -> Rate 8 871 Bits 14-15: Rate 8 -> Rate 7 872 Bits 16-17: Rate 7 -> Rate 6 873 Bits 18-19: Rate 6 -> Rate 5 874 Bits 20-21: Rate 5 -> Rate 4 875 Bits 22-23: Rate 4 -> Rate 3 876 Bits 24-25: Rate 3 -> Rate 2 877 Bits 26-27: Rate 2 -> Rate 1 878 Bits 28-29: Rate 1 -> Rate 0 880 Table 2: The QS Nonce. 882 The transport sender MUST initialize the QS Nonce to a random value. 883 If the router reduces the Rate Request from rate K to rate K-1, then 884 the router MUST set the field in the QS Nonce for "Rate K -> Rate 885 K-1" to a new random value, using the requirements for "randomness" 886 in the previous paragraph. Similarly, if the router reduces the 887 Rate Request by N steps, the router MUST set the 2N bits in the 888 relevant fields in the QS Nonce to a new random value. The receiver 889 MUST report the QS Nonce back to the sender. 891 If the Rate Request was not decremented in the network, then the QS 892 Nonce should have its original value. Similarly, if the Rate 893 Request was decremented by N steps in the network, and the receiver 894 reports back a Rate Request of K, then the last 2K bits of the QS 895 Nonce should have their original value. 897 With the QS Nonce, the receiver has a 1/4 chance of cheating about 898 each step change in the rate request. Thus, if the rate request was 899 reduced by two steps in the network, the receiver has a 1/16 chance 900 of successfully reporting that the original request was approved, as 901 this requires reporting the original value for the QS nonce. 902 Similarly, if the rate request is reduced many steps in the network, 903 and the receiver receives a QS Option with a rate request of K, the 904 receiver has a 1/16 chance of guessing the original values for the 905 fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 -> 906 Rate K". Thus, the receiver has a 1/16 chance in successfully lying 907 and saying that the received rate request was K+2 instead of K. 909 We note that the protection offered by the QS Nonce is the same 910 whether one router makes all of the decrements in the rate request, 911 or whether they are made at different routers along the path. 913 The requirements for randomization for the sender and routers in 914 setting `random' values in the QS Nonce are not stringent - almost 915 any form of pseudo-random numbers would do. The requirement is that 916 the original value for the QS Nonce is not easily guessable by the 917 receiver, and in particular, the nonce MUST NOT be easily determined 918 from inspection of the rest of the packet or from previous packets. 919 In particular, the nonce MUST NOT be based only on a combination of 920 specific packet header fields. Thus, if two bits of the QS Nonce 921 are changed by a router along the path, the receiver should not be 922 able to guess those two bits from the other 28 bits in the QS Nonce. 924 An additional requirement is that the receiver can not be able to 925 tell, from the QS Nonce itself, which numbers in the QS Nonce were 926 generated by the sender, and which were generated by routers along 927 the path. This makes it harder for the receiver to infer the value 928 of the original rate request, making it one step harder for the 929 receiver to cheat. 931 Section 9.4 also considers issues of receiver cheating in more 932 detail. 934 4. The Quick-Start Mechanisms in TCP 936 This section describes how the Quick-Start mechanism would be used 937 in TCP. We first sketch the procedure and then tightly define it in 938 the subsequent subsections. 940 If a TCP sender, say host A, would like to use Quick-Start, the TCP 941 sender puts the requested sending rate in bytes per second, 942 appropriately formatted, in the Quick-Start option in the IP header 943 of the TCP packet, called the Quick-Start request packet. (We will 944 be somewhat loose in our use of "packet" vs. "segment" in this 945 section.) The Quick-Start Request also includes random values for 946 the QS TTL and the QS Nonce. When used for initial start-up, the 947 Quick-Start request packet can be either the SYN or SYN/ACK packet, 948 as described above. The requested rate includes an estimate for the 949 transport and IP header overhead. The TCP receiver, say host B, 950 returns the Quick-Start Response option in the TCP header in the 951 responding SYN/ACK packet or ACK packet, called the Quick-Start 952 response packet, informing host A of the results of their request. 954 If the acknowledging packet does not contain a Quick-Start Response, 955 or contains a Quick-Start Response with the wrong value for the TTL 956 Diff or the QS Nonce, then host A MUST assume that its Quick-Start 957 request failed. In this case, host A sends a Report of Approved 958 Rate with a Rate Report of zero, and uses TCP's default congestion 959 control procedure. For initial start-up, host A uses the default 960 initial congestion window. 962 If the returning packet contains a valid Quick-Start Response, then 963 host A uses the information in the response, along with its 964 measurement of the round-trip time, to determine the Quick-Start 965 congestion window (QS-cwnd). Quick-Start data packets are defined 966 as data packets sent as the result of a successful Quick-Start 967 request, up to the time when the first Quick-Start packet is 968 acknowledged. The sender sends a Report of Approved Rate. In order 969 to use Quick-Start, the TCP host MUST use rate-based pacing to 970 transmit Quick-Start packets at the rate indicated in the Quick- 971 Start Response, at the level of granularity possible by the sending 972 host. We note that the limitations of interrupt timing on computers 973 can limit the ability of the TCP host in rate-pacing the outgoing 974 packets. 976 The two TCP end-hosts can independently decide whether to request 977 Quick-Start. For example, host A could sent a Quick-Start Request 978 in the SYN packet, and host B could also send a Quick-Start Request 979 in the SYN/ACK packet. 981 4.1. When to Use Quick-Start 983 In addition to the use of Quick-Start when a connection is 984 established, there are several additional points in a connection 985 when a transport protocol may want to issue a Rate Request. We 986 first re-iterate the notion that Quick-Start is a coarse-grained 987 mechanism. That is, Quick-Start's Rate Requests are not meant to be 988 used for fine-grained control of the transport's sending rate. 989 Rather, the transport MAY issue a Rate Request when no information 990 about the appropriate sending rate is available and the default 991 congestion control mechanisms might be significantly underestimating 992 the appropriate sending rate. 994 The following are potential points where Quick-Start may be useful: 996 (1) At or soon after connection initiation, when the transport 997 has no idea of the capacity of the network, as discussed above. 998 (A transport that uses TCP Control Block sharing, the Congestion 999 Manager, or the like may not need Quick-Start to determine an 1000 appropriate rate.) 1001 (2) After an idle period when the transport no longer has a 1002 validated estimate of the available bandwidth for this flow. 1003 (An example could be a persistent-HTTP connection when a new 1004 HTTP request is received after an idle period.) 1006 (3) After a host has received explicit indications that one of 1007 the endpoints has moved its point of network attachment. This 1008 can happen due to some underlying mobility mechanism like Mobile 1009 IP [RFC3344,RFC3775]. Some transports, such as SCTP [RFC2960], 1010 may associate with multiple IP addresses and can switch 1011 addresses (and, therefore network paths) in mid-connection. If 1012 the transport has concrete knowledge of a changing network path 1013 then the current sending rate may not be appropriate and the 1014 transport sender may use Quick-Start to probe the network to see 1015 if it can send at a higher rate. (Alternatively, traditional 1016 slow-start should be used in this case when Quick-Start is not 1017 available.) 1019 (4) After an application-limited period when the sender has been 1020 using only a small amount of its appropriate share of the 1021 network capacity, and has no valid estimate for its fair share. 1022 In this case, Quick-Start may be an appropriate mechanism to 1023 determine if the sender can send at a higher rate. For 1024 instance, consider an application that steadily exchanges low- 1025 rate control messages and suddenly needs to transmit a large 1026 amount of data. 1028 Of the above, this document recommends that a TCP sender MAY attempt 1029 to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that 1030 a TCP sender use Quick-Start for case (3) at the current time. Case 1031 (3) requires external notifications not presently defined for TCP or 1032 other transport protocols. Finally, a TCP SHOULD NOT use Quick- 1033 Start for case (4) at the current time. Case (4) requires further 1034 thought and investigation with regard to how the transport protocol 1035 could determine it was in a situation that would warrant 1036 transmitting a Quick-Start Request. 1038 As a general guideline, a TCP sender SHOULD NOT send a Quick-Start 1039 request until it has confirmed that is ready to transmit enough data 1040 to use the requested rate over the round-trip time of the connection 1041 (or over 100 ms, if the round-trip time is not known). In any 1042 circumstances, the sender MUST NOT make a QS request if it has made 1043 a QS request within the most recent round-trip time. 1045 Section 4.6 discusses some of the issues of using Quick-Start at 1046 connection initiation, and Section 4.7 discusses issues that arise 1047 when Quick-Start is used to request a larger sending rate after an 1048 idle period. 1050 4.2. The Quick-Start Response Option in the TCP header 1052 In order to approve the use of Quick-Start, the TCP receiver 1053 responds to the receipt of a Quick-Start Request with a Quick-Start 1054 Response, using the Quick-Start Response Option in the TCP header. 1055 TCP's Quick-Start Response option is defined as follows: 1057 0 1 2 3 1058 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 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Kind | Length=8 | Resv. | Rate | TTL Diff | 1061 | | | |Request| | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | QS Nonce | | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Figure 5. The Quick-Start Response option in the TCP header. 1068 The first byte of the Quick-Start Response option contains the 1069 option kind, identifying the TCP option (to be assigned by IANA). 1071 The second byte of the Quick-Start Response option contains the 1072 option length in bytes. The length field MUST be set to four bytes. 1074 The third byte of the Quick-Start Response option contains a four- 1075 bit Reserved field, and the four-bit allowed Rate Request, formatted 1076 as in the Quick-Start option. 1078 The fourth byte of the TCP option contains the TTL Diff. The TTL 1079 Diff contains the difference between the IP TTL and QS TTL fields in 1080 the received Quick-Start request packet, as calculated in equations 1081 (1) or (2) (depending on whether IPv4 or IPv6 is used). 1083 The last four bytes of the TCP option contain the 30-bit QS Nonce 1084 and a two-bit Reserved field. 1086 We note that the Quick-Start Response Option for TCP contains eight 1087 bytes, and the length of the TCP option field is generally at most 1088 40 bytes. Other TCP options that might be used include Time Stamp 1089 (ten bytes), Window Scale (three bytes), Maximum Segment Size (four 1090 bytes), Selective Acknowledgments Data (at least ten bytes), and 1091 Selective Acknowledgments Permitted (two bytes). 1093 4.3. TCP: Sending the Quick-Start Response 1095 An end host, say host B, that receives an IP packet containing a 1096 Quick-Start Request passes the Quick-Start Request, along with the 1097 value in the IP TTL field, to the receiving TCP layer. 1099 If the TCP host is willing to permit the Quick-Start Request, then a 1100 Quick-Start Response option is included in the TCP header of the 1101 corresponding acknowledgement packet. The Rate Request in the 1102 Quick-Start Response option is set to the received value of the Rate 1103 Request in the Quick-Start option, or to a lower value if the TCP 1104 receiver is only willing to allow a lower Rate Request. The TTL 1105 Diff in the Quick-Start Response is set to the difference between 1106 the IP TTL value and the QS TTL value as given in equation (1) or 1107 (2) (depending on whether IPv4 or IPv6 is used). The QS Nonce in 1108 the Response is set to the received value of the QS Nonce in the 1109 Quick-Start option. 1111 The Quick-Start Response will NOT be resent if it is lost in the 1112 network. Packet loss is an indication of congestion on the return 1113 path, in which case it is better not to approve the Quick-Start 1114 Request. 1116 4.4. TCP: Receiving and Using the Quick-Start Response Packet 1118 A TCP host, say TCP host A, that sent a Quick-Start Request and 1119 receives a Quick-Start Response in an acknowledgement first checks 1120 that the Quick-Start Response is valid. The Quick-Start Response is 1121 valid if it contains the correct value for the TTL Diff, and an 1122 equal or lesser value for the Rate Request than that transmitted in 1123 the Quick-Start Request. In addition, if the received Rate Request 1124 is K, then the the rightmost 2K bits of the QS Nonce must match 1125 those bits in the QS Nonce sent in the Quick-Start Request. If 1126 these checks are not successful, then the Quick-Start request 1127 failed, and the TCP host MUST use the default TCP congestion window 1128 that it would have used without Quick-Start. If the rightmost 2K 1129 bits of the QS Nonce do not match those bits in the QS Nonce sent in 1130 the Quick-Start Request, for a received Rate Request of K, then the 1131 TCP host MUST NOT send additional Quick-Start requests during the 1132 life of the connection. Whether the Quick-Start request was 1133 successful or not, the TCP host MUST send a Report of Approved Rate. 1135 If the checks of the TTL Diff and the Rate Request are successful, 1136 then the TCP host sets its Quick-Start congestion window (in terms 1137 of MSS-sized segments), QS-cwnd, as follows: 1139 QS-cwnd = (R * T) / (MSS + H) (3) 1141 where R the Rate Request in bytes per second, T the measured round- 1142 trip time in seconds, and H the estimated TCP/IP header size in 1143 bytes (e.g., 40 bytes). 1145 Derivation: the sender is allowed to transmit at R bytes per second 1146 including packet headers, but only R*MSS/(MSS+H) bytes per second, 1147 or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of 1148 application data. 1150 The TCP host SHOULD set its congestion window cwnd to QS-cwnd only 1151 if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. When 1152 Quick-Start is used at the beginning of a connection, before any 1153 packet marks or losses have been reported, the TCP host MAY use the 1154 reported Rate Request to set the slow-start threshold to a desired 1155 value, e.g., to some small multiple of the congestion window. (The 1156 initial value of ssthresh is allowed to be arbitrarily high, and 1157 some TCP implementations use the size of the advertised window for 1158 ssthresh [RFC2581].) 1160 If QS-cwnd is used, the TCP host sets a flag that it is in Quick- 1161 Start mode, and while in Quick-Start mode the TCP sender MUST use 1162 rate-based pacing to pace out Quick-Start packets at the specified 1163 Rate Request. If, during Quick-Start mode, the TCP sender receives 1164 ACKs for packets sent before this Quick-Start mode was entered, 1165 these ACKs are processed as usual, following the default congestion 1166 control mechanisms. Quick-Start mode ends when the TCP host 1167 receives an ACK for one of the Quick-Start packets. 1169 If the congestion window has not been fully used when the first ack 1170 arrives ending the Quick-Start mode, then the congestion window is 1171 decreased to the amount that has actually been used so far. This is 1172 necessary because when the Quick-Start Response is received, the TCP 1173 sender's round-trip-time estimate might be longer than for 1174 succeeding round-trip times, e.g., because of delays at routers 1175 processing the IP QuickStart option, or because of delays at the 1176 receiver in responding to the Quick-Start Request packet. In this 1177 case, an overly-large round-trip-time estimate could have caused the 1178 TCP sender to translate the approved Quick-Start sending rate in 1179 bytes per second into a congestion window that is larger than 1180 needed, with the TCP sender receiving an ACK for the first Quick- 1181 Start packet before the entire congestion window has been used. 1182 Thus, when the TCP sender receives the first ACK for a Quick-Start 1183 packet, the sender reduces its congestion window to the amount that 1184 has actually been used. 1186 As an example, a TCP sender with an approved Quick-Start request of 1187 R KBps, B-byte packets including headers, and an RTT estimate of T 1188 seconds, would translate the Rate Request of R KBps to a congestion 1189 window of R*T/B packets. The TCP sender would send the Quick-Start 1190 packets rate-paced at R KBps. However, if the actual current round- 1191 trip time was T/2 seconds instead of T seconds, then the sender 1192 would begin to receive acknowledgements for Quick-Start packets 1193 after T/2 seconds. Following the paragraph above, the TCP sender 1194 would then reduce its congestion window from R*T/B to R*T/(B*2) 1195 packets, the actual number of packets that were needed to fill the 1196 pipe at a sending rate of R KBps. 1198 After Quick-Start mode is exited and the congestion window adjusted 1199 if necessary, the TCP sender returns to using the default congestion 1200 control mechanisms, processing further incoming ACK packets as 1201 specified by those congestion control mechanisms. For example, if 1202 the TCP sender was in slow-start prior to the Quick-Start request, 1203 and no packets were lost or marked since that time, then the sender 1204 continues in slow-start after exiting Quick-Start mode, as allowed 1205 by ssthresh. 1207 To add robustness, the TCP sender MUST use Limited Slow-Start 1208 [RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP 1209 sender limits the number of packets by which the congestion window 1210 is increased for one window of data during slow-start. 1212 4.5. TCP: Responding to a Loss of a Quick-Start Packet 1214 For TCP, we have defined a ``Quick-Start packet'' as one of the 1215 packets sent in the window immediately following a successful Quick- 1216 Start request. After detecting the loss of a Quick-Start packet, 1217 TCP MUST revert to the default congestion control procedures that 1218 would have been used if the Quick-Start request had not been 1219 approved. For example, if Quick-Start is used for setting the 1220 initial window, and a packet from the initial window is lost, then 1221 the TCP sender MUST then slow-start with the default initial window 1222 that would have been used if Quick-Start had not been used. In 1223 addition to reverting to the default congestion control mechanisms, 1224 the sender MUST take into account that the Quick-Start congestion 1225 window was too large. Thus, the sender SHOULD decrease ssthresh to 1226 at most half the number of Quick-Start packets that were 1227 successfully transmitted. Section A.5 discusses possible 1228 alternatives in responding to the loss of a Quick-Start packet. 1230 We note that ECN [RFC3168] MAY be used with Quick-Start. As is 1231 always the case with ECN, the sender's congestion control response 1232 to an ECN-marked Quick-Start packet is the same as the response to a 1233 dropped Quick-Start packet, thus reverting to slow start in the case 1234 of Quick-Start packets marked as experiencing congestion. 1236 4.6. TCP: A Quick-Start Request for a Larger Initial Window 1238 Some of the issues of using Quick-Start are related to the specific 1239 scenario in which Quick-Start is used. This section discusses the 1240 following issues that arise when Quick-Start is used by TCP to 1241 request a larger initial window: (1) interactions with Path MTU 1242 Discovery (PMTUD); and (2) Quick-Start request packets that are 1243 discarded by middleboxes. 1245 4.6.1. Interactions with Path MTU Discovery 1247 One issue when Quick-Start is used to request a large initial window 1248 concerns the interactions between the large initial window and Path 1249 MTU Discovery. Some of the issues are discussed in RFC 3390: 1251 "When larger initial windows are implemented along with Path MTU 1252 Discovery [RFC1191], alternatives are to set the "Don't 1253 Fragment" (DF) bit in all segments in the initial window, or to 1254 set the "Don't Fragment" (DF) bit in one of the segments. It is 1255 an open question as to which of these two alternatives is best." 1257 If the sender knows the Path MTU when the initial window is sent 1258 (e.g., from a PMTUD cache or from some other IETF-approved method), 1259 then the sender should use that MTU for segments in the initial 1260 window. Unfortunately, the sender doesn't necessarily know the Path 1261 MTU when it sends packets in the initial window. In this case, the 1262 sender should be conservative in the packet size used. Sending a 1263 large number of overly-large packets with the DF bit set is not 1264 desirable, but sending a large number of packets that are fragmented 1265 in the network can be equally undesirable. 1267 The sender SHOULD send one large packet in the initial window with 1268 the DF bit set, and send the remaining packets in the initial window 1269 with a smaller MTU of 576 bytes (or 1280 bytes with IPv6). 1271 A second possibility would be for the sender to delay sending the 1272 Quick-Start Request for one round-trip time, sending the Quick-Start 1273 Request with the first window of data while also doing Path MTU 1274 Discovery. 1276 4.6.2. Quick-Start Request Packets that are Discarded by Middleboxes 1278 It is always possible for a TCP SYN packet carrying a Quick-Start 1279 request to be dropped in the network due to congestion, or to be 1280 blocked due to interactions with middleboxes, where a middlebox is 1281 defined as any intermediary box performing functions apart from 1282 normal, standard functions of an IP router on the data path between 1283 a source host and destination host [RFC3234]. Measurement studies 1284 of interactions between transport protocols and middleboxes [MAF04] 1285 show that for 70% of the web servers investigated, no connection is 1286 established if the TCP SYN packet contains an unknown IP option (and 1287 for 43% of the web servers, no connection is established if the TCP 1288 SYN packet contains an IP TimeStamp Option). In both cases, this is 1289 presumably due to middleboxes along that path. 1291 If the TCP sender doesn't receive a response to the SYN or SYN/ACK 1292 packet containing the Quick-Start Request, then the TCP sender 1293 SHOULD resend the SYN or SYN/ACK packet without the Quick-Start 1294 Request. Similarly, if the TCP sender receives a TCP reset in 1295 response to the SYN or SYN/ACK packet containing the Quick-Start 1296 Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet 1297 without the Quick-Start Request [RFC3360]. 1299 RFC 1122 and 2988 recommend that the sender should set the initial 1300 RTO to three seconds, though many TCP implementations set the 1301 initial RTO to one second. For a TCP SYN packet sent with a Quick- 1302 Start request, the TCP sender SHOULD use an initial RTO of three 1303 seconds. 1305 In the case of a retransmission, in addition to resending the SYN or 1306 SYN/ACK packet without the Quick-Start Request, the TCP sender 1307 SHOULD use an RTO of three seconds and a different Initial Sequence 1308 Number. Using this scheme the TCP sender MUST keep track of when 1309 each of the SYN (or SYN/ACK) packets was transmitted. In this way, 1310 an acknowledgement for the retransmitted SYN or SYN/ACK packet can 1311 be matched with the SYN or SYN/ACK being acknowledged, and the 1312 transmission time of the SYN (or SYN/ACK) being acknowledged can be 1313 used for an RTT measurement to seed the RTO. If only the 1314 retransmitted SYN or SYN/ACK is acknowledged, the TCP sender can 1315 reasonably assume that the earlier SYN or SYN/ACK with the Quick- 1316 Start option was dropped by the network because of the option and 1317 not because of congestion. In this case, the TCP sender can refrain 1318 from performing TCP's standard congestion control state changes. 1320 We note that if the TCP SYN packet is using the IP Quick-Start 1321 Option for a Quick-Start request, and it is also using bits in the 1322 TCP header to negotiate ECN-capability with the TCP host at the 1323 other end, then the drop of a TCP SYN packet could be due to 1324 congestion, to a middlebox dropping the packet because of the IP 1325 Option, or because of a middlebox dropping the packet because of the 1326 information in the TCP header negotiating ECN. In this case, the 1327 sender could resend the dropped packet without either the Quick- 1328 Start or the ECN requests. Alternately, the sender could resend the 1329 dropped packet with only the ECN request in the TCP header, 1330 resending the TCP SYN packet without either the Quick-Start or the 1331 ECN requests if the second TCP SYN packet is dropped. The second 1332 choice seems reasonable, given that a TCP SYN packet today is more 1333 likely to be blocked due to IP Options than due to an ECN request in 1334 the TCP header [MAF04]. 1336 It is always possible that some middlebox that doesn't drop TCP SYN 1337 packets containing Quick-Start options will still drop or delay TCP 1338 data packets containing Quick-Start options as Approved Rate 1339 reports. This would be one reason for a TCP sender to report the 1340 Approved Rate in a separate control packet, rather than in a data 1341 packet. 1343 4.7. TCP: A Quick-Start Request in the Middle of a Connection 1345 This section discusses the following issues that arise when Quick- 1346 Start is used by TCP to request a larger window in the middle of 1347 connection, for example after an idle period: (1) determining the 1348 rate to request; and (2) the response if Quick-Start packets are 1349 dropped; 1351 (1) Determining the rate to request: 1352 In the middle of connection, an easy rule of thumb would be for the 1353 TCP sender to determine the largest congestion window that the TCP 1354 connection achieved since the last packet drop, to translate this 1355 congestion window to a sending rate, and use this rate in the Quick- 1356 Start request. If the request is granted, then the sender 1357 essentially restarts with its old congestion window from before it 1358 was reduced, for example during an idle period. 1360 In the case of an idle period, the sender SHOULD NOT use Quick-Start 1361 if the idle period has been less than an RTO, and the congestion 1362 window has not decayed down to less than half of its value at the 1363 start of the idle period. Such a use of Quick-Start requires 1364 further investigation. 1366 A Quick-Start Request sent in the middle of a TCP connection could 1367 be carried either in a data packet or in a pure acknowledgement 1368 packet. 1370 (2) Response if Quick-Start packets are dropped: 1372 If Quick-Start packets are dropped in the middle of connection, then 1373 the sender MUST revert to half of the Quick-Start window, or to the 1374 congestion window that the sender would have used if the Quick-Start 1375 request had not been approved, whichever is smaller. 1377 4.8. An Example Quick-Start Scenario with TCP 1379 The following is an example scenario in the case when both hosts 1380 request Quick-Start for setting their initial windows. This is 1381 similar to Figures 1 and 2 in Section 2.1, except that it 1382 illustrates a TCP connection with both TCP hosts sending Quick-Start 1383 Requests. 1385 * The TCP SYN packet from Host A contains a Quick-Start Request in 1386 the IP header. 1388 * Routers along the forward path modify the Quick-Start Request as 1389 appropriate. 1391 * Host B receives the Quick-Start Request in the SYN packet, and 1392 calculates the TTL Diff. If Host B approves the Quick-Start 1393 Request, then Host B sends a Quick-Start Response in the TCP header 1394 of the SYN/ACK packet. Host B also sends a Quick-Start Request in 1395 the IP header of the SYN/ACK packet. 1397 * Routers along the reverse path modify the Quick-Start Request as 1398 appropriate. 1400 * Host A receives the Quick-Start Response in the SYN/ACK packet, 1401 and checks the TTL Diff, Rate Request, and QS Nonce for validity. 1402 If they are valid, then Host A sets its initial congestion window 1403 appropriately, and sets up rate-based pacing to be used with the 1404 initial window. If the Quick-Start Response is not valid, then Host 1405 A uses TCP's default initial window. In either case, Host A sends a 1406 Report of Approved Rate. 1408 Host A also calculates the TTL Diff for the Quick-Start Request in 1409 the incoming SYN/ACK packet, and sends a Quick-Start Response in the 1410 TCP header of the ACK packet. 1412 * Host B receives the Quick-Start Response in an ACK packet, and 1413 checks the TTL Diff, Rate Request, and QS Nonce for validity. If 1414 the Quick-Start Response is valid, then Host B sets its initial 1415 congestion window appropriately, and sets up rate-based pacing to be 1416 used with its initial window. If the Quick-Start Response is not 1417 valid, then Host B uses TCP's default initial window. In either 1418 case, Host B sends a Report of Approved Rate. 1420 5. Quick-Start and IPsec AH 1422 This section shows that Quick-Start is compatible with IPsec AH 1423 (Authentication Header). AH uses an Integrity Check Value (ICV) in 1424 the IPsec Authentication Header to verify both message 1425 authentication and integrity [RFC2402,2402bis]. Changes to the 1426 Quick-Start option in the IP header do not affect this AH ICV. The 1427 tunnel considerations in Section 6 below apply to all IPsec tunnels, 1428 regardless of what IPsec headers or processing are used in 1429 conjunction with the tunnel. 1431 Because the contents of the Quick-Start option can change along the 1432 path, it is important that these changes not affect the IPsec 1433 Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC 1434 2402 requires that unrecognized IPv4 options be zeroed for AH ICV 1435 computation purposes, so Quick-Start IP Option data changing en 1436 route does not cause problems with existing IPsec AH implementations 1437 for IPv4. If the Quick-Start option is recognized, it MUST be 1438 treated as a mutable IPv4 option, and hence be completely zeroed for 1439 AH ICV calculation purposes. IPv6 option numbers explicitly 1440 indicate whether the option is mutable; the 3rd highest order bit in 1441 the IANA-allocated option type has the value 1 to indicate that the 1442 Quick-Start option data can change en route. RFC 2402 requires that 1443 the option data of any such option be zeroed for AH ICV computation 1444 purposes. Therefore changes to the Quick-Start option in the IP 1445 header do not affect the calculation of the AH ICV. 1447 6. Quick-Start in IP Tunnels 1449 This section considers interactions between Quick-Start and IP 1450 tunnels, including IPsec [RFC2401,2401bis] and IP in IP [RFC2003]. 1452 In the discussion, we use TTL Diff, defined earlier as the 1453 difference between the IP TTL and the Quick-Start TTL, mod 256. 1454 Recall that the sender considers the Quick-Start request approved 1455 only if the value of TTL Diff for the packet entering the network is 1456 the same as the value of TTL Diff for the packet exiting the 1457 network. 1459 Simple tunnels: IP tunnel modes are generally based on adding a new 1460 "outer" IP header that encapsulates the original or "inner" IP 1461 header and its associated packet. In many cases, the new "outer" IP 1462 header may be added and removed at intermediate points along a 1463 connection, enabling the network to establish a tunnel without 1464 requiring endpoint participation. We denote tunnels that specify 1465 that the outer header be discarded at tunnel egress as "simple 1466 tunnels", and we denote tunnels where the egress saves and uses 1467 information from the outer header before discarding it as "non- 1468 simple tunnels". An example of a "non-simple tunnel" would be a 1469 tunnel configured to support ECN, where the egress router might copy 1470 the ECN codepoint in the outer header to the inner header before 1471 discarding the outer header [RFC3168]. 1473 __ Tunnels Compatible with Quick-Start 1474 / 1475 Simple Tunnels __/ 1476 \ 1477 \__ Tunnels Not Compatible with Quick-Start 1478 (False Positives!) 1480 __ Tunnels Supporting Quick-Start 1481 / 1482 / 1483 Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start, 1484 \ but Not Supporting Quick-Start 1485 \ 1486 \__ Tunnels Not Compatible with Quick-Start? 1488 Figure 6: Categories of Tunnels. 1490 Tunnels that are compatible with Quick-Start: We say that an IP 1491 tunnel `is not compatible with Quick-Start' if the use of a Quick- 1492 Start Request over such a tunnel allows false positives, where the 1493 TCP sender incorrectly believes that the Quick-Start Request was 1494 approved by all routers along the path. If the use of Quick-Start 1495 over the tunnel does not cause false positives, we say that the IP 1496 tunnel `is compatible with Quick-Start'. 1498 If the IP TTL of the inner header is decremented during forwarding 1499 before tunnel encapsulation takes place, then the simple tunnel is 1500 compatible with Quick-Start, with Quick-Start requests being 1501 rejected. Section 6.1 describes in more detail the ways that a 1502 simple tunnel can be compatible with Quick-Start. 1504 There are some simple tunnels that are not compatible with Quick- 1505 Start, allowing `false positives' where the TCP sender incorrectly 1506 believes that the Quick-Start Request was approved by all routers 1507 along the path. This is discussed in Section 6.2 below. 1509 One of our tasks in the future will be to investigate the occurrence 1510 of tunnels that are not compatible with Quick-Start, and to track 1511 the extent to which such tunnels are modified over time. The 1512 evaluation of the problem of false positives from tunnels that are 1513 not compatible with Quick-Start will affect the progression of 1514 Quick-Start from Experimental to Proposed Standard, and will affect 1515 the degree of deployment of Quick-Start while in Experimental mode. 1517 Tunnels that support Quick-Start: We say that an IP tunnel `supports 1518 Quick-Start' if it allows routers along the tunnel path to process 1519 the Quick-Start Request and give feedback, resulting in the 1520 appropriate possible acceptance of the Quick-Start request. Some 1521 tunnels that are compatible with Quick-Start support Quick-Start, 1522 while others do not. We note that a simple tunnel is not able to 1523 support Quick-Start. 1525 From a security point of view, the use of Quick-Start in the outer 1526 header of an IP tunnel might raise security concerns because an 1527 adversary could tamper with the Quick-Start information that 1528 propagates beyond the tunnel endpoint, or because the Quick-Start 1529 Option exposes information to network scanners. Our approach is to 1530 make supporting Quick-Start an option for IP tunnels. That is, in 1531 environments or tunneling protocols where the risks of using Quick- 1532 Start are judged to outweigh its benefits, the tunnel can simply 1533 delete the Quick-Start option or zero the Quick-Start rate request 1534 and QS TTL fields before encapsulation. The result is that there 1535 are two viable options for IP tunnels to be compatible with Quick- 1536 Start. The first option is the simple tunnel described above and in 1537 Section 6.1, where the tunnel is compatible with Quick-Start but 1538 does not support Quick-Start, where all Quick-Start requests along 1539 the path will be rejected. The second approach is a Quick-Start- 1540 capable mode, described in Section 6.3, where the tunnel actively 1541 supports Quick-Start. 1543 6.1. Simple Tunnels That Are Compatible with Quick-Start 1545 This section describes the ways that a simple tunnel can be 1546 compatible with Quick-Start but not support Quick-Start, resulting 1547 in the rejection of all Quick-Start requests that traverse the 1548 tunnel. 1550 If the tunnel ingress for the simple tunnel is at a router, the IP 1551 TTL of the inner header is generally decremented during forwarding 1552 before tunnel encapsulation takes place. In this case TTL Diff will 1553 be changed, correctly causing the Quick-Start request to be 1554 rejected. For a simple tunnel it is preferable if the Quick-Start 1555 Request is not copied to the outer header, saving the routers within 1556 the tunnel from unnecessarily processing the Quick-Start request. 1557 However, the Quick-Start request will be rejected correctly in this 1558 case whether or not the Quick-Start Request is copied to the outer 1559 header. 1561 6.1.1. Simple Tunnels that are Aware of Quick-Start 1563 If a tunnel ingress is aware of Quick-Start, but does not want to 1564 support Quick-Start, then the tunnel ingress MUST either zero the 1565 Quick-Start rate request, QS TTL, and QS Nonce fields or remove the 1566 Quick-Start option from the inner header before encapsulation. 1567 Section 6.3 describes the procedures for a tunnel that does want to 1568 support Quick-Start. 1570 Deleting the Quick-Start option or zeroing the Quick-Start rate 1571 request *after decapsulation* also serves to prevent the propagation 1572 of Quick-Start information, and is compatible with Quick-Start. If 1573 the outer header does not contain a Quick-Start Request, a Quick- 1574 Start-aware tunnel egress MUST reject the inner Quick-Start Request 1575 by zeroing the Rate Request field in the inner header, or by 1576 deleting the Quick-Start option. 1578 If the tunnel ingress is at a sending host or router where the IP 1579 TTL is not decremented prior to encapsulation, and neither tunnel 1580 endpoint is aware of Quick-Start, then this allows false positives, 1581 described in the section below. 1583 6.2. Simple Tunnels That Are Not Compatible with Quick-Start 1585 Sometimes a tunnel implementation that does not support Quick-Start 1586 is independent of the TCP sender or a router implementation that 1587 supports Quick-Start. In these cases it is possible that a Quick- 1588 Start Request gets erroneously approved without the routers in the 1589 tunnel having individually approved the request, causing a false 1590 positive. 1592 If a tunnel ingress is a separate component from the TCP sender or 1593 IP forwarding, it is possible that a packet with a Quick-Start 1594 option is encapsulated without the IP TTL being decremented first, 1595 or with both IP TTL and QS TTL being decremented before the tunnel 1596 encapsulation takes place. If the tunnel ingress does not know about 1597 Quick-Start, a valid Quick-Start Request with unchanged TTL Diff 1598 traverses in the inner header, while the outer header most likely 1599 does not carry a Quick-Start Request. If the tunnel egress also 1600 does not support Quick-Start, it remains possible that the Quick- 1601 Start Request would be falsely approved, because the packet is 1602 decapsulated using the Quick-Start request from the inner header, 1603 and the value of TTL Diff echoed to the sender remains unchanged. 1605 For example, such a scenario can occur with a Bump-In-The-Stack 1606 (BITS), an IPSec encryption implementation where the data encryption 1607 occurs between the network drivers and the TCP/IP protocol stack 1608 [RFC2401]. 1610 As one example, if a remote access VPN client uses a BITS structure, 1611 then Quick-Start obstacles between the client and the VPN gateway 1612 won't be seen. This is a particular problem because the path 1613 between the client and the VPN gateway is likely to contain the most 1614 congested part of the path. Because most VPN clients are reported 1615 to use BITS [H05], we will explore this in more detail. 1617 A Bump-In-The-Wire (BITW) is an IPSec encryption implementation 1618 where the encryption occurs on an outboard processor, offloading the 1619 encryption processing overhead from the host or router [RFC2401]. 1620 The BITW device is usually IP addressable, which means that the IP 1621 TTL is decremented before the packet is passed to the BITW. If the 1622 QS TTL is not decremented, then the value of TTL Diff is changed, 1623 and the Quick-Start request will be denied. However, if the BITW 1624 supports a host and does not have its own IP address, then the IP 1625 TTL is not decremented before the packet is passed from the host to 1626 the BITW, and a false positive could occur. 1628 Other tunnels that need to be looked at are IP tunnels over non- 1629 network protocols, such as IP over TCP and IP over UDP [RFC3948], 1630 and tunnels using the Layer Two Tunneling Protocol [RFC2661]. 1632 Section 9.2 discusses the related issue of non-IP queues, such as 1633 layer-two Ethernet or ATM networks, as another instance of possible 1634 bottlenecks that do not participate in the Quick-Start feedback. 1636 6.3. Tunnels That Support Quick-Start 1638 This section discusses tunnels configured to support Quick-Start. 1640 If the tunnel ingress node chooses to locally approve the Quick- 1641 Start request, then the ingress node MUST decrement the Quick-Start 1642 TTL at the same time it decrements the IP TTL, and MUST copy IP TTL 1643 and the Quick-Start option from the inner IP header to the outer 1644 header. During encapsulation, the tunnel ingress MUST zero the 1645 Quick-Start rate request field in the inner header to ensure that 1646 the Quick-Start request will be rejected if the tunnel egress does 1647 not support Quick-Start. 1649 If the tunnel ingress node does not choose to locally approve the 1650 Quick-Start request, then it MUST either delete the Quick-Start 1651 option from the inner header before encapsulation, or zero the QS 1652 TTL and the Rate Request fields before encapsulation. 1654 Upon decapsulation, if the outer header contains a Quick-Start 1655 option, the tunnel egress MUST copy the IP TTL and the Quick-Start 1656 option from the outer IP header to the inner header. 1658 IPsec uses the IKE (Internet Key Exchange) Protocol for security 1659 associations. We do not consider the interactions between Quick- 1660 Start and IPsec with IKEv1 [RFC2409] in this document. Now that the 1661 RFC for IKEv2 [RFC4306] is published, we plan to specify a 1662 modification of IPsec to allow the support of Quick-Start to be 1663 negotiated; this modification will specify the negotiation between 1664 tunnel endpoints to allow or forbid support for Quick-Start within 1665 the tunnel. This was done for ECN for IPsec tunnels, with IKEv1 1666 [RFC3168, Section 9.2]. This negotiation of Quick-Start capability 1667 in an IPsec tunnel will be specified in a separate IPsec document. 1668 This document will also include a discussion of the potential 1669 effects of an adversary's modifications of the Quick-Start field (as 1670 in Sections 18 and 19 of RFC 3168), and of the security 1671 considerations of exposing the Quick-Start rate request to network 1672 scanners. 1674 7. The Quick-Start Mechanism in other Transport Protocols 1676 The section earlier specified the use of Quick-Start in TCP. In 1677 this section, we generalize this to give guidelines for the use of 1678 Quick-Start with other transport protocols. We also discuss briefly 1679 how Quick-Start could be specified for other transport protocols. 1681 The general guidelines for Quick-Start in transport protocols are as 1682 follows: 1684 * Quick-Start is only specified for unicast transport protocols with 1685 appropriate congestion control mechanisms. Note: Quick-Start is not 1686 a replacement for standard congestion control techniques, but meant 1687 to augment their operation. 1689 * A transport-level mechanism is needed for the Quick-Start response 1690 from the receiver to the sender. This response contains the Rate 1691 Request, TTL Diff, and QS Nonce. 1693 * The sender checks the validity of the Quick-Start response. 1695 * The sender has an estimate of the round-trip time, and translates 1696 the Quick-Start response into an allowed window or allowed sending 1697 rate. The sender sends a Report of Approved Rate. The sender 1698 starts sending Quick-Start packets, rate-paced out at the approved 1699 sending rate. 1701 * After the sender receives the first acknowledgement packet for a 1702 Quick-Start packet, no more Quick-Start packets are sent. The 1703 sender adjusts its current congestion window or sending rate to be 1704 consistent with the actual amount of data that was transmitted in 1705 that round-trip time. 1707 * When the last Quick-Start packet is acknowledged, the sender 1708 continues using the standard congestion control mechanisms of that 1709 protocol. 1711 * If one of the Quick-Start packets is lost, then the sender reverts 1712 to the standard congestion control method of that protocol that 1713 would have been used if the Quick-Start request had not been 1714 approved. In addition, the sender takes into account the 1715 information that the Quick-Start congestion window was too large 1716 (e.g., by decreasing ssthresh in TCP). 1718 8. Using Quick-Start 1720 8.1. Determining the Rate to Request 1722 As discussed in [SAF05], the data sender does not necessarily have 1723 information about the size of the data transfer at connection 1724 initiation; for example, in request-response protocols such as HTTP, 1725 the server doesn't know the size or name of the requested object 1726 during connection initiation. [SAF05] explores some of the 1727 performance implications of overly-large Quick-Start requests, and 1728 discusses heuristics that end-nodes could use to size their requests 1729 appropriately. For example, the sender might have information about 1730 the bandwidth of the last-mile hop, the size of the local socket 1731 buffer, or of the TCP receive window, and could use this information 1732 in determining the rate to request. Web servers that mostly have 1733 small objects to transfer might decide not to use Quick-Start at 1734 all, since Quick-Start would be of little benefit to them. 1736 Quick-Start will be more effective if Quick-Start requests are not 1737 larger than necessary; every Quick-Start request that is approved 1738 but not used (or not fully used) takes away from the bandwidth pool 1739 available for granting successive Quick-Start requests. Following 1740 Section 4.1, the sender SHOULD NOT request a sending rate larger 1741 than it is able to use over the round-trip time of the connection 1742 (or over 100 ms, if the round-trip time is not known), except as 1743 required to round up the desired sending rate to the next-highest 1744 allowable request. 1746 8.2. Deciding the Permitted Rate Request at a Router 1748 In this section we briefly outline how a router might decide whether 1749 or not to approve a Quick-Start Request. The router should ask the 1750 following questions: 1752 * Has the router's output link been underutilized for some time 1753 (e.g., several seconds). 1755 * Would the output link remain underutilized if the arrival rate was 1756 to increase by the aggregate rate requests that the router has 1757 approved over the last fraction of a second? 1759 In order to answer the last question, the router must have some 1760 knowledge of the available bandwidth on the output link and of the 1761 Quick-Start bandwidth that could arrive due to recently-approved 1762 Quick-Start Requests. In this way, if an underutilized router 1763 experiences a flood of Quick-Start requests, the router can begin to 1764 deny Quick-Start requests while the output link is still 1765 underutilized. 1767 A simple way for the router to keep track of the potential bandwidth 1768 from recently-approved requests is to maintain two counters, one for 1769 the total aggregate Rate Requests that have been approved in the 1770 current time interval [T1, T2], and one for the total aggregate Rate 1771 Requests approved over a previous time interval [T0, T1]. However, 1772 this document doesn't specify router algorithms for approving Quick- 1773 Start requests, or make requirements for the appropriate time 1774 intervals for remembering the aggregate approved Quick-Start 1775 bandwidth. A possible router algorithm is given in Appendix D, and 1776 more discussion of these issues is available in [SAF05].) 1778 * If the router's output link has been underutilized and the 1779 aggregate of the Quick Start Request Rate options granted is low 1780 enough to prevent a near-term bandwidth shortage, then the router 1781 could approve the Quick-Start Request. 1783 Section 10.2 discusses some of the implementation issues in 1784 processing Quick-Start requests at routers. [SAF05] discusses the 1785 range of possible Quick-Start algorithms at the router for deciding 1786 whether to approve a Quick-Start request. In order to explore the 1787 limits of the possible functionality at routers, [SAF05] also 1788 discusses Extreme Quick-Start mechanisms at routers, where the 1789 router would keep per-flow state concerning approved Quick-Start 1790 requests. 1792 9. Evaluation of Quick-Start 1794 9.1. Benefits of Quick-Start 1796 The main benefit of Quick-Start is the faster start-up for the 1797 transport connection itself. For a small TCP transfer of one to 1798 five packets, Quick-Start is probably of very little benefit; at 1799 best, it might shorten the connection lifetime from three to two 1800 round-trip times (including the round-trip time for connection 1801 establishment). Similarly, for a very large transfer, where the 1802 slow-start phase would have been only a small fraction of the 1803 connection lifetime, Quick-Start would be of limited benefit. 1804 Quick-Start would not significantly shorten the connection lifetime, 1805 but it might eliminate or at least shorten the start-up phase. 1806 However, for moderate-sized connections in a well-provisioned 1807 environment, Quick-Start could possibly allow the entire transfer of 1808 M packets to be completed in one round-trip time (after the initial 1809 round-trip time for the SYN exchange), instead of the log_2(M)-2 1810 round-trip times that it would normally take for the data transfer, 1811 in an uncongested environments (assuming an initial window of four 1812 packets). 1814 9.2. Costs of Quick-Start 1816 This section discusses the costs of Quick-Start for the connection 1817 and for the routers along the path. 1819 The cost of having a Quick-Start packet dropped: 1820 For the sender the biggest risk in using Quick-Start lies in the 1821 possibility of suffering from congestion-related losses of the 1822 Quick-Start packets. This should be an unlikely situation because 1823 routers are expected to approve Quick-Start Requests only when they 1824 are significantly underutilized. However, a transient increase in 1825 cross-traffic in one of the routers, a sudden decrease in available 1826 bandwidth on one of the links, or congestion at a non-IP queue could 1827 result in packet losses even when the Quick-Start Request was 1828 approved by all of the routers along the path. If a Quick-Start 1829 packet is dropped, then the sender reverts to the congestion control 1830 mechanisms it would have used if the Quick-Start request had not 1831 been approved, so the performance cost to the connection of having a 1832 Quick-Start packet dropped is small, compared to the performance 1833 without Quick-Start. (On the other hand, the performance difference 1834 between Quick-Start with a Quick-Start packet dropped and Quick- 1835 Start with no Quick-Start packet dropped can be considerable.) 1837 Added complexity at routers: 1839 The main cost of Quick-Start at routers concerns the costs of added 1840 complexity. The added complexity at the end-points is moderate, and 1841 might easily be outweighed by the benefit of Quick-Start to the end 1842 hosts. The added complexity at the routers is also somewhat 1843 moderate; it involves estimating the unused bandwidth on the output 1844 link over the last several seconds, processing the Quick-Start 1845 request, and keeping a counter of the aggregate Quick-Start rate 1846 approved over the last fraction of a second. However, this added 1847 complexity at routers adds to the development cycle, and could 1848 prevent the addition of other competing functionality to routers. 1849 Thus, careful thought would have to be given to the addition of 1850 Quick-Start to IP. 1852 The slow path in routers: 1853 Another drawback of Quick-Start is that packets containing the 1854 Quick-Start Request message might not take the fast path in routers, 1855 particularly in the beginning of Quick-Start's deployment in the 1856 Internet. This would mean some extra delay for the end hosts, and 1857 extra processing burden for the routers. However, as discussed in 1858 Sections 4.1 and 4.6, not all packets would carry the Quick-Start 1859 option. In addition, for the underutilized links where Quick-Start 1860 Requests could actually be approved, or in typical environments 1861 where most of the packets belong to large flows, the burden of the 1862 Quick-Start Option on routers would be considerably reduced. 1863 Nevertheless, it is still conceivable, in the worst case, that many 1864 packets would carry Quick-Start requests; this could slow down the 1865 processing of Quick-Start packets in routers considerably. As 1866 discussed in Section 9.6, routers can easily protect against this by 1867 enforcing a limit on the rate at which Quick-Start requests will be 1868 considered. [RW03] and [RW04] contain measurements of the impact of 1869 IP Option Processing on packet round-trip times. 1871 Multiple paths: 1872 One limitation of Quick-Start is that it presumes that the data 1873 packets of a connection will follow the same path as the Quick-Start 1874 request packet. If this is not the case, then the connection could 1875 be sending the Quick-Start packets, at the approved rate, along a 1876 path that was already congested, or that became congested as a 1877 result of this connection. Thus, Quick-Start could give poor 1878 performance when there is a routing change immediately after the 1879 Quick-Start request is approved, and the Quick-Start data packets 1880 follow a different path from that of the original Quick-Start 1881 Request. This is, however, similar to what would happen, for a 1882 connection with sufficient data, if the connection's path was 1883 changed in the middle of the connection, when the connection had 1884 already established the allowed initial rate. 1886 A router that uses multipath routing for packets within a single 1887 connection MUST NOT approve a Quick-Start request. Quick-Start 1888 would not perform robustly in an environment with multipath routing, 1889 where different packets in a connection routinely follow different 1890 paths. In such an environment, the Quick-Start request and some 1891 fraction of the packets in the connection might take an 1892 underutilized path, while the rest of the packets take an alternate, 1893 congested path. 1895 Non-IP queues: 1896 A problem of any mechanism for feedback from routers at the IP level 1897 is that there can be queues and bottlenecks in the end-to-end path 1898 that are not in IP-level routers. As an example, these include 1899 queues in layer-two Ethernet or ATM networks. One possibility would 1900 be that an IP-level router adjacent to such a non-IP queue or 1901 bottleneck would be configured to reject Quick-Start requests if 1902 that was appropriate. One would hope that in general, IP networks 1903 are configured so that non-IP queues between IP routers do not end 1904 up being the congested bottlenecks. 1906 9.3. Quick-Start with QoS-enabled Traffic 1908 The discussion in this document has largely been of Quick-Start with 1909 default, best-effort traffic. However, Quick-Start could also be 1910 used by traffic using some form of differentiated services, and 1911 routers could take the traffic class into account when deciding 1912 whether or not to grant the Quick-Start request. We don't address 1913 this context further in this paper, since it is orthogonal to the 1914 specification of Quick-Start. 1916 9.4. Protection against Misbehaving Nodes 1918 In this section we discuss the protection against senders, 1919 receivers, or colluding middleboxes lying about the Quick-Start 1920 Request. First, we note that it is not necessarily in the sender's 1921 or receiver's interest to lie about the Quick-Start Request. If the 1922 sender sends at too-high of an initial rate, and has a packet 1923 dropped, this does not necessarily improve the performance of the 1924 connection, relative to the case when the Quick-Start Request was 1925 not approved. 1927 9.4.1. Misbehaving Senders 1929 A transport sender could try to transmit data at a higher rate than 1930 that approved in the Quick-Start Request, or transmit at a high rate 1931 even without using Quick-Start at all. The network could use a 1932 traffic policer to protect against such misbehaving senders, for 1933 example by dropping packets that exceed the allowed transmission 1934 rate. The required Report of Approved Rate allows traffic policers 1935 to check that the Report of Approved Rate does not exceed the Rate 1936 Request actually approved at that point in the network in the 1937 previous Quick-Start Request from that connection. The required 1938 Approved Rate report also allows traffic policers to check that the 1939 sender's sending rate does not exceed the rate in the Report of 1940 Approved Rate. 1942 If a router or receiver receives an Approved Rate report that is 1943 larger than the Rate Request in the Quick-Start request approved for 1944 that sender for that connection in the previous round-trip time, 1945 then the router or receiver could deny future Quick-Start requests 1946 from that sender, e.g., by deleting the Quick-Start Request from 1947 future packets from that sender. We note that routers are not 1948 required to use Approved Rate reports to check if senders are 1949 cheating; this is at the discretion of the router. If a router sees 1950 a Report of Approved Rate, and did not see an earlier Quick-Start 1951 request, then either the sender could be cheating, or the 1952 connection's path could have changed since the Quick-Start request 1953 was sent. In either case, the router could decide to deny future 1954 Quick-Start requests from this sender. In particular, it is 1955 reasonable for the router to deny a Quick-Start request if either 1956 the sender is cheating, or if the connection path suffers from path 1957 changes or multi-pathing. 1959 If a router approved a Quick-Start Request, but does not see a 1960 subsequent Approved Rate report, then there are several 1961 possibilities: (1) the sender did not send a Report of Approved 1962 Rate; (2) the Approved Rate report was dropped in the network; or 1963 (3) the Approved Rate report took a different path from the Quick- 1964 Start Request. In any of these three cases, the router would be 1965 justified in denying future Quick-Start Requests from this sender. 1967 In any of the above mentioned cases (i.e., an Approved Rate report 1968 that is larger than the Rate Request in the earlier Quick-Start 1969 request; no Approved Rate report because of packet drops, path 1970 changes, or the sender's failure to send one), a traffic policer may 1971 assume that Quick-Start is not being used appropriately, or is being 1972 used in an inappropriate environment, and take some corresponding 1973 action. 1975 9.4.2. Receivers Lying about Whether the Request was Approved 1977 One form of misbehavior would be for the receiver to lie to the 1978 sender about whether the Quick-Start Request was approved, by 1979 falsely reporting the TTL Diff and QS Nonce. If a router that 1980 understands the Quick-Start Request denies the request by deleting 1981 the request or by zeroing the QS TTL and QS Nonce, then the receiver 1982 can ``lie" about whether the request was approved only by 1983 successfully guessing the value of the TTL Diff and QS Nonce to 1984 report. The chance of the receiver successfully guessing the 1985 correct value for the TTL Diff is 1/256, and the chance of the 1986 receiver successfully guessing the QS nonce for a reported rate 1987 request of K is 1/(2K). 1989 However, if the Quick-Start request is denied only by a non-Quick- 1990 Start-capable router, or by a router that is unable to zero the QS 1991 TTL and QS Nonce fields, then the receiver could lie about whether 1992 the Quick-Start Requests were approved by modifying the QS TTL in 1993 successive requests received from the same host. In particular, if 1994 the sender does not act on a Quick-Start Request, then the receiver 1995 could decrement the QS TTL by one in the next request received from 1996 that host before calculating the TTL Diff, and decrement the QS TTL 1997 by two in the following received request, until the sender acts on 1998 one of the Quick-Start Requests. 2000 Unfortunately, if a router doesn't understand Quick-Start, then it 2001 is not possible for that router to take an active step such as 2002 zeroing the QS TTL and QS Nonce to deny a request. As a result, the 2003 QS TTL is not a fail-safe mechanism for preventing lying by 2004 receivers in the case of non-Quick-Start-capable routers. 2006 As we noted above, it is not necessarily in the receiver's interests 2007 to lie about whether the rate request was approved, particularly 2008 since such lying could result in Quick-Start data packets dropped in 2009 the network due to congestion. 2011 9.4.3. Receivers Lying about the Approved Rate 2013 A second form of receiver misbehavior would be for the receiver to 2014 lie to the sender about the Rate Request for an approved Quick-Start 2015 Request, by increasing the value of the Rate Request field. 2016 However, the receiver doesn't necessarily know the Rate Request in 2017 the original Quick-Start Request sent by the sender, and a higher 2018 Rate Request reported by the receiver will only be considered valid 2019 by the sender if it is no higher than the Rate Request originally 2020 requested by the sender. For example, if the sender sends a Quick- 2021 Start Request with a Rate Request of X, and the receiver reports 2022 receiving a Quick-Start Request with a Rate Request of Y > X, then 2023 the sender knows that either some router along the path 2024 malfunctioned (increasing the Rate Request inappropriately), or the 2025 receiver is lying about the Rate Request in the received packet. 2027 If the sender sends a Quick-Start Request with a Rate Request of Z, 2028 the receiver receives the Quick-Start Request with an approved Rate 2029 Request of X, and reports a Rate Request of Y, for X < Y <= Z, then 2030 the receiver only succeeds in lying to the sender about the approved 2031 rate if the receiver successfully reports the rightmost 2Y bits in 2032 the QS nonce. 2034 If senders often use a configured default value for the Rate 2035 Request, then receivers would often be able to guess the original 2036 Rate Request, and this would make it easier for the receiver to lie 2037 about the value of the Rate Request field. Similarly, if the 2038 receiver often communicates with a particular sender, and the sender 2039 always uses the same Rate Request for that receiver, then the 2040 receiver might over time be able to infer the original Rate Request 2041 used by the sender. 2043 There are several possible additional forms of protection against 2044 receivers lying about the value of the Rate Request. One possible 2045 additional protection would be for a router that decreases a Rate 2046 Request in a Quick-Start Request to report the decrease directly to 2047 the sender. However, this could lead to many reports back to the 2048 sender for a single request, and could also be used in address- 2049 spoofing attacks. 2051 A second limited form of protection would be for senders to use some 2052 degree of randomization in the requested Rate Request, so that it is 2053 difficult for receivers to guess the original value for the Rate 2054 Request. However, this is difficult because there is a fairly 2055 coarse granularity in the set of rate requests available to the 2056 sender, and randomizing the initial request only offers limited 2057 protection in any case. 2059 Again, as we noted above, it is not necessarily in the receiver's 2060 interests to lie about the value of the approved rate request, 2061 particularly since such lying could result in Quick-Start data 2062 packets dropped in the network due to congestion. 2064 9.4.4. Collusion between Misbehaving Routers 2066 In addition to protecting against misbehaving receivers, it is 2067 necessary also to protect against misbehaving routers. Consider 2068 collusion between an ingress router and an egress router belonging 2069 to the same Intranet. The ingress router could decrement the Rate 2070 Request at the ingress, with the egress router increasing it again 2071 at the egress. The routers between the ingress and egress that 2072 approved the decremented rate request might not have been willing to 2073 approve the larger, original request. 2075 Another form of collusion would be for the ingress router to inform 2076 the egress router out-of-band of the TTL Diff and QS Nonce for the 2077 request packet at the ingress. This would enable the egress router 2078 to modify the QS TTL and QS Nonce so that it appeared that all of 2079 the routers along the path had approved the request. There does not 2080 appear to be any protection against a colluding ingress and egress 2081 router. Even if an intermediate router had deleted the Quick-Start 2082 Option from the packet, the ingress router could have sent the 2083 Quick-Start Option to the egress router out-of-band, with the egress 2084 router inserting the Quick-Start Option, with a modified QS TTL 2085 field, back in the packet. 2087 However, unlike ECN, there is somewhat less incentive for 2088 cooperating ingress and egress routers to collude to falsely modify 2089 the Quick-Start Request so that it appears to have been approved by 2090 all of the routers along the path. With ECN, a colluding ingress 2091 router could falsely mark a packet as ECN-capable, with the 2092 colluding egress router returning the ECN field in the IP header to 2093 its original non-ECN-capable codepoint, and congested routers along 2094 the path could have been fooled into not dropping that packet. This 2095 collusion would give an unfair competitive advantage to the traffic 2096 protected by the colluding ingress and egress routers. 2098 In contrast, with Quick-Start, the collusion of the ingress and 2099 egress routers to make it falsely appear that a Quick-Start request 2100 was approved does not necessarily give an advantage to the traffic 2101 covered by that collusion. If some router along the path really 2102 does not have enough available bandwidth to approve the Quick-Start 2103 request, then the Quick-Start packets sent as a result of the 2104 falsely-approved request could be dropped in the network, to the 2105 resulting disadvantage of the connection. Thus, while the ingress 2106 and egress routers could collude to prevent intermediate routers 2107 from denying a Quick-Start request, it would not necessarily be to 2108 the connection's advantage for this to happen. In addition, the 2109 router between the ingress and egress nodes that denied the request 2110 could be monitoring connection performance, actively penalizing 2111 nodes that seem to be using Quick-Start after a Quick-Start request 2112 was denied, or that are reporting an Approved Rate higher than that 2113 actually approved by that router. 2115 If the congested router was ECN-capable, and the colluding ingress 2116 and egress routers were lying about ECN-capability as well as about 2117 Quick-Start, then the result could be that the Quick-Start request 2118 falsely appears to the sender to have been approved, and the Quick- 2119 Start packets falsely appear to the congested router to be ECN- 2120 capable. In this case, the colluding routers might succeed in 2121 giving a competitive advantage to the traffic protected by their 2122 collusion (if no intermediate router is monitoring to catch such 2123 misbehavior). 2125 9.5. Misbehaving Middleboxes and the IP TTL 2127 One possible difficulty is that of traffic normalizers [HKP01] or 2128 other middleboxes along that path that re-write IP TTLs, in order to 2129 foil other kinds of attacks in the network. If such a traffic 2130 normalizer re-wrote the IP TTL, but did not adjust the Quick-Start 2131 TTL by the same amount, then the sender's mechanism for determining 2132 if the request was approved by all routers along the path would no 2133 longer be reliable. Re-writing the IP TTL could result in false 2134 positives (with the sender incorrectly believing that the Quick- 2135 Start request was approved) as well as false negatives (with the 2136 sender incorrectly believing that the Quick-Start request was 2137 denied). 2139 9.6. Attacks on Quick-Start 2141 As discussed in [SAF05], Quick-Start is vulnerable to two kinds of 2142 Quick-Start attacks: (1) attacks to increase the routers' 2143 processing and state load; and (2) attacks with bogus Quick-Start 2144 requests to temporarily tie up available Quick-Start bandwidth, 2145 preventing routers from approving Quick-Start requests from other 2146 connections. Routers can protect against the first kind of attack 2147 by applying a simple limit on the rate at which Quick-Start requests 2148 will be considered by the router. 2150 The second kind of attack, attacks to tie up the available Quick- 2151 Start bandwidth, is more difficult to defend against. As discussed 2152 in [SAF05]. Quick-Start Requests that are not going to be used, 2153 either because they are from malicious attackers or because they are 2154 denied by routers downstream, can result in `wasting' potential 2155 Quick-Start bandwidth, resulting in routers denying subsequent 2156 Quick-Start Requests that if approved would in fact have been used. 2157 We note that the likelihood of malicious attacks would be minimized 2158 significantly when Quick-Start was deployed in a controlled 2159 environment such as an Intranet, where there was some form of 2160 centralized control over the users in the system. We also note that 2161 this form of attack could potentially make Quick-Start unusable, but 2162 it would not do any further damage; in the worst case, the network 2163 would function as a network without Quick-Start. 2165 [SAF05] considers the potential of Extreme Quick-Start algorithms at 2166 routers, which keep per-flow state for Quick-Start connections, in 2167 protecting the availability of Quick-Start bandwidth in the face of 2168 frequent overly-larqe Quick-Start requests. 2170 9.7. Simulations with Quick-Start 2172 Quick-Start was added to the NS simulator [SH02] by Srikanth 2173 Sundarrajan, and additional functionality was added by Pasi 2174 Sarolahti. The validation test is at `test-all-quickstart' in the 2175 `tcl/test' directory in NS. The initial simulation studies from 2176 [SH02] show a significant performance improvement using Quick-Start 2177 for moderate-sized flows (between 4KB and 128KB) in under-utilized 2178 environments. These studies are of file transfers, with the 2179 improvement measured as the relative increase in the overall 2180 throughput for the file transfer. The study shows that potential 2181 improvement from Quick-Start is proportional to the delay-bandwidth 2182 product of the path. 2184 The Quick-Start simulations in [SAF05] explore the following: the 2185 potential benefit of Quick-Start for the connection; the relative 2186 benefits of different router-based algorithms for approving Quick- 2187 Start requests; and the effectiveness of Quick-Start as a function 2188 of the senders' algorithms for choosing the size of the rate 2189 request. 2191 10. Implementation and Deployment Issues 2193 This section discusses some of the implementation issues with Quick- 2194 Start. This section also discusses some of the key deployment 2195 issues, such as the chicken-and-egg deployment problems of 2196 mechanisms that have to be deployed in both routers and end nodes in 2197 order to work, and the problems posed by the wide deployment of 2198 middleboxes today that block the use of known or unknown IP Options. 2200 10.1. Implementation Issues for Sending Quick-Start Requests 2202 Section 4.6 discusses some of the issues with deciding the initial 2203 sending rate to request. Quick-Start raises additional issues about 2204 the communication between the transport protocol and the 2205 application, and about the use of the past history with Quick-Start 2206 in the end node. 2208 One possibility is that a protocol implementation could provide an 2209 API for applications to indicate when they want to request Quick- 2210 Start, and what rate they would like to request. In the 2211 conventional socket API this could be a socket option that is set 2212 before a connection is established. Some applications, such those 2213 that use TCP for bulk transfers, do not have interest in the 2214 transmission rate, but they might know the amount of data that can 2215 be sent immediately. Based on this, the sender implementation could 2216 decide whether Quick-Start would be useful, and what rate should be 2217 requested. Datagram-based real-time streaming applications, on the 2218 other hand, may have a specific preference on the transmission rate 2219 and they could indicate the required rate explicitly to the 2220 transport protocol to be used in the Quick-Start Request. 2222 We note that when Quick-Start is used, the TCP sender is required to 2223 save the QS Nonce and the TTL Diff when the Quick-Start request is 2224 sent, and to implement an additional timer for the paced 2225 transmission of Quick-Start packets. 2227 10.2. Implementation Issues for Processing Quick-Start Requests 2229 A router or other network host must be able to determine the 2230 approximate bandwidth of its outbound network interfaces in order to 2231 process incoming Quick-Start rate requests, including those that 2232 originate from the host itself. One possibility would be for hosts 2233 to rely on configuration information to determine link bandwidths; 2234 this has the drawback of not being robust to errors in 2235 configuration. Another possibility would be for network device 2236 drivers to infer the bandwidth for the interface and to communicate 2237 this to the IP layer. 2239 Particular issues will arise for wireless links with variable 2240 bandwidth, where decisions will have to be made about how frequently 2241 the network host gets updates of the changing bandwidth. It seems 2242 appropriate that Quick-Start Requests would be handled particularly 2243 conservatively for links with variable bandwidth, to avoid cases 2244 where Quick-Start Requests are approved, the link bandwidth is 2245 reduced, and the data packets that are sent end up being dropped. 2247 Difficult issues also arise for paths with multi-access links (e.g., 2248 Ethernet). Routers with multi-access links should be particularly 2249 conservative in granting Quick-Start requests. 2251 10.3. Possible Deployment Scenarios 2253 Because of possible problems discussed above concerning using Quick- 2254 Start over some network paths, the most realistic initial deployment 2255 of Quick-Start would most likely take place in Intranets and other 2256 controlled environments. Quick-Start is most useful on high 2257 bandwidth-delay paths that are significantly underutilized. The 2258 primary initial users of Quick-Start would likely be in 2259 organizations that provide network services to their users and also 2260 have control over a large portion of the network path. 2262 Below are a few examples of networking environments where Quick- 2263 Start would potentially be useful. These are the environments that 2264 might consider an initial deployment of Quick-Start in the routers 2265 and end-nodes, where the incentives for routers to deploy Quick- 2266 Start might be the most clear. 2268 * Centrally-administrated organizational Intranets: These intranets 2269 often have large network capacity, with networks that are 2270 underutilized for much of the time. Such Intranets might also 2271 include high-bandwidth and high-delay paths to remote sites. In 2272 such an environment, Quick-Start would be of benefit to users, and 2273 there would be a clear incentive for the deployment of Quick-Start 2274 in routers. For example, Quick-Start could be quite useful in high- 2275 bandwidth networks used for scientific computing. 2277 * GPRS: Quick-Start could also be useful in high-delay environments 2278 of Cellular Wide-Area Wireless Networks such as the GPRS [BW97] and 2279 their enhancements and next generations. For example, GPRS EDGE 2280 (Enhanced Data for GSM Evolution) is expected to provide wireless 2281 bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per 2282 second) while the GPRS round-trip times range typically from few 2283 hundred milliseconds to over a second excluding any possible 2284 queueing delays in the network [GPAR02]. In addition, these networks 2285 sometimes have variable additional delays due to resource allocation 2286 that could be avoided by keeping the connection path constantly 2287 utilized, starting from initial slow-start. Thus, Quick-Start could 2288 be of significant benefit to users in these environments. 2290 * Paths over satellite links: Geostationary Orbit (GEO) satellite 2291 links have one-way propagation delays on the order of 250 ms while 2292 the bandwidth can be measured in megabits per second [RFC2488]. 2293 Because of the considerable bandwidth-delay product on the link, 2294 TCP's slow-start is a major performance limitation in the beginning 2295 of the connection. A large initial congestion window would be 2296 useful to users of such satellite links. 2298 10.4. Would QuickStart packets take the slow path in routers? 2300 How much delay would the slow path add to the processing time for 2301 Quick-Start request packets? In addition, if QuickStart request 2302 packets took the slow path, this could add stress to routers, though 2303 routers could always rate-limit the number of QuickStart request 2304 packets they are willing to consider. 2306 10.5. A Comparison with the Deployment Problems of ECN 2308 Given the glacially slow rate of deployment of ECN in the Internet 2309 to date [MAF05], it is disconcerting to note that some of the 2310 deployment problems of Quick-Start are even greater than those of 2311 ECN. First, unlike ECN, which can be of benefit even if it is only 2312 deployed on one of the routers along the end-to-end path, a 2313 connection's use of Quick-Start requires its deployment on all of 2314 the routers along the end-to-end path. Second, unlike ECN, which 2315 uses an allocated field in the IP header, Quick-Start requires the 2316 extra complications of an IP Option. 2318 However, in spite of these issues, there is some hope for the 2319 deployment of Quick-Start, at least in protected corners of the 2320 Internet, because the potential benefits of Quick-Start to the user 2321 are considerably more dramatic than those of ECN. Rather than 2322 simply replacing the occasional dropped packet by an ECN-marked 2323 packet, Quick-Start is capable of dramatically increasing the 2324 throughput of connections in underutilized environments. 2326 11. Related Work 2328 The Quick-Start proposal, taken together with HighSpeed TCP 2329 [RFC3649] or other transport protocols for high-bandwidth transfers, 2330 could go a significant way towards extending the range of 2331 performance for best-effort traffic in the Internet. However, there 2332 are many things that the Quick-Start proposal would not accomplish. 2333 Quick-Start is not a congestion control mechanism, and would not 2334 help in making more precise use of the available bandwidth, that is, 2335 of achieving the goal of high throughput with low delay and low 2336 packet loss rates. Quick-Start would not give routers more control 2337 over the decrease rates of active connections. 2339 In addition, any evaluation of Quick-Start must include a discussion 2340 of the relative benefits of approaches that use no explicit 2341 information from routers, and of approaches that use more fine- 2342 grained feedback from routers as part of a larger congestion control 2343 mechanism. We discuss several classes of proposals (no explicit 2344 feedback from routers; explicit feedback about the initial rate; 2345 more fine-grained feedback from routers; and proposals based on 2346 lower-than-best-effort service) in the sections below. 2348 11.1. Fast Start-ups without Explicit Information from Routers 2350 One possibility would be for senders to use information from the 2351 packet streams to learn about the available bandwidth, without 2352 explicit information from routers. These techniques would not allow 2353 a start-up as fast as that available from Quick-Start in an 2354 underutilized environment; one has to have sent some packets 2355 already to use the packet stream to learn about available bandwidth. 2356 However, these techniques could allow a start-up considerably faster 2357 than the current slow-start. While it seems clear that approaches 2358 *without* explicit feedback from the routers will be strictly less 2359 powerful that is possible *with* explicit feedback, it is also 2360 possible that approaches that are more aggressive than slow-start 2361 are possible without explicit feedback from routers. 2363 Periodic packet streams: 2364 [JD02] explores the use of periodic packet streams to estimate the 2365 available bandwidth along a path. The idea is that the one-way 2366 delays of a periodic packet stream show an increasing trend when the 2367 stream's rate is higher than the available bandwidth. While [JD02] 2368 states that the proposed mechanism does not cause significant 2369 increases in network utilization, losses, or delays when done by one 2370 flow at a time, the approach could be problematic if conducted 2371 concurrently by a number of flows. [JD02] also gives an overview of 2372 some of the earlier work on inferring the available bandwidth from 2373 packet trains. 2375 Swift-Start: 2376 The Swift Start proposal from [PRAKS02] combines packet-pair and 2377 packet-pacing techniques. An initial congestion window of four 2378 segments is used to estimate the available bandwidth along the path. 2379 This estimate is then used to dramatically increase the congestion 2380 window during the second RTT of data transmission. 2382 SPAND: 2383 In the TCP/SPAND proposal from [ZQK00] for speeding up short data 2384 transfers, network performance information would be shared among 2385 many co-located hosts to estimate each connection's fair share of 2386 the network resources. Based on such estimation and the transfer 2387 size, the TCP sender would determine the optimal initial congestion 2388 window size. The design for TCP/SPAND uses a performance gateway 2389 that monitors all traffic entering and leaving an organization's 2390 network. 2392 While continued research on the limits of the ability of TCP and 2393 other transport protocols to learn of available bandwidth without 2394 explicit feedback from the router seems useful, we note that there 2395 are several fundamental advantages of explicit feedback from 2396 routers. 2398 (1) Explicit feedback is faster than implicit feedback: 2399 One advantage of explicit feedback from the routers is that it 2400 allows the transport sender to reliably learn of available bandwidth 2401 in one round-trip time. 2403 (2) Explicit feedback is more reliable than implicit feedback: 2404 A second advantage of explicit feedback from the routers is that the 2405 available bandwidth along the path does not necessarily map to the 2406 allowed sending rate for an individual flow. As an example, if the 2407 TCP sender sends four packets back-to-back in the initial window, 2408 and the TCP receiver reports that the data packets were received 2409 with roughly the same spacing as they were transmitted, does this 2410 mean that the flow can infer an underutilized path? And how fast 2411 can the flow send in the next round-trip time? Do the results 2412 depend on the level of statistical multiplexing at the congested 2413 link, and on the number of flows attempting a faster start-up at the 2414 same time? 2416 11.2. Optimistic Sending without Explicit Information from Routers 2418 Another possibility that has been suggested [S02] is for the sender 2419 to start with a large initial window without explicit permission 2420 from the routers and without bandwidth estimation techniques, and 2421 for the first packet of the initial window to contain information 2422 such as the size or sending rate of the initial window. The 2423 proposal would be that congested routers would use this information 2424 in the first data packet to drop or delay many or all of the packets 2425 from that initial window. In this way a flow's optimistically-large 2426 initial window would not force the router to drop packets from 2427 competing flows in the network. Such an approach would seem to 2428 require some mechanism for the sender to ensure that the routers 2429 along the path understood the mechanism for marking the first packet 2430 of a large initial window. 2432 Obviously there would be a number of questions to consider about an 2433 approach of optimistic sending. 2435 (1) Incremental deployment: 2436 One question would be the potential complications of incremental 2437 deployment, where some of the routers along the path might not 2438 understand the packet information describing the initial window. 2440 (2) Congestion collapse: 2441 There could also be concerns about congestion collapse if many flows 2442 used large initial windows, many packets were dropped from 2443 optimistic initial windows, and many congested links ended up 2444 carrying packets that are only going to be dropped downstream. 2446 (3) Distributed Denial of Service attacks: 2448 A third key question would be the potential role of optimistic 2449 senders in amplifying the damage done by a Distributed Denial of 2450 Service (DDoS) attack. 2452 (4) Performance hits if a packet is dropped: 2453 A fourth issue would be to quantify the performance hit to the 2454 connection when a packet is dropped from one of the initial windows. 2456 11.3. Fast Start-ups with other Information from Routers 2458 There have been several proposals somewhat similar to Quick-Start, 2459 where the transport protocol collects explicit information from the 2460 routers along the path. 2462 An IP Option about the free buffer size: 2463 In related work, [P00] investigates the use of a slightly different 2464 IP option for TCP connections to discover the available bandwidth 2465 along the path. In that proposal, the IP option would query the 2466 routers along the path about the smallest available free buffer 2467 size. Also, the IP option would have been sent after the initial SYN 2468 exchange, when the TCP sender already had an estimate of the round- 2469 trip time. 2471 The Performance Transparency Protocol: 2472 The Performance Transparency Protocol (PTP) includes a proposal for 2473 a single PTP packet that would collect information from routers 2474 along the path from the sender to the receiver [W00]. For example, 2475 a single PTP packet could be used to determine the bottleneck 2476 bandwidth along a path. 2478 ETEN: 2479 Additional proposals for end nodes to collect explicit information 2480 from routers include Explicit Transport Error Notification (ETEN), 2481 which includes a cumulative mechanism to notify endpoints of 2482 aggregate congestion statistics along the path [KAPS02]. 2484 11.4. Fast Start-ups with more Fine-Grained Feedback from Routers 2486 Proposals for more fine-grained congestion-related feedback from 2487 routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking 2488 [K03]. Section A.6 discusses in more detail the relationship 2489 between Quick-Start and proposals for more fine-grained per-packet 2490 feedback from routers. 2492 XCP: 2493 Proposals such as XCP for new congestion control mechanisms based on 2494 more feedback from routers are more powerful than Quick-Start, but 2495 also are more complex to understand and more difficult to deploy. 2496 XCP routers maintain no per-flow state, but provide more fine- 2497 grained feedback to end-nodes than the one-bit congestion feedback 2498 of ECN. The per-packet feedback from XCP can be positive or 2499 negative, and specifies the increase or decrease in the sender's 2500 congestion window when this packet is acknowledged. 2502 AntiECN: 2503 The AntiECN proposal is for a single bit in the packet header that 2504 routers could set to indicate that they are underutilized. For each 2505 TCP ACK arriving at the sender indicating that a packet has been 2506 received with the Anti-ECN bit set, the sender would be able to 2507 increase its congestion window by one packet, as it would during 2508 slow-start. 2510 11.5. Fast Start-ups with Lower-Than-Best-Effort Service 2512 There have been proposals for routers to provide a Lower Effort 2513 differentiated service that would be lower than best effort 2514 [RFC3662]. Such a service could carry traffic for which delivery is 2515 strictly optional, or could carry traffic that is important but that 2516 has low priority in terms of time. Because it does not interfere 2517 with best-effort traffic, Lower Effort services would be used by 2518 transport protocols that start-up faster than slow-start. For 2519 example, [SGF05] is a proposal for the transport sender to use low- 2520 priority traffic for much of the initial traffic, with routers 2521 configured to use strict priority queueing. 2523 A separate but related issue is that of below-best-effort TCP, 2524 variants of TCP that would not rely on Lower Effort services in the 2525 network, but would approximate below-best-effort traffic by 2526 detecting and responding to congestion sooner that standard TCP. 2527 TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such 2528 proposals for below-best-effort TCP, with the purpose of allowing 2529 TCP connections to use the bandwidth unused by TCP and other traffic 2530 in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use 2531 the default slow-start mechanisms of TCP. 2533 We note that Quick-Start is quite different from either a Lower 2534 Effort service or a below-best-effort variant of TCP. Unlike these 2535 proposals, Quick-Start is intended to be useful for best-effort 2536 traffic that wishes to receive at least as much bandwidth as 2537 competing best-effort connections. 2539 12. Security Considerations 2541 Sections 9.4 and 9.6 discuss the security considerations related to 2542 Quick-Start. Section 9.4 discusses the potential abuse of Quick- 2543 Start by senders or receivers lying about whether the request was 2544 approved or about the approved rate, and of routers in collusion to 2545 misuse Quick-Start. Section 9.5 discusses potential problems with 2546 traffic normalizers that rewrite IP TTLs in packet headers. All of 2547 these problems could result in the sender using a Rate Request that 2548 was inappropriately large, or thinking that a request was approved 2549 when it was in fact denied by at least one router along the path. 2550 This inappropriate use of Quick-Start would result in congestion and 2551 an unacceptable level of packet drops along the path, Such 2552 congestion could also be part of a Denial of Service attack. 2554 Section 9.6 discusses a potential attack on the routers' processing 2555 and state load from an attack of Quick-Start Requests. Section 9.6 2556 also discusses a potential attack on the available Quick-Start 2557 bandwidth by sending bogus Quick-Start requests for bandwidth that 2558 will not in fact be used. 2560 Section 4.6.2 discusses the potential problem of packets with Quick- 2561 Start Requests dropped by middleboxes along the path. 2563 As discussed in Section 5, for IPv4 IPsec Authentication Header 2564 Integrity Check Value (AH ICV) calculation, the Quick-Start option 2565 MUST be treated as a mutable IPv4 option, and hence completely 2566 zeroed for AH ICV calculation purposes; this is also the treatment 2567 required by RFC 2402 for unrecognized IPv4 options. The IPv6 Quick- 2568 Start option's IANA-allocated option type indicates that it is a 2569 mutable option, hence, according to RFC 2402, its option data MUST 2570 be zeroed for AH ICV computation purposes. See RFC 2402 for further 2571 explanation. 2573 Section 6.2 discusses possible problems of Quick-Start used by 2574 connections carried over simple tunnels that are not compatible with 2575 Quick-Start. In this case it is possible that a Quick-Start 2576 Request is erroneously considered approved by the sender without the 2577 routers in the tunnel having individually approved the request, 2578 causing a false positive. 2580 13. Conclusions 2582 We are presenting the Quick-Start mechanism as a simple, 2583 understandable, and incrementally-deployable mechanism that would be 2584 sufficient to allow some connections to start up with large initial 2585 rates, or large initial congestion windows, in overprovisioned, 2586 high-bandwidth environments. We expect there will be an increasing 2587 number of overprovisioned, high-bandwidth environments where the 2588 Quick-Start mechanism, or another mechanism of similar power, could 2589 be of significant benefit to a wide range of traffic. We are 2590 presenting the Quick-Start mechanism as a request for the community 2591 to provide feedback and experimentation on issues relating to Quick- 2592 Start. 2594 14. Acknowledgements 2596 The authors wish to thank Mark Handley for discussions of these 2597 issues. The authors also thank the End-to-End Research Group, the 2598 Transport Services Working Group, and members of IPAM's program on 2599 Large Scale Communication Networks for both positive and negative 2600 feedback on this proposal. We thank Srikanth Sundarrajan for the 2601 initial implementation of Quick-Start in the NS simulator, and for 2602 the initial simulation study. Many thanks to David Black and Joe 2603 Touch for extensive feedback on QuickStart and IP tunnels. We also 2604 thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom 2605 Dunigan, Gorry Fairhurst, John Heidemann, Paul Hyder, Dina Katabi 2606 and Vern Paxson for feedback. This draft builds upon the concepts 2607 described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of 2608 the text on Quick-Start in tunnels was borrowed directly from RFC 2609 3168. 2611 This document is the development of a proposal originally by Amit 2612 Jain for Initial Window Discovery. 2614 A. Design Decisions 2616 A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP 2618 This document has proposed using an IP Option for the Quick-Start 2619 Request from the sender to the receiver, and using transport 2620 mechanisms for the Quick-Start Response from the receiver back to 2621 the sender. In this section we discuss alternate mechanisms, and 2622 consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols 2623 could be used for delivering the Quick-Start Request. 2625 A.1.1. ICMP 2627 Being a control protocol used between Internet nodes, one could 2628 argue that ICMP is the ideal method for requesting a permission for 2629 faster startup from routers. The ICMP header is above the IP 2630 header. Quick-Start could be accomplished with ICMP as follows: If 2631 the ICMP protocol is used to implement Quick-Start, the equivalent 2632 of the Quick-Start IP option would be carried in the ICMP header of 2633 the ICMP Quick-Start Request. The ICMP Quick-Start Request would 2634 have to pass by the routers on the path to the receiver, possibly 2635 using the IP Router Alert option [RFC2113]. A router that approves 2636 the Quick-Start Request would take the same actions as in the case 2637 with the Quick-Start IP Option, and forward the packet to the next 2638 router along the path. A router that does not approve the Quick- 2639 Start Request, even with a decreased value for the Requested Rate, 2640 would delete the ICMP Quick-Start Request, and send an ICMP Reply to 2641 the sender that the request was not approved. If the ICMP Reply was 2642 dropped in the network, and did not reach the receiver, the sender 2643 would still know that the request was not approved from the absence 2644 of feedback from the receiver. If the ICMP Quick-Start request was 2645 dropped in the network due to congestion, the sender would assume 2646 that the request was not approved. The ICMP message would need the 2647 source and destination port numbers for demultiplexing at the end 2648 nodes. If the ICMP Quick-Start Request reached the receiver, the 2649 receiver would use transport-level or application-level mechanisms 2650 to send a response to the sender, exactly as with the IP Option. 2652 One benefit of using ICMP would be that the delivery of the TCP SYN 2653 packet or other initial packet would not be delayed by IP option 2654 processing at routers. A greater advantage is that if middleboxes 2655 were blocking packets with Quick-Start Requests, using the Quick- 2656 Start Request in a separate ICMP packet would mean that the 2657 middlebox behavior would not affect the connection as a whole. (To 2658 get this robustness to middleboxes with TCP using an IP Quick-Start 2659 Option, one would have to have a TCP-level Quick-Start Request 2660 packet that could be sent concurrently but separately from the TCP 2661 SYN packet.) 2663 However, there are a number of disadvantages to using ICMP. Some 2664 firewalls and middleboxes may not forward the ICMP Quick-Start 2665 Request packets. (If an ICMP Reply packet from a router to the 2666 sender is dropped in the network, the sender would still know that 2667 the request was not approved, as stated earlier, so this would not 2668 be as serious of a problem.) In addition, it would be difficult, if 2669 not impossible, for a router in the middle of an IP tunnel to 2670 deliver an ICMP Reply packet to the actual source, for example when 2671 the inner IP header is encrypted as in IPsec tunnel mode [RFC2401]. 2672 Again, however, the ICMP Reply packet would not be essential to the 2673 correct operation of ICMP Quick-Start. 2675 Unauthenticated out-of-band ICMP messages could enable some types of 2676 attacks by third-party malicious hosts that are not possible when 2677 the control information is carried in-band with the IP packets that 2678 can only be altered by the routers on the connection path. Finally, 2679 as a minor concern, using ICMP would cause a small amount of 2680 additional traffic in the network, which is not the case when using 2681 IP options. 2683 A.1.2. RSVP 2685 With some modifications RSVP [RFC2205] could be used as a bearer 2686 protocol for carrying the Quick-Start Requests. Because routers are 2687 expected to process RSVP packets more extensively than the normal 2688 transport protocol IP packets, delivering a Quick-Start rate request 2689 using an RSVP packet would seem an appealing choice. However, Quick- 2690 Start with RSVP would require a few differences from the 2691 conventional usage of RSVP. Quick-Start would not require periodical 2692 refreshing of soft state, because Quick-Start does not require per- 2693 connection state in routers. Quick-Start Requests would be 2694 transmitted downstream from the sender to receiver in the RSVP Path 2695 messages, which is different from the conventional RSVP model where 2696 the reservations originate from the receiver. Furthermore, the 2697 Quick-Start Response would be sent using the transport-level or 2698 application-level mechanisms instead of using the RSVP Resv message. 2700 If RSVP was used for carrying a Quick-Start Request, a new "Quick- 2701 Start Request" class object would be included in the RSVP Path 2702 message that is sent from the sender to receiver. The object would 2703 contain the rate request field in addition to the common length and 2704 type fields. The Send_TTL field in the RSVP common header could be 2705 used as the equivalent of the QS TTL field. The Quick-Start capable 2706 routers along the path would inspect the Quick-Start Request object 2707 in the RSVP Path message, decrement Send_TTL and adjust the rate 2708 request field if needed. If an RSVP router did not understand the 2709 Quick-Start Request object, it would reject the entire RSVP message 2710 and send an RSVP PathErr message back to the sender. When an RSVP 2711 message with the Quick-Start Request object reaches the receiver, 2712 the receiver sends a Quick-Start Reply message in the corresponding 2713 transport protocol header in the same way as described in the 2714 context of IP options earlier. If the RSVP message with the Quick- 2715 Start Request object was dropped along the path, the transport 2716 sender would simply proceed with the normal congestion control 2717 procedures. 2719 Much of the discussion about benefits and drawbacks of using ICMP 2720 for making the Quick-Start Request also applies to the RSVP case. If 2721 the Quick-Start Request was transmitted in a separate packet instead 2722 of as an IP option, the transport protocol packet delivery would not 2723 be delayed due to IP option processing at the routers, and the 2724 initial transport packets would reach their destination more 2725 reliably. The possible disadvantages of using ICMP and RSVP are also 2726 expected to be similar: middleboxes in the network may not be able 2727 to forward the Quick-Start Request messages, and the IP tunnels 2728 might cause problems for processing the Quick-Start Requests. 2730 A.2. Alternate Encoding Functions 2732 In this section we look at alternate encoding functions for the Rate 2733 Request field in the Quick-Start Request. The main requirements for 2734 this function is that it should have a sufficiently wide range for 2735 the requested rate. There is no need for overly-fine-grained 2736 precision in the requested rate. Similarly, while it would be 2737 attractive for the encoding function to be easily computable, it is 2738 also possible for end-nodes and routers to simply store the table 2739 giving the mapping between the value N in the Rate Request field, 2740 and the actual rate request f(N). In this section we consider 2741 possible encoding methods for Rate Request fields of different 2742 sizes, including four-bit, eight-bit, and larger Rate Request 2743 fields. 2745 Linear functions: 2746 One possible proposal would be for the Rate Request field to be 2747 formatted in bits per second, scaled so that one unit equals M Kbps, 2748 for some fixed value of M. Thus, for the value N in the Rate 2749 Request field, the requested rate would be M*N Kbps. 2751 Powers of two: 2752 If a granularity of factors of two is sufficient for the Rate 2753 Request, then the encoding function with the most range would be for 2754 the requested rate to be K*2^N, for N the value in the Rate Request 2755 field, and for K some constant. For N=0, the rate request would be 2756 set to zero, regardless of the encoding function. For example, for 2757 K=40,000 and an eight-bit Rate Request field, the request range 2758 would be from 80 Kbps to 40*2^255 Kbps. This clearly would be an 2759 unnecessarily large request range. 2761 For a four-bit Rate Request field, the upper limit on the rate 2762 request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps 2763 would be fine for the Quick-Start rate request, and that connections 2764 wishing to start up with a higher initial sending rate should be 2765 encouraged to use other mechanisms, such as the explicit reservation 2766 of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, 2767 then five or six bits could be used for the Rate Request field. 2769 If the granularity of factors of two was too coarse, then the 2770 encoding function could use a base less than two. An alternate form 2771 for the encoding function would be to use a hybrid of linear and 2772 exponential functions. 2774 A mantissa and exponent representation: 2775 Section 4.4 of [B05] suggests a mantissa and exponent representation 2776 for the Quick-Start encoding function. With e and f as the binary 2777 numbers in the exponent and mantissa fields, and with 0 <= f < 1, 2778 this would represent the rate (1+f)*2^e. [B05] suggests a mantissa 2779 field for f of 8, 16, or 24 bits, with an exponent field for e of 8 2780 bits. This representation would allow larger rate requests, with an 2781 encoding that is less coarse than the powers-of-two encoding used in 2782 this document. 2784 Constraints of the transport protocol: 2785 We note that the Rate Request is also constrained by the abilities 2786 of the transport protocol. For example, for TCP with Window 2787 Scaling, the maximum window is at most 2**30 bytes. For a TCP 2788 connection with a long, 1 second round-trip time, this would give a 2789 maximum sending rate of 1.07 Gbps. 2791 A.3. The Quick-Start Request: Packets or Bytes? 2793 One of the design questions is whether the Rate Request field should 2794 be in bytes per second or in packets per second. We discuss this 2795 separately from the perspective of the transport, and from the 2796 perspective of the router. 2798 For TCP, the results from the Quick-Start Request are translated 2799 into a congestion window in bytes, using the measured round-trip 2800 time and the MSS. This window applies only to the bytes of data 2801 payload, and does not include the bytes in the TCP or IP packet 2802 headers. Other transport protocols would conceivably use the Quick- 2803 Start Request directly in packets per second, or could translate the 2804 Quick-Start Request to a congestion window in packets. 2806 The assumption of this draft is that the router only approves the 2807 Quick-Start Request when the output link is significantly 2808 underutilized. For this, the router could measure the available 2809 bandwidth in bytes per second, or could convert between packets and 2810 bytes by some mechanism. 2812 If the Quick-Start Request was in bytes per second, and applied only 2813 to the data payload, then the router would have to convert from 2814 bytes per second of data payload, to bytes per second of packets on 2815 the wire. If the Rate Request field was in bytes per second and the 2816 sender ended up using very small packets, this could translate to a 2817 significantly larger number in terms of bytes per second on the 2818 wire. Therefore, for a Quick-Start Request in bytes per second, it 2819 makes most sense for this to include the transport and IP headers as 2820 well as the data payload. Of course, this will be at best a rough 2821 approximation on the part of the sender; the transport-level sender 2822 might not know the size of the transport and IP headers in bytes, 2823 and might know nothing at all about the separate headers added in IP 2824 tunnels downstream. This rough estimate seems sufficient, however, 2825 given the overall lack of fine precision in Quick-Start 2826 functionality. 2828 It has been suggested that the router could possibly use information 2829 from the MSS option in the TCP packet header of the SYN packet to 2830 convert the Quick-Start Request from packets per second to bytes per 2831 second, or vice versa. The MSS option is defined as the maximum MSS 2832 that the TCP sender expects to receive, not the maximum MSS that the 2833 TCP sender plans to send [RFC793]. However, it is probably often 2834 the case that this MSS also applies as an upper bound on the MSS 2835 used by the TCP sender in sending. 2837 We note that the sender does not necessarily know the Path MTU when 2838 the Quick-Start Request is sent, or when the initial window of data 2839 is sent. Thus, with IPv4, packets from the initial window could end 2840 up being fragmented in the network if the "Don't Fragment" (DF) bit 2841 is not set [RFC1191]. A Rate Request in bytes per second is 2842 reasonably robust to fragmentation. Clearly a Rate Request in 2843 packets per second is less robust in the presence of fragmentation. 2844 Interactions between larger initial windows and Path MTU Discovery 2845 are discussed in more detail in RFC 3390 [RFC3390]. 2847 For a Quick-Start Request in bytes per second, the transport senders 2848 would have the additional complication of estimating the bandwidth 2849 usage added by the packet headers. 2851 We have chosen a Rate Request field in bytes per second rather than 2852 in packets per second because it seems somewhat more robust, 2853 particularly to routers. 2855 A.4. Quick-Start Semantics: Total Rate or Additional Rate? 2857 For a Quick-Start Request sent in the middle of a connection, there 2858 are two possible semantics for the Rate Request field, as follows: 2860 (1) Total Rate: The requested Rate Request is the requested total 2861 rate for the connection, including the current rate; or 2863 (2) Additional Rate: The requested Rate Request is the requested 2864 increase in the total rate for that connection, over and above the 2865 current sending rate. 2867 When the Quick-Start Request is sent after an idle period, the 2868 current sending rate is zero, and there is no difference between (1) 2869 and (2) above. However, a Quick-Start Request can also be sent in 2870 the middle of a connection that has not been idle, e.g., after a 2871 mobility event, or after an application-limited period when the 2872 sender is suddenly ready to send at a much higher rate. In this 2873 case, there can be a significant difference between (1) and (2) 2874 above. In this section we consider briefly the tradeoffs between 2875 these two options, and explain why we have chosen the `Total Rate' 2876 semantics. 2878 The Total Rate semantics makes it easier for routers to ``allocate'' 2879 the same rate to all connections. This lends itself to fairness, 2880 and improves convergence times between old and new connections. 2881 With the Additional Rate semantics, the router would not necessarily 2882 know the current sending rates of the flows requesting additional 2883 rates, and therefore would not have sufficient information to use 2884 fairness as a metric in granting rate requests. With the Total Rate 2885 semantics, the fairness is automatic; the router is not granting 2886 rate requests for *additional* bandwidth without knowing the current 2887 sending rates of the different flows. 2889 The Additional Rate semantics also lends itself to gaming by the 2890 connection, with senders sending frequent Quick-Start Requests in 2891 the hope of gaining a higher rate. If the router is granting the 2892 same maximum rate for all rate requests, then there is little 2893 benefit to a connection of sending a rate request over and over 2894 again. However, if the router is granting an *additional* rate with 2895 each rate request, over and above the current sending rate, then it 2896 is in a connection's interest to send as many rate requests as 2897 possible, even if very few of them are in fact granted. 2899 Appendix D discusses a Report of Current Sending Rate as one 2900 possible function in the Quick-Start Option. However, we have not 2901 standardized this possible use at this time. 2903 A.5. Alternate Responses to the Loss of a Quick-Start Packet 2905 Section 4.5 discusses TCP's response to the loss of a Quick-Start 2906 packet in the initial window. This section discusses several 2907 alternate responses. 2909 One possible alternative to reverting to the default slow-start 2910 after the loss of a Quick-Start packet from the initial window would 2911 have been to halve the congestion window and continue in congestion 2912 avoidance. However, we note that this would not have been a 2913 desirable response for either the connection or for the network as a 2914 whole. The packet loss in the initial window indicates that Quick- 2915 Start failed in finding an appropriate congestion window, meaning 2916 that the congestion window after halving may easily also be wrong. 2918 A more moderate alternate would be to continue in congestion 2919 avoidance from a window of (W-D)/2, where W is the Quick-Start 2920 congestion window, and D is the number of packets dropped or marked 2921 from that window. However, such an approach would implicitly assume 2922 that the number of Quick-Start packets delivered is a good 2923 indication of the appropriate available bandwidth for that flow, 2924 even though other packets from that window were dropped in the 2925 network. We believe that such an assumption would require more 2926 analysis at this point, particularly in a network with a range of 2927 packet dropping mechanisms at the router, and we cannot recommend it 2928 at this time. 2930 Another drawback of approaches that don't revert back to slow-start 2931 when a Quick-Start packet in the initial window is dropped is that 2932 any such approaches could give the TCP receiver an incentive to lie 2933 about the Quick-Start request. That is, if the sender reverts to 2934 slow-start when a Quick-Start packet is dropped, then it is 2935 generally not to the receiver's advantage to report a larger rate 2936 request than was actually approved if the result is going to be a 2937 Quick-Start packet dropped in the network. However, if the receiver 2938 benefits from a larger Quick-Start window even when the larger 2939 window results in Quick-Start packets dropped in the network, then 2940 the receiver has a greater incentive to lie about the received rate 2941 request, in an effort to get the sender to use a larger initial 2942 sending rate. 2944 A.6. Why Not Include More Functionality? 2946 This proposal for Quick-Start is a rather coarse-grained mechanism 2947 that would allow connections to use higher sending rates along 2948 underutilized paths, but that does not attempt to provide a next- 2949 generation transport protocol, and does not attempt the goal of 2950 providing very high throughput with very low delay. As Section 11.4 2951 discusses, there are a number of proposals such as XCP, MaxNet, and 2952 AntiECN for more fine-grained per-packet feedback from routers than 2953 the current congestion control mechanisms, that do attempt these 2954 more ambitious goals. 2956 Compared to proposals such as XCP and AntiECN, Quick-Start offers 2957 much less control. Quick-Start does not attempt to provide a new 2958 congestion control mechanism, but simply to get permission from 2959 routers for a higher sending rate at start-up, or after an idle 2960 period. Quick-Start can be thought of as an "anti-congestion- 2961 control" mechanism, that is only of any use when all of the routers 2962 along the path are significantly under-utilized. Thus, Quick-Start 2963 is of no use towards a target of high link utilization, or fairness 2964 in a high-utilization scenario, or controlling queueing delay during 2965 high-utilization, or anything of the like. 2967 At the same time, Quick-Start would allow larger initial windows 2968 than would proposals such as AntiECN, requires less input to routers 2969 than XCP (e.g., XCP's cwnd and rtt fields), and would require less 2970 frequent feedback from routers than any new congestion control 2971 mechanism. Thus, Quick-Start is significantly less powerful than 2972 proposals for new congestion control mechanisms such as XCP and 2973 AntiECN, but as powerful or more powerful in terms of the specific 2974 issue of allowing larger initial windows, and (we think) more 2975 amenable to incremental deployment in the current Internet. 2977 We do not discuss proposals such as XCP in detail, but simply note 2978 that there are a number of open questions. One question concerns 2979 whether there is a pressing need for more sophisticated congestion 2980 control mechanisms such as XCP in the Internet. Quick-Start is 2981 inherently a rather crude tool that does not deliver assurances 2982 about maintaining high link utilization and low queueing delay; 2983 Quick-Start is designed for use in environments that are 2984 significantly underutilized, and addresses the single question of 2985 whether a higher sending rate is allowed. New congestion control 2986 mechanisms with more fine-grained feedback from routers could allow 2987 faster startups even in environments with rather high link 2988 utilization. Is this a pressing requirement? Are the other 2989 benefits of more fine-grained congestion control feedback from 2990 routers a pressing requirement? 2992 We would argue that even if more fine-grained per-packet feedback 2993 from routers was implemented, it is reasonable to have a separate 2994 mechanism such as Quick-Start for indicating an allowed initial 2995 sending rate, or an allowed total sending rate after an idle or 2996 underutilized period. 2998 One difference between Quick-Start and current proposals for fine- 2999 grained per-packet feedback such as XCP is that XCP is designed to 3000 give robust performance even in the case where different packets 3001 within a connection routinely follow different paths. XCP achieves 3002 relatively robust performance in the presence of multi-path routing 3003 by using per-packet feedback, where the feedback carried in a single 3004 packet is about the relative increase or decrease in the rate or 3005 window to take effect when that particular packet is acknowledged, 3006 not about the allowed sending rate for the connection as a whole. 3008 In contrast, Quick-Start sends a single Quick-Start request, and the 3009 answer to that request gives the allowed sending rate for an entire 3010 window of data. As a result, Quick-Start could be problematic in an 3011 environment where some fraction of the packets in a window of data 3012 take path A, and the rest of the packets take path B; for example, 3013 the Quick-Start Request could have travelled on path A, while half 3014 of the Quick-Start packets sent in the succeeding round-trip time 3015 are routed on path B. 3017 There are also differences between Quick-Start and some of the 3018 proposals for per-packet feedback in terms of the number of bits of 3019 feedback required from the routers to the end-nodes. Quick-Start 3020 uses four bits of feedback in the rate request field to indicate the 3021 allowed sending rate. XCP allocates a byte for per-packet feedback, 3022 though there has been discussion of variants of XCP with less per- 3023 packet feedback. This would be more like other proposals such as 3024 anti-ECN that use a single bit of feedback from routers to indicate 3025 that the sender can increase as fast as slow-starting, in response 3026 to this particular packet acknowledgement. In general, there is 3027 probably considerable power in fine-grained proposals with only two 3028 bits of feedback, indicating that the sender should decrease, 3029 maintain, or increase the sending rate or window when this packet is 3030 acknowledged. However, the power of Quick-Start would be 3031 considerably limited if it was restricted to only two bits of 3032 feedback; it seems likely that determining the initial sending rate 3033 fundamentally requires more bits of feedback from routers than does 3034 the steady-state, per-packet feedback to increase or decrease the 3035 sending rate. 3037 On a more practical level, one difference between Quick-Start and 3038 proposals for per-packet feedback is that there are fewer open 3039 issues with Quick-Start than there would be with a new congestion 3040 control mechanism. Because Quick-Start is a mechanism for 3041 requesting an initial sending rate in an underutilized environment, 3042 its fairness issues are less severe than those of a general 3043 congestion control mechanism. With Quick-Start, there is no need 3044 for the end nodes to tell the routers the round-trip time and 3045 congestion window, as is done in XCP; all that is needed is for the 3046 end nodes to report the requested sending rate. 3048 Table 3 provides a summary of the differences between Quick-Start 3049 and proposals for per-packet congestion control feedback. 3051 Proposals for 3052 Quick-Start Per-Packet Feedback 3053 +------------------+----------------------+----------------------+ 3054 Semantics: | Allowed sending rate | Change in rate/window, 3055 | per connection. | per-packet. 3056 +------------------+----------------------+----------------------+ 3057 Relationship to | In addition. | Replacement. 3058 congestion ctrl: | | 3059 +------------------+----------------------+----------------------+ 3060 Frequency: | Start-up, or after | Every packet. 3061 | an idle period. | 3062 +------------------+----------------------+----------------------+ 3063 Limitations: | Only useful on | General congestion 3064 | underutilized paths.| control mechanism. 3065 +------------------+----------------------+----------------------+ 3066 Input to routers: | Rate request. |RTT, cwnd, request (XCP) 3067 | | None (Anti-ECN). 3068 +------------------+----------------------+----------------------+ 3069 Bits of feedback: | Four bits for | A few bits would 3070 | rate request. | suffice? 3071 +------------------+----------------------+----------------------+ 3073 Table 3: Differences between Quick-Start and Proposals for 3074 Fine-Grained Per-Packet Feedback. 3076 A separate question concerns whether mechanisms such as Quick-Start, 3077 in combination with HighSpeed TCP and other changes in progress, 3078 would make a significant contribution towards meeting some of these 3079 needs for new congestion control mechanisms. This could be viewed 3080 as a positive step towards meeting some of the more pressing current 3081 needs with a simple and reasonably deployable mechanism, or 3082 alternately, as a negative step of unnecessarily delaying more 3083 fundamental changes. Without answering this question, we would note 3084 that our own approach tends to favor the incremental deployment of 3085 relatively simple mechanisms, as long as the simple mechanisms are 3086 not short-term hacks but mechanisms that lead the overall 3087 architecture in the fundamentally correct direction. 3089 A.7. Alternate Implementations for a QuickStart Nonce 3091 A.7.1. An Alternate Proposal for the QuickStart Nonce 3093 An alternate proposal for the Quick-Start Nonce from [B05] would be 3094 for an n-bit field for the QS Nonce, with the sender generating a 3095 random nonce when it generates a Quick-Start Request. Each router 3096 that reduces the Rate Request by r would hash the QS nonce r times, 3097 using a one-way hash function such as MD5 [RFC1321] or the secure 3098 hash 1 [SHA1]. The receiver returns the QS nonce to the sender. 3099 Because the sender knows the original value for the nonce, and the 3100 original rate request, the sender knows the total number of steps s 3101 that the rate has been reduced. The sender then hashes the original 3102 nonce s times, to check whether the result is the same as the nonce 3103 returned by the receiver. 3105 This alternate proposal for the nonce would be considerably more 3106 powerful than the QS nonce described in Section 3.4, but it would 3107 also require more CPU cycles from the routers when they reduce a 3108 Quick-Start request, and from the sender in verifying the nonce 3109 returned by the receiver. As reported in [B05], routers could 3110 protect themselves from processor exhaustion attacks by limiting the 3111 rate at which they will approve reductions of Quick-Start requests. 3113 Both the Function field and the Reserved field in the Quick-Start 3114 Option would allow the extension of Quick-Start to use Quick-Start 3115 requests with the alternate proposal for the Quick-Start Nonce, if 3116 it was ever desired. 3118 A.7.2. The Earlier Request-Approved QuickStart Nonce 3120 An earlier version of this document included a Request-Approved 3121 QuickStart Nonce (QS Nonce) that was initialized by the sender to a 3122 non-zero, `random' eight-bit number, along with a QS TTL that was 3123 initialized to the same value as the TTL in the IP header. The 3124 Request-Approved QuickStart Nonce would have been returned by the 3125 transport receiver to the transport sender in the Quick-Start 3126 Response. A router could deny the Quick-Start request by failing to 3127 decrement the QS TTL field, by zeroing the QS Nonce field, or by 3128 deleting the Quick-Start Request from the packet header. The QS 3129 Nonce was included to provide some protection against broken 3130 downstream routers, or against misbehaving TCP receivers that might 3131 be inclined to lie about whether the Rate Request was approved. 3132 This protection is now provided by the QS Nonce, by the use of a 3133 random initial value for the QS TTL field, and by Quick-Start- 3134 capable routers hopefully either deleting the Quick-Start Option or 3135 zeroing the QS TTL and QS Nonce fields when they deny a request. 3137 With the old Request-Approved QuickStart Nonce, along with the QS 3138 TTL field set to the same value as the TTL field in the IP header, 3139 the Quick-Start Request mechanism would have been self-terminating; 3140 the Quick-Start Request would terminate at the first participating 3141 router after a non-participating router had been encountered on the 3142 path. This minimizes unnecessary overhead incurred by routers 3143 because of option processing for the Quick-Start Request. In the 3144 current specification, this "self-terminating" property is provided 3145 by Quick-Start-capable routers hopefully either deleting the Quick- 3146 Start Option or zeroing the Rate Request field when they deny a 3147 request. Because the current specification uses a random initial 3148 value for the QS TTL, Quick-Start-capable routers can't tell if the 3149 Quick-Start Request is invalid because of non-Quick-Start-capable 3150 routers upstream. This is the cost of using a design that makes it 3151 difficult for the receiver to cheat about the value of the QS TTL. 3153 B. Quick-Start with DCCP 3155 DCCP is a new transport protocol for congestion-controlled, 3156 unreliable datagrams, intended for applications such as streaming 3157 media, Internet telephony, and on-line games. In DCCP, the 3158 application has a choice of congestion control mechanisms, with the 3159 currently-specified Congestion Control Identifiers (CCIDs) being 3160 CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an 3161 equation-based form of congestion control. We refer the reader to 3162 [KHF05] for a more detailed description of DCCP, and of the 3163 congestion control mechanisms. 3165 Because CCID 3 uses a rate-based congestion control mechanism, it 3166 raises some new issues about the use of Quick-Start with transport 3167 protocols. In this document we don't attempt to specify the use of 3168 Quick-Start with DCCP. However, we do discuss some of the issues 3169 that might arise. 3171 In considering the use of Quick-Start with CCID 3 for requesting a 3172 higher initial sending rate, the following questions arise: (1) how 3173 does the sender respond if a Quick-Start packet is dropped; and (2) 3174 when does the sender determine that there has been no feedback from 3175 the receiver, and reduce the sending rate? 3177 (1) How does the sender respond if a Quick-Start packet is dropped: 3178 As in TCP, if an initial Quick-Start packet is dropped, the CCID 3 3179 sender should revert to the congestion control mechanisms it would 3180 have used if the Quick-Start request had not been approved. 3182 (2) When does the sender decide there has been no feedback from the 3183 receiver: 3184 Unlike TCP, CCID 3 does not use acknowledgements for every packet, 3185 or for every other packet. In contrast, the CCID 3 receiver sends 3186 feedback to the sender roughly once per round-trip time. In CCID 3, 3187 the allowed sending rate is halved if no feedback is received from 3188 the receiver in at least four round-trip times (when the sender is 3189 sending at least one packet every two round-trip times). When a 3190 Quick-Start request is used, it would seem necessary to use a 3191 smaller time interval, e.g., to reduce the sending rate if no 3192 feedback is received from the receiver in at least two round-trip 3193 times. 3195 The question also arises of how the sending rate should be reduced 3196 after a period of no feedback from the receiver. As with TCP, the 3197 default CCID 3 response of halving the sending rate is not 3198 necessarily a sufficient response to the absence of feedback; an 3199 alternative is to reduce the sending rate to the sending rate that 3200 would have been used if no Quick-Start request had been approved. 3201 That is, if a CCID 3 sender uses a Quick-Start request, special 3202 rules might be required to handle the sender's response to a period 3203 of no feedback from the receiver regarding the Quick-Start packets. 3205 Similarly, in considering the use of Quick-Start with CCID 3 for 3206 requesting a higher sending rate after an idle period, the following 3207 questions arise: (1) what rate does the sender request; (2) what is 3208 the response to a packet loss; and (3) when does the sender 3209 determine that there has been no feedback from the receiver, and the 3210 sending rate must be reduced? 3212 (1) What rate does the sender request: 3213 As in TCP, there is a straightforward answer to the rate request 3214 that the CCID 3 sender should use in requesting a higher sending 3215 rate after an idle period. The sender knows the current loss event 3216 rate, either from its own calculations or from feedback from the 3217 receiver, and can determine the sending rate allowed by that loss 3218 event rate. This is the upper bound on the sending rate that should 3219 be requested by the CCID 3 sender. A Quick-Start request is useful 3220 with CCID 3 when the sender is coming out of an idle or 3221 underutilized period, because in standard operation CCID 3 does not 3222 allow the sender to send more than twice as fast as the receiver has 3223 reported received in the most recent feedback message. 3225 (2) What is the response to loss: 3226 The response to the loss of Quick-Start packets should be to return 3227 to the sending rate that would have been used if Quick-Start had not 3228 been requested. 3230 (3) When does the sender decide there has been no feedback from the 3231 receiver: 3232 As in the case of the initial sending rate, it would seem prudent to 3233 reduce the sending rate if no feedback is received from the receiver 3234 in at least two round-trip times. It seems likely that in this 3235 case, the sending rate should be reduced to the sending rate that 3236 would have been used if no Quick-Start request had been approved. 3238 C. Possible Router Algorithm 3240 This specification does not tightly define the algorithm a router 3241 uses when deciding whether to approve a Quick-Start Rate Request or 3242 whether and how to reduce a Rate Request. A range of algorithms is 3243 likely useful in this space and we consider the algorithm a 3244 particular router uses to be a local policy decision. In addition, 3245 we believe that additional experimentation with router algorithms is 3246 necessary to have a solid understanding of the dynamics various 3247 algorithms impose. However, we provide one particular algorithm in 3248 this appendix as an example and as a framework for thinking about 3249 additional mechanisms. 3251 [SAF05] provides several algorithms routers can use to consider 3252 incoming Rate Requests. The decision process involves two 3253 algorithms. First, the router needs to track the link utilization 3254 over the recent past. Second, this utilization needs to be updated 3255 by the potential new bandwidth from recent Quick-Start approvals, 3256 and then compared with the router's notion of when it is 3257 underutilized enough to approve Quick-Start requests (of some size). 3259 First, we define the "peak utilization" estimation technique (from 3260 [SAF05]). This mechanism records the utilization of the link every 3261 S seconds and stores the most recent N of these measurements. The 3262 utilization is then taken as the highest utilization of the N 3263 samples. This method, therefore, keeps N*S seconds of history. 3264 This algorithm reacts rapidly to increases in the link utilization. 3265 In [SAF05] S is set to 0.15 seconds, and experiments use values for 3266 N ranging from 3 to 20. 3268 Second, we define the "target" algorithm for processing incoming 3269 Quick-Start Rate Requests (also from [SAF05]). The algorithm relies 3270 on knowing the bandwidth of the outgoing link (which in many cases 3271 can be easily configured), the utilization of the outgoing link 3272 (from an estimation technique such as given above) and an estimate 3273 of the potential bandwidth from recent Quick-Start approvals. 3275 Tracking the potential bandwidth from recent Quick-Start approvals 3276 is another case where local policy dictates how it should be done. 3277 The simpliest method, outlined in Section 8.2, is for the router to 3278 keep track of the aggregate Quick-Start rate requests approved in 3279 the most recent two or more time intervals, including the current 3280 time interval, and to use the sum of the aggregate rate requests 3281 over these time intervals as the estimate of the approved Rate 3282 Requests. The experiments in [SAF05] keep track of the aggregate 3283 approved Rate Requests over the most recent two time intervals, for 3284 intervals of 150~msec. 3286 The target algorithm also depends on a threshold (qs_thresh) that is 3287 the fraction of the outgoing link bandwidth that represents the 3288 router's notion of "significantly underutilized". If the 3289 utilization, augmented by the potential bandwidth from recent Quick- 3290 Start approvals, is above this threshold then no Quick-Start Rate 3291 Requests will be approved. If the utilization, again augmented by 3292 the potential bandwidth from recent Quick-Start approvals, is less 3293 than the threshold then Rate Requests can be approved. The Rate 3294 Requests will be reduced such that the bandwidth allocated would not 3295 drive the utilization to more than the given threshold. The 3296 algorithm is: 3298 util_bw = bandwidth * utilization; 3299 util_bw = util_bw + recent_qs_approvals; 3300 if (util_bw < (qs_thresh * bandwidth)) 3301 { 3302 approved = (qs_thresh * bandwidth) - util_bw; 3303 if (rate_request < approved) 3304 approved = rate_request; 3305 approved = round_down (approved); 3306 recent_qs_approvals += approved; 3307 } 3309 Also note that given that Rate Requests are fairly coarse, the 3310 approved rate should be rounded down when it does not fall exactly 3311 on one of the rates allowed by the encoding scheme. 3313 Routers that wish to keep close track of the allocated Quick-Start 3314 bandwidth could use Approved Rate reports to learn when rate 3315 requests had been decremented downstream in the network, and also to 3316 learn when a sender begins to use the approved Quick-Start request. 3318 D. Possible Additional Uses for the Quick-Start Option 3320 The Quick-Start Option contains a four-bit Function field in the 3321 third byte, enabling additional uses to be defined for the Quick- 3322 Start Option. In this section we discuss some of the possible 3323 additional uses that have been discussed for Quick-Start. The 3324 Function field makes it easy to add new functions for the Quick- 3325 Start Option. 3327 Report of Current Sending Rate: A Quick-Start Request with the 3328 `Report of Current Sending Rate' codepoint set in the Function field 3329 would be using the Rate Request field to report the current 3330 estimated sending rate for that connection. This could accompany a 3331 second Quick-Start Request in the same packet containing a standard 3332 rate request, for a connection that is using Quick-Start to increase 3333 its current sending rate. 3335 Request to Increase Sending Rate: A codepoint for `Request to 3336 Increase Sending Rate' in the Function field would indicate that the 3337 connection is not idle or just starting up, but is attemmpting to 3338 use Quick-Start to increase its current sending rate. This 3339 codepoint would not change the semantics of the Rate Request field. 3341 RTT Estimate: If a codepoint for `RTT Estimate' was used, a field 3342 for the RTT Estimate would contain one or more bits giving the 3343 sender's rough estimate of the round-trip time, if known. E.g., the 3344 sender could estimate whether the RTT was greater or less than 200 3345 ms. Alternately, if the sender had an estimate of the RTT when it 3346 sends the Rate Request, the two-bit Reserved field at the end of the 3347 Quick-Start Option could be used for a coarse-grained encoding of 3348 the RTT. 3350 Informational Request: An Informational Request codepoint in the 3351 Function field would indicate that a request is purely 3352 informational, for the sender to find out if a rate request would be 3353 approved, and what size rate request would be approved, when the 3354 Informational Request is sent. For example, an Informational 3355 Request could be followed one round-trip time later by a standard 3356 Quick-Start Request. A router approving an Informational Request 3357 would not consider this as an approval for Quick-Start bandwidth to 3358 be used, and would not be under any obligation to approve a similar 3359 standard Quick-Start Request one round-trip time later. 3361 Use Format X for the Rate Request Field: A Quick-Start codepoint for 3362 `Use Format X for the Rate Request Field' would indicate that an 3363 alternate format was being used for the Rate Request field. 3365 Do Not Decrement: A Do Not Decrement codepoint could be used for a 3366 Quick-Start request where the sender would rather have the request 3367 denied than to have the rate request decremented in the network. 3368 This could be used if the sender was only interested in using Quick- 3369 Start if the original rate request was approved. 3371 E. Feedback from Bob Briscoe 3373 [B05] in a review of an earlier version of the Quick-Start proposal 3374 discussed a number of potential problems with Quick-Start, and 3375 argued for an alternate approach for policing congestion in networks 3376 using re-feedback [BJCG+05,BJS05]. However, [B05] didn't oppose the 3377 move to Quick-Start to experimental status as long as its 3378 applicability is made clear. 3380 E.1. Potential Deployment Scenarios 3382 [B05] argues that because the sender's trustworthiness is not 3383 necessarily verified, Quick-Start, if it is remain stateless, should 3384 be confined to environments where every source is trusted. Section 3385 3.2 of [B05] argues that either (1) Quick-Start should be 3386 recommended for deployment only in trusted environments, or (2) 3387 Quick-Start could be recommended for deployment also in untrusted 3388 environments, with flow state required at some or all routers. 3390 Since [B05], we have added the Report of Approved Rate as a required 3391 part of Quick-Start, and discussed ways that this could be used by 3392 routers or by traffic policers, if desired, to check on the use of 3393 Quick-Start by senders. We also note that senders can send at an 3394 initial high rate even in the absence of Quick-Start, in the current 3395 network; that is, in our view, Quick-Start does not change the 3396 dangers to the network from malicious senders. Thus, while we are 3397 clearly not recommending Quick-Start for widespread deployment in 3398 the global Internet, we also don't feel the need to explicitly 3399 restrict its deployment to environments where every source is 3400 trusted, or to explicitly require per-flow state at Quick-Start 3401 routers. We assume that Quick-Start will only be enabled at routers 3402 if the system administrators feel either that they have sufficient 3403 trust in senders, sufficient policing mechanisms for checking for 3404 misbehaving nodes, or sufficient oversite to disable Quick-Start if 3405 it is determined to be causisng problems.. 3407 E.2. Misbehaving Senders and Receivers 3409 Some of the criticisms of Quick-Start in [B05] are criticisms for 3410 mechanisms that allocate rates to senders, but this is not what 3411 Quick-Start does. Quick-Start requests apply to individual 3412 connections, not to unique addresses or unique tuples of addresses. 3413 Further, the approval by routers of Quick-Start requests does not 3414 result in an allocation of bandwidth for the sender making that 3415 request; the approval by routers does not result in any allocation 3416 of bandwidth at all. The state used by routers from past Quick- 3417 Start approvals is used only to guide the router in its approval or 3418 rejection of future Quick-Start requests. We have added text to 3419 this document to make this quite explicit. 3421 [B05] discusses the dangers of sender spoofing and identity 3422 splitting. Identify splitting would not be a problem with Quick- 3423 Start, because Quick-Start requests apply to individual connections, 3424 not to unique addresses or unique tuples of addresses. Because 3425 Quick-Start does not allocate rates to senders, sender-spoofing is 3426 also not a critical issue (except as it would make it more difficult 3427 for those Quick-Start routers that maintain per-flow state to 3428 identify senders that send Quick-Start requests that are not in fact 3429 used, due either to malicious requests or due to requests denied 3430 downstream). 3432 In Section 3.3, [B05] says that "the lack of a secure binding 3433 between a request and subsequent traffic means that any other node 3434 could send a burst of traffic and claim it requests it, with no-one 3435 being able to prove it didn't." In the current Internet, any node 3436 can send a burst of traffic any time it would like, even without 3437 Quick-Start. However, in the absense of Quick-Start, sending at a 3438 high rate is not always in the sender's interest, as the packets 3439 that are send might have a high probability of being dropped in the 3440 network, particularly in the absense of Quick-Start. The addition 3441 of the Report of Approved Rate to Quick-Start gives traffic policers 3442 the ability to check on some of the potential abuses of Quick-Start, 3443 if they so desire. 3445 In Section 3.8, [B05] states that "not only do Quick-Start senders 3446 have to be trusted, but also other senders who could claim their 3447 data had been authorised by a Quick-Start response when it hadn't 3448 (Section 3.3)." In response, we would again clarify that with Quick- 3449 Start, the Quick-Start request makes no difference in how the 3450 subsequent Quick-Start data packets are treated at the router, 3451 compared to non-Quick-Start data packets. Thus, a sender's claim 3452 that its data results from a previous Quick-Start request should 3453 make no difference in how those data packets are treated at routers. 3454 The approval of a Quick-Start request is not a promise by the router 3455 that the subsequent data packets will receive differential treatment 3456 at the router; it is only a statement from the router that the 3457 router believes that the Quick-Start data packets will not change 3458 the current under-utilized state of the router. We have clarified 3459 this in Section 3.3 of this document. 3461 E.3. Fairness 3463 In its abstract, [B05] says the following: "Because traffic variance 3464 will always blur the boundary, we argue that under-utilisation 3465 should be treated as the extreme of a spectrum where fairness is 3466 always an issue to some extent." 3468 The specification for Quick-Start now says the following: "A router 3469 should only approve a Quick-Start request if the output link is 3470 underutilized, and if the router judges that the output link will 3471 continue to be underutilized if the request is approved." 3473 We changed the quote "for a mechanism for requesting an initial 3474 sending rate in an underutilized environment, the fairness issues of 3475 a general congestion control mechanism go away" to the following: 3476 "because Quick-Start is a mechanism for requesting an initial 3477 sending rate in an underutilized environment, its fairness issues 3478 are less severe than those of a general congestion control 3479 mechanism." 3481 However, we did not add the sentence recommended in Ssection 3.4 of 3482 [B05], that "Quick-Start is targeted at an experimental environment 3483 where the more intractable issues can be set aside". In particular, 3484 we don't agree that Quick-Start needs to be targeted only for 3485 environments where fairness is not an issue. 3487 E.4. Models of Under-Utilization 3489 [B05] states that "One of the under-utilisation assumptions I had in 3490 my head while reading the paper was that any one host is generally 3491 able to over-fill available capacity, but that, given a high rate, 3492 the flow would end quickly." We are sorry that this is the model 3493 that the author inferred from the draft, but we can give assurances 3494 that this `one big flow at a time" model was *never* the implicit or 3495 explicit model underlying the Quick-Start design. (We would also 3496 note that every version of this document since the first version 3497 back in 2002 has discussed router responses when the router 3498 experiences a flood of Quick-Start requests.) 3500 [B05] also says the following: "By reverse engineering this 3501 algorithm, it was possible to guess that there was an assumption 3502 that host capacity was smaller than the network's, so meeting a 3503 request in full would still leave a lot of spare capacity for the 3504 next request." Again, we would like to clarify that there has been 3505 no such assumption underlying the Quick-Start design. 3507 E.5. Router Algorithms as Local Policy 3509 [B05] recommends that either this document should set constraints on 3510 possible router algorithms, or say that experiments are needed "in 3511 order to establish constraints required on router algorithms for 3512 interworking, robustness, fairness etc." While it is possible that 3513 experiments will lead to an understanding of constraints that are 3514 needed on router algorithms, we think it is more likely that there 3515 will not be a need for explicit constraints on router algorithms for 3516 accepting or rejecting Quick-Start requests. 3518 Our approach is that, while the Quick-Start IETF documentation 3519 standardizes the semantics of Quick-Start and the format of the 3520 Quick-Start IP Option and the Quick-Start Response TCP Option, the 3521 IETF documentation should not and does not standardize the 3522 algorithms used at routers for approving or denying Quick-Start 3523 request. Appendix D in this document has presented one possible 3524 router algorithm for approving or denying Quick-Start requests, but 3525 further discussion of the range of possibilities in router 3526 algorithms is available elsewhere [SAF05]. As an example, the 3527 fairness criteria that routers might apply in granting or denying 3528 Quick-Start requests are discussed in [SAF05], but are not discussed 3529 in the same detail in this document. This document leaves routers 3530 free to apply any criteria they choose in accepting or denying 3531 Quick-Start requests, modulo the requirements given in Section 3.3 3532 above. 3534 This approach of the Quick-Start router algorithm as a matter of 3535 local policy is consistent with the approach in RFC 3168 on 3536 standardizing Explicit Congestion Notification (ECN). RFC 3168 3537 standardized the semantics of the ECN field, but did not standardize 3538 a router's Active Queue Management mechanisms for deciding when to 3539 set the Congestion Experienced codepoint in packets. 3541 E.6. An Alternate Proposal 3543 [B05] proposes an alternate to Quick-Start where endpoints allocate 3544 rates to themselves. [B05] argues that adding rate allocation to 3545 interior routers is not the fundamenally correct direction. 3547 [B05] argues for an approach that associates senders with their 3548 ingress attachment point, with routers reporting their impairment 3549 status back to the sender [BJCG+05, BJS05]. The source declares the 3550 impairment that it believes it will accumulate along the path, and 3551 routers effectively subtract the local impairment status. If the 3552 sender is reporting correctly, and the impairment has not changed 3553 significantly from one round-trip time to the next, the reported 3554 impairment at the egress router should be close to zero. 3556 Normative References 3558 [RFC793] J. Postel, Transmission Control Protocol, RFC 793, 3559 September 1981. 3561 [RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191, 3562 November 1990. 3564 [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 3565 (IPv6) Specification. RFC 2460, December 1998. 3567 [RFC2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 3568 Control. RFC 2581. April 1999. 3570 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D. The Addition 3571 of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed 3572 Standard, September 2001. 3574 [RFC3390] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's 3575 Initial Window. RFC 3390, October 2002. 3577 [RFC3742] Floyd, S., Limited Slow-Start for TCP with Large 3578 Congestion Windows, RFC 3742, Experimental, March 2004. 3580 Informative References 3582 [RFC792] J. Postel. Internet Control Message Protocol. RFC 792, 3583 September 1981. 3585 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3586 April 1992. 3588 [RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC 3589 1812, June 1995. 3591 [RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, 3592 October 1996. 3594 [RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997. 3596 [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. 3597 April 1997. 3599 [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- 3600 Version 1 Functional Specification. RFC 2205, September 1997. 3602 [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), 3603 RFC 2409, November 1998. 3605 [RFC2246] T. Dierks and C. Allen, The TLS Protocol, RFC 2246. 3607 [RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, 3608 D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. 3609 Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, 3610 Recommendations on Queue Management and Congestion Avoidance in the 3611 Internet, RFC 2309, April 1998. 3613 [RFC2401] S. Kent and R. Atkinson. Security Architecture for the 3614 Internet Protocol. RFC 2401, November 1998. 3616 [2401bis] S. Kent and K. Seo, Security Architecture for the Internet 3617 Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work- 3618 in-progress, March 2005. 3620 [RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC 3621 2402, November 1998. 3623 [2402bis] S. Kent, IP Authentication Header, internet-draft draft- 3624 ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005. 3626 [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased 3627 Initial TCP Window Size. RFC 2415. September 1998. 3629 [RFC2416] T. Shepard and C. Partridge. When TCP Starts Up With Four 3630 Packets Into Only Three Buffers. RFC 2416. September 1998. 3632 [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol 3633 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. 3634 RFC 2463, December 1998. 3636 [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over 3637 Satellite Channels using Standard Mechanisms. RFC 2488. January 3638 1999. 3640 [RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and 3641 B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August 3642 1999. 3644 [RFC2960] R. Stewart, et. al. Stream Control Transmission Protocol. 3645 RFC 2960, October 2000. 3647 [RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC 3648 3124. June 2001. 3650 [RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and 3651 Issues, RFC 3234, February 2002. 3653 [RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344, 3654 August 2002. 3656 [RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. 3657 RFC 3360, August 2002. 3659 [RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC 3660 3649, December 2003. 3662 [RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per- 3663 Domain Behavior (PDB) for Differentiated Services. RFC 3662, 3664 December 2003. 3666 [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in 3667 IPv6. RFC 3775, June 2004. 3669 [RFC3819] P. Karn et al., "Advice for Internet Subnetwork 3670 Designers", July 2004. 3672 [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. 3673 Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January 3674 2005. 3676 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 3677 4306, December 2005. 3679 [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP 3680 with Larger Initial Windows. ACM Computer Communication Review, July 3681 1998. 3683 [B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft 3684 draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL 3685 "http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005. 3687 [BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., 3688 Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion 3689 Response in an Internetwork Using Re-Feedback", SIGCOMM, August 3690 2005. 3692 [BJS05] Briscoe, B., Jacquet, A., and A. Salvatori, "Re-ECN: Adding 3693 Accountability for Causing Congestion to TCP/IP", internet-draft 3694 draft-briscoe-tsvwg-re-ecn-tcp-00.txt, work-in-progress, October 3695 2005. 3697 [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of 3698 the new GSM Phase 2+ General Packet Radio Service. IEEE 3699 Communications Magazine, pages 94--104, August 1997. 3701 [FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End 3702 Congestion Control in the Internet, IEEE/ACM Transactions on 3703 Networking, August 1999. 3705 [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi- 3706 Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE 3707 Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, 3708 September 2002. 3710 [H05] P. Hoffman, email, October 2005. Citation for acknowledgement 3711 purposes only. 3713 [HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion 3714 Detection: Evasion, Traffic Normalization, and End-to-End Protocol 3715 Semantics, Proc. USENIX Security Symposium 2001. 3717 [Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM 3719 [JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available 3720 Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP 3721 Throughput, SIGCOMM 2002. 3723 [K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High 3724 Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. 3725 URL "http://www.seas.upenn.edu/~kunniyur/". 3727 [KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. 3728 Sterbenz. Explicit Transport Error Notification (ETEN) for Error- 3729 Prone Wireless and Satellite Networks. Technical Report No. 8333, 3730 BBN Technologies, March 2002. URL 3731 "http://www.icir.org/mallman/papers/". 3733 [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet 3734 Congestion Control for Future High Bandwidth-Delay Product 3735 Environments. ACM Sigcomm 2002, August 2002. URL 3736 "http://ana.lcs.mit.edu/dina/XCP/". 3738 [KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion 3739 Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt, 3740 work in progress, March 2005. 3742 [KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed 3743 Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003. 3745 [L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005. 3746 URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf". 3748 [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring 3749 Interactions Between Transport Protocols and Middleboxes, Internet 3750 Measurement Conference 2004, August 2004. URL 3751 "http://www.icir.org/tbit/". 3753 [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the 3754 Evolution of Transport Protocols in the Internet. Computer 3755 Communications Review, April 2004. 3757 [MaxNet] MaxNet Home Page, URL 3758 "http://netlab.caltech.edu/~bartek/maxnet.htm". 3760 [PK98] Venkata N. Padmanabhan and Randy H. Katz, TCP Fast Start: A 3761 Technique For Speeding Up Web Transfers, IEEE GLOBECOM '98, November 3762 1998. 3764 [P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection, 3765 report to John Jeidemann, 2000, private communication. Citation for 3766 acknowledgement purposes only. 3768 [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh 3769 Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical 3770 Report No. 8339, BBN Technologies, March 2002. URL 3771 "http://www.icir.org/mallman/papers/". 3773 [RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option 3774 Processing, Preprint-Reihe des Fachbereichs Mathematik - Informatik, 3775 No. 15, October 2003. 3777 [RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option 3778 Processing - Part 2, Preprint-Reihe des Fachbereichs Mathematik - 3779 Informatik, No. 26, July 2004. 3781 [S02] Ion Stoica, private communication, 2002. Citation for 3782 acknowledgement purposes only. 3784 [SAF05] Pasi Sarolahti, Mark Allman, and Sally Floyd. Evaluating 3785 Quick-Start for TCP. May 2005. URL 3786 "http://www.icir.org/floyd/quickstart.html". 3788 [SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare 3789 network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work 3790 in Progress session , August 2005, 3791 https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf. 3793 [SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce, 3794 Washington, D.C. publication 180-1, April 1995. 3796 [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick 3797 Start with NS-2. Class Project, December 2002. Not publically 3798 available; citation for acknowledgement purposes only. 3800 [V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A 3801 Mechanism for Background Transfers. OSDI 2002. 3803 [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed 3804 Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE 3805 International Performance, Computing, And Communications 3806 Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL 3807 "http://informatik.uibk.ac.at/users/c70370/research/publications/". 3809 [W03] Michael Welzl, PMTU-Options: Path MTU Discovery Using Options, 3810 expired internet-draft draft-welzl-pmtud-options-01.txt, work-in- 3811 progress. February 2003. 3813 [ZPS00] Y. Zhang, V. Paxson, and S. Shenker, The Stationarity of 3814 Internet Path Properties: Routing, Loss, and Throughput, ACIRI 3815 Technical Report, May 2000. 3817 [ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data 3818 Transfers: Theory, Architectural Support, and Simulation Results, 3819 NOSSDAV 2000, June 2000. 3821 F. IANA Considerations 3823 Quick-Start requires an IP Option and a TCP Option. 3825 F.1. IP Option 3827 Quick-Start requires that both an IPv4 and an IPv6 Option Number be 3828 allocated. The IPv4 Option would have a copied flag of 0, a class 3829 field of 00, and the assigned five-bit option number. The IPv6 3830 Option would have the first three bits of "001" [RFC 2460, Section 3831 4.2], with the first two bits indicating that the IPv6 node skip 3832 over this option and continue processing the header if it doesn't 3833 recognize the option type, and the third bit indicating that the 3834 Option Data may change en-route. 3836 In both cases the name of the option would be "QS - Quick-Start", 3837 with this document as the reference document. 3839 F.2. TCP Option 3841 Quick-Start also requires that a TCP Option Number be allocated. 3842 The Length would be 4, and the Meaning would be "Quick-Start 3843 Request", with this document as the reference document. 3845 AUTHORS' ADDRESSES 3847 Sally Floyd 3848 Phone: +1 (510) 666-2989 3849 ICIR (ICSI Center for Internet Research) 3850 Email: floyd@icir.org 3851 URL: http://www.icir.org/floyd/ 3853 Mark Allman 3854 ICSI Center for Internet Research 3855 1947 Center Street, Suite 600 3856 Berkeley, CA 94704-1198 3857 Phone: (440) 243-7361 3858 Email: mallman@icir.org 3859 URL: http://www.icir.org/mallman/ 3861 Amit Jain 3862 F5 Networks 3863 Email : a.jain@f5.com 3865 Pasi Sarolahti 3866 Nokia Research Center 3867 P.O. Box 407 3868 FI-00045 NOKIA GROUP 3869 Finland 3870 Phone: +358 50 4876607 3871 Email: pasi.sarolahti@iki.fi 3873 Full Copyright Statement 3875 Copyright (C) The Internet Society (2006). This document is subject 3876 to the rights, licenses and restrictions contained in BCP 78, and 3877 except as set forth therein, the authors retain all their rights. 3879 This document and the information contained herein are provided on 3880 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3881 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3882 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3883 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3884 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3887 Intellectual Property 3889 The IETF takes no position regarding the validity or scope of any 3890 Intellectual Property Rights or other rights that might be claimed 3891 to pertain to the implementation or use of the technology described 3892 in this document or the extent to which any license under such 3893 rights might or might not be available; nor does it represent that 3894 it has made any independent effort to identify any such rights. 3895 Information on the procedures with respect to rights in RFC 3896 documents can be found in BCP 78 and BCP 79. 3898 Copies of IPR disclosures made to the IETF Secretariat and any 3899 assurances of licenses to be made available, or the result of an 3900 attempt made to obtain a general license or permission for the use 3901 of such proprietary rights by implementers or users of this 3902 specification can be obtained from the IETF on-line IPR repository 3903 at http://www.ietf.org/ipr. 3905 The IETF invites any interested party to bring to its attention any 3906 copyrights, patents or patent applications, or other proprietary 3907 rights that may cover technology that may be required to implement 3908 this standard. Please address the information to the IETF at ietf- 3909 ipr@ietf.org.