idnits 2.17.1 draft-ietf-tsvwg-quickstart-06.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 4051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4069. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4075. ** 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 ([RFC2581], [KHR02], [RFC3390], [RFC2581,RFC3390]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2678 has weird spacing: '... act chg ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (30 August 2006) is 6441 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: 'T1' is mentioned on line 2028, but not defined == Missing Reference: 'T2' is mentioned on line 2027, but not defined == Missing Reference: 'T0' is mentioned on line 2028, but not defined ** 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 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 2409 (Obsoleted by RFC 4306) -- 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 (-11) exists of draft-ietf-pmtud-method-07 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 17 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-06.txt ICIR 4 Expires: February 2007 A. Jain 5 F5 Networks 6 P. Sarolahti 7 Nokia Research Center 8 30 August 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 February 2007. 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 only specify its use with TCP. Quick-Start is designed 45 to allow connections to use higher sending rates when there is 46 significant unused bandwidth along the path and the sender and all 47 of the routers along the path approve the Quick-Start Request. 49 This document describes many paths where Quick-Start requests would 50 not be approved. These paths include all paths containing routers, 51 IP tunnels, MPLS paths, and the like that do not support Quick- 52 Start. These paths also include paths with routers or middleboxes 53 that drop packets containing IP options. Quick-Start requests could 54 be difficult to approve over paths that include multi-access layer- 55 two networks. This document also describes environments where the 56 Quick-Start process could fail with false positives, with the sender 57 incorrectly assuming that the Quick-Start request had been approved 58 by all of the routers along the path. As a result of these 59 concerns, and as a result of the difficulties and seeming absence of 60 motivation for routers such as core routers to deploy Quick-Start, 61 Quick-Start is being proposed as a mechanism that could be of use in 62 controlled environments, and not as a mechanism that would be 63 intended or appropriate for ubiquitous deployment in the global 64 Internet. 66 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 68 Changes from draft-ietf-tsvwg-quickstart-05: 70 * Minor editing in response to AD feedback from 71 Lars Eggert. 72 This includes changing one "should" to "SHOULD", 73 and changing formating of the IANA Considerations 74 section. 76 * Clarifying in the Introduction that the QS router 77 does not give preferential treatment to QS packets. 78 In response to email from Fil Dickinson. 80 * Added a discussion of interactions between 81 Quick-Start and draft-ietf-pmtud-method. In 82 response to AD Feedback from Lars Eggert. 84 * Deleted Appendix F on "Feedback from Bob Briscoe". 85 From AD feedback about deleting unnecessary 86 appendices. 88 * Added a paragraph to the Introduction about which 89 sections contain normative references, and which 90 sections are general discussion. From AD feedback. 92 * Added a discussion about congestion control for 93 TCP's reverse-path traffic. From feedback from 94 Mitchell Erblich. 96 Changes from draft-ietf-tsvwg-quickstart-04: 98 * Reformatted references so that "[RFC2581, RFC3390]" 99 is instead "([RFC2581], [RFC3390])", to eliminate 100 bug reports from the idnits tool. From feedback 101 from Dan Romascanu. 103 * Rephrased beginning of second paragraph in the 104 Abstract. From feedback from James Polk. 106 Changes from draft-ietf-tsvwg-quickstart-03: 108 * Added a discussion of the lower limit of the rate request 109 of 80 kbps, from feedback from Gorry Fairhurst. 111 * Added the QS Nonce to the QS Approved Rate. 112 From feedback from Gorry Fairhurst. 114 * Moved the Related Work section to the appendix. 115 From feedback from Gorry Fairhurst. 117 Changes from draft-ietf-tsvwg-quickstart-02: 119 * Some general editing. 121 * Said that if the receiver receives a Quick-Start Request 122 with a rate of zero, then the receiver SHOULD NOT send 123 a Quick-Start response. And that if the sender 124 receives an acknowledgement of its packet with no 125 Quick-Start response, then the sender MUST assume that the 126 request was denied, and send a Report of Approved Rate 127 with a rate of zero. 129 * Said that if a Quick-Start packet is dropped or marked, 130 the sender should not make more Quick-Start requests in this 131 connection. 133 * Said that the Quick-Start Request SHOULD be sent on a packet 134 that requires an acknowledgement, e.g., a SYN, SYN/ACK, or data 135 packet. 137 * Made changes to the section on "TCP: A Quick-Start Request in the 138 Middle of a Connection". 140 * Added that if the TCP host is going to use the successful 141 Quick-Start Request, it MUST start using it within one 142 round-trip time of receiving the Quick-Start Response, 143 or within three seconds, whichever is smaller. 145 * Added a stronger applicability statement, in the abstract 146 and in Section 10 on "Implementation and Deployment Issues". 147 From feedback from the working group. 149 * Added a section about MPLS. From feedback from Mitchell 150 Erblichs. 152 * Strengthened the language of the difficulties presented by 153 multi-access links. 155 * Added a discussion in Section 10.3 about the deployment of 156 Quick-Start on single-hop paths. From feedback from 157 Mitchell Erblichs. 159 * Clarified that the "router" function of approving 160 Quick-Start requests includes the IP-layer processing 161 at the sender. 163 * Clarified in Section 3.3 on "Processing the Quick-Start 164 Request at Routers" that this document standardizes only 165 the semantics of Quick-Start, and not the specific 166 algorithms for processing Quick-Start requests at routers. 168 * Clarified in Section 3.3 on "Processing the Quick-Start 169 Request at Routers" that a router will have to consider 170 the previous Quick-Start requests in approving a new one. 172 * In Section 9.3 on "Quick-Start with QoS-enabled Traffic", 173 which says that routers are free to take into account 174 the diff-serv codepoint in considering QS requests, clarified 175 that routers are also free to take into account their own 176 understanding of priorities. 178 * Added the Temporary bit to Appendix on "Possible Additional 179 Uses for the Quick-Start Option". Clarified that the Quick-Start 180 mechanism is not designed to help routers achieve full link 181 utilization. 183 * Editing from feedback from Gorry Fairhurst. 185 Changes from draft-ietf-tsvwg-quickstart-01: 187 * Added a citation to SPAND: Speeding Up Short Data Transfers. 188 * Added a sentence in Section 8.1 on "Implementation Issues for 189 Processing Quick-Start Requests" about multi-access links. 190 * Mentioned the IP Router Alert option, RFC 2113, in Appendix. 191 * Added a discussion of lower-than-best-effort service. 192 * Added a few sentences about the requirements for 193 randomness in the nonce. 194 * Changed the name of the option from the Quick-Start Request 195 Option to the Quick-Start Option. 196 * Changed the semantics of the Reserved field to the Function 197 field, adding that a Quick-Start option is only interpreted 198 as a request if this field is zero. 199 * Changed the "Reporting Approved Rate" option from a 200 "Possible Use" in Appendix to a required use in Section 3.1, 201 to allow routers and receivers some protection against 202 misbehaving senders. 203 * Changes from feedback from Bob Briscoe: 204 - Added Appendix about Sections 1-3 of 205 Bob Briscoe's document. 206 - Added a clarification that the approval of a 207 Quick-Start request at a router does not affect 208 the treatment of the subsequent arriving 209 Quick-Start data packets. 210 - Added the one-way hash function as an alternate 211 implementation for the QS Nonce. 212 - Clarified the phrase "incrementally deployable", adding 213 the following: 214 "We note that while Quick-Start is incrementally deployable 215 in this sense, a Quick-Start request cannot be approved 216 for a particular connection unless both end-nodes and all 217 of the routers along the path have been configured to 218 support Quick-Start." 219 - Clarified semantics about additional rate. 220 - Said that when denying a rate request, the router 221 may in the future use the QS Nonce field to report 222 an error code. 223 - Add Bob's suggestion from Section 4.4 as an alternate 224 possible rate encoding. 225 - Made changes suggested in Section 5.1.3 of Bob's paper, 226 including saying that the router should decrement the QS TTL 227 by the same amount that it decrements the IP TTL (on the 228 off chance that it decrements the IP TTL by more than one). 229 - Fixed nits. 231 Changes from draft-ietf-tsvwg-quickstart-00: 232 * Added a 30-bit QS Nonce. Based on feedback from Guohan Lu 233 and Gorry Fairhurst (and deleted the text about a possible 234 four-bit QS nonce). 235 * Added a new section "Quick-Start and IPsec AH", based on feedback 236 from Joe Touch and David Black. 237 * Revised "Quick-Start in IP Tunnels" Section, based on feedback 238 from Joe Touch and David Black. 239 * Added a section about "Possible Uses for the Reserved Fields". 240 * Changes from feedback from Gorry Fairhurst: 241 - Section 4.4, revised the explanation for reducing the 242 congestion window when the first ACK for a Quick-Start 243 packet is received. 244 - Section 6.4, deleted the last sentence. 245 - Minor editing changes. 246 - Revised Section 4.6.2 to say that sender SHOULD send one packet 247 with an initial RTO of three seconds. 248 - Revised Section 4.6.3 to say that the TCP sender SHOULD use an 249 initial RTO setting of three seconds. 250 - Added text to Section 6.2 on Multiple Paths, discussing 251 multipath routing. 252 - Clarified about GPRS round-trip times. 253 - Clarified about PMTUD and the first window of data. 254 - A small reorganization, rearranging sections. 255 * Changes from feedback from Martin Duke: 256 - Revised text about the size of QS requests. 257 - Added some text to Section 4.1, about when to send QS requests. 259 Changes from draft-amit-quick-start-04.txt: 260 * A significant amount of general editing. 261 * Because the Rate Request field only uses four bits, specified 262 that the other four bits are reserved, and talked about a 263 possible use for them. This is discussed in a new section on 264 "A Rate-Reduced Nonce?" 265 * Specified that a Quick-Start-capable router denying a request 266 SHOULD delete the Quick-Start option, and if this is not 267 possible, SHOULD zero the QS TTL and the Rate Request fields. 268 * Made the following change: If the Quick-Start Response is lost 269 in the network, it is not retransmitted. 270 * For PMTUD, in Section 4.6, added a suggestion to send one large 271 packet in the initial window for PMTUD, and to send the other 272 packets at 576 bytes. 273 * Added a paragraph to Section 4.6.3 on retransmitted SYN packets, 274 saying they should use an RTO of three seconds and a new ISN 275 on the retransmitted SYN packet. 276 * Added that "TCP SHOULD NOT use Quick-Start" after an 277 application-limited period at this time, in Section 4.1, in 278 addition to the old sentence that this "requires further thought 279 and investigation". 280 * Added an appendix on "Possible Router Algorithm". 281 * Moved the section on "Quick-Start with DCCP" to the appendix. 282 * Name changed from draft-amit-quick-start-04.txt to 283 draft-tsvwg-quickstart-00.txt. 285 Changes from draft-amit-quick-start-03.txt: 286 * Added a citation to the paper on "Evaluating Quick-Start for 287 TCP", and added pointers to the work in that paper. 288 This work includes: 289 - Discussions of router algorithms. 290 - Discussions of sizing Quick-Start requests. 291 * Added sections on "Misbehaving Middleboxes", and on "Attacks on 292 Quick-Start". 294 Changes from draft-amit-quick-start-02.txt: 295 * Added a discussion on Using Quick-Start in the Middle of a 296 Connection. The request would be on the total rate, 297 not on the additional rate. 298 * Changed name "Initial Rate" to "Rate Request", and changed 299 the units from packets per second to bytes per second. 300 * The following sections are new: 301 - The Quick-Start Request Option for IPv6 302 - Quick-Start in IP Tunnels 303 - When to Use Quick-Start 304 - TCP: Responding to a Loss of a Quick-Start Packet 305 - TCP: A Quick-Start Request for a Larger Initial Window 306 - TCP: A Quick-Start Request after an Idle Period 307 - The Quick-Start Mechanisms in DCCP and other Transport 308 Protocols 309 - Quick-Start with DCCP 310 - Implementation and Deployment Issues 311 - Design Decisions 312 * Added a discussion of Kunniyur's Anti-ECN proposal. 313 * Added a section on simulations, with a brief discussion of the 314 simulations by Srikanth Sundarrajan. 316 Changes from draft-amit-quick-start-01.txt: 317 * Added a discussion in the related work section about the 318 possibility of optimistically sending a large initial window, 319 without explicit permission of routers. 320 * Added a discussion in the related work section about the 321 tradeoffs of XCP vs. Quick-Start. 322 * Added a section on "The Quick-Start Request: Packets or Bytes?" 324 Changes from draft-amit-quick-start-00.txt: 325 * The addition of a citation to [KHR02]. 326 * The addition of a Related Work section. 327 * Deleted the QS Nonce, in favor of a random initial value for the 328 QS TTL. 330 Table of Contents 332 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 12 333 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 14 334 2. Assumptions and General Principles. . . . . . . . . . . . . . 14 335 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 15 336 3. The Quick-Start Option in IP. . . . . . . . . . . . . . . . . 17 337 3.1. The Quick-Start Option for IPv4. . . . . . . . . . . . . 17 338 3.2. The Quick-Start Option for IPv6. . . . . . . . . . . . . 21 339 3.3. Processing the Quick-Start Request at 340 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 341 3.3.1. Processing the Report of Approved 342 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 343 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 24 344 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 26 345 4.1. Sending the Quick-Start Request. . . . . . . . . . . . . 27 346 4.2. The Quick-Start Response Option in the TCP 347 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 348 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 30 349 4.4. TCP: Receiving and Using the Quick-Start 350 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 30 351 4.5. TCP: Controlling Acknowledgement Traffic on 352 the Reverse Path . . . . . . . . . . . . . . . . . . . . . . 33 353 4.6. TCP: Responding to a Loss of a Quick-Start 354 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 355 4.7. TCP: A Quick-Start Request for a Larger Ini- 356 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 35 357 4.7.1. Interactions with Path MTU Discovery. . . . . . . . 35 358 4.7.2. Quick-Start Request Packets that are 359 Discarded by Routers or Middleboxes. . . . . . . . . . . . 36 360 4.8. TCP: A Quick-Start Request in the Middle of 361 a Connection. . . . . . . . . . . . . . . . . . . . . . . . . 37 362 4.9. An Example Quick-Start Scenario with TCP . . . . . . . . 38 363 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 39 364 6. Quick-Start in IP Tunnels and MPLS. . . . . . . . . . . . . . 39 365 6.1. Simple Tunnels That Are Compatible with 366 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 41 367 6.1.1. Simple Tunnels that are Aware of Quick- 368 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 369 6.2. Simple Tunnels That Are Not Compatible with 370 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 42 371 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 43 372 6.4. Quick-Start and MPLS . . . . . . . . . . . . . . . . . . 44 373 7. The Quick-Start Mechanism in other Transport Pro- 374 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 375 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 46 376 8.1. Determining the Rate to Request. . . . . . . . . . . . . 46 377 8.2. Deciding the Permitted Rate Request at a 378 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 379 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 47 380 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 47 381 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 48 382 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 49 383 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 50 384 9.4.1. Misbehaving Senders . . . . . . . . . . . . . . . . 50 385 9.4.2. Receivers Lying about Whether the 386 Request was Approved . . . . . . . . . . . . . . . . . . . 51 387 9.4.3. Receivers Lying about the Approved 388 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 389 9.4.4. Collusion between Misbehaving Routers . . . . . . . 53 390 9.5. Misbehaving Middleboxes and the IP TTL . . . . . . . . . 54 391 9.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 55 392 9.7. Simulations with Quick-Start . . . . . . . . . . . . . . 55 393 10. Implementation and Deployment Issues . . . . . . . . . . . . 56 394 10.1. Implementation Issues for Sending Quick- 395 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 56 396 10.2. Implementation Issues for Processing Quick- 397 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 57 398 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 57 399 10.4. A Comparison with the Deployment Problems 400 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 401 11. Security Considerations. . . . . . . . . . . . . . . . . . . 59 402 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 60 403 12.1. IP Option . . . . . . . . . . . . . . . . . . . . . . . 60 404 12.2. TCP Option. . . . . . . . . . . . . . . . . . . . . . . 61 405 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 61 406 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61 407 A. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 62 408 A.1. Fast Start-ups without Explicit Information 409 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 63 410 A.2. Optimistic Sending without Explicit Informa- 411 tion from Routers . . . . . . . . . . . . . . . . . . . . . . 64 412 A.3. Fast Start-ups with other Information from 413 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 414 A.4. Fast Start-ups with more Fine-Grained Feed- 415 back from Routers . . . . . . . . . . . . . . . . . . . . . . 66 416 A.5. Fast Start-ups with Lower-Than-Best-Effort 417 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 418 B. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 67 419 B.1. Alternate Mechanisms for the Quick-Start 420 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 67 421 B.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 67 422 B.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 69 423 B.2. Alternate Encoding Functions . . . . . . . . . . . . . . 70 424 B.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 71 425 B.4. Quick-Start Semantics: Total Rate or Addi- 426 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 73 427 B.5. Alternate Responses to the Loss of a Quick- 428 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 74 429 B.6. Why Not Include More Functionality?. . . . . . . . . . . 74 430 B.7. Alternate Implementations for a Quick-Start 431 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 432 B.7.1. An Alternate Proposal for the Quick- 433 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 434 B.7.2. The Earlier Request-Approved Quick- 435 Start Nonce. . . . . . . . . . . . . . . . . . . . . . . . 78 436 C. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 79 437 D. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 81 438 E. Possible Additional Uses for the Quick-Start 439 Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 440 Normative References . . . . . . . . . . . . . . . . . . . . . . 84 441 Informative References . . . . . . . . . . . . . . . . . . . . . 84 442 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 89 443 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 91 444 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 91 446 1. Introduction 448 Each connection begins with a question: "What is the appropriate 449 sending rate for the current network path?" The question is not 450 answered explicitly, but each TCP connection determines the sending 451 rate by probing the network path and altering the congestion window 452 (cwnd) based on perceived congestion. Each TCP connection starts 453 with a pre-configured initial congestion window (ICW). Currently, 454 TCP allows an initial window of between one and four MSS-sized 455 segments ([RFC2581], [RFC3390]). The TCP connection then probes the 456 network for available bandwidth using the slow-start procedure 457 ([Jac88], [RFC2581]), doubling cwnd during each congestion-free 458 round-trip time (RTT). 460 The slow-start algorithm can be time-consuming --- especially over 461 networks with large bandwidth or long delays. It may take a number 462 of RTTs in slow-start before the TCP connection begins to fully use 463 the available bandwidth of the network. For instance, it takes 464 log_2(N) - 2 round-trip times to build cwnd up to N segments, 465 assuming an initial congestion window of 4 segments. This time in 466 slow-start is not a problem for large file transfers, where the 467 slow-start stage is only a fraction of the total transfer time. 468 However, in the case of moderate-sized transfers the connection 469 might carry out its entire transfer in the slow-start phase, taking 470 many round-trip times, where one or two RTTs might have been 471 sufficient when using the currently available bandwidth along the 472 path. 474 A fair amount of work has already been done to address the issue of 475 choosing the initial congestion window for TCP, with RFC 3390 476 allowing an initial window of up to four segments based on the MSS 477 used by the connection [RFC3390]. Our underlying premise is that 478 explicit feedback from all of the routers along the path would be 479 required, in the current architecture, for best-effort connections 480 to use initial windows significantly larger than those allowed by 481 [RFC3390], in the absence of other information about the path. 483 In using Quick-Start, a TCP host, say, host A, would indicate its 484 desired sending rate in bytes per second, using a Quick-Start option 485 in the IP header of a TCP packet. Each router along the path could, 486 in turn, either approve the requested rate, reduce the requested 487 rate, or indicate that the Quick-Start request is not approved. (We 488 note that the `routers' referred to in this document also include 489 the IP-layer processing of the Quick-Start request at the sender.) 490 In approving a Quick-Start request, a router does not give 491 preferential treatment to subsequent packets from that connection; 492 the router is only asserting that it is currently underutilized and 493 believes there is sufficient available bandwidth to accommodate the 494 sender's requested rate. The Quick-Start mechanism can determine if 495 there are routers along the path that do not understand the Quick- 496 Start option, or have not agreed to the Quick-Start rate request. 497 TCP host B communicates the final rate request to TCP host A in a 498 transport-level Quick-Start Response in an answering TCP packet. 500 If the Quick-Start request is approved by all routers along the 501 path, then the TCP host can send at up to the approved rate for a 502 window of data. Subsequent transmissions will be governed by the 503 default TCP congestion control mechanisms of that connection. If 504 the Quick-Start request is not approved, then the sender would use 505 the default congestion control mechanisms. 507 Quick-Start would not be the first mechanism for explicit 508 communication from routers to transport protocols about sending 509 rates. Explicit Congestion Notification (ECN) gives explicit 510 congestion control feedback from routers to transport protocols, 511 based on the router detecting congestion before buffer overflow 512 [RFC3168]. In contrast, routers would not use Quick-Start to give 513 congestion information, but instead would use Quick-Start as an 514 optional mechanism to give permission to transport protocols to use 515 higher sending rates, based on the ability of all the routers along 516 the path to determine if their respective output links are 517 significantly underutilized. 519 Section 2 gives an overview of Quick-Start. The formal 520 specifications for Quick-Start are contained in Sections 3, 4, 521 6.1.1, and 6.3. In particular, Quick-Start is specified for IPv4 522 and for IPv6 in Section 3, and is specified for TCP in Section 4. 523 Section 6 consists mostly of a non-normative discussion of 524 interactions of Quick-Start with IP tunnels and MPLS; however, 525 Section 6.1.1 and 6.3 specify behavior for IP tunnels that are aware 526 of Quick-Start. 528 The rest of the document is non-normative, as follows. Section 5 529 shows that Quick-Start is compatible with IPsec AH (Authentication 530 Header). Section 7 gives a non-normative set of guidelines for 531 specifying Quick-Start in other transport protocols, and Section 8 532 discusses using Quick-Start in transport end-nodes and in routers. 533 Section 9 gives an evaluation of the costs and benefits of Quick- 534 Start, and Section 10 discusses implementation and deployment 535 issues. The appendices discuss related work, Quick-Start design 536 decisions, and possible router algorithms. 538 1.1. Conventions and Terminology 540 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 541 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 542 document are to be interpreted as described in [RFC2119]. 544 2. Assumptions and General Principles 546 This section describes the assumptions and general principles behind 547 the design of the Quick-Start mechanism. 549 Assumptions: 551 * The data transfer in the two directions of a connection traverses 552 different queues, and possibly even different routers. Thus, any 553 mechanism for determining the allowed sending rate would have to be 554 used independently for each direction. 556 * The path between the two endpoints is relatively stable, such that 557 the path used by the Quick-Start request is generally the same path 558 used by the Quick-Start packets one round-trip time later. [ZDPS01] 559 shows this assumption should be generally valid. However, [RFC3819] 560 discusses a range of Bandwidth on Demand subnets that could cause 561 the characteristics of the path to change over time. 563 * Any new mechanism must be incrementally deployable, and might not 564 be supported by all of the routers and/or end-hosts. Thus, any new 565 mechanism must be able to accommodate non-supporting routers or end- 566 hosts without disturbing the current Internet semantics. We note 567 that while Quick-Start is incrementally deployable in this sense, a 568 Quick-Start request cannot be approved for a particular connection 569 unless both end-nodes and all of the routers along the path have 570 been configured to support Quick-Start. 572 General Principles: 574 * Our underlying premise is that explicit feedback from all of the 575 routers along the path would be required, in the current 576 architecture, for best-effort connections to use initial windows 577 significantly larger than those allowed by [RFC3390], in the absence 578 of other information about the path. 580 * A router should only approve a Quick-Start request if the output 581 link is underutilized. Any other approach will result in either 582 per-flow state at the router, or the possibility of a (possibly 583 transient) queue at the router. 585 * No per-flow state should be required at the router. Note that 586 while per-flow state is not required, we also do not preclude a 587 router from storing per-flow state for making Quick-Start decisions 588 or for checking for misbehaving nodes. 590 2.1. Overview of Quick-Start 592 In this section we give an overview of the use of Quick-Start with 593 TCP to request a higher congestion window. The description in this 594 section is non-normative; the normative description of Quick-Start 595 with IP and TCP follows in Sections 3 and 4. Quick-Start could be 596 used in the middle of a connection, e.g., after an idle or 597 underutilized period, as well as for the initial sending rate; these 598 uses of Quick-Start are discussed later in the document. 600 Quick-Start requires end-points and routers to work together, with 601 end-points requesting a higher sending rate in the Quick-Start (QS) 602 option in IP, and routers along the path approving, modifying, 603 discarding or ignoring (and therefore disallowing) the Quick-Start 604 Request. The receiver uses reliable, transport-level mechanisms to 605 inform the sender of the status of the Quick-Start Request. In 606 addition, Quick-Start assumes a unicast, congestion-controlled 607 transport protocol; we do not consider the use of Quick-Start for 608 multicast traffic. 610 When sent as a request, the Quick-Start Option includes a request 611 for a sending rate in bits per second, and a Quick-Start TTL (QS 612 TTL) to be decremented by every router along the path that 613 understands the option and approves the request. The Quick-Start 614 TTL is initialized by the sender to a random value. The transport 615 receiver returns the rate, information about the TTL and the Quick- 616 Start Nonce to the sender using transport-level mechanisms. In 617 particular, the receiver computes the difference between the Quick- 618 Start TTL and the IP TTL (the TTL in the IP header) of the Quick- 619 Start request packet, and returns this in the Quick-Start response. 620 The sender uses this information to determine if all of the routers 621 along the path decremented the Quick-Start TTL, approving the Quick- 622 Start Request. 624 If the request is approved by all of the routers along the path, 625 then the TCP sender combines this allowed rate with the measurement 626 of the round-trip time, and ends up with an allowed TCP congestion 627 window. This window is sent rate-paced over the next round-trip 628 time, or until an ACK packet is received. 630 Figure 1 shows a successful use of Quick-Start, with the sender's IP 631 layer and both routers along the path approving the Quick-Start 632 Request. In this example, Quick-Start is used by TCP to establish 633 the initial congestion window. 635 Sender Router 1 Router 2 Receiver 636 ------ -------- -------- -------- 637 | 638 | 639 | 640 | Quick-Start Request 641 | in SYN or SYN/ACK. 642 | IP: Decrement QS TTL 643 | to approve request --> 644 | 645 | Decrement 646 | QS TTL 647 | to approve 648 | request --> 649 | 650 | Decrement 651 | QS TTL 652 | to approve 653 | request --> 654 | 655 | 656 | 657 | 658 | Return Quick-Start 659 | info to sender in 660 | <-- TCP ACK packet. 661 | 662 | 663 | Quick-Start approved, 664 | translate to cwnd. 665 | Report Approved Rate. 666 V Send cwnd paced over one RTT. --> 668 Figure 1: A successful Quick-Start Request. 670 Figure 2 shows an unsuccessful use of Quick-Start, with one of the 671 routers along the path not approving the Quick-Start Request. If 672 the Quick-Start Request is not approved, then the sender uses the 673 default congestion control mechanisms for that transport protocol, 674 including the default initial congestion window, response to idle 675 periods, etc. 677 Sender Router 1 Router 2 Receiver 678 ------ -------- -------- -------- 679 | 680 | 681 | 682 | Quick-Start Request 683 | in SYN or SYN/ACK. 684 | IP: Decrement QS TTL 685 | to approve request --> 686 | 687 | Decrement 688 | QS TTL 689 | to approve 690 | request --> 691 | 692 | Forward packet 693 | without modifying 694 | Quick-Start Option. --> 695 | 696 | 697 | 698 | 699 | Return Quick-Start 700 | info to sender in 701 | <-- TCP ACK packet. 702 | 703 | 704 | Quick-Start not approved. 705 | Report Approved Rate. 706 V Use default initial cwnd. --> 708 Figure 2: An unsuccessful Quick-Start Request. 710 3. The Quick-Start Option in IP 712 3.1. The Quick-Start Option for IPv4 714 The Quick-Start Request for IPv4 is defined as follows: 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Option | Length=8 | Func. | Rate | QS TTL | 720 | | | 0000 |Request| | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | QS Nonce | R | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Figure 3. The Quick-Start Option for IPv4. 726 A Quick-Start Request. 728 The first byte contains the option field, which includes the one-bit 729 copy flag, the 2-bit class field, and the 5-bit option number (to be 730 assigned by IANA). 732 The second byte contains the length field, indicating an option 733 length of eight bytes. 735 The third byte includes a four-bit Function field. If the Function 736 field is set to "0000", then the Quick-Start Option is a Rate 737 Request. In this case, the second half of the third byte is a four- 738 bit Rate Request field. 740 For a Rate Request, the fourth byte contains the Quick-Start TTL (QS 741 TTL) field. The sender MUST set the QS TTL field to a random value. 742 Routers that approve the Quick-Start Request decrement the QS TTL 743 (mod 256) by the same amount that they decrement the IP TTL. (As 744 elsewhere in this document, we use the term `router' imprecisely to 745 also include the Quick-Start functionality at the IP layer at the 746 sender.) The QS TTL is used by the sender to detect if all of the 747 routers along the path understood and approved the Quick-Start 748 option. 750 For a Rate Request, the transport sender MUST calculate and store 751 the TTL Diff, the difference between the IP TTL value and the QS TTL 752 value in the Quick-Start request packet, as follows: 754 TTL Diff = ( IP TTL - QS TTL ) mod 256 (1) 756 For a Rate Request, bytes 5-8 contain a 30-bit QS Nonce, discussed 757 in Section 3.4, and a two-bit Reserved field. The sender SHOULD set 758 the reserved field to zero, and routers and receivers SHOULD ignore 759 the reserved field. The sender SHOULD set the 30-bit QS Nonce to a 760 random value. 762 The sender initializes the Rate Request to the desired sending rate, 763 including an estimate of the transport and IP header overhead. The 764 encoding function for the Rate Request sets the request rate to 765 K*2^N bps (bits per second), for N the value in the Rate Request 766 field, and for K set to 40,000. For N=0, the rate request would be 767 set to zero, regardless of the encoding function. This is 768 illustrated in Table 1 below. For the four-bit Rate Request field, 769 the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings 770 that were considered for the Rate Request are given in Appendix B.2. 772 N Rate Request (in Kbps) 773 --- ------------------- 774 0 0 775 1 80 776 2 160 777 3 320 778 4 640 779 5 1,280 780 6 2,560 781 7 5,120 782 8 10,240 783 9 20,480 784 10 40,960 785 11 81,920 786 12 163,840 787 13 327,680 788 14 655,360 789 15 1,310,720 791 Table 1: Mapping from Rate Request field to rate request in Kbps. 793 Routers can approve the Quick-Start Request for a lower rate by 794 decreasing the Rate Request in the Quick-Start Request. Section 4.2 795 discusses the Quick-Start Response from the TCP receiver to the TCP 796 sender, and Section 4.4 discusses the TCP sender's mechanism for 797 determining if a Quick-Start Request has been approved. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Option | Length=8 | Func. | Rate | Not Used | 803 | | | 1000 | Report| | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | QS Nonce | R | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Figure 4. The Quick-Start Option for IPv4. 809 Report of Approved Rate. 811 If the Function field in the third byte of the Quick-Start Option is 812 set to "1000", then the Quick-Start Option is a Report of Approved 813 Rate. In this case the second four bits in the third byte are the 814 Rate Report field, formatted exactly as in the Rate Request field in 815 a Rate Request. For a Report of Approved Rate, the fourth byte of 816 the Quick-Start Option are not used. Bytes 5-8 contain a 30-bit QS 817 Nonce and a two- bit Reserved field. 819 After an approved Rate Request, the sender MUST report the Approved 820 Rate, using a Quick-Start Option configured as a Report of Approved 821 Rate with the Rate Report field set to the approved rate, and the QS 822 Nonce set to the QS Nonce sent in the Quick-Start Request. The 823 packet containing the Report of Approved Rate MUST be either a 824 control packet sent before the first Quick-Start data packet, or a 825 Quick-Start Option in the first data packet itself. The Report of 826 Approved Rate does not have to be sent reliably; for example, if the 827 approved rate is reported in a separate control packet, the sender 828 does not necessarily know if the control packet has been dropped in 829 the network. If the packet contained the Quick-Start Request is 830 acknowledged, but the acknowledgement packet does not contain a 831 Quick-Start Response, then the sender MUST assume that the Quick- 832 Start Request was denied, and set a Report of Approved Rate with a 833 rate of zero. Routers may choose to ignore the Report of Approved 834 Rate, or to use the Report of Approved Rate but ignore the QS Nonce. 835 Alternately, some routers that use the Report of Approved Rate may 836 choose to match the QS Nonce, masked by the approved rate, with the 837 QS Nonce seen in the original request. 839 If the Rate Request is denied, the sender MUST sent a Report of 840 Approved Rate with the Rate Report field set to zero. 842 We note that unlike a Quick-Start Request sent at the beginning of a 843 connection, when a Quick-Start Request is sent in the middle of a 844 connection, the connection could already have an established 845 congestion window or sending rate. The Rate Request is the 846 requested total rate for the connection, including the current rate 847 of the connection; the Rate Request is *not* a request for an 848 additional sending rate over and above the current sending rate. If 849 the Rate Request is denied, or lowered to a value below the 850 connection's current sending rate, then the sender ignores the 851 request, and reverts to the default congestion control mechanisms of 852 the transport protocol. 854 The use of the Quick-Start Option does not require the additional 855 use of the Router Alert Option [RFC2113]. 857 We note that in IPv4, a change in IP options at routers requires 858 recalculating the IP header checksum. 860 3.2. The Quick-Start Option for IPv6 862 The Quick-Start Option for IPv6 is placed in the Hop-by-Hop Options 863 extension header that is processed at every network node along the 864 communication path [RFC2460]. The option format following the 865 generic Hop-by-Hop Options header is identical to the IPv4 format, 866 with the exception that the Length field should exclude the common 867 type and length fields in the option format and be set to 6 bytes 868 instead of 8 bytes. 870 For a Quick-Start Request, the transport receiver compares the 871 Quick-Start TTL with the IPv6 Hop Limit field to calculate the TTL 872 Diff. (The Hop Limit in IPv6 is the equivalent of the TTL in IPv4.) 873 That is, TTL Diff MUST be calculated and stored as follows: 875 TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2) 877 Unlike IPv4, modifying or deleting the Quick-Start IPv6 Option does 878 not require checksum re-calculation, because the IPv6 header does 879 not have a checksum field, and modifying the Quick-Start Request in 880 the IPv6 Hop-by-Hop options header does not affect the IPv6 pseudo- 881 header checksum used in upper-layer checksum calculations. 883 Note that [RFC2460] specifies that when a specific flow label has 884 been assigned to packets, the contents of the Hop-by-Hop options, 885 excluding the next header field, must originate with the same 886 contents throughout the IP flow lifetime. However, the Quick-Start 887 option would be included in only a small fraction of the packets 888 during a flow lifetime. Thus, Quick-Start SHOULD NOT be used in an 889 IPv6 connection that uses flow labels unless the experimental 890 specification of flow labels in Appendix A of RFC 2460 is changed. 891 We note that RFC 2460 states that the use of the flow label field in 892 IPv6 "is, at the time of writing, still experimental and subject to 893 change as the requirements for flow support in the Internet become 894 clearer" [RFC2460]. 896 3.3. Processing the Quick-Start Request at Routers 898 The Quick-Start Request does not report the current sending rate of 899 the connection sending the request; in the default case of a router 900 (or IP layer implementation at an end-node) that does not maintain 901 per-flow state, a router makes the conservative assumption that the 902 flow's current sending rate is zero. Each participating router can 903 either terminate or approve the Quick-Start Request. A router MUST 904 only approve a Quick-Start request if the output link is 905 underutilized, and if the router judges that the output link will 906 continue to be underutilized if this and earlier approved requests 907 are used by the senders. Otherwise, the router reduces or 908 terminates the Quick-Start Request. 910 While the paragraph above defines the *semantics* of approving a 911 Quick-Start request, this document does not specify the specific 912 algorithms to be used by routers in processing Quick-Start Requests 913 or Reports. This is similar to RFC 3168, which specifics the 914 semantics of the ECN codepoints in the IP header, but does not 915 specify specific algorithms for routers to use in deciding when to 916 drop or mark packets before buffer overflow. 918 A router that wishes to terminate the Quick-Start Request SHOULD 919 delete the Quick-Start Request from the IP header. This saves 920 resources because downstream routers will have no option to process. 921 If a Quick-Start-capable router wishes to deny the request but 922 doesn't delete the Quick-Start Request from the IP header, then the 923 router SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. 924 Zeroing the Rate Request field may be more efficient for routers to 925 implement than deleting the Quick-Start option. As suggested in 926 [B05], future additions to Quick-Start could define error codes for 927 routers to insert into the QS Nonce field to report back to the 928 sender the reason that the Quick-Start request was denied, e.g., 929 that the router is denying all Quick-Start requests at this time, or 930 that this router as a matter of policy does not grant Quick-Start 931 requests. A router that doesn't understand the Quick-Start option 932 will simply forward the packet with the Quick-Start Request 933 unchanged (ensuring that the TTL Diff will not match and Quick-Start 934 will not be used). 936 If the participating router has decided to approve the Quick-Start 937 Request, it does the following: 939 * The router MUST decrement the QS TTL by the amount the IP TTL is 940 decremented (usually one). 942 * If the router is only willing to approve a Rate Request less than 943 that in the Quick-Start Request, then the router replaces the Rate 944 Request with a smaller value. The router MUST NOT increase the Rate 945 Request in the Quick-Start Request. If the router decreases the 946 Rate Request, the router MUST also modify the QS Nonce, as described 947 in Section 3.4. 949 * In IPv4, the router MUST update the IP header checksum. 951 If the router approves the Quick-Start request, this approval SHOULD 952 be taken into account in the router's decision to accept or reject 953 subsequent Quick-Start requests (e.g., using a variable that tracks 954 the recent aggregate of accepted Quick-Start requests). This 955 consideration of earlier approved Quick-Start request is necessary 956 to ensure that the router only approves a Quick-Start request when 957 the router judges that the output link will remain underutilized if 958 this and earlier Quick-Start requests are used by the senders. 960 In addition, the approval of a Quick-Start request SHOULD NOT be 961 used by the router to affect the treatment of the data packets that 962 arrive from this connection in the next few round-trip times. That 963 is, the approval by the router of a Quick-Start request does not 964 give differential treatment for Quick-Start data packets at that 965 router; it is only a statement from the router that the router 966 believes that the subsequent Quick-Start data packets from this 967 connection will not change the current under-utilized state of the 968 router. 970 A non-participating router forwards the Quick-Start Request 971 unchanged, without decrementing the QS TTL. The non-participating 972 router still decrements the TTL field in the IP header, as is 973 required for all routers [RFC1812]. As a result, the sender will be 974 able to detect that the Quick-Start Request had not been understood 975 or approved by all of the routers along the path. 977 A router that uses multipath routing for packets within a single 978 connection MUST NOT approve a Quick-Start request. This is 979 discussed in more detail in Section 9.2. 981 3.3.1. Processing the Report of Approved Rate 983 If the Quick-Start Option has the Function field set to "1000", then 984 this is a Report of Approved Rate, rather than a Rate Request. The 985 router MAY ignore such an option, and in any case it MUST NOT modify 986 the contents of the option for a Report of Approved Rate. However, 987 the router MAY use the Approved Rate report to check that the sender 988 is not lying about the approved rate. If the reported Approved Rate 989 is higher than the rate that the router actually approved for this 990 connection in the previous round-trip time, then the router may 991 implement some policy for cheaters. For instance, the router MAY 992 decide to deny future Quick-Start requests from this sender, 993 including, if desired, deleting Quick-Start requests from future 994 packets from this sender. Section 9.4.1 discusses misbehaving 995 senders in more detail. From the Report of Approved Rate, the 996 router can also learn if some of the downstream routers have 997 approved the Quick-Start request for a smaller rate or denied the 998 use of Quick-Start, and adjust its bandwidth allocations 999 accordingly. 1001 3.4. The QS Nonce 1003 The QS Nonce gives the Quick-Start sender some protection against 1004 receivers lying about the value of the received Rate Request. This 1005 is particularly important if the receiver knows the original value 1006 of the Rate Request (e.g., when the sender always requests the same 1007 value, and the receiver has a long history of communication with 1008 that sender). Without the QS Nonce, there is nothing to prevent the 1009 receiver from reporting back to the sender a Rate Request of K, when 1010 the received Rate Request was in fact less than K. 1012 Table 2 gives the format for the 30-bit QS Nonce. 1014 Bits Purpose 1015 --------- ------------------ 1016 Bits 0-1: Rate 15 -> Rate 14 1017 Bits 2-3: Rate 14 -> Rate 13 1018 Bits 4-5: Rate 13 -> Rate 12 1019 Bits 6-7: Rate 12 -> Rate 11 1020 Bits 8-9: Rate 11 -> Rate 10 1021 Bits 10-11: Rate 10 -> Rate 9 1022 Bits 12-13: Rate 9 -> Rate 8 1023 Bits 14-15: Rate 8 -> Rate 7 1024 Bits 16-17: Rate 7 -> Rate 6 1025 Bits 18-19: Rate 6 -> Rate 5 1026 Bits 20-21: Rate 5 -> Rate 4 1027 Bits 22-23: Rate 4 -> Rate 3 1028 Bits 24-25: Rate 3 -> Rate 2 1029 Bits 26-27: Rate 2 -> Rate 1 1030 Bits 28-29: Rate 1 -> Rate 0 1032 Table 2: The QS Nonce. 1034 The transport sender MUST initialize the QS Nonce to a random value. 1035 If the router reduces the Rate Request from rate K to rate K-1, then 1036 the router MUST set the field in the QS Nonce for "Rate K -> Rate 1037 K-1" to a new random value. Similarly, if the router reduces the 1038 Rate Request by N steps, the router MUST set the 2N bits in the 1039 relevant fields in the QS Nonce to a new random value. The receiver 1040 MUST report the QS Nonce back to the sender. 1042 If the Rate Request was not decremented in the network, then the QS 1043 Nonce should have its original value. Similarly, if the Rate 1044 Request was decremented by N steps in the network, and the receiver 1045 reports back a Rate Request of K, then the last 2K bits of the QS 1046 Nonce should have their original value. 1048 With the QS Nonce, the receiver has a 1/4 chance of cheating about 1049 each step change in the rate request. Thus, if the rate request was 1050 reduced by two steps in the network, the receiver has a 1/16 chance 1051 of successfully reporting that the original request was approved, as 1052 this requires reporting the original value for the QS nonce. 1053 Similarly, if the rate request is reduced many steps in the network, 1054 and the receiver receives a QS Option with a rate request of K, the 1055 receiver has a 1/16 chance of guessing the original values for the 1056 fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 -> 1057 Rate K". Thus, the receiver has a 1/16 chance in successfully lying 1058 and saying that the received rate request was K+2 instead of K. 1060 We note that the protection offered by the QS Nonce is the same 1061 whether one router makes all of the decrements in the rate request, 1062 or whether they are made at different routers along the path. 1064 The requirements for randomization for the sender and routers in 1065 setting `random' values in the QS Nonce are not stringent - almost 1066 any form of pseudo-random numbers would do. The requirement is that 1067 the original value for the QS Nonce is not easily guessable by the 1068 receiver, and in particular, the nonce MUST NOT be easily determined 1069 from inspection of the rest of the packet or from previous packets. 1070 In particular, the nonce MUST NOT be based only on a combination of 1071 specific packet header fields. Thus, if two bits of the QS Nonce 1072 are changed by a router along the path, the receiver should not be 1073 able to guess those two bits from the other 28 bits in the QS Nonce. 1075 An additional requirement is that the receiver cannot be able to 1076 tell, from the QS Nonce itself, which numbers in the QS Nonce were 1077 generated by the sender, and which were generated by routers along 1078 the path. This makes it harder for the receiver to infer the value 1079 of the original rate request, making it one step harder for the 1080 receiver to cheat. 1082 Section 9.4 also considers issues of receiver cheating in more 1083 detail. 1085 4. The Quick-Start Mechanisms in TCP 1087 This section describes how the Quick-Start mechanism would be used 1088 in TCP. We first sketch the procedure and then tightly define it in 1089 the subsequent subsections. 1091 If a TCP sender, say host A, would like to use Quick-Start, the TCP 1092 sender puts the requested sending rate in bits per second, 1093 appropriately formatted, in the Quick-Start option in the IP header 1094 of the TCP packet, called the Quick-Start request packet. (We will 1095 be somewhat loose in our use of "packet" vs. "segment" in this 1096 section.) When used for initial start-up, the Quick-Start request 1097 packet can be either the SYN or SYN/ACK packet, as illustrated in 1098 Figure 1. The requested rate includes an estimate for the transport 1099 and IP header overhead. The TCP receiver, say host B, returns the 1100 Quick-Start Response option in the TCP header in the responding 1101 SYN/ACK packet or ACK packet, called the Quick-Start response 1102 packet, informing host A of the results of their request. 1104 If the acknowledging packet does not contain a Quick-Start Response, 1105 or contains a Quick-Start Response with the wrong value for the TTL 1106 Diff or the QS Nonce, then host A MUST assume that its Quick-Start 1107 request failed. In this case, host A sends a Report of Approved 1108 Rate with a Rate Report of zero, and uses TCP's default congestion 1109 control procedure. For initial start-up, host A uses the default 1110 initial congestion window ([RFC2581], [RFC3390]). 1112 If the returning packet contains a valid Quick-Start Response, then 1113 host A uses the information in the response, along with its 1114 measurement of the round-trip time, to determine the Quick-Start 1115 congestion window (QS-cwnd). Quick-Start data packets are defined 1116 as data packets sent as the result of a successful Quick-Start 1117 request, up to the time when the first Quick-Start packet is 1118 acknowledged. The sender also sends a Report of Approved Rate. In 1119 order to use Quick-Start, the TCP host MUST use rate-based pacing 1120 [VH97] to transmit Quick-Start packets at the rate indicated in the 1121 Quick-Start Response, at the level of granularity possible by the 1122 sending host. We note that the limitations of interrupt timing on 1123 computers can limit the ability of the TCP host in rate-pacing the 1124 outgoing packets. 1126 The two TCP end-hosts can independently decide whether to request 1127 Quick-Start. For example, host A could sent a Quick-Start Request 1128 in the SYN packet, and host B could also send a Quick-Start Request 1129 in the SYN/ACK packet. 1131 4.1. Sending the Quick-Start Request 1133 When sending a Quick-Start Request, the TCP sender SHOULD send the 1134 request on a packet that requires an acknowledgement, such as a SYN, 1135 SYN/ACK, or data packet. In this case, if the packet is 1136 acknowledged but no Quick-Start Response is included, then the 1137 sender knows that the Quick-Start request has been denied, and can 1138 send a Report of Approved Rate. 1140 In addition to the use of Quick-Start when a connection is 1141 established, there are several additional points in a connection 1142 when a transport protocol may want to issue a Rate Request. We 1143 first re-iterate the notion that Quick-Start is a coarse-grained 1144 mechanism. That is, Quick-Start's Rate Requests are not meant to be 1145 used for fine-grained control of the transport's sending rate. 1146 Rather, the transport MAY issue a Rate Request when no information 1147 about the appropriate sending rate is available and the default 1148 congestion control mechanisms might be significantly underestimating 1149 the appropriate sending rate. 1151 The following are potential points where Quick-Start may be useful: 1153 (1) At or soon after connection initiation, when the transport 1154 has no idea of the capacity of the network path, as discussed 1155 above. (A transport that uses TCP Control Block sharing 1156 [RFC2140], the Congestion Manager [RFC3124], or other mechanisms 1157 for sharing congestion information may not need Quick-Start to 1158 determine an appropriate rate.) 1160 (2) After an idle period when the transport no longer has a 1161 validated estimate of the available bandwidth for this flow. 1162 (An example could be a persistent-HTTP connection when a new 1163 HTTP request is received after an idle period.) 1165 (3) After a host has received explicit indications that one of 1166 the endpoints has moved its point of network attachment. This 1167 can happen due to some underlying mobility mechanism like Mobile 1168 IP ([RFC3344], [RFC3775]). Some transports, such as SCTP 1169 [RFC2960], may associate with multiple IP addresses and can 1170 switch addresses (and, therefore network paths) in mid- 1171 connection. If the transport has concrete knowledge of a 1172 changing network path then the current sending rate may not be 1173 appropriate and the transport sender may use Quick-Start to 1174 probe the network to see if it can send at a higher rate. 1175 (Alternatively, traditional slow-start should be used in this 1176 case when Quick-Start is not available.) 1178 (4) After an application-limited period when the sender has been 1179 using only a small amount of its appropriate share of the 1180 network capacity, and has no valid estimate for its fair share. 1181 In this case, Quick-Start may be an appropriate mechanism to 1182 determine if the sender can send at a higher rate. For 1183 instance, consider an application that steadily exchanges low- 1184 rate control messages and suddenly needs to transmit a large 1185 amount of data. 1187 Of the above, this document recommends that a TCP sender MAY attempt 1188 to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that 1189 a TCP sender use Quick-Start for case (3) at the current time. Case 1190 (3) requires external notifications not presently defined for TCP or 1191 other transport protocols. Finally, a TCP SHOULD NOT use Quick- 1192 Start for case (4) at the current time. Case (4) requires further 1193 thought and investigation with regard to how the transport protocol 1194 could determine it was in a situation that would warrant 1195 transmitting a Quick-Start Request. 1197 As a general guideline, a TCP sender SHOULD NOT request a sending 1198 rate larger than it is able to use over the next round-trip time of 1199 the connection (or over 100 ms, if the round-trip time is not 1200 known), except as required to round up the desired sending rate to 1201 the next-highest allowable request. 1203 In any circumstances, the sender MUST NOT make a QS request if it 1204 has made a QS request within the most recent round-trip time. 1206 Section 4.7 discusses some of the issues of using Quick-Start at 1207 connection initiation, and Section 4.8 discusses issues that arise 1208 when Quick-Start is used to request a larger sending rate after an 1209 idle period. 1211 4.2. The Quick-Start Response Option in the TCP header 1213 In order to approve the use of Quick-Start, the TCP receiver 1214 responds to the receipt of a Quick-Start Request with a Quick-Start 1215 Response, using the Quick-Start Response Option in the TCP header. 1216 TCP's Quick-Start Response option is defined as follows: 1218 0 1 2 3 1219 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 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Kind | Length=8 | Resv. | Rate | TTL Diff | 1222 | | | |Request| | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | QS Nonce | R | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Figure 5. The Quick-Start Response option in the TCP header. 1229 The first byte of the Quick-Start Response option contains the 1230 option kind, identifying the TCP option (to be assigned by IANA). 1232 The second byte of the Quick-Start Response option contains the 1233 option length in bytes. The length field MUST be set to 8 bytes. 1235 The third byte of the Quick-Start Response option contains a four- 1236 bit Reserved field, and the four-bit allowed Rate Request, formatted 1237 as in the Quick-Start Rate Request option. 1239 The fourth byte of the TCP option contains the TTL Diff. The TTL 1240 Diff contains the difference between the IP TTL and QS TTL fields in 1241 the received Quick-Start request packet, as calculated in equations 1242 (1) or (2) (depending on whether IPv4 or IPv6 is used). 1244 Bytes 5-8 of the TCP option contain the 30-bit QS Nonce and a two- 1245 bit Reserved field. 1247 We note that while there are limitations on the potential size of 1248 the Quick-Start Response Option, a Quick-Start Response Option of 1249 eight bytes should not be a problem. The TCP Options field can 1250 contain up to 40 bytes. Other TCP options that might be used in a 1251 SYN or SYN/ACK packet include Maximum Segment Size (four bytes), 1252 Time Stamp (ten bytes), Window Scale (three bytes), and Selective 1253 Acknowledgments Permitted (two bytes). 1255 4.3. TCP: Sending the Quick-Start Response 1257 An end host, say host B, that receives an IP packet containing a 1258 Quick-Start Request passes the Quick-Start Request, along with the 1259 value in the IP TTL field, to the receiving TCP layer. 1261 If the TCP host is willing to permit the Quick-Start Request, then a 1262 Quick-Start Response option is included in the TCP header of the 1263 corresponding acknowledgement packet. The Rate Request in the 1264 Quick-Start Response option is set to the received value of the Rate 1265 Request in the Quick-Start option, or to a lower value if the TCP 1266 receiver is only willing to allow a lower Rate Request. The TTL 1267 Diff in the Quick-Start Response is set to the difference between 1268 the IP TTL value and the QS TTL value as given in equation (1) or 1269 (2) (depending on whether IPv4 or IPv6 is used). The QS Nonce in 1270 the Response is set to the received value of the QS Nonce in the 1271 Quick-Start option. 1273 If an end host receives an IP packet with a Quick-Start Request with 1274 a rate request of zero, then that host SHOULD NOT send a Quick-Start 1275 Response. 1277 The Quick-Start Response MUST NOT be resent if it is lost in the 1278 network. Packet loss could be an indication of congestion on the 1279 return path, in which case it is better not to approve the Quick- 1280 Start Request. 1282 4.4. TCP: Receiving and Using the Quick-Start Response Packet 1284 A TCP host, say TCP host A, that sent a Quick-Start Request and 1285 receives a Quick-Start Response in an acknowledgement first checks 1286 that the Quick-Start Response is valid. The Quick-Start Response is 1287 valid if it contains the correct value for the TTL Diff, and an 1288 equal or lesser value for the Rate Request than that transmitted in 1289 the Quick-Start Request. In addition, if the received Rate Request 1290 is K, then the rightmost 2K bits of the QS Nonce must match those 1291 bits in the QS Nonce sent in the Quick-Start Request. If these 1292 checks are not successful, then the Quick-Start request failed, and 1293 the TCP host MUST use the default TCP congestion window that it 1294 would have used without Quick-Start. If the rightmost 2K bits of 1295 the QS Nonce do not match those bits in the QS Nonce sent in the 1296 Quick-Start Request, for a received Rate Request of K, then the TCP 1297 host MUST NOT send additional Quick-Start requests during the life 1298 of the connection. Whether the Quick-Start request was successful 1299 or not, the host receiving the Quick-Start Response MUST send a 1300 Report of Approved Rate. Similarly, if the packet containing the 1301 Quick-Start Request is acknowledged, but the acknowledgement does 1302 not include a Quick-Start Response, then the sender MUST send a 1303 Report of Approved Rate. 1305 If the checks of the TTL Diff and the Rate Request are successful, 1306 and the TCP host is going to use the Quick-Start Request, it MUST 1307 start using it within one round-trip time of receiving the Quick- 1308 Start Response, or within three seconds, whichever is smaller. To 1309 use the Quick-Start Request, the host sets its Quick-Start 1310 congestion window (in terms of MSS-sized segments), QS-cwnd, as 1311 follows: 1313 QS-cwnd = (R * T) / (MSS + H) (3) 1315 where R the Rate Request in bytes per second, T the measured round- 1316 trip time in seconds, and H the estimated TCP/IP header size in 1317 bytes (e.g., 40 bytes). 1319 Derivation: the sender is allowed to transmit at R bytes per second 1320 including packet headers, but only R*MSS/(MSS+H) bytes per second, 1321 or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of 1322 application data. 1324 The TCP host SHOULD set its congestion window cwnd to QS-cwnd only 1325 if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. If 1326 QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start 1327 mode, and while in Quick-Start mode the TCP sender MUST use rate- 1328 based pacing to pace out Quick-Start packets at the approved rate. 1329 If, during Quick-Start mode, the TCP sender receives ACKs for 1330 packets sent before this Quick-Start mode was entered, these ACKs 1331 are processed as usual, following the default congestion control 1332 mechanisms. Quick-Start mode ends when the TCP host receives an ACK 1333 for one of the Quick-Start packets. 1335 If the congestion window has not been fully used when the first ack 1336 arrives ending the Quick-Start mode, then the congestion window is 1337 decreased to the amount that has actually been used so far. This is 1338 necessary because when the Quick-Start Response is received, the TCP 1339 sender's round-trip-time estimate might be longer than for 1340 succeeding round-trip times, e.g., because of delays at routers 1341 processing the IP Quick-Start option, or because of delays at the 1342 receiver in responding to the Quick-Start Request packet. In this 1343 case, an overly-large round-trip-time estimate could have caused the 1344 TCP sender to translate the approved Quick-Start sending rate in 1345 bytes per second into a congestion window that is larger than 1346 needed, with the TCP sender receiving an ACK for the first Quick- 1347 Start packet before the entire congestion window has been used. 1348 Thus, when the TCP sender receives the first ACK for a Quick-Start 1349 packet, the sender MUST reduce the congestion window to the amount 1350 that has actually been used. 1352 As an example, a TCP sender with an approved Quick-Start request of 1353 R KBps, B-byte packets including headers, and an RTT estimate of T 1354 seconds, would translate the Rate Request of R KBps to a congestion 1355 window of R*T/B packets. The TCP sender would send the Quick-Start 1356 packets rate-paced at R KBps. However, if the actual current round- 1357 trip time was T/2 seconds instead of T seconds, then the sender 1358 would begin to receive acknowledgements for Quick-Start packets 1359 after T/2 seconds. Following the paragraph above, the TCP sender 1360 would then reduce its congestion window from R*T/B to approximately 1361 R*T/(B*2) packets, the actual number of packets that were needed to 1362 fill the pipe at a sending rate of R KBps. (Note: this is just an 1363 illustration and that the congestion window is actually set to the 1364 amount of data sent before the ACK arrives and not based on 1365 equations above.) 1367 After Quick-Start mode is exited and the congestion window adjusted 1368 if necessary, the TCP sender returns to using the default congestion 1369 control mechanisms, processing further incoming ACK packets as 1370 specified by those congestion control mechanisms. For example, if 1371 the TCP sender was in slow-start prior to the Quick-Start request, 1372 and no packets were lost or marked since that time, then the sender 1373 continues in slow-start after exiting Quick-Start mode, as allowed 1374 by ssthresh. 1376 To add robustness, the TCP sender MUST use Limited Slow-Start 1377 [RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP 1378 sender limits the number of packets by which the congestion window 1379 is increased for one window of data during slow-start. 1381 When Quick-Start is used at the beginning of a connection, before 1382 any packet marks or losses have been reported, the TCP host MAY use 1383 the reported Rate Request to set the slow-start threshold to a 1384 desired value, e.g., to some small multiple of the congestion 1385 window. A possible future research topic is how the sender might 1386 modify the show-start threshold at the beginning of a connection to 1387 avoid overshooting the path capacity. (The initial value of 1388 ssthresh is allowed to be arbitrarily high, and some TCP 1389 implementations use the size of the advertised window for ssthresh 1390 [RFC2581].) 1392 4.5. TCP: Controlling Acknowledgement Traffic on the Reverse Path 1394 When a Quick-Start Request is approved for a TCP sender, the 1395 resulting Quick-Start data traffic can result in a sudden increase 1396 in traffic for pure ACK packets on the reverse path. For example, 1397 for the largest Quick-Start request of 1.3 Gbps, given a TCP sender 1398 with 1500-byte packets and a TCP receiver with delayed 1399 acknowledgements acking every other packet, this could result in 1400 17.3 Mbps of acknowledgement traffic on the reverse path. 1402 One possibility, in cases with large Quick-Start requests, would be 1403 for TCP receivers to send Quick-Start requests to request bandwidth 1404 for the acknowledgement traffic on the reverse path. However, in 1405 our view, a better approach would be for TCP receivers to simply 1406 control the rate of sending acknowledgement traffic. The optimal 1407 future solution would involve the explicit use of congestion control 1408 for TCP acknowledgement traffic, as is done now for the 1409 acknowledgement traffic in DCCP's CCID2 [RFC4341]. 1411 In the absence of congestion control for acknowledgement traffic, 1412 the TCP receiver could limit its sending rate for ACK packets sent 1413 in response to Quick-Start data packets. The following information 1414 is needed by the TCP receiver: 1416 * The RTT: TCP naturally measures the RTT of the path and therefore 1417 should have a sample of the RTT. If the TCP receiver does not 1418 have a measurement of the round-trip time, it can use the time 1419 between the receipt of the Quick-Start Request and the Quick-Start 1420 Response packets. 1422 * The Approved Rate Request (R): When the TCP receiver receives the 1423 Quick-Start Response packet, the receiver knows the value of the 1424 approved Rate Request. 1426 * The MSS: TCP advertises the MSS during the initial three-way 1427 handshake and therefore the receiver should have an understanding 1428 of the packet size the sender will be using. If the receiver does 1429 not have such an understanding or wishes to confirm the negotiated 1430 MSS, the size of the first data packet can be used. 1432 With this set of information the TCP receiver can restrict its 1433 sending rate for pure acknowledgment traffic to at most 100 pure ACK 1434 packets per RTT by sending at most one ACK for every K data packets, 1435 for the ACK Ratio K set to R*RTT/(100*8*MSS). The receiver would 1436 acknowledge the first Quick-Start data packet, and every succeeding 1437 K data packets. Thus, for a somewhat extreme case of R=1.3 Gbps, 1438 RTT=0.2 seconds, and MSS=1500 bytes, K would be set to 216, and the 1439 receiver would acknowledge every 216 data packets. From [RFC2581], 1440 the ACK Ratio K should have a minimum value of two. When the ACK 1441 Ratio is greater than two, and the TCP sender receives 1442 acknowledgements each acknowledging more than two data packets, the 1443 TCP sender may want to use rate-based pacing to control the 1444 burstiness of its outgoing data traffic. 1446 In the absence of explicit congestion control mechanisms, the TCP 1447 end nodes cannot determine the packet drop rate for pure 1448 acknowledgement traffic. This is true with or without Quick-Start. 1449 However, the TCP receiver could limit its increase in the sending 1450 rate for pure ACK packets by at most doubling the sending rate for 1451 pure ACK packets from one round-trip time to the next. The TCP 1452 receiver would do this by halving the ACK Ratio each round-trip 1453 time. 1455 Note that the above is one particular mechanism that could be used 1456 to control the ACK stream. Future work that investigates this 1457 scheme and others in detail is encouraged. 1459 4.6. TCP: Responding to a Loss of a Quick-Start Packet 1461 For TCP, we have defined a ``Quick-Start packet'' as one of the 1462 packets sent in the window immediately following a successful Quick- 1463 Start request. After detecting the loss or ECN-marking of a Quick- 1464 Start packet, TCP MUST revert to the default congestion control 1465 procedures that would have been used if the Quick-Start request had 1466 not been approved. For example, if Quick-Start is used for setting 1467 the initial window, and a packet from the initial window is lost or 1468 marked, then the TCP sender MUST then slow-start with the default 1469 initial window that would have been used if Quick-Start had not been 1470 used. In addition to reverting to the default congestion control 1471 mechanisms, the sender MUST take into account that the Quick-Start 1472 congestion window was too large. Thus, the sender SHOULD decrease 1473 ssthresh to at most half the number of Quick-Start packets that were 1474 successfully transmitted. Section B.5 discusses possible 1475 alternatives in responding to the loss of a Quick-Start packet. 1477 If a Quick-Start packet is lost or ECN-marked, then the sender 1478 SHOULD NOT make future Quick-Start requests for this connection. 1480 We note that ECN [RFC3168] MAY be used with Quick-Start. As is 1481 always the case with ECN, the sender's congestion control response 1482 to an ECN-marked Quick-Start packet is the same as the response to a 1483 dropped Quick-Start packet, thus reverting to slow start in the case 1484 of Quick-Start packets marked as experiencing congestion. 1486 4.7. TCP: A Quick-Start Request for a Larger Initial Window 1488 Some of the issues of using Quick-Start are related to the specific 1489 scenario in which Quick-Start is used. This section discusses the 1490 following issues that arise when Quick-Start is used by TCP to 1491 request a larger initial window: (1) interactions with Path MTU 1492 Discovery (PMTUD); and (2) Quick-Start request packets that are 1493 discarded by middleboxes. 1495 4.7.1. Interactions with Path MTU Discovery 1497 One issue when Quick-Start is used to request a large initial window 1498 concerns the interactions between the large initial window and Path 1499 MTU Discovery. Some of the issues are discussed in RFC 3390: 1501 "When larger initial windows are implemented along with Path MTU 1502 Discovery [RFC1191], alternatives are to set the "Don't 1503 Fragment" (DF) bit in all segments in the initial window, or to 1504 set the "Don't Fragment" (DF) bit in one of the segments. It is 1505 an open question as to which of these two alternatives is best." 1507 If the sender knows the Path MTU when the initial window is sent 1508 (e.g., from a PMTUD cache or from some other IETF-approved method), 1509 then the sender SHOULD use that MTU for segments in the initial 1510 window. Unfortunately, the sender doesn't necessarily know the Path 1511 MTU when it sends packets in the initial window. In this case, the 1512 sender should be conservative in the packet size used. Sending a 1513 large number of overly-large packets with the DF bit set is not 1514 desirable, but sending a large number of packets that are fragmented 1515 in the network can be equally undesirable. 1517 If the sender doesn't know the Path MTU when the initial window is 1518 sent, the sender SHOULD send one large packet in the initial window 1519 with the DF bit set, and send the remaining packets in the initial 1520 window with a smaller MTU of 576 bytes (or 1280 bytes with IPv6). 1522 A second possibility would be for the sender to delay sending the 1523 Quick-Start Request for one round-trip time, sending the Quick-Start 1524 Request with the first window of data while also doing Path MTU 1525 Discovery. 1527 The sender may be using an iterative approach such as Packetization 1528 Layer Path MTU Discovery (PLPMTUD) [MH06] for Path MTU Discovery, 1529 where the sender tests successively larger MTUs. If a probe is 1530 successfully delivered then the MTU can be raised to reflect the 1531 value used in that probe. We would note that PLPMTUD does not allow 1532 the sender to determine the Path MTU before sending the initial 1533 window of data. 1535 4.7.2. Quick-Start Request Packets that are Discarded by Routers or 1536 Middleboxes 1538 It is always possible for a TCP SYN packet carrying a Quick-Start 1539 request to be dropped in the network due to congestion, or to be 1540 blocked due to interactions with routers or middleboxes, where a 1541 middlebox is defined as any intermediary box performing functions 1542 apart from normal, standard functions of an IP router on the data 1543 path between a source host and destination host [RFC3234]. 1544 Measurement studies of interactions between transport protocols and 1545 middleboxes [MAF04] show that for 70% of the web servers 1546 investigated, no connection is established if the TCP SYN packet 1547 contains an unknown IP option (and for 43% of the web servers, no 1548 connection is established if the TCP SYN packet contains an IP 1549 TimeStamp Option). In both cases, this is presumably due to routers 1550 or middleboxes along that path. 1552 If the TCP sender doesn't receive a response to the SYN or SYN/ACK 1553 packet containing the Quick-Start Request, then the TCP sender 1554 SHOULD resend the SYN or SYN/ACK packet without the Quick-Start 1555 Request. Similarly, if the TCP sender receives a TCP reset in 1556 response to the SYN or SYN/ACK packet containing the Quick-Start 1557 Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet 1558 without the Quick-Start Request [RFC3360]. 1560 RFC 1122 and 2988 specify that the sender should set the initial RTO 1561 to three seconds, though many TCP implementations set the initial 1562 RTO to one second. For a TCP SYN packet sent with a Quick-Start 1563 request, the TCP sender SHOULD use an initial RTO of three seconds. 1565 We note that if the TCP SYN packet is using the IP Quick-Start 1566 Option for a Quick-Start request, and it is also using bits in the 1567 TCP header to negotiate ECN-capability with the TCP host at the 1568 other end, then the drop of a TCP SYN packet could be due to 1569 congestion, to a router or middlebox dropping the packet because of 1570 the IP Option, or because of a router or middlebox dropping the 1571 packet because of the information in the TCP header negotiating ECN. 1572 In this case, the sender could resend the dropped packet without 1573 either the Quick-Start or the ECN requests. Alternately, the sender 1574 could resend the dropped packet with only the ECN request in the TCP 1575 header, resending the TCP SYN packet without either the Quick-Start 1576 or the ECN requests if the second TCP SYN packet is dropped. The 1577 second choice seems reasonable, given that a TCP SYN packet today is 1578 more likely to be blocked due to policies that discard packets with 1579 IP Options than due to policies that discard packets with ECN 1580 requests in the TCP header [MAF04]. 1582 4.8. TCP: A Quick-Start Request in the Middle of a Connection 1584 This section discusses the following issues that arise when Quick- 1585 Start is used by TCP to request a larger window in the middle of a 1586 connection, such as after an idle period: (1) determining the rate 1587 to request; (2) when to make a request; and (3) the response if 1588 Quick-Start packets are dropped; 1590 (1) Determining the rate to request: 1591 For a connection that has not yet had a congestion event (that is, a 1592 marked or dropped packet), the TCP sender is not restricted in the 1593 rate that it requests. As an example, a server might wait and send 1594 a Quick-Start request after a short interaction with the client. 1596 To use a Quick-Start Request in a connection that has already 1597 experienced a congestion event, and that has not had a recent 1598 mobility event, the TCP sender can determine the largest congestion 1599 window that the TCP connection achieved since the last packet drop 1600 and translate this to a sending rate to get the maximum allowed 1601 request rate. If the request is granted, then the sender 1602 essentially restarts with its old congestion window from before it 1603 was reduced, for example during an idle period. 1605 A Quick-Start Request sent in the middle of a TCP connection SHOULD 1606 be sent on a data packet. 1608 (2) When to make a request: 1609 A TCP connection MAY make a Quick-Start request before the 1610 connection has experienced a congestion event, or after an idle 1611 period of at least one RTO. 1613 (3) Response if Quick-Start packets are dropped: 1614 If Quick-Start packets are dropped in the middle of connection, then 1615 the sender MUST revert to half of the Quick-Start window, or to the 1616 congestion window that the sender would have used if the Quick-Start 1617 request had not been approved, whichever is smaller. 1619 4.9. An Example Quick-Start Scenario with TCP 1621 The following is an example scenario in the case when both hosts 1622 request Quick-Start for setting their initial windows. This is 1623 similar to Figures 1 and 2 in Section 2.1, except that it 1624 illustrates a TCP connection with both TCP hosts sending Quick-Start 1625 Requests. 1627 * The TCP SYN packet from Host A contains a Quick-Start Request in 1628 the IP header. 1630 * Routers along the forward path modify the Quick-Start Request as 1631 appropriate. 1633 * Host B receives the Quick-Start Request in the SYN packet, and 1634 calculates the TTL Diff. If Host B approves the Quick-Start 1635 Request, then Host B sends a Quick-Start Response in the TCP header 1636 of the SYN/ACK packet. Host B also sends a Quick-Start Request in 1637 the IP header of the SYN/ACK packet. 1639 * Routers along the reverse path modify the Quick-Start Request as 1640 appropriate. 1642 * Host A receives the Quick-Start Response in the SYN/ACK packet, 1643 and checks the TTL Diff, Rate Request, and QS Nonce for validity. 1644 If they are valid, then Host A sets its initial congestion window 1645 appropriately, and sets up rate-based pacing to be used with the 1646 initial window. If the Quick-Start Response is not valid, then Host 1647 A uses TCP's default initial window. In either case, Host A sends a 1648 Report of Approved Rate. 1650 Host A also calculates the TTL Diff for the Quick-Start Request in 1651 the incoming SYN/ACK packet, and sends a Quick-Start Response in the 1652 TCP header of the ACK packet. 1654 * Host B receives the Quick-Start Response in an ACK packet, and 1655 checks the TTL Diff, Rate Request, and QS Nonce for validity. If 1656 the Quick-Start Response is valid, then Host B sets its initial 1657 congestion window appropriately, and sets up rate-based pacing to be 1658 used with its initial window. If the Quick-Start Response is not 1659 valid, then Host B uses TCP's default initial window. In either 1660 case, Host B sends a Report of Approved Rate. 1662 5. Quick-Start and IPsec AH 1664 This section shows that Quick-Start is compatible with IPsec AH 1665 (Authentication Header). AH uses an Integrity Check Value (ICV) in 1666 the IPsec Authentication Header to verify both message 1667 authentication and integrity ([RFC2402], [RFC4302]). Changes to the 1668 Quick-Start option in the IP header do not affect this AH ICV. The 1669 tunnel considerations in Section 6 below apply to all IPsec tunnels, 1670 regardless of what IPsec headers or processing are used in 1671 conjunction with the tunnel. 1673 Because the contents of the Quick-Start option can change along the 1674 path, it is important that these changes not affect the IPsec 1675 Authentication Header Integrity Check Value (AH ICV). For IPv4, RFC 1676 2402 requires that unrecognized IPv4 options be zeroed for AH ICV 1677 computation purposes, so Quick-Start IP Option data changing en 1678 route does not cause problems with existing IPsec AH implementations 1679 for IPv4. If the Quick-Start option is recognized, it MUST be 1680 treated as a mutable IPv4 option, and hence be completely zeroed for 1681 AH ICV calculation purposes. IPv6 option numbers explicitly 1682 indicate whether the option is mutable; the 3rd highest order bit in 1683 the IANA-allocated option type has the value 1 to indicate that the 1684 Quick-Start option data can change en route. RFC 2402 requires that 1685 the option data of any such option be zeroed for AH ICV computation 1686 purposes. Therefore changes to the Quick-Start option in the IP 1687 header do not affect the calculation of the AH ICV. 1689 6. Quick-Start in IP Tunnels and MPLS 1691 This section considers interactions between Quick-Start and IP 1692 tunnels, including IPsec ([RFC2401], [RFC4301]), IP in IP [RFC2003], 1693 GRE [RFC2784], and others. This section also considers interactions 1694 between Quick-Start and MPLS [RFC3031]. 1696 In the discussion, we use TTL Diff, defined earlier as the 1697 difference between the IP TTL and the Quick-Start TTL, mod 256. 1698 Recall that the sender considers the Quick-Start request approved 1699 only if the value of TTL Diff for the packet entering the network is 1700 the same as the value of TTL Diff for the packet exiting the 1701 network. 1703 Simple tunnels: IP tunnel modes are generally based on adding a new 1704 "outer" IP header that encapsulates the original or "inner" IP 1705 header and its associated packet. In many cases, the new "outer" IP 1706 header may be added and removed at intermediate points along a path, 1707 enabling the network to establish a tunnel without requiring 1708 endpoint participation. We denote tunnels that specify that the 1709 outer header be discarded at tunnel egress as "simple tunnels", and 1710 we denote tunnels where the egress saves and uses information from 1711 the outer header before discarding it as "non-simple tunnels". An 1712 example of a "non-simple tunnel" would be a tunnel configured to 1713 support ECN, where the egress router might copy the ECN codepoint in 1714 the outer header to the inner header before discarding the outer 1715 header [RFC3168]. 1717 __ Tunnels Compatible with Quick-Start 1718 / 1719 Simple Tunnels __/ 1720 \ 1721 \__ Tunnels Not Compatible with Quick-Start 1722 (False Positives!) 1724 __ Tunnels Supporting Quick-Start 1725 / 1726 / 1727 Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start, 1728 \ but Not Supporting Quick-Start 1729 \ 1730 \__ Tunnels Not Compatible with Quick-Start? 1732 Figure 6: Categories of Tunnels. 1734 Tunnels that are compatible with Quick-Start: We say that an IP 1735 tunnel `is not compatible with Quick-Start' if the use of a Quick- 1736 Start Request over such a tunnel allows false positives, where the 1737 TCP sender incorrectly believes that the Quick-Start Request was 1738 approved by all routers along the path. If the use of Quick-Start 1739 over the tunnel does not cause false positives, we say that the IP 1740 tunnel `is compatible with Quick-Start'. 1742 If the IP TTL of the inner header is decremented during forwarding 1743 before tunnel encapsulation takes place, then the simple tunnel is 1744 compatible with Quick-Start, with Quick-Start requests being 1745 rejected. Section 6.1 describes in more detail the ways that a 1746 simple tunnel can be compatible with Quick-Start. 1748 There are some simple tunnels that are not compatible with Quick- 1749 Start, allowing `false positives' where the TCP sender incorrectly 1750 believes that the Quick-Start Request was approved by all routers 1751 along the path. This is discussed in Section 6.2 below. 1753 One of our tasks in the future will be to investigate the occurrence 1754 of tunnels that are not compatible with Quick-Start, and to track 1755 the extent to which such tunnels are modified over time. The 1756 evaluation of the problem of false positives from tunnels that are 1757 not compatible with Quick-Start will affect the progression of 1758 Quick-Start from Experimental to Proposed Standard, and will affect 1759 the degree of deployment of Quick-Start while in Experimental mode. 1761 Tunnels that support Quick-Start: We say that an IP tunnel `supports 1762 Quick-Start' if it allows routers along the tunnel path to process 1763 the Quick-Start Request and give feedback, resulting in the 1764 appropriate possible acceptance of the Quick-Start request. Some 1765 tunnels that are compatible with Quick-Start support Quick-Start, 1766 while others do not. We note that a simple tunnel is not able to 1767 support Quick-Start. 1769 From a security point of view, the use of Quick-Start in the outer 1770 header of an IP tunnel might raise security concerns because an 1771 adversary could tamper with the Quick-Start information that 1772 propagates beyond the tunnel endpoint, or because the Quick-Start 1773 Option exposes information to network scanners. Our approach is to 1774 make supporting Quick-Start an option for IP tunnels. That is, in 1775 environments or tunneling protocols where the risks of using Quick- 1776 Start are judged to outweigh its benefits, the tunnel can simply 1777 delete the Quick-Start option or zero the Quick-Start rate request 1778 and QS TTL fields before encapsulation. The result is that there 1779 are two viable options for IP tunnels to be compatible with Quick- 1780 Start. The first option is the simple tunnel described above and in 1781 Section 6.1, where the tunnel is compatible with Quick-Start but 1782 does not support Quick-Start, where all Quick-Start requests along 1783 the path will be rejected. The second approach is a Quick-Start- 1784 capable mode, described in Section 6.3, where the tunnel actively 1785 supports Quick-Start. 1787 6.1. Simple Tunnels That Are Compatible with Quick-Start 1789 This section describes the ways that a simple tunnel can be 1790 compatible with Quick-Start but not support Quick-Start, resulting 1791 in the rejection of all Quick-Start requests that traverse the 1792 tunnel. 1794 If the tunnel ingress for the simple tunnel is at a router, the IP 1795 TTL of the inner header is generally decremented during forwarding 1796 before tunnel encapsulation takes place. In this case TTL Diff will 1797 be changed, correctly causing the Quick-Start request to be 1798 rejected. For a simple tunnel it is preferable if the Quick-Start 1799 Request is not copied to the outer header, saving the routers within 1800 the tunnel from unnecessarily processing the Quick-Start request. 1802 However, the Quick-Start request will be rejected correctly in this 1803 case whether or not the Quick-Start Request is copied to the outer 1804 header. 1806 6.1.1. Simple Tunnels that are Aware of Quick-Start 1808 If a tunnel ingress is aware of Quick-Start, but does not want to 1809 support Quick-Start, then the tunnel ingress MUST either zero the 1810 Quick-Start rate request, QS TTL, and QS Nonce fields or remove the 1811 Quick-Start option from the inner header before encapsulation. 1812 Section 6.3 describes the procedures for a tunnel that does want to 1813 support Quick-Start. 1815 Deleting the Quick-Start option or zeroing the Quick-Start rate 1816 request *after decapsulation* also serves to prevent the propagation 1817 of Quick-Start information, and is compatible with Quick-Start. If 1818 the outer header does not contain a Quick-Start Request, a Quick- 1819 Start-aware tunnel egress MUST reject the inner Quick-Start Request 1820 by zeroing the Rate Request field in the inner header, or by 1821 deleting the Quick-Start option. 1823 If the tunnel ingress is at a sending host or router where the IP 1824 TTL is not decremented prior to encapsulation, and neither tunnel 1825 endpoint is aware of Quick-Start, then this allows false positives, 1826 described in the section below. 1828 6.2. Simple Tunnels That Are Not Compatible with Quick-Start 1830 Sometimes a tunnel implementation that does not support Quick-Start 1831 is independent of the TCP sender or a router implementation that 1832 supports Quick-Start. In these cases it is possible that a Quick- 1833 Start Request gets erroneously approved without the routers in the 1834 tunnel having individually approved the request, causing a false 1835 positive. 1837 If a tunnel ingress is a separate component from the TCP sender or 1838 IP forwarding, it is possible that a packet with a Quick-Start 1839 option is encapsulated without the IP TTL being decremented first, 1840 or with both IP TTL and QS TTL being decremented before the tunnel 1841 encapsulation takes place. If the tunnel ingress does not know about 1842 Quick-Start, a valid Quick-Start Request with unchanged TTL Diff 1843 traverses in the inner header, while the outer header most likely 1844 does not carry a Quick-Start Request. If the tunnel egress also 1845 does not support Quick-Start, it remains possible that the Quick- 1846 Start Request would be falsely approved, because the packet is 1847 decapsulated using the Quick-Start request from the inner header, 1848 and the value of TTL Diff echoed to the sender remains unchanged. 1849 For example, such a scenario can occur with a Bump-In-The-Stack 1850 (BITS), an IPSec encryption implementation where the data encryption 1851 occurs between the network drivers and the TCP/IP protocol stack 1852 [RFC2401]. 1854 As one example, if a remote access VPN client uses a BITS structure, 1855 then Quick-Start obstacles between the client and the VPN gateway 1856 won't be seen. This is a particular problem because the path 1857 between the client and the VPN gateway is likely to contain the most 1858 congested part of the path. Because most VPN clients are reported 1859 to use BITS [H05], we will explore this in more detail. 1861 A Bump-In-The-Wire (BITW) is an IPSec encryption implementation 1862 where the encryption occurs on an outboard processor, offloading the 1863 encryption processing overhead from the host or router [RFC2401]. 1864 The BITW device is usually IP addressable, which means that the IP 1865 TTL is decremented before the packet is passed to the BITW. If the 1866 QS TTL is not decremented, then the value of TTL Diff is changed, 1867 and the Quick-Start request will be denied. However, if the BITW 1868 supports a host and does not have its own IP address, then the IP 1869 TTL is not decremented before the packet is passed from the host to 1870 the BITW, and a false positive could occur. 1872 Other tunnels that need to be looked at are IP tunnels over non- 1873 network protocols, such as IP over TCP and IP over UDP [RFC3948], 1874 and tunnels using the Layer Two Tunneling Protocol [RFC2661]. 1876 Section 9.2 discusses the related issue of non-IP queues, such as 1877 layer-two Ethernet or ATM networks, as another instance of possible 1878 bottlenecks that do not participate in the Quick-Start feedback. 1880 6.3. Tunnels That Support Quick-Start 1882 This section discusses tunnels configured to support Quick-Start. 1884 If the tunnel ingress node chooses to locally approve the Quick- 1885 Start request, then the ingress node MUST decrement the Quick-Start 1886 TTL at the same time it decrements the IP TTL, and MUST copy IP TTL 1887 and the Quick-Start option from the inner IP header to the outer 1888 header. During encapsulation, the tunnel ingress MUST zero the 1889 Quick-Start rate request field in the inner header to ensure that 1890 the Quick-Start request will be rejected if the tunnel egress does 1891 not support Quick-Start. 1893 If the tunnel ingress node does not choose to locally approve the 1894 Quick-Start request, then it MUST either delete the Quick-Start 1895 option from the inner header before encapsulation, or zero the QS 1896 TTL and the Rate Request fields before encapsulation. 1898 Upon decapsulation, if the outer header contains a Quick-Start 1899 option, the tunnel egress MUST copy the IP TTL and the Quick-Start 1900 option from the outer IP header to the inner header. 1902 IPsec uses the IKE (Internet Key Exchange) Protocol for security 1903 associations. We do not consider the interactions between Quick- 1904 Start and IPsec with IKEv1 [RFC2409] in this document. Now that the 1905 RFC for IKEv2 [RFC4306] is published, we plan to specify a 1906 modification of IPsec to allow the support of Quick-Start to be 1907 negotiated; this modification will specify the negotiation between 1908 tunnel endpoints to allow or forbid support for Quick-Start within 1909 the tunnel. This was done for ECN for IPsec tunnels, with IKEv1 1910 [RFC3168, Section 9.2]. This negotiation of Quick-Start capability 1911 in an IPsec tunnel will be specified in a separate IPsec document. 1912 This document will also include a discussion of the potential 1913 effects of an adversary's modifications of the Quick-Start field (as 1914 in Sections 18 and 19 of RFC 3168), and of the security 1915 considerations of exposing the Quick-Start rate request to network 1916 scanners. 1918 6.4. Quick-Start and MPLS 1920 The behavior of Quick-Start with MPLS is similar to the behavior of 1921 Quick-Start with IP Tunnels. For those MPLS paths where the IP TTL 1922 is decremented as part of traversing the MPLS path, these paths are 1923 compatible with Quick-Start, but do not support Quick-Start; Quick- 1924 Start requests traversing these paths will be correctly understood 1925 by the transport sender as having been denied. Any MPLS paths where 1926 the IP TTL is not decremented as part of traversing the MPLS path 1927 would be not compatible with Quick-Start; such paths would result in 1928 false positives, where the TCP sender incorrectly believes that the 1929 Quick-Start Request was approved by all routers along the path. 1931 For cases where the ingress node to the MPLS path is aware of Quick- 1932 Start, this node should either zero the Quick-Start rate request, QS 1933 TTL, and QS Nonce fields or remove the Quick-Start option from the 1934 IP header. 1936 7. The Quick-Start Mechanism in other Transport Protocols 1938 The section earlier specified the use of Quick-Start in TCP. In 1939 this section, we generalize this to give guidelines for the use of 1940 Quick-Start with other transport protocols. We also discuss briefly 1941 how Quick-Start could be specified for other transport protocols. 1943 The general guidelines for Quick-Start in transport protocols are as 1944 follows: 1946 * Quick-Start is only specified for unicast transport protocols with 1947 appropriate congestion control mechanisms. Note: Quick-Start is not 1948 a replacement for standard congestion control techniques, but meant 1949 to augment their operation. 1951 * A transport-level mechanism is needed for the Quick-Start response 1952 from the receiver to the sender. This response contains the Rate 1953 Request, TTL Diff, and QS Nonce. 1955 * The sender checks the validity of the Quick-Start response. 1957 * The sender has an estimate of the round-trip time, and translates 1958 the Quick-Start response into an allowed window or allowed sending 1959 rate. The sender sends a Report of the Approved Rate. The sender 1960 starts sending Quick-Start packets, rate-paced out at the approved 1961 sending rate. 1963 * After the sender receives the first acknowledgement packet for a 1964 Quick-Start packet, no more Quick-Start packets are sent. The 1965 sender adjusts its current congestion window or sending rate to be 1966 consistent with the actual amount of data that was transmitted in 1967 that round-trip time. 1969 * When the last Quick-Start packet is acknowledged, the sender 1970 continues using the standard congestion control mechanisms of that 1971 protocol. 1973 * If one of the Quick-Start packets is lost, then the sender reverts 1974 to the standard congestion control method of that protocol that 1975 would have been used if the Quick-Start request had not been 1976 approved. In addition, the sender takes into account the 1977 information that the Quick-Start congestion window was too large 1978 (e.g., by decreasing ssthresh in TCP). 1980 8. Using Quick-Start 1982 8.1. Determining the Rate to Request 1984 As discussed in [SAF06], the data sender does not necessarily have 1985 information about the size of the data transfer at connection 1986 initiation; for example, in request-response protocols such as HTTP, 1987 the server doesn't know the size or name of the requested object 1988 during connection initiation. [SAF06] explores some of the 1989 performance implications of overly-large Quick-Start requests, and 1990 discusses heuristics that end-nodes could use to size their requests 1991 appropriately. For example, the sender might have information about 1992 the bandwidth of the last-mile hop, the size of the local socket 1993 buffer, or of the TCP receive window, and could use this information 1994 in determining the rate to request. Web servers that mostly have 1995 small objects to transfer might decide not to use Quick-Start at 1996 all, since Quick-Start would be of little benefit to them. 1998 Quick-Start will be more effective if Quick-Start requests are not 1999 larger than necessary; every Quick-Start request that is approved 2000 but not used (or not fully used) takes away from the bandwidth pool 2001 available for granting successive Quick-Start requests. 2003 8.2. Deciding the Permitted Rate Request at a Router 2005 In this section we briefly outline how a router might decide whether 2006 or not to approve a Quick-Start Request. The router should ask the 2007 following questions: 2009 * Has the router's output link been underutilized for some time 2010 (e.g., several seconds). 2012 * Would the output link remain underutilized if the arrival rate was 2013 to increase by the aggregate rate requests that the router has 2014 approved over the last fraction of a second? 2016 In order to answer the last question, the router must have some 2017 knowledge of the available bandwidth on the output link and of the 2018 Quick-Start bandwidth that could arrive due to recently-approved 2019 Quick-Start Requests. In this way, if an underutilized router 2020 experiences a flood of Quick-Start requests, the router can begin to 2021 deny Quick-Start requests while the output link is still 2022 underutilized. 2024 A simple way for the router to keep track of the potential bandwidth 2025 from recently-approved requests is to maintain two counters, one for 2026 the total aggregate Rate Requests that have been approved in the 2027 current time interval [T1, T2], and one for the total aggregate Rate 2028 Requests approved over a previous time interval [T0, T1]. However, 2029 this document doesn't specify router algorithms for approving Quick- 2030 Start requests, or make requirements for the appropriate time 2031 intervals for remembering the aggregate approved Quick-Start 2032 bandwidth. A possible router algorithm is given in Appendix E, and 2033 more discussion of these issues is available in [SAF06].) 2035 * If the router's output link has been underutilized and the 2036 aggregate of the Quick-Start Request Rate options granted is low 2037 enough to prevent a near-term bandwidth shortage, then the router 2038 could approve the Quick-Start Request. 2040 Section 10.2 discusses some of the implementation issues in 2041 processing Quick-Start requests at routers. [SAF06] discusses the 2042 range of possible Quick-Start algorithms at the router for deciding 2043 whether to approve a Quick-Start request. In order to explore the 2044 limits of the possible functionality at routers, [SAF06] also 2045 discusses Extreme Quick-Start mechanisms at routers, where the 2046 router would keep per-flow state concerning approved Quick-Start 2047 requests. 2049 9. Evaluation of Quick-Start 2051 9.1. Benefits of Quick-Start 2053 The main benefit of Quick-Start is the faster start-up for the 2054 transport connection itself. For a small TCP transfer of one to 2055 five packets, Quick-Start is probably of very little benefit; at 2056 best, it might shorten the connection lifetime from three to two 2057 round-trip times (including the round-trip time for connection 2058 establishment). Similarly, for a very large transfer, where the 2059 slow-start phase would have been only a small fraction of the 2060 connection lifetime, Quick-Start would be of limited benefit. 2061 Quick-Start would not significantly shorten the connection lifetime, 2062 but it might eliminate or at least shorten the start-up phase. 2063 However, for moderate-sized connections in a well-provisioned 2064 environment, Quick-Start could possibly allow the entire transfer of 2065 M packets to be completed in one round-trip time (after the initial 2066 round-trip time for the SYN exchange), instead of the log_2(M)-2 2067 round-trip times that it would normally take for the data transfer, 2068 in an uncongested environments (assuming an initial window of four 2069 packets). 2071 9.2. Costs of Quick-Start 2073 This section discusses the costs of Quick-Start for the connection 2074 and for the routers along the path. 2076 The cost of having a Quick-Start packet dropped: 2077 For the sender the biggest risk in using Quick-Start lies in the 2078 possibility of suffering from congestion-related losses of the 2079 Quick-Start packets. This should be an unlikely situation because 2080 routers are expected to approve Quick-Start Requests only when they 2081 are significantly underutilized. However, a transient increase in 2082 cross-traffic in one of the routers, a sudden decrease in available 2083 bandwidth on one of the links, or congestion at a non-IP queue could 2084 result in packet losses even when the Quick-Start Request was 2085 approved by all of the routers along the path. If a Quick-Start 2086 packet is dropped, then the sender reverts to the congestion control 2087 mechanisms it would have used if the Quick-Start request had not 2088 been approved, so the performance cost to the connection of having a 2089 Quick-Start packet dropped is small, compared to the performance 2090 without Quick-Start. (On the other hand, the performance difference 2091 between Quick-Start with a Quick-Start packet dropped and Quick- 2092 Start with no Quick-Start packet dropped can be considerable.) 2094 Added complexity at routers: 2095 The main cost of Quick-Start at routers concerns the costs of added 2096 complexity. The added complexity at the end-points is moderate, and 2097 might easily be outweighed by the benefit of Quick-Start to the end 2098 hosts. The added complexity at the routers is also somewhat 2099 moderate; it involves estimating the unused bandwidth on the output 2100 link over the last several seconds, processing the Quick-Start 2101 request, and keeping a counter of the aggregate Quick-Start rate 2102 approved over the last fraction of a second. However, this added 2103 complexity at routers adds to the development cycle, and could 2104 prevent the addition of other competing functionality to routers. 2105 Thus, careful thought would have to be given to the addition of 2106 Quick-Start to IP. 2108 The slow path in routers: 2109 Another drawback of Quick-Start is that packets containing the 2110 Quick-Start Request message might not take the fast path in routers, 2111 particularly in the beginning of Quick-Start's deployment in the 2112 Internet. This would mean some extra delay for the end hosts, and 2113 extra processing burden for the routers. However, as discussed in 2114 Sections 4.1 and 4.7, not all packets would carry the Quick-Start 2115 option. In addition, for the underutilized links where Quick-Start 2116 Requests could actually be approved, or in typical environments 2117 where most of the packets belong to large flows, the burden of the 2118 Quick-Start Option on routers would be considerably reduced. 2120 Nevertheless, it is still conceivable, in the worst case, that many 2121 packets would carry Quick-Start requests; this could slow down the 2122 processing of Quick-Start packets in routers considerably. As 2123 discussed in Section 9.6, routers can easily protect against this by 2124 enforcing a limit on the rate at which Quick-Start requests will be 2125 considered. [RW03] and [RW04] contain measurements of the impact of 2126 IP Option Processing on packet round-trip times. 2128 Multiple paths: 2129 One limitation of Quick-Start is that it presumes that the data 2130 packets of a connection will follow the same path as the Quick-Start 2131 request packet. If this is not the case, then the connection could 2132 be sending the Quick-Start packets, at the approved rate, along a 2133 path that was already congested, or that became congested as a 2134 result of this connection. Thus, Quick-Start could give poor 2135 performance when there is a routing change immediately after the 2136 Quick-Start request is approved, and the Quick-Start data packets 2137 follow a different path from that of the original Quick-Start 2138 Request. This is, however, similar to what would happen, for a 2139 connection with sufficient data, if the connection's path was 2140 changed in the middle of the connection, when the connection had 2141 already established the allowed initial rate. 2143 As specified in Section 3.3, a router that uses multipath routing 2144 for packets within a single connection must not approve a Quick- 2145 Start request. Quick-Start would not perform robustly in an 2146 environment with multipath routing, where different packets in a 2147 connection routinely follow different paths. In such an 2148 environment, the Quick-Start request and some fraction of the 2149 packets in the connection might take an underutilized path, while 2150 the rest of the packets take an alternate, congested path. 2152 Non-IP queues: 2153 A problem of any mechanism for feedback from routers at the IP level 2154 is that there can be queues and bottlenecks in the end-to-end path 2155 that are not in IP-level routers. As an example, these include 2156 queues in layer-two Ethernet or ATM networks. One possibility would 2157 be that an IP-level router adjacent to such a non-IP queue or 2158 bottleneck would be configured to reject Quick-Start requests if 2159 that was appropriate. One would hope that in general, IP networks 2160 are configured so that non-IP queues between IP routers do not end 2161 up being the congested bottlenecks. 2163 9.3. Quick-Start with QoS-enabled Traffic 2165 The discussion in this document has largely been of Quick-Start with 2166 default, best-effort traffic. However, Quick-Start could also be 2167 used by traffic using some form of differentiated services, and 2168 routers could take the traffic class into account when deciding 2169 whether or not to grant the Quick-Start request. We don't address 2170 this context further in this paper, since it is orthogonal to the 2171 specification of Quick-Start. 2173 Routers are also free to take into account their own priority 2174 classifications in processing Quick-Start requests. 2176 9.4. Protection against Misbehaving Nodes 2178 In this section we discuss the protection against senders, 2179 receivers, or colluding routers or middleboxes lying about the 2180 Quick-Start Request. 2182 9.4.1. Misbehaving Senders 2184 A transport sender could try to transmit data at a higher rate than 2185 that approved in the Quick-Start Request. The network could use a 2186 traffic policer to protect against misbehaving senders that exceed 2187 the approved rate, for example by dropping packets that exceed the 2188 allowed transmission rate. The required Report of Approved Rate 2189 allows traffic policers to check that the Report of Approved Rate 2190 does not exceed the Rate Request actually approved at that point in 2191 the network in the previous Quick-Start Request from that 2192 connection. The required Approved Rate report also allows traffic 2193 policers to check that the sender's sending rate does not exceed the 2194 rate in the Report of Approved Rate. 2196 If a router or receiver receives an Approved Rate report that is 2197 larger than the Rate Request in the Quick-Start request approved for 2198 that sender for that connection in the previous round-trip time, 2199 then the router or receiver could deny future Quick-Start requests 2200 from that sender, e.g., by deleting the Quick-Start Request from 2201 future packets from that sender. We note that routers are not 2202 required to use Approved Rate reports to check if senders are 2203 cheating; this is at the discretion of the router. 2205 If a router sees a Report of Approved Rate, and did not see an 2206 earlier Quick-Start request, then either the sender could be 2207 cheating, or the connection's path could have changed since the 2208 Quick-Start request was sent. In either case, the router could 2209 decide to deny future Quick-Start requests for this connection. In 2210 particular, it is reasonable for the router to deny a Quick-Start 2211 request if either the sender is cheating, or if the connection path 2212 suffers from path changes or multipathing. 2214 If a router approved a Quick-Start Request, but does not see a 2215 subsequent Approved Rate report, then there are several 2216 possibilities: (1) the request was denied and/or dropped downstream 2217 and the sender did not send a Report of Approved Rate; (2) the 2218 request was approved but the sender did not send a Report of 2219 Approved Rate; (3) the Approved Rate report was dropped in the 2220 network; or (4) the Approved Rate report took a different path from 2221 the Quick-Start Request. In any of these cases, the router would be 2222 justified in denying future Quick-Start Requests for this 2223 connection. 2225 In any of the cases mentioned in the three paragraphs above (i.e., 2226 an Approved Rate report that is larger than the Rate Request in the 2227 earlier Quick-Start request; a Report of Approved Rate with no 2228 preceding Rate Request, or a Rate Request with no Report of Approved 2229 Rate), a traffic policer may assume that Quick-Start is not being 2230 used appropriately, or is being used in an unsuitable environment 2231 (e.g., with multiple paths), and take some corresponding action. 2233 What are the incentives for a sender to cheat by over-sending after 2234 a Quick-Start request? Assuming that the sender's interests are 2235 measured by a performance metric such as the completion time for its 2236 connections, sometimes it might be in the sender's interests to 2237 cheat, and sometimes it might not; in some cases it could be 2238 difficult for the sender to judge whether it would be in its 2239 interests to cheat. The incentives for a sender to cheat by over- 2240 sending after a Quick-Start request are not that different from the 2241 incentives for a sender to cheat by over-sending even in the absence 2242 of Quick-Start, with one difference: the use of Quick-Start could 2243 help a sender to evade policing actions from policers in the 2244 network. The Report of Approved Rate is designed to address this, 2245 to make it harder to senders to use Quick-Start to `cover' their 2246 cheating. 2248 9.4.2. Receivers Lying about Whether the Request was Approved 2250 One form of misbehavior would be for the receiver to lie to the 2251 sender about whether the Quick-Start Request was approved, by 2252 falsely reporting the TTL Diff and QS Nonce. If a router that 2253 understands the Quick-Start Request denies the request by deleting 2254 the request or by zeroing the QS TTL and QS Nonce, then the receiver 2255 can ``lie" about whether the request was approved only by 2256 successfully guessing the value of the TTL Diff and QS Nonce to 2257 report. The chance of the receiver successfully guessing the 2258 correct value for the TTL Diff is 1/256, and the chance of the 2259 receiver successfully guessing the QS nonce for a reported rate 2260 request of K is 1/(2K). 2262 However, if the Quick-Start request is denied only by a non-Quick- 2263 Start-capable router, or by a router that is unable to zero the QS 2264 TTL and QS Nonce fields, then the receiver could lie about whether 2265 the Quick-Start Requests were approved by modifying the QS TTL in 2266 successive requests received from the same host. In particular, if 2267 the sender does not act on a Quick-Start Request, then the receiver 2268 could decrement the QS TTL by one in the next request received from 2269 that host before calculating the TTL Diff, and decrement the QS TTL 2270 by two in the following received request, until the sender acts on 2271 one of the Quick-Start Requests. 2273 Unfortunately, if a router doesn't understand Quick-Start, then it 2274 is not possible for that router to take an active step such as 2275 zeroing the QS TTL and QS Nonce to deny a request. As a result, the 2276 QS TTL is not a fail-safe mechanism for preventing lying by 2277 receivers in the case of non-Quick-Start-capable routers. 2279 What would be the incentives for a receiver to cheat in reporting on 2280 a Quick-Start request, in the absence of a mechanism such as the QS 2281 Nonce? In some cases, cheating would have been of clear benefit to 2282 the receiver, resulting in a faster completion time for the 2283 transfer. In other cases, where cheating would have resulted in 2284 Quick-Start packets being dropped in the network, cheating might or 2285 might not have improved the receiver's performance metric, depending 2286 on the details of that particular scenario. 2288 9.4.3. Receivers Lying about the Approved Rate 2290 A second form of receiver misbehavior would be for the receiver to 2291 lie to the sender about the Rate Request for an approved Quick-Start 2292 Request, by increasing the value of the Rate Request field. 2293 However, the receiver doesn't necessarily know the Rate Request in 2294 the original Quick-Start Request sent by the sender, and a higher 2295 Rate Request reported by the receiver will only be considered valid 2296 by the sender if it is no higher than the Rate Request originally 2297 requested by the sender. For example, if the sender sends a Quick- 2298 Start Request with a Rate Request of X, and the receiver reports 2299 receiving a Quick-Start Request with a Rate Request of Y > X, then 2300 the sender knows that either some router along the path 2301 malfunctioned (increasing the Rate Request inappropriately), or the 2302 receiver is lying about the Rate Request in the received packet. 2304 If the sender sends a Quick-Start Request with a Rate Request of Z, 2305 the receiver receives the Quick-Start Request with an approved Rate 2306 Request of X, and reports a Rate Request of Y, for X < Y <= Z, then 2307 the receiver only succeeds in lying to the sender about the approved 2308 rate if the receiver successfully reports the rightmost 2Y bits in 2309 the QS nonce. 2311 If senders often use a configured default value for the Rate 2312 Request, then receivers would often be able to guess the original 2313 Rate Request, and this would make it easier for the receiver to lie 2314 about the value of the Rate Request field. Similarly, if the 2315 receiver often communicates with a particular sender, and the sender 2316 always uses the same Rate Request for that receiver, then the 2317 receiver might over time be able to infer the original Rate Request 2318 used by the sender. 2320 There are several possible additional forms of protection against 2321 receivers lying about the value of the Rate Request. One possible 2322 additional protection would be for a router that decreases a Rate 2323 Request in a Quick-Start Request to report the decrease directly to 2324 the sender. However, this could lead to many reports back to the 2325 sender for a single request, and could also be used in address- 2326 spoofing attacks. 2328 A second limited form of protection would be for senders to use some 2329 degree of randomization in the requested Rate Request, so that it is 2330 difficult for receivers to guess the original value for the Rate 2331 Request. However, this is difficult because there is a fairly 2332 coarse granularity in the set of rate requests available to the 2333 sender, and randomizing the initial request only offers limited 2334 protection in any case. 2336 9.4.4. Collusion between Misbehaving Routers 2338 In addition to protecting against misbehaving receivers, it is 2339 necessary also to protect against misbehaving routers. Consider 2340 collusion between an ingress router and an egress router belonging 2341 to the same Intranet. The ingress router could decrement the Rate 2342 Request at the ingress, with the egress router increasing it again 2343 at the egress. The routers between the ingress and egress that 2344 approved the decremented rate request might not have been willing to 2345 approve the larger, original request. 2347 Another form of collusion would be for the ingress router to inform 2348 the egress router out-of-band of the TTL Diff and QS Nonce for the 2349 request packet at the ingress. This would enable the egress router 2350 to modify the QS TTL and QS Nonce so that it appeared that all of 2351 the routers along the path had approved the request. There does not 2352 appear to be any protection against a colluding ingress and egress 2353 router. Even if an intermediate router had deleted the Quick-Start 2354 Option from the packet, the ingress router could have sent the 2355 Quick-Start Option to the egress router out-of-band, with the egress 2356 router inserting the Quick-Start Option, with a modified QS TTL 2357 field, back in the packet. 2359 However, unlike ECN, there is somewhat less incentive for 2360 cooperating ingress and egress routers to collude to falsely modify 2361 the Quick-Start Request so that it appears to have been approved by 2362 all of the routers along the path. With ECN, a colluding ingress 2363 router could falsely mark a packet as ECN-capable, with the 2364 colluding egress router returning the ECN field in the IP header to 2365 its original non-ECN-capable codepoint, and congested routers along 2366 the path could have been fooled into not dropping that packet. This 2367 collusion would give an unfair competitive advantage to the traffic 2368 protected by the colluding ingress and egress routers. 2370 In contrast, with Quick-Start, the collusion of the ingress and 2371 egress routers to make it falsely appear that a Quick-Start request 2372 was approved sometimes could give an advantage to the traffic 2373 covered by that collusion, and sometimes would give a disadvantage, 2374 depending on the details of the scenario. If some router along the 2375 path really does not have enough available bandwidth to approve the 2376 Quick-Start request, then Quick-Start packets sent as a result of 2377 the falsely-approved request could be dropped in the network, to the 2378 possible disadvantage of the connection. Thus, while the ingress 2379 and egress routers could collude to prevent intermediate routers 2380 from denying a Quick-Start request, it would not always be to the 2381 connection's advantage for this to happen. One defense against such 2382 a collusion would be for some router between the ingress and egress 2383 nodes that denied the request to monitor connection performance, 2384 penalizing connections that seeem to be using Quick-Start after a 2385 Quick-Start request was denied, or that are reporting an Approved 2386 Rate higher than that actually approved by that router. 2388 If the congested router is ECN-capable, and the colluding ingress 2389 and egress routers are lying about ECN-capability as well as about 2390 Quick-Start, then the result could be that the Quick-Start request 2391 falsely appears to the sender to have been approved, and the Quick- 2392 Start packets falsely appear to the congested router to be ECN- 2393 capable. In this case, the colluding routers might succeed in 2394 giving a competitive advantage to the traffic protected by their 2395 collusion (if no intermediate router is monitoring to catch such 2396 misbehavior). 2398 9.5. Misbehaving Middleboxes and the IP TTL 2400 One possible difficulty is that of traffic normalizers [HKP01] or 2401 other middleboxes along that path that re-write IP TTLs in order to 2402 foil other kinds of attacks in the network. If such a traffic 2403 normalizer re-wrote the IP TTL, but did not adjust the Quick-Start 2404 TTL by the same amount, then the sender's mechanism for determining 2405 if the request was approved by all routers along the path would no 2406 longer be reliable. Re-writing the IP TTL could result in false 2407 positives (with the sender incorrectly believing that the Quick- 2408 Start request was approved) as well as false negatives (with the 2409 sender incorrectly believing that the Quick-Start request was 2410 denied). 2412 9.6. Attacks on Quick-Start 2414 As discussed in [SAF06], Quick-Start is vulnerable to two kinds of 2415 attacks: (1) attacks to increase the routers' processing and state 2416 load; and (2) attacks with bogus Quick-Start requests to temporarily 2417 tie up available Quick-Start bandwidth, preventing routers from 2418 approving Quick-Start requests from other connections. Routers can 2419 protect against the first kind of attack by applying a simple limit 2420 on the rate at which Quick-Start requests will be considered by the 2421 router. 2423 The second kind of attack, to tie up the available Quick-Start 2424 bandwidth, is more difficult to defend against. As discussed in 2425 [SAF06]. Quick-Start Requests that are not going to be used, either 2426 because they are from malicious attackers or because they are denied 2427 by routers downstream, can result in short-term `wasting' potential 2428 Quick-Start bandwidth, resulting in routers denying subsequent 2429 Quick-Start Requests that if approved would in fact have been used. 2430 We note that the likelihood of malicious attacks would be minimized 2431 significantly when Quick-Start was deployed in a controlled 2432 environment such as an Intranet, where there was some form of 2433 centralized control over the users in the system. We also note that 2434 this form of attack could potentially make Quick-Start unusable, but 2435 it would not do any further damage; in the worst case, the network 2436 would function as a network without Quick-Start. 2438 [SAF06] considers the potential of Extreme Quick-Start algorithms at 2439 routers, which keep per-flow state for Quick-Start connections, in 2440 protecting the availability of Quick-Start bandwidth in the face of 2441 frequent overly-larqe Quick-Start requests. 2443 9.7. Simulations with Quick-Start 2445 Quick-Start was added to the NS simulator [SH02] by Srikanth 2446 Sundarrajan, and additional functionality was added by Pasi 2447 Sarolahti. The validation test is at `test-all-quickstart' in the 2448 `tcl/test' directory in NS. The initial simulation studies from 2450 [SH02] show a significant performance improvement using Quick-Start 2451 for moderate-sized flows (between 4KB and 128KB) in under-utilized 2452 environments. These studies are of file transfers, with the 2453 improvement measured as the relative increase in the overall 2454 throughput for the file transfer. The study shows that potential 2455 improvement from Quick-Start is proportional to the delay-bandwidth 2456 product of the path. 2458 The Quick-Start simulations in [SAF06] explore the following: the 2459 potential benefit of Quick-Start for the connection; the relative 2460 benefits of different router-based algorithms for approving Quick- 2461 Start requests; and the effectiveness of Quick-Start as a function 2462 of the senders' algorithms for choosing the size of the rate 2463 request. 2465 10. Implementation and Deployment Issues 2467 This section discusses some of the implementation issues with Quick- 2468 Start. This section also discusses some of the key deployment 2469 issues, such as the chicken-and-egg deployment problems of 2470 mechanisms that have to be deployed in both routers and end nodes in 2471 order to work, and the problems posed by the wide deployment of 2472 middleboxes today that block the use of known or unknown IP Options. 2474 10.1. Implementation Issues for Sending Quick-Start Requests 2476 Section 4.7 discusses some of the issues with deciding the initial 2477 sending rate to request. Quick-Start raises additional issues about 2478 the communication between the transport protocol and the 2479 application, and about the use of the past history with Quick-Start 2480 in the end node. 2482 One possibility is that a protocol implementation could provide an 2483 API for applications to indicate when they want to request Quick- 2484 Start, and what rate they would like to request. In the 2485 conventional socket API this could be a socket option that is set 2486 before a connection is established. Some applications, such as 2487 those that use TCP for bulk transfers, do not have interest in the 2488 transmission rate, but they might know the amount of data that can 2489 be sent immediately. Based on this, the sender implementation could 2490 decide whether Quick-Start would be useful, and what rate should be 2491 requested. 2493 We note that when Quick-Start is used, the TCP sender is required to 2494 save the QS Nonce and the TTL Diff when the Quick-Start request is 2495 sent, and to implement an additional timer for the paced 2496 transmission of Quick-Start packets. 2498 10.2. Implementation Issues for Processing Quick-Start Requests 2500 A router or other network host must be able to determine the 2501 approximate bandwidth of its outbound network interfaces in order to 2502 process incoming Quick-Start rate requests, including those that 2503 originate from the host itself. One possibility would be for hosts 2504 to rely on configuration information to determine link bandwidths; 2505 this has the drawback of not being robust to errors in 2506 configuration. Another possibility would be for network device 2507 drivers to infer the bandwidth for the interface and to communicate 2508 this to the IP layer. 2510 Particular issues will arise for wireless links with variable 2511 bandwidth, where decisions will have to be made about how frequently 2512 the host gets updates of the changing bandwidth. It seems 2513 appropriate that Quick-Start Requests would be handled particularly 2514 conservatively for links with variable bandwidth, to avoid cases 2515 where Quick-Start Requests are approved, the link bandwidth is 2516 reduced, and the data packets that are sent end up being dropped. 2518 Difficult issues also arise for paths with multi-access links (e.g., 2519 Ethernet). Routers or end-nodes with multi-access links should be 2520 particularly conservative in granting Quick-Start requests. In 2521 particular, for some multi-access links there may be no procedure 2522 for an attached node to use to determine whether all parts of the 2523 multi-access link have been underutilized in the recent past. 2525 10.3. Possible Deployment Scenarios 2527 Because of possible problems discussed above concerning using Quick- 2528 Start over some network paths and the security issues discussed in 2529 section 11, the most realistic initial deployment of Quick-Start 2530 would most likely take place in Intranets and other controlled 2531 environments. Quick-Start is most useful on high bandwidth-delay 2532 paths that are significantly underutilized. The primary initial 2533 users of Quick-Start would likely be in organizations that provide 2534 network services to their users and also have control over a large 2535 portion of the network path. 2537 Quick-Start is not currently intended for ubiquitous deployment in 2538 the global Internet. In particular, Quick-Start should not be 2539 enabled by default in end-nodes or in routers; instead, when Quick- 2540 Start is used, it should be explicitly enabled by users or system 2541 administrators. 2543 Below are a few examples of networking environments where Quick- 2544 Start would potentially be useful. These are the environments that 2545 might consider an initial deployment of Quick-Start in the routers 2546 and end-nodes, where the incentives for routers to deploy Quick- 2547 Start might be the most clear. 2549 * Centrally-administrated organizational Intranets: These intranets 2550 often have large network capacity, with networks that are 2551 underutilized for much of the time [PABL+05]. Such Intranets might 2552 also include high-bandwidth and high-delay paths to remote sites. 2553 In such an environment, Quick-Start would be of benefit to users, 2554 and there would be a clear incentive for the deployment of Quick- 2555 Start in routers. For example, Quick-Start could be quite useful in 2556 high-bandwidth networks used for scientific computing. 2558 * Wireless networks: Quick-Start could also be useful in high-delay 2559 environments of Cellular Wide-Area Wireless Networks such as the 2560 GPRS [BW97] and their enhancements and next generations. For 2561 example, GPRS EDGE (Enhanced Data for GSM Evolution) is expected to 2562 provide wireless bandwidth of up to 384 Kbps (roughly 32 1500-byte 2563 packets per second) while the GPRS round-trip times range typically 2564 from few hundred milliseconds to over a second excluding any 2565 possible queueing delays in the network [GPAR02]. In addition, these 2566 networks sometimes have variable additional delays due to resource 2567 allocation that could be avoided by keeping the connection path 2568 constantly utilized, starting from initial slow-start. Thus, Quick- 2569 Start could be of significant benefit to users in these 2570 environments. 2572 * Paths over satellite links: Geostationary Orbit (GEO) satellite 2573 links have one-way propagation delays on the order of 250 ms while 2574 the bandwidth can be measured in megabits per second [RFC2488]. 2575 Because of the considerable bandwidth-delay product on the link, 2576 TCP's slow-start is a major performance limitation in the beginning 2577 of the connection. A large initial congestion window would be 2578 useful to users of such satellite links. 2580 * Single-hop paths: Quick-Start should work well over point-to-point 2581 single-hop paths, e.g., from a host to an adjacent server. Quick- 2582 Start would work over a single-hop IP path consisting of a multi- 2583 access link only if the host was able to determine if the path to 2584 the next IP hop has been significantly underutilized over the recent 2585 past. If the multi-access link includes a layer-2 switch, then the 2586 attached host cannot necessarily determine the status of the other 2587 links in the layer-2 network. 2589 10.4. A Comparison with the Deployment Problems of ECN 2591 Given the glacially slow rate of deployment of ECN in the Internet 2592 to date [MAF05], it is disconcerting to note that some of the 2593 deployment problems of Quick-Start are even greater than those of 2594 ECN. First, unlike ECN, which can be of benefit even if it is only 2595 deployed on one of the routers along the end-to-end path, a 2596 connection's use of Quick-Start requires Quick-Start deployment on 2597 all of the routers along the end-to-end path. Second, unlike ECN, 2598 which uses an allocated field in the IP header, Quick-Start requires 2599 the extra complications of an IP Option, which can be difficult to 2600 pass through the current Internet [MAF05]. 2602 However, in spite of these issues, there is some hope for the 2603 deployment of Quick-Start, at least in protected corners of the 2604 Internet, because the potential benefits of Quick-Start to the user 2605 are considerably more dramatic than those of ECN. Rather than 2606 simply replacing the occasional dropped packet by an ECN-marked 2607 packet, Quick-Start is capable of dramatically increasing the 2608 throughput of connections in underutilized environments [SAF06]. 2610 11. Security Considerations 2612 Sections 9.4 and 9.6 discuss the security considerations related to 2613 Quick-Start. Section 9.4 discusses the potential abuse of Quick- 2614 Start by senders or receivers lying about whether the request was 2615 approved or about the approved rate, and of routers in collusion to 2616 misuse Quick-Start. Section 9.5 discusses potential problems with 2617 traffic normalizers that rewrite IP TTLs in packet headers. All of 2618 these problems could result in the sender using a Rate Request that 2619 was inappropriately large, or thinking that a request was approved 2620 when it was in fact denied by at least one router along the path. 2621 This inappropriate use of Quick-Start could result in congestion and 2622 an unacceptable level of packet drops along the path, Such 2623 congestion could also be part of a Denial of Service attack. 2625 Section 9.6 discusses a potential attack on the routers' processing 2626 and state load from an attack of Quick-Start Requests. Section 9.6 2627 also discusses a potential attack on the available Quick-Start 2628 bandwidth by sending bogus Quick-Start requests for bandwidth that 2629 will not in fact be used. While this impacts the global usability 2630 of Quick-Start it does not endanger the network as a whole since TCP 2631 uses standard congestion control if Quick-Start is not available. 2633 Section 4.7.2 discusses the potential problem of packets with Quick- 2634 Start Requests dropped by middleboxes along the path. 2636 As discussed in Section 5, for IPv4 IPsec Authentication Header 2637 Integrity Check Value (AH ICV) calculation, the Quick-Start option 2638 is a mutable IPv4 option, and hence completely zeroed for AH ICV 2639 calculation purposes; this is also the treatment required by RFC 2640 2402 for unrecognized IPv4 options. The IPv6 Quick-Start option's 2641 IANA-allocated option type indicates that it is a mutable option, 2642 hence, according to RFC 2402, its option data is required to be 2643 zeroed for AH ICV computation purposes. See RFC 2402 for further 2644 explanation. 2646 Section 6.2 discusses possible problems of Quick-Start used by 2647 connections carried over simple tunnels that are not compatible with 2648 Quick-Start. In this case it is possible that a Quick-Start 2649 Request is erroneously considered approved by the sender without the 2650 routers in the tunnel having individually approved the request, 2651 causing a false positive. 2653 We note two high-order points here. First, the Quick-Start Nonce 2654 goes a long way towards preventing large scale cheating. And, 2655 second, even if a host occasionally uses Quick-Start when it is not 2656 approved by the entire network path the network will not collapse. 2657 Quick-Start does not remove TCP's basic congestion control 2658 mechanisms and these will kick in when the network is heavily 2659 loaded, relegating any Quick-Start mistake to a transient. 2661 12. IANA Considerations 2663 Quick-Start requires an IP Option and a TCP Option. 2665 12.1. IP Option 2667 Quick-Start requires both an IPv4 Option Number (Section 3.1) and an 2668 IPv6 Option Number (Section 3.2). 2670 IPv4 Option Number: 2672 Copy Class Number Value Name 2673 ---- ----- ------ ----- ---- 2674 0 00 TBD1 TBD2 QS - Quick-Start 2676 IPv6 Option Number [RFC2460]: 2678 HEX act chg rest 2679 --- --- --- ----- 2680 TBD3 00 1 TBD4 Quick-Start 2682 For the IPv6 Option Number, the first two bits indicate that the 2683 IPv6 node skip over this option and continue processing the header 2684 if it doesn't recognize the option type, and the third bit indicates 2685 that the Option Data may change en-route. 2687 In both cases this document should be listed as the reference 2688 document. 2690 12.2. TCP Option 2692 Quick-Start requires a TCP Option Number (Section 4.2). 2694 TCP Option Number: 2696 Kind Length Meaning 2697 ---- ------ ------------------------------ 2698 TBD5 8 Quick-Start Response 2700 This document should be listed as the reference document. 2702 13. Conclusions 2704 We are presenting the Quick-Start mechanism as a simple, 2705 understandable, and incrementally-deployable mechanism that would be 2706 sufficient to allow some connections to start up with large initial 2707 rates, or large initial congestion windows, in overprovisioned, 2708 high-bandwidth environments. We expect there will be an increasing 2709 number of overprovisioned, high-bandwidth environments where the 2710 Quick-Start mechanism, or another mechanism of similar power, could 2711 be of significant benefit to a wide range of traffic. We are 2712 presenting the Quick-Start mechanism as a request for the community 2713 to provide feedback and experimentation on issues relating to Quick- 2714 Start. 2716 14. Acknowledgements 2718 The authors wish to thank Mark Handley for discussions of these 2719 issues. The authors also thank the End-to-End Research Group, the 2720 Transport Services Working Group, and members of IPAM's program on 2721 Large Scale Communication Networks for both positive and negative 2722 feedback on this proposal. We thank Srikanth Sundarrajan for the 2723 initial implementation of Quick-Start in the NS simulator, and for 2724 the initial simulation study. Many thanks to David Black and Joe 2725 Touch for extensive feedback on Quick-Start and IP tunnels. We also 2726 thank Mohammed Ashraf, John Border, Bob Briscoe, Martin Duke, Tom 2727 Dunigan, Mitchell Erblich, Gorry Fairhurst, John Heidemann, Paul 2728 Hyder, Dina Katabi and Vern Paxson for feedback. Thanks also to 2729 Gorry Fairhurst for the suggestion of adding the QS Nonce to the 2730 Report of Approved Rate. 2732 The version of the QS Nonce in this document is based on a proposal 2733 from Guohan Lu [L05]. Earlier versions of this document contained 2734 an eight-bit QS Nonce, and subsequent versions discussed the 2735 possibility of a four-bit QS Nonce. 2737 This draft builds upon the concepts described in [RFC3390], [AHO98], 2738 [RFC2415], and [RFC3168]. Some of the text on Quick-Start in 2739 tunnels was borrowed directly from RFC 3168. 2741 This document is the development of a proposal originally by Amit 2742 Jain for Initial Window Discovery. 2744 A. Related Work 2746 The Quick-Start proposal, taken together with HighSpeed TCP 2747 [RFC3649] or other transport protocols for high-bandwidth transfers, 2748 could go a significant way towards extending the range of 2749 performance for best-effort traffic in the Internet. However, there 2750 are many things that the Quick-Start proposal would not accomplish. 2751 Quick-Start is not a congestion control mechanism, and would not 2752 help in making more precise use of the available bandwidth, that is, 2753 of achieving the goal of high throughput with low delay and low 2754 packet loss rates. Quick-Start would not give routers more control 2755 over the decrease rates of active connections. 2757 In addition, any evaluation of Quick-Start must include a discussion 2758 of the relative benefits of approaches that use no explicit 2759 information from routers, and of approaches that use more fine- 2760 grained feedback from routers as part of a larger congestion control 2761 mechanism. We discuss several classes of proposals in the sections 2762 below. 2764 A.1. Fast Start-ups without Explicit Information from Routers 2766 One possibility would be for senders to use information from the 2767 packet streams to learn about the available bandwidth, without 2768 explicit information from routers. These techniques would not allow 2769 a start-up as fast as that available from Quick-Start in an 2770 underutilized environment; one has to have sent some packets 2771 already to use the packet stream to learn about available bandwidth. 2772 However, these techniques could allow a start-up considerably faster 2773 than the current slow-start. While it seems clear that approaches 2774 *without* explicit feedback from the routers will be strictly less 2775 powerful that is possible *with* explicit feedback, it is also 2776 possible that approaches that are more aggressive than slow-start 2777 are possible without the complexity involved in obtaining explicit 2778 feedback from routers. 2780 Periodic packet streams: 2781 [JD02] explores the use of periodic packet streams to estimate the 2782 available bandwidth along a path. The idea is that the one-way 2783 delays of a periodic packet stream show an increasing trend when the 2784 stream's rate is higher than the available bandwidth (due to an 2785 increasing queue). While [JD02] states that the proposed mechanism 2786 does not cause significant increases in network utilization, losses, 2787 or delays when done by one flow at a time, the approach could be 2788 problematic if conducted concurrently by a number of flows. [JD02] 2789 also gives an overview of some of the earlier work on inferring the 2790 available bandwidth from packet trains. 2792 Swift-Start: 2793 The Swift Start proposal from [PRAKS02] combines packet-pair and 2794 packet-pacing techniques. An initial congestion window of four 2795 segments is used to estimate the available bandwidth along the path. 2796 This estimate is then used to dramatically increase the congestion 2797 window during the second RTT of data transmission. 2799 SPAND: 2800 In the TCP/SPAND proposal from [ZQK00] for speeding up short data 2801 transfers, network performance information would be shared among 2802 many co-located hosts to estimate each connection's fair share of 2803 the network resources. Based on such estimation and the transfer 2804 size, the TCP sender would determine the optimal initial congestion 2805 window size. The design for TCP/SPAND uses a performance gateway 2806 that monitors all traffic entering and leaving an organization's 2807 network. 2809 Sharing information among TCP connections: 2810 The Congestion Manager [RFC3124] and TCP control block sharing 2811 [RFC2140] both propose sharing congestion information among multiple 2812 TCP connections with the same endpoints. With the Congestion 2813 Manager, a new TCP connection could start with a high initial cwnd 2814 if it was sharing the path and the cwnd with a pre-existing TCP 2815 connection to the same destination that had already obtained a high 2816 congestion window. RFC 2140 discusses ensemble sharing, where an 2817 established connection's congestion window could be `divided up' to 2818 be shared with a new connection to the same host. However, neither 2819 of these approaches addresses the case of a connection to a new 2820 destination, with no existing or recent connection (and therefore 2821 congestion control state) to that destination. 2823 While continued research on the limits of the ability of TCP and 2824 other transport protocols to learn of available bandwidth without 2825 explicit feedback from the router seems useful, we note that there 2826 are several fundamental advantages of explicit feedback from 2827 routers. 2829 (1) Explicit feedback is faster than implicit feedback: 2830 One advantage of explicit feedback from the routers is that it 2831 allows the transport sender to reliably learn of available bandwidth 2832 in one round-trip time. 2834 (2) Explicit feedback is more reliable than implicit feedback: 2835 Techniques that attempt to assess the available bandwidth at 2836 connection startup using implicit techniques are more error-prone 2837 than techniques that involve every element in the network path. 2838 While explicit information from the network can be wrong, it has a 2839 much better chance of being appropriate than an end-host trying to 2840 *estimate* an appropriate sending rate using "block box" probing 2841 techniques of the entire path. 2843 A.2. Optimistic Sending without Explicit Information from Routers 2845 Another possibility that has been suggested [S02] is for the sender 2846 to start with a large initial window without explicit permission 2847 from the routers and without bandwidth estimation techniques, and 2848 for the first packet of the initial window to contain information 2849 such as the size or sending rate of the initial window. The 2850 proposal would be that congested routers would use this information 2851 in the first data packet to drop or delay many or all of the packets 2852 from that initial window. In this way a flow's optimistically-large 2853 initial window would not force the router to drop packets from 2854 competing flows in the network. Such an approach would seem to 2855 require some mechanism for the sender to ensure that the routers 2856 along the path understood the mechanism for marking the first packet 2857 of a large initial window. 2859 Obviously there would be a number of questions to consider about an 2860 approach of optimistic sending. 2862 (1) Incremental deployment: 2863 One question would be the potential complications of incremental 2864 deployment, where some of the routers along the path might not 2865 understand the packet information describing the initial window. 2867 (2) Congestion collapse: 2868 There could also be concerns about congestion collapse if many flows 2869 used large initial windows, many packets were dropped from 2870 optimistic initial windows, and many congested links ended up 2871 carrying packets that are only going to be dropped downstream. 2873 (3) Distributed Denial of Service attacks: 2874 A third question would be the potential role of optimistic senders 2875 in amplifying the damage done by a Distributed Denial of Service 2876 (DDoS) attack (assuming attackers use conformant congestion control 2877 in the hopes of "flying under the radar"). 2879 (4) Performance hits if a packet is dropped: 2880 A fourth issue would be to quantify the performance hit to the 2881 connection when a packet is dropped from one of the initial windows. 2883 A.3. Fast Start-ups with other Information from Routers 2885 There have been several proposals somewhat similar to Quick-Start, 2886 where the transport protocol collects explicit information from the 2887 routers along the path. 2889 An IP Option about the free buffer size: 2890 In related work, [P00] investigates the use of a slightly different 2891 IP option for TCP connections to discover the available bandwidth 2892 along the path. In that proposal, the IP option would query the 2893 routers along the path about the smallest available free buffer 2894 size. Also, the IP option would have been sent after the initial SYN 2895 exchange, when the TCP sender already had an estimate of the round- 2896 trip time. 2898 The Performance Transparency Protocol: 2899 The Performance Transparency Protocol (PTP) includes a proposal for 2900 a single PTP packet that would collect information from routers 2901 along the path from the sender to the receiver [W00]. For example, 2902 a single PTP packet could be used to determine the bottleneck 2903 bandwidth along a path. 2905 ETEN: 2907 Additional proposals for end nodes to collect explicit information 2908 from routers include one variant of Explicit Transport Error 2909 Notification (ETEN), which includes a cumulative mechanism to notify 2910 endpoints of aggregate congestion statistics along the path 2911 [KAPS02]. (A second variant in [KSEPA04] does not depend on 2912 cumulative congestion statistics from the network.) 2914 A.4. Fast Start-ups with more Fine-Grained Feedback from Routers 2916 Proposals for more fine-grained congestion-related feedback from 2917 routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking 2918 [K03]. Section B.6 discusses in more detail the relationship 2919 between Quick-Start and proposals for more fine-grained per-packet 2920 feedback from routers. 2922 XCP: 2923 Proposals such as XCP for new congestion control mechanisms based on 2924 more feedback from routers are more powerful than Quick-Start, but 2925 also are more complex to understand and more difficult to deploy. 2926 XCP routers maintain no per-flow state, but provide more fine- 2927 grained feedback to end-nodes than the one-bit congestion feedback 2928 of ECN. The per-packet feedback from XCP can be positive or 2929 negative, and specifies the increase or decrease in the sender's 2930 congestion window when this packet is acknowledged. XCP is a full- 2931 fledge congestion control scheme, whereas Quick-Start represents a 2932 quick check to determine if the network path is significantly 2933 underutilized such that a connection can start faster and then fall 2934 back to TCP's standard congestion control algorithms. 2936 AntiECN: 2937 The AntiECN proposal is for a single bit in the packet header that 2938 routers could set to indicate that they are underutilized. For each 2939 TCP ACK arriving at the sender indicating that a packet has been 2940 received with the Anti-ECN bit set, the sender would be able to 2941 increase its congestion window by one packet, as it would during 2942 slow-start. 2944 A.5. Fast Start-ups with Lower-Than-Best-Effort Service 2946 There have been proposals for routers to provide a Lower Effort 2947 differentiated service that would be lower than best effort 2948 [RFC3662]. Such a service could carry traffic for which delivery is 2949 strictly optional, or could carry traffic that is important but that 2950 has low priority in terms of time. Because it does not interfere 2951 with best-effort traffic, Lower Effort services could be used by 2952 transport protocols that start-up faster than slow-start. For 2953 example, [SGF05] is a proposal for the transport sender to use low- 2954 priority traffic for much of the initial traffic, with routers 2955 configured to use strict priority queueing. 2957 A separate but related issue is that of below-best-effort TCP, 2958 variants of TCP that would not rely on Lower Effort services in the 2959 network, but would approximate below-best-effort traffic by 2960 detecting and responding to congestion sooner that standard TCP. 2961 TCP Nice [V02] and TCP Low Priority (TCP-LP) [KK03] are two such 2962 proposals for below-best-effort TCP, with the purpose of allowing 2963 TCP connections to use the bandwidth unused by TCP and other traffic 2964 in a non-intrusive fashion. Both TCP Nice and TCP Low Priority use 2965 the default slow-start mechanisms of TCP. 2967 We note that Quick-Start is quite different from either a Lower 2968 Effort service or a below-best-effort variant of TCP. Unlike these 2969 proposals, Quick-Start is intended to be useful for best-effort 2970 traffic that wishes to receive at least as much bandwidth as 2971 competing best-effort connections. 2973 B. Design Decisions 2975 B.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP 2977 This document has proposed using an IP Option for the Quick-Start 2978 Request from the sender to the receiver, and using transport 2979 mechanisms for the Quick-Start Response from the receiver back to 2980 the sender. In this section we discuss alternate mechanisms, and 2981 consider whether ICMP ([RFC792], [RFC2463]) or RSVP [RFC2205] 2982 protocols could be used for delivering the Quick-Start Request. 2984 B.1.1. ICMP 2986 Being a control protocol used between Internet nodes, one could 2987 argue that ICMP is the ideal method for requesting a permission for 2988 faster startup from routers. The ICMP header is above the IP 2989 header. Quick-Start could be accomplished with ICMP as follows: If 2990 the ICMP protocol is used to implement Quick-Start, the equivalent 2991 of the Quick-Start IP option would be carried in the ICMP header of 2992 the ICMP Quick-Start Request. The ICMP Quick-Start Request would 2993 have to pass by the routers on the path to the receiver, possibly 2994 using the IP Router Alert option [RFC2113]. A router that approves 2995 the Quick-Start Request would take the same actions as in the case 2996 with the Quick-Start IP Option, and forward the packet to the next 2997 router along the path. A router that does not approve the Quick- 2998 Start Request, even with a decreased value for the Requested Rate, 2999 would delete the ICMP Quick-Start Request, and send an ICMP Reply to 3000 the sender that the request was not approved. If the ICMP Reply was 3001 dropped in the network, and did not reach the receiver, the sender 3002 would still know that the request was not approved from the absence 3003 of feedback from the receiver. If the ICMP Quick-Start request was 3004 dropped in the network due to congestion, the sender would assume 3005 that the request was not approved. The ICMP message would need the 3006 source and destination port numbers for demultiplexing at the end 3007 nodes. If the ICMP Quick-Start Request reached the receiver, the 3008 receiver would use transport-level or application-level mechanisms 3009 to send a response to the sender, exactly as with the IP Option. 3011 One benefit of using ICMP would be that the delivery of the TCP SYN 3012 packet or other initial packet would not be delayed by IP option 3013 processing at routers. A greater advantage is that if middleboxes 3014 were blocking packets with Quick-Start Requests, using the Quick- 3015 Start Request in a separate ICMP packet would mean that the 3016 middlebox behavior would not affect the connection as a whole. (To 3017 get this robustness to middleboxes with TCP using an IP Quick-Start 3018 Option, one would have to have a TCP-level Quick-Start Request 3019 packet that could be sent concurrently but separately from the TCP 3020 SYN packet.) 3022 However, there are a number of disadvantages to using ICMP. Some 3023 firewalls and middleboxes may not forward the ICMP Quick-Start 3024 Request packets. (If an ICMP Reply packet from a router to the 3025 sender is dropped in the network, the sender would still know that 3026 the request was not approved, as stated earlier, so this would not 3027 be as serious of a problem.) In addition, it would be difficult, if 3028 not impossible, for a router in the middle of an IP tunnel to 3029 deliver an ICMP Reply packet to the actual source, for example when 3030 the inner IP header is encrypted as in IPsec tunnel mode [RFC2401]. 3031 Again, however, the ICMP Reply packet would not be essential to the 3032 correct operation of ICMP Quick-Start. 3034 Unauthenticated out-of-band ICMP messages could enable some types of 3035 attacks by third-party malicious hosts that are not possible when 3036 the control information is carried in-band with the IP packets that 3037 can only be altered by the routers on the connection path. Finally, 3038 as a minor concern, using ICMP would cause a small amount of 3039 additional traffic in the network, which is not the case when using 3040 IP options. 3042 B.1.2. RSVP 3044 With some modifications RSVP [RFC2205] could be used as a bearer 3045 protocol for carrying the Quick-Start Requests. Because routers are 3046 expected to process RSVP packets more extensively than the normal 3047 transport protocol IP packets, delivering a Quick-Start rate request 3048 using an RSVP packet would seem an appealing choice. However, Quick- 3049 Start with RSVP would require a few differences from the 3050 conventional usage of RSVP. Quick-Start would not require periodical 3051 refreshing of soft state, because Quick-Start does not require per- 3052 connection state in routers. Quick-Start Requests would be 3053 transmitted downstream from the sender to receiver in the RSVP Path 3054 messages, which is different from the conventional RSVP model where 3055 the reservations originate from the receiver. Furthermore, the 3056 Quick-Start Response would be sent using the transport-level or 3057 application-level mechanisms instead of using the RSVP Resv message. 3059 If RSVP was used for carrying a Quick-Start Request, a new "Quick- 3060 Start Request" class object would be included in the RSVP Path 3061 message that is sent from the sender to receiver. The object would 3062 contain the rate request field in addition to the common length and 3063 type fields. The Send_TTL field in the RSVP common header could be 3064 used as the equivalent of the QS TTL field. The Quick-Start capable 3065 routers along the path would inspect the Quick-Start Request object 3066 in the RSVP Path message, decrement Send_TTL and adjust the rate 3067 request field if needed. If an RSVP router did not understand the 3068 Quick-Start Request object, it would reject the entire RSVP message 3069 and send an RSVP PathErr message back to the sender. When an RSVP 3070 message with the Quick-Start Request object reaches the receiver, 3071 the receiver sends a Quick-Start Reply message in the corresponding 3072 transport protocol header in the same way as described in the 3073 context of IP options earlier. If the RSVP message with the Quick- 3074 Start Request object was dropped along the path, the transport 3075 sender would simply proceed with the normal congestion control 3076 procedures. 3078 Much of the discussion about benefits and drawbacks of using ICMP 3079 for making the Quick-Start Request also applies to the RSVP case. If 3080 the Quick-Start Request was transmitted in a separate packet instead 3081 of as an IP option, the transport protocol packet delivery would not 3082 be delayed due to IP option processing at the routers, and the 3083 initial transport packets would reach their destination more 3084 reliably. The possible disadvantages of using ICMP and RSVP are also 3085 expected to be similar: middleboxes in the network may not be able 3086 to forward the Quick-Start Request messages, and the IP tunnels 3087 might cause problems for processing the Quick-Start Requests. 3089 B.2. Alternate Encoding Functions 3091 In this section we look at alternate encoding functions for the Rate 3092 Request field in the Quick-Start Request. The main requirements for 3093 this function is that it should have a sufficiently wide range for 3094 the requested rate. There is no need for overly-fine-grained 3095 precision in the requested rate. Similarly, while it would be 3096 attractive for the encoding function to be easily computable, it is 3097 also possible for end-nodes and routers to simply store the table 3098 giving the mapping between the value N in the Rate Request field, 3099 and the actual rate request f(N). In this section we consider 3100 possible encoding methods for Rate Request fields of different 3101 sizes, including four-bit, eight-bit, and larger Rate Request 3102 fields. 3104 Linear functions: 3105 One possible proposal would be for the Rate Request field to be 3106 formatted in bits per second, scaled so that one unit equals M Kbps, 3107 for some fixed value of M. Thus, for the value N in the Rate 3108 Request field, the requested rate would be M*N Kbps. 3110 Powers of two: 3111 If a granularity of factors of two is sufficient for the Rate 3112 Request, then the encoding function with the most range would be for 3113 the requested rate to be K*2^N, for N the value in the Rate Request 3114 field, and for K some constant. For N=0, the rate request would be 3115 set to zero, regardless of the encoding function. For example, for 3116 K=40,000 and an eight-bit Rate Request field, the request range 3117 would be from 80 Kbps to 40*2^255 Kbps. This clearly would be an 3118 unnecessarily large request range. 3120 For a four-bit Rate Request field, the upper limit on the rate 3121 request is 1.3 Gbps. It seems to us that an upper limit of 1.3 Gbps 3122 would be fine for the Quick-Start rate request, and that connections 3123 wishing to start up with a higher initial sending rate should be 3124 encouraged to use other mechanisms, such as the explicit reservation 3125 of bandwidth. If an upper limit of 1.3 Gbps was not acceptable, 3126 then five or six bits could be used for the Rate Request field. 3128 The lower limit of 80 Kbps could be useful for flows with round-trip 3129 times of a second or more. For a flow with a round-trip time of one 3130 second, as is typical in some wireless networks, the TCP initial 3131 window of 4380 bytes allowed by RFC 3390 (given appropriate packet 3132 sizes) would translate to an initial sending rate of 35 Kbps. Thus, 3133 for TCP flows, a rate request of 80 Kbps could be useful for some 3134 flows with large round-trip times. 3136 The lower limit of 80 Kbps could also be useful for some non-TCP 3137 flows that send small packets, with at most one small packet every 3138 10 ms. A rate request of 80 Kbps would translate to a rate of a 3139 hundred 100-byte packets per second (including packet headers). 3140 While some small-packet flows with large round-trip times might find 3141 a smaller rate request of 40 Kbps to be useful, our assumption is 3142 that a lower limit of 80 Kbps on the rate request will be generally 3143 sufficient. Again, if the lower limit of 80 kbps was not 3144 acceptable, then extra bits could be used for the Rate Request 3145 field. 3147 If the granularity of factors of two was too coarse, then the 3148 encoding function could use a base less than two. An alternate form 3149 for the encoding function would be to use a hybrid of linear and 3150 exponential functions. 3152 A mantissa and exponent representation: 3153 Section 4.4 of [B05] suggests a mantissa and exponent representation 3154 for the Quick-Start encoding function. With e and f as the binary 3155 numbers in the exponent and mantissa fields, and with 0 <= f < 1, 3156 this would represent the rate (1+f)*2^e. [B05] suggests a mantissa 3157 field for f of 8, 16, or 24 bits, with an exponent field for e of 8 3158 bits. This representation would allow larger rate requests, with an 3159 encoding that is less coarse than the powers-of-two encoding used in 3160 this document. 3162 Constraints of the transport protocol: 3163 We note that the Rate Request is also constrained by the abilities 3164 of the transport protocol. For example, for TCP with Window 3165 Scaling, the maximum window is at most 2**30 bytes. For a TCP 3166 connection with a long, 1 second round-trip time, this would give a 3167 maximum sending rate of 1.07 Gbps. 3169 B.3. The Quick-Start Request: Packets or Bytes? 3171 One of the design questions is whether the Rate Request field should 3172 be in bytes per second or in packets per second. We discuss this 3173 separately from the perspective of the transport, and from the 3174 perspective of the router. 3176 For TCP, the results from the Quick-Start Request are translated 3177 into a congestion window in bytes, using the measured round-trip 3178 time and the MSS. This window applies only to the bytes of data 3179 payload, and does not include the bytes in the TCP or IP packet 3180 headers. Other transport protocols would conceivably use the Quick- 3181 Start Request directly in packets per second, or could translate the 3182 Quick-Start Request to a congestion window in packets. 3184 The assumption of this draft is that the router only approves the 3185 Quick-Start Request when the output link is significantly 3186 underutilized. For this, the router could measure the available 3187 bandwidth in bytes per second, or could convert between packets and 3188 bytes by some mechanism. 3190 If the Quick-Start Request was in bytes per second, and applied only 3191 to the data payload, then the router would have to convert from 3192 bytes per second of data payload, to bytes per second of packets on 3193 the wire. If the Rate Request field was in bytes per second and the 3194 sender ended up using very small packets, this could translate to a 3195 significantly larger number in terms of bytes per second on the 3196 wire. Therefore, for a Quick-Start Request in bytes per second, it 3197 makes most sense for this to include the transport and IP headers as 3198 well as the data payload. Of course, this will be at best a rough 3199 approximation on the part of the sender; the transport-level sender 3200 might not know the size of the transport and IP headers in bytes, 3201 and might know nothing at all about the separate headers added in IP 3202 tunnels downstream. This rough estimate seems sufficient, however, 3203 given the overall lack of fine precision in Quick-Start 3204 functionality. 3206 It has been suggested that the router could possibly use information 3207 from the MSS option in the TCP packet header of the SYN packet to 3208 convert the Quick-Start Request from packets per second to bytes per 3209 second, or vice versa. The MSS option is defined as the maximum MSS 3210 that the TCP sender expects to receive, not the maximum MSS that the 3211 TCP sender plans to send [RFC793]. However, it is probably often 3212 the case that this MSS also applies as an upper bound on the MSS 3213 used by the TCP sender in sending. 3215 We note that the sender does not necessarily know the Path MTU when 3216 the Quick-Start Request is sent, or when the initial window of data 3217 is sent. Thus, with IPv4, packets from the initial window could end 3218 up being fragmented in the network if the "Don't Fragment" (DF) bit 3219 is not set [RFC1191]. A Rate Request in bytes per second is 3220 reasonably robust to fragmentation. Clearly a Rate Request in 3221 packets per second is less robust in the presence of fragmentation. 3222 Interactions between larger initial windows and Path MTU Discovery 3223 are discussed in more detail in RFC 3390 [RFC3390]. 3225 For a Quick-Start Request in bytes per second, the transport senders 3226 would have the additional complication of estimating the bandwidth 3227 usage added by the packet headers. 3229 We have chosen a Rate Request field in bytes per second rather than 3230 in packets per second because it seems somewhat more robust, 3231 particularly to routers. 3233 B.4. Quick-Start Semantics: Total Rate or Additional Rate? 3235 For a Quick-Start Request sent in the middle of a connection, there 3236 are two possible semantics for the Rate Request field, as follows: 3238 (1) Total Rate: The requested Rate Request is the requested total 3239 rate for the connection, including the current rate; or 3241 (2) Additional Rate: The requested Rate Request is the requested 3242 increase in the total rate for that connection, over and above the 3243 current sending rate. 3245 When the Quick-Start Request is sent after an idle period, the 3246 current sending rate is zero, and there is no difference between (1) 3247 and (2) above. However, a Quick-Start Request can also be sent in 3248 the middle of a connection that has not been idle, e.g., after a 3249 mobility event, or after an application-limited period when the 3250 sender is suddenly ready to send at a much higher rate. In this 3251 case, there can be a significant difference between (1) and (2) 3252 above. In this section we consider briefly the tradeoffs between 3253 these two options, and explain why we have chosen the `Total Rate' 3254 semantics. 3256 The Total Rate semantics makes it easier for routers to ``allocate'' 3257 the same rate to all connections. This lends itself to fairness, 3258 and improves convergence times between old and new connections. 3259 With the Additional Rate semantics, the router would not necessarily 3260 know the current sending rates of the flows requesting additional 3261 rates, and therefore would not have sufficient information to use 3262 fairness as a metric in granting rate requests. With the Total Rate 3263 semantics, the fairness is automatic; the router is not granting 3264 rate requests for *additional* bandwidth without knowing the current 3265 sending rates of the different flows. 3267 The Additional Rate semantics also lends itself to gaming by the 3268 connection, with senders sending frequent Quick-Start Requests in 3269 the hope of gaining a higher rate. If the router is granting the 3270 same maximum rate for all rate requests, then there is little 3271 benefit to a connection of sending a rate request over and over 3272 again. However, if the router is granting an *additional* rate with 3273 each rate request, over and above the current sending rate, then it 3274 is in a connection's interest to send as many rate requests as 3275 possible, even if very few of them are in fact granted. 3277 Appendix E discusses a Report of Current Sending Rate as one 3278 possible function in the Quick-Start Option. However, we have not 3279 standardized this possible use at this time. 3281 B.5. Alternate Responses to the Loss of a Quick-Start Packet 3283 Section 4.6 discusses TCP's response to the loss of a Quick-Start 3284 packet in the initial window. This section discusses several 3285 alternate responses. 3287 One possible alternative to reverting to the default slow-start 3288 after the loss of a Quick-Start packet from the initial window would 3289 have been to halve the congestion window and continue in congestion 3290 avoidance. However, we note that this would not have been a 3291 desirable response for either the connection or for the network as a 3292 whole. The packet loss in the initial window indicates that Quick- 3293 Start failed in finding an appropriate congestion window, meaning 3294 that the congestion window after halving may easily also be wrong. 3296 A more moderate alternate would be to continue in congestion 3297 avoidance from a window of (W-D)/2, where W is the Quick-Start 3298 congestion window, and D is the number of packets dropped or marked 3299 from that window. However, such an approach would implicitly assume 3300 that the number of Quick-Start packets delivered is a good 3301 indication of the appropriate available bandwidth for that flow, 3302 even though other packets from that window were dropped in the 3303 network. And, further, that using half the number of segments that 3304 were successfully transmitted is conservative enough to account for 3305 the possibly inaccurate congestion window indication. We believe 3306 that such an assumption would require more analysis at this point, 3307 particularly in a network with a range of packet dropping mechanisms 3308 at the router, and we cannot recommend it at this time. 3310 Another drawback of approaches that don't revert back to slow-start 3311 when a Quick-Start packet in the initial window is dropped is that 3312 such approaches could give the TCP receiver a greater incentive to 3313 lie about the Quick-Start request. If the sender reverts to slow- 3314 start when a Quick-Start packet in the initial window is dropped, 3315 this diminishes the benefit a receiver would get from a Quick-Start 3316 request that resulted in a dropped or ECN-marked packet. 3318 B.6. Why Not Include More Functionality? 3320 This proposal for Quick-Start is a rather coarse-grained mechanism 3321 that would allow a connection to use a higher sending rate along 3322 underutilized paths, but that does not attempt to provide a next- 3323 generation transport protocol or congestion control mechanism, and 3324 does not attempt the goal of providing very high throughput with 3325 very low delay. As Section A.4 discusses, there are a number of 3326 proposals such as XCP, MaxNet, and AntiECN for more fine-grained 3327 per-packet feedback from routers than the current congestion control 3328 mechanisms, that do attempt these more ambitious goals. 3330 Compared to proposals such as XCP and AntiECN, Quick-Start offers 3331 much less control. Quick-Start does not attempt to provide a new 3332 congestion control mechanism, but simply to get permission from 3333 routers for a higher sending rate at start-up, or after an idle 3334 period. Quick-Start can be thought of as an "anti-congestion- 3335 control" mechanism, that is only of any use when all of the routers 3336 along the path are significantly under-utilized. Thus, Quick-Start 3337 is of no use towards a target of high link utilization, or fairness 3338 in a high-utilization scenario, or controlling queueing delay during 3339 high-utilization, or anything of the like. 3341 At the same time, Quick-Start would allow larger initial windows 3342 than would proposals such as AntiECN, requires less input to routers 3343 than XCP (e.g., XCP's cwnd and RTT fields), and would require less 3344 frequent feedback from routers than any new congestion control 3345 mechanism. Thus, Quick-Start is significantly less powerful than 3346 proposals for new congestion control mechanisms such as XCP and 3347 AntiECN, but as powerful or more powerful in terms of the specific 3348 issue of allowing larger initial windows, and (we think) more 3349 amenable to incremental deployment in the current Internet. 3351 We do not discuss proposals such as XCP in detail, but simply note 3352 that there are a number of open questions. One question concerns 3353 whether there is a pressing need for more sophisticated congestion 3354 control mechanisms such as XCP in the Internet. Quick-Start is 3355 inherently a rather crude tool that does not deliver assurances 3356 about maintaining high link utilization and low queueing delay; 3357 Quick-Start is designed for use in environments that are 3358 significantly underutilized, and addresses the single question of 3359 whether a higher sending rate is allowed. New congestion control 3360 mechanisms with more fine-grained feedback from routers could allow 3361 faster startups even in environments with rather high link 3362 utilization. Is this a pressing requirement? Are the other 3363 benefits of more fine-grained congestion control feedback from 3364 routers a pressing requirement? 3366 We would argue that even if more fine-grained per-packet feedback 3367 from routers was implemented, it is reasonable to have a separate 3368 mechanism such as Quick-Start for indicating an allowed initial 3369 sending rate, or an allowed total sending rate after an idle or 3370 underutilized period. 3372 One difference between Quick-Start and current proposals for fine- 3373 grained per-packet feedback such as XCP is that XCP is designed to 3374 give robust performance even in the case where different packets 3375 within a connection routinely follow different paths. XCP achieves 3376 relatively robust performance in the presence of multipath routing 3377 by using per-packet feedback, where the feedback carried in a single 3378 packet is about the relative increase or decrease in the rate or 3379 window to take effect when that particular packet is acknowledged, 3380 not about the allowed sending rate for the connection as a whole. 3382 In contrast, Quick-Start sends a single Quick-Start request, and the 3383 answer to that request gives the allowed sending rate for an entire 3384 window of data. As a result, Quick-Start could be problematic in an 3385 environment where some fraction of the packets in a window of data 3386 take path A, and the rest of the packets take path B; for example, 3387 the Quick-Start Request could have travelled on path A, while half 3388 of the Quick-Start packets sent in the succeeding round-trip time 3389 are routed on path B. We note that [ZDPS01] shows Internet paths to 3390 be stable on the order of RTTs. 3392 There are also differences between Quick-Start and some of the 3393 proposals for per-packet feedback in terms of the number of bits of 3394 feedback required from the routers to the end-nodes. Quick-Start 3395 uses four bits of feedback in the rate request field to indicate the 3396 allowed sending rate. XCP allocates a byte for per-packet feedback, 3397 though there has been discussion of variants of XCP with less per- 3398 packet feedback. This would be more like other proposals such as 3399 anti-ECN that use a single bit of feedback from routers to indicate 3400 that the sender can increase as fast as slow-starting, in response 3401 to this particular packet acknowledgement. In general, there is 3402 probably considerable power in fine-grained proposals with only two 3403 bits of feedback, indicating that the sender should decrease, 3404 maintain, or increase the sending rate or window when this packet is 3405 acknowledged. However, the power of Quick-Start would be 3406 considerably limited if it was restricted to only two bits of 3407 feedback; it seems likely that determining the initial sending rate 3408 fundamentally requires more bits of feedback from routers than does 3409 the steady-state, per-packet feedback to increase or decrease the 3410 sending rate. 3412 On a more practical level, one difference between Quick-Start and 3413 proposals for per-packet feedback is that there are fewer open 3414 issues with Quick-Start than there would be with a new congestion 3415 control mechanism. Because Quick-Start is a mechanism for 3416 requesting an initial sending rate in an underutilized environment, 3417 its fairness issues are less severe than those of a general 3418 congestion control mechanism. With Quick-Start, there is no need 3419 for the end nodes to tell the routers the round-trip time and 3420 congestion window, as is done in XCP; all that is needed is for the 3421 end nodes to report the requested sending rate. 3423 Table 3 provides a summary of the differences between Quick-Start 3424 and proposals for per-packet congestion control feedback. 3426 Proposals for 3427 Quick-Start Per-Packet Feedback 3428 +------------------+----------------------+----------------------+ 3429 Semantics: | Allowed sending rate | Change in rate/window, 3430 | per connection. | per-packet. 3431 +------------------+----------------------+----------------------+ 3432 Relationship to | In addition. | Replacement. 3433 congestion ctrl: | | 3434 +------------------+----------------------+----------------------+ 3435 Frequency: | Start-up, or after | Every packet. 3436 | an idle period. | 3437 +------------------+----------------------+----------------------+ 3438 Limitations: | Only useful on | General congestion 3439 | underutilized paths.| control mechanism. 3440 +------------------+----------------------+----------------------+ 3441 Input to routers: | Rate request. |RTT, cwnd, request (XCP) 3442 | | None (Anti-ECN). 3443 +------------------+----------------------+----------------------+ 3444 Bits of feedback: | Four bits for | A few bits would 3445 | rate request. | suffice? 3446 +------------------+----------------------+----------------------+ 3448 Table 3: Differences between Quick-Start and Proposals for 3449 Fine-Grained Per-Packet Feedback. 3451 A separate question concerns whether mechanisms such as Quick-Start, 3452 in combination with HighSpeed TCP and other changes in progress, 3453 would make a significant contribution towards meeting some of these 3454 needs for new congestion control mechanisms. This could be viewed 3455 as a positive step towards meeting some of the more pressing current 3456 needs with a simple and reasonably deployable mechanism, or 3457 alternately, as a negative step of unnecessarily delaying more 3458 fundamental changes. Without answering this question, we would note 3459 that our own approach tends to favor the incremental deployment of 3460 relatively simple mechanisms, as long as the simple mechanisms are 3461 not short-term hacks but mechanisms that lead the overall 3462 architecture in the fundamentally correct direction. 3464 B.7. Alternate Implementations for a Quick-Start Nonce 3465 B.7.1. An Alternate Proposal for the Quick-Start Nonce 3467 An alternate proposal for the Quick-Start Nonce from [B05] would be 3468 for an n-bit field for the QS Nonce, with the sender generating a 3469 random nonce when it generates a Quick-Start Request. Each router 3470 that reduces the Rate Request by r would hash the QS nonce r times, 3471 using a one-way hash function such as MD5 [RFC1321] or the secure 3472 hash 1 [SHA1]. The receiver returns the QS nonce to the sender. 3473 Because the sender knows the original value for the nonce, and the 3474 original rate request, the sender knows the total number of steps s 3475 that the rate has been reduced. The sender then hashes the original 3476 nonce s times, to check whether the result is the same as the nonce 3477 returned by the receiver. 3479 This alternate proposal for the nonce would be considerably more 3480 powerful than the QS nonce described in Section 3.4, but it would 3481 also require more CPU cycles from the routers when they reduce a 3482 Quick-Start request, and from the sender in verifying the nonce 3483 returned by the receiver. As reported in [B05], routers could 3484 protect themselves from processor exhaustion attacks by limiting the 3485 rate at which they will approve reductions of Quick-Start requests. 3487 Both the Function field and the Reserved field in the Quick-Start 3488 Option would allow the extension of Quick-Start to use Quick-Start 3489 requests with the alternate proposal for the Quick-Start Nonce, if 3490 it was ever desired. 3492 B.7.2. The Earlier Request-Approved Quick-Start Nonce 3494 An earlier version of this document included a Request-Approved 3495 Quick-Start Nonce (QS Nonce) that was initialized by the sender to a 3496 non-zero, `random' eight-bit number, along with a QS TTL that was 3497 initialized to the same value as the TTL in the IP header. The 3498 Request-Approved Quick-Start Nonce would have been returned by the 3499 transport receiver to the transport sender in the Quick-Start 3500 Response. A router could deny the Quick-Start request by failing to 3501 decrement the QS TTL field, by zeroing the QS Nonce field, or by 3502 deleting the Quick-Start Request from the packet header. The QS 3503 Nonce was included to provide some protection against broken 3504 downstream routers, or against misbehaving TCP receivers that might 3505 be inclined to lie about whether the Rate Request was approved. 3506 This protection is now provided by the QS Nonce, by the use of a 3507 random initial value for the QS TTL field, and by Quick-Start- 3508 capable routers hopefully either deleting the Quick-Start Option or 3509 zeroing the QS TTL and QS Nonce fields when they deny a request. 3511 With the old Request-Approved Quick-Start Nonce, along with the QS 3512 TTL field set to the same value as the TTL field in the IP header, 3513 the Quick-Start Request mechanism would have been self-terminating; 3514 the Quick-Start Request would terminate at the first participating 3515 router after a non-participating router had been encountered on the 3516 path. This minimizes unnecessary overhead incurred by routers 3517 because of option processing for the Quick-Start Request. In the 3518 current specification, this "self-terminating" property is provided 3519 by Quick-Start-capable routers hopefully either deleting the Quick- 3520 Start Option or zeroing the Rate Request field when they deny a 3521 request. Because the current specification uses a random initial 3522 value for the QS TTL, Quick-Start-capable routers can't tell if the 3523 Quick-Start Request is invalid because of non-Quick-Start-capable 3524 routers upstream. This is the cost of using a design that makes it 3525 difficult for the receiver to cheat about the value of the QS TTL. 3527 C. Quick-Start with DCCP 3529 DCCP is a new transport protocol for congestion-controlled, 3530 unreliable datagrams, intended for applications such as streaming 3531 media, Internet telephony, and on-line games. In DCCP, the 3532 application has a choice of congestion control mechanisms, with the 3533 currently-specified Congestion Control Identifiers (CCIDs) being 3534 CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an 3535 equation-based form of congestion control. We refer the reader to 3536 [RFC4340] for a more detailed description of DCCP, and of the 3537 congestion control mechanisms. 3539 Because CCID 3 uses a rate-based congestion control mechanism, it 3540 raises some new issues about the use of Quick-Start with transport 3541 protocols. In this document we don't attempt to specify the use of 3542 Quick-Start with DCCP. However, we do discuss some of the issues 3543 that might arise. 3545 In considering the use of Quick-Start with CCID 3 for requesting a 3546 higher initial sending rate, the following questions arise: 3548 (1) How does the sender respond if a Quick-Start packet is dropped? 3549 As in TCP, if an initial Quick-Start packet is dropped, the CCID 3 3550 sender should revert to the congestion control mechanisms it would 3551 have used if the Quick-Start request had not been approved. 3553 (2) When does the sender decide there has been no feedback from the 3554 receiver? 3555 Unlike TCP, CCID 3 does not use acknowledgements for every packet, 3556 or for every other packet. In contrast, the CCID 3 receiver sends 3557 feedback to the sender roughly once per round-trip time. In CCID 3, 3558 the allowed sending rate is halved if no feedback is received from 3559 the receiver in at least four round-trip times (when the sender is 3560 sending at least one packet every two round-trip times). When a 3561 Quick-Start request is used, it would seem necessary to use a 3562 smaller time interval, e.g., to reduce the sending rate if no 3563 feedback arrives from the receiver in at least two round-trip times. 3565 The question also arises of how the sending rate should be reduced 3566 after a period of no feedback from the receiver. As with TCP, the 3567 default CCID 3 response of halving the sending rate is not 3568 necessarily a sufficient response to the absence of feedback; an 3569 alternative is to reduce the sending rate to the sending rate that 3570 would have been used if no Quick-Start request had been approved. 3571 That is, if a CCID 3 sender uses a Quick-Start request, special 3572 rules might be required to handle the sender's response to a period 3573 of no feedback from the receiver regarding the Quick-Start packets. 3575 Similarly, in considering the use of Quick-Start with CCID 3 for 3576 requesting a higher sending rate after an idle period, the following 3577 questions arise: 3579 (1) What rate does the sender request? 3580 As in TCP, there is a straightforward answer to the rate request 3581 that the CCID 3 sender should use in requesting a higher sending 3582 rate after an idle period. The sender knows the current loss event 3583 rate, either from its own calculations or from feedback from the 3584 receiver, and can determine the sending rate allowed by that loss 3585 event rate. This is the upper bound on the sending rate that should 3586 be requested by the CCID 3 sender. A Quick-Start request is useful 3587 with CCID 3 when the sender is coming out of an idle or 3588 underutilized period, because in standard operation CCID 3 does not 3589 allow the sender to send more than twice as fast as the receiver has 3590 reported received in the most recent feedback message. 3592 (2) What is the response to loss? 3593 The response to the loss of Quick-Start packets should be to return 3594 to the sending rate that would have been used if Quick-Start had not 3595 been requested. 3597 (3) When does the sender decide there has been no feedback from the 3598 receiver? 3599 As in the case of the initial sending rate, it would seem prudent to 3600 reduce the sending rate if no feedback is received from the receiver 3601 in at least two round-trip times. It seems likely that in this 3602 case, the sending rate should be reduced to the sending rate that 3603 would have been used if no Quick-Start request had been approved. 3605 D. Possible Router Algorithm 3607 This specification does not tightly define the algorithm a router 3608 uses when deciding whether to approve a Quick-Start Rate Request or 3609 whether and how to reduce a Rate Request. A range of algorithms is 3610 likely useful in this space and we consider the algorithm a 3611 particular router uses to be a local policy decision. In addition, 3612 we believe that additional experimentation with router algorithms is 3613 necessary to have a solid understanding of the dynamics various 3614 algorithms impose. However, we provide one particular algorithm in 3615 this appendix as an example and as a framework for thinking about 3616 additional mechanisms. 3618 [SAF06] provides several algorithms routers can use to consider 3619 incoming Rate Requests. The decision process involves two 3620 algorithms. First, the router needs to track the link utilization 3621 over the recent past. Second, this utilization needs to be updated 3622 by the potential new bandwidth from recent Quick-Start approvals, 3623 and then compared with the router's notion of when it is 3624 underutilized enough to approve Quick-Start requests (of some size). 3626 First, we define the "peak utilization" estimation technique (from 3627 [SAF06]). This mechanism records the utilization of the link every 3628 S seconds and stores the most recent N of these measurements. The 3629 utilization is then taken as the highest utilization of the N 3630 samples. This method, therefore, keeps N*S seconds of history. 3631 This algorithm reacts rapidly to increases in the link utilization. 3632 In [SAF06] S is set to 0.15 seconds, and experiments use values for 3633 N ranging from 3 to 20. 3635 Second, we define the "target" algorithm for processing incoming 3636 Quick-Start Rate Requests (also from [SAF06]). The algorithm relies 3637 on knowing the bandwidth of the outgoing link (which in many cases 3638 can be easily configured), the utilization of the outgoing link 3639 (from an estimation technique such as given above) and an estimate 3640 of the potential bandwidth from recent Quick-Start approvals. 3642 Tracking the potential bandwidth from recent Quick-Start approvals 3643 is another case where local policy dictates how it should be done. 3644 The simpliest method, outlined in Section 8.2, is for the router to 3645 keep track of the aggregate Quick-Start rate requests approved in 3646 the most recent two or more time intervals, including the current 3647 time interval, and to use the sum of the aggregate rate requests 3648 over these time intervals as the estimate of the approved Rate 3649 Requests. The experiments in [SAF06] keep track of the aggregate 3650 approved Rate Requests over the most recent two time intervals, for 3651 intervals of 150~msec. 3653 The target algorithm also depends on a threshold (qs_thresh) that is 3654 the fraction of the outgoing link bandwidth that represents the 3655 router's notion of "significantly underutilized". If the 3656 utilization, augmented by the potential bandwidth from recent Quick- 3657 Start approvals, is above this threshold then no Quick-Start Rate 3658 Requests will be approved. If the utilization, again augmented by 3659 the potential bandwidth from recent Quick-Start approvals, is less 3660 than the threshold then Rate Requests can be approved. The Rate 3661 Requests will be reduced such that the bandwidth allocated would not 3662 drive the utilization to more than the given threshold. The 3663 algorithm is: 3665 util_bw = bandwidth * utilization; 3666 util_bw = util_bw + recent_qs_approvals; 3667 if (util_bw < (qs_thresh * bandwidth)) 3668 { 3669 approved = (qs_thresh * bandwidth) - util_bw; 3670 if (rate_request < approved) 3671 approved = rate_request; 3672 approved = round_down (approved); 3673 recent_qs_approvals += approved; 3674 } 3676 Also note that given that Rate Requests are fairly coarse, the 3677 approved rate should be rounded down when it does not fall exactly 3678 on one of the rates allowed by the encoding scheme. 3680 Routers that wish to keep close track of the allocated Quick-Start 3681 bandwidth could use Approved Rate reports to learn when rate 3682 requests had been decremented downstream in the network, and also to 3683 learn when a sender begins to use the approved Quick-Start request. 3685 E. Possible Additional Uses for the Quick-Start Option 3687 The Quick-Start Option contains a four-bit Function field in the 3688 third byte, enabling additional uses to be defined for the Quick- 3689 Start Option. In this section we discuss some of the possible 3690 additional uses that have been discussed for Quick-Start. The 3691 Function field makes it easy to add new functions for the Quick- 3692 Start Option. 3694 Report of Current Sending Rate: A Quick-Start Request with the 3695 `Report of Current Sending Rate' codepoint set in the Function field 3696 would be using the Rate Request field to report the current 3697 estimated sending rate for that connection. This could accompany a 3698 second Quick-Start Request in the same packet containing a standard 3699 rate request, for a connection that is using Quick-Start to increase 3700 its current sending rate. 3702 Request to Increase Sending Rate: A codepoint for `Request to 3703 Increase Sending Rate' in the Function field would indicate that the 3704 connection is not idle or just starting up, but is attempting to use 3705 Quick-Start to increase its current sending rate. This codepoint 3706 would not change the semantics of the Rate Request field. 3708 RTT Estimate: If a codepoint for `RTT Estimate' was used, a field 3709 for the RTT Estimate would contain one or more bits giving the 3710 sender's rough estimate of the round-trip time, if known. E.g., the 3711 sender could estimate whether the RTT was greater or less than 200 3712 ms. Alternately, if the sender had an estimate of the RTT when it 3713 sends the Rate Request, the two-bit Reserved field at the end of the 3714 Quick-Start Option could be used for a coarse-grained encoding of 3715 the RTT. 3717 Informational Request: An Informational Request codepoint in the 3718 Function field would indicate that a request is purely 3719 informational, for the sender to find out if a rate request would be 3720 approved, and what size rate request would be approved, when the 3721 Informational Request is sent. For example, an Informational 3722 Request could be followed one round-trip time later by a standard 3723 Quick-Start Request. A router approving an Informational Request 3724 would not consider this as an approval for Quick-Start bandwidth to 3725 be used, and would not be under any obligation to approve a similar 3726 standard Quick-Start Request one round-trip time later. An 3727 Informational Request with a rate request of zero could be used by 3728 the sender to find out if all of the routers along the path 3729 supported Quick-Start. 3731 Use Format X for the Rate Request Field: A Quick-Start codepoint for 3732 `Use Format X for the Rate Request Field' would indicate that an 3733 alternate format was being used for the Rate Request field. 3735 Do Not Decrement: A Do Not Decrement codepoint could be used for a 3736 Quick-Start request where the sender would rather have the request 3737 denied than to have the rate request decremented in the network. 3738 This could be used if the sender was only interested in using Quick- 3739 Start if the original rate request was approved. 3741 Temporary Bandwidth Use: A Temporary codepoint has been proposed to 3742 indicate that a connection would only use the requested bandwidth 3743 for a single time interval. 3745 Normative References 3747 [RFC793] J. Postel, Transmission Control Protocol, RFC 793, 3748 September 1981. 3750 [RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191, 3751 November 1990. 3753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3754 Requirement Levels", BCP 14, RFC 2119, March 1997. 3756 [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 3757 (IPv6) Specification. RFC 2460, December 1998. 3759 [RFC2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 3760 Control. RFC 2581. April 1999. 3762 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D. The Addition 3763 of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed 3764 Standard, September 2001. 3766 [RFC3390] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's 3767 Initial Window. RFC 3390, October 2002. 3769 [RFC3742] Floyd, S., Limited Slow-Start for TCP with Large 3770 Congestion Windows, RFC 3742, Experimental, March 2004. 3772 Informative References 3774 [RFC792] J. Postel. Internet Control Message Protocol. RFC 792, 3775 September 1981. 3777 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3778 April 1992. 3780 [RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC 3781 1812, June 1995. 3783 [RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, 3784 October 1996. 3786 [RFC2113] D. Katz. P Router Alert Option. RFC 2113, February 1997. 3788 [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. 3789 April 1997. 3791 [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- 3792 Version 1 Functional Specification. RFC 2205, September 1997. 3794 [RFC2401] S. Kent and R. Atkinson, Security Architecture for the 3795 Internet Protocol, RFC 2401, November 1998. 3797 [RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC 3798 2402, November 1998. 3800 [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), 3801 RFC 2409, November 1998. 3803 [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased 3804 Initial TCP Window Size. RFC 2415. September 1998. 3806 [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol 3807 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. 3808 RFC 2463, December 1998. 3810 [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over 3811 Satellite Channels using Standard Mechanisms. RFC 2488. January 3812 1999. 3814 [RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and 3815 B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August 3816 1999. 3818 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, 3819 Generic Routing Encapsulation (GRE), RFC 2784, March 2000. 3821 [RFC2960] R. Stewart, et al. Stream Control Transmission Protocol. 3822 RFC 2960, October 2000. 3824 [RFC3031] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol 3825 Label Switching Architecture. RFC 3031. January 2001. 3827 [RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC 3828 3124. June 2001. 3830 [RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and 3831 Issues, RFC 3234, February 2002. 3833 [RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344, 3834 August 2002. 3836 [RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. 3837 RFC 3360, August 2002. 3839 [RFC3649] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC 3840 3649, December 2003. 3842 [RFC3662] R. Bless, K. Nichols, and K. Wehrle. A Lower Effort Per- 3843 Domain Behavior (PDB) for Differentiated Services. RFC 3662, 3844 December 2003. 3846 [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in 3847 IPv6. RFC 3775, June 2004. 3849 [RFC3819] P. Karn et al., "Advice for Internet Subnetwork 3850 Designers", July 2004. 3852 [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. 3853 Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January 3854 2005. 3856 [RFC4301] S. Kent and K. Seo, Security Architecture for the Internet 3857 Protocol, RFC 4301, December 2005. 3859 [RFC4302] S. Kent, IP Authentication Header, RFC 4302, December 3860 2005. 3862 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 3863 4306, December 2005. 3865 [RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion 3866 Control Protocol (DCCP), RFC 4340, March 2006. 3868 [RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion 3869 Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion 3870 Control, RFC 4341, March 2006. 3872 [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP 3873 with Larger Initial Windows. ACM Computer Communication Review, July 3874 1998. 3876 [B05] B. Briscoe, Review: Quick-Start for TCP and IP, internet-draft 3877 draft-briscoe-tsvwg-quickstart-rvw-00, work-in-progress, URL 3878 "http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html", November 2005. 3880 [BJCG+05] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., 3881 Salvatori, A., Soppera, A., and M. Koyabe, "Policing Congestion 3882 Response in an Internetwork Using Re-Feedback", SIGCOMM, August 3883 2005. 3885 [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of 3886 the new GSM Phase 2+ General Packet Radio Service. IEEE 3887 Communications Magazine, pages 94--104, August 1997. 3889 [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi- 3890 Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE 3891 Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, 3892 September 2002. 3894 [H05] P. Hoffman, email, October 2005. Citation for acknowledgement 3895 purposes only. 3897 [HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion 3898 Detection: Evasion, Traffic Normalization, and End-to-End Protocol 3899 Semantics, Proc. USENIX Security Symposium 2001. 3901 [Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM 3903 [JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available 3904 Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP 3905 Throughput, SIGCOMM 2002. 3907 [K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High 3908 Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. 3909 URL "http://www.seas.upenn.edu/~kunniyur/". 3911 [KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. 3912 Sterbenz. Explicit Transport Error Notification (ETEN) for Error- 3913 Prone Wireless and Satellite Networks. Technical Report No. 8333, 3914 BBN Technologies, March 2002. URL 3915 "http://www.icir.org/mallman/papers/". 3917 [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet 3918 Congestion Control for Future High Bandwidth-Delay Product 3919 Environments. ACM Sigcomm 2002, August 2002. URL 3920 "http://ana.lcs.mit.edu/dina/XCP/". 3922 [KK03] A. Kuzmanovic and E. W. Knightly. TCP-LP: A Distributed 3923 Algorithm for Low Priority Data Transfer. INFOCOM 2003, April 2003. 3925 [KSEPA04] Rajesh Krishnan, James Sterbenz, Wesley Eddy, Craig 3926 Partridge, Mark Allman. Explicit Transport Error Notification (ETEN) 3927 for Error-Prone Wireless and Satellite Networks. Computer Networks, 3928 46(3), October 2004. 3930 [L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005. 3931 URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf". 3933 [MH06] M. Mathis and J. Heffner, Packetization Layer Path MTU 3934 Discovery, internet-draft draft-ietf-pmtud-method-07.txt, work in 3935 progress, June 2006. 3937 [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring 3938 Interactions Between Transport Protocols and Middleboxes, Internet 3939 Measurement Conference 2004, August 2004. URL 3940 "http://www.icir.org/tbit/". 3942 [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the 3943 Evolution of Transport Protocols in the Internet. Computer 3944 Communications Review, April 2005. 3946 [MaxNet] MaxNet Home Page, URL 3947 "http://netlab.caltech.edu/~bartek/maxnet.htm". 3949 [P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection, 3950 report to John Jeidemann, 2000, private communication. Citation for 3951 acknowledgement purposes only. 3953 [PABL+05] Ruoming Pang, Mark Allman, Mike Bennett, Jason Lee, Vern 3954 Paxson, Brian Tierney. A First Look at Modern Enterprise Traffic. 3955 ACM SIGCOMM/USENIX Internet Measurement Conference, October 2005. 3957 [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh 3958 Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical 3959 Report No. 8339, BBN Technologies, March 2002. URL 3960 "http://www.icir.org/mallman/papers/". 3962 [RW03] Mattia Rossi and Michael Welzl, On the Impact of IP Option 3963 Processing, Preprint-Reihe des Fachbereichs Mathematik - Informatik, 3964 No. 15, Institute of Computer Science, University of Innsbruck, 3965 Austria, October 2003. 3967 [RW04] Mattia Rossi and Michael Welzl, On the Impact of IP Option 3968 Processing - Part 2, Preprint-Reihe des Fachbereichs Mathematik - 3969 Informatik, No. 26, Institute of Computer Science, University of 3970 Innsbruck, Austria, July 2004. 3972 [S02] Ion Stoica, private communication, 2002. Citation for 3973 acknowledgement purposes only. 3975 [SAF06] Pasi Sarolahti, Mark Allman, and Sally Floyd. Determining 3976 an Appropriate Sending Rate Over an Underutilized Network Path. 3977 February 2006. URL "http://www.icir.org/floyd/quickstart.html". 3979 [SGF05] Singh, M., Guha, S., and P. Francis, "Utilizing spare 3980 network bandwidth to improve TCP performance", ACM SIGCOMM 2005 Work 3981 in Progress session, August 2005, 3982 https://www.guha.cc/saikat/pub/sigcomm05-lowtcp.pdf. 3984 [SHA1] "Secure Hash Standard", FIPS, U.S. Department of Commerce, 3985 Washington, D.C. publication 180-1, April 1995. 3987 [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick 3988 Start with NS-2. Class Project, December 2002. Not publicly 3989 available; citation for acknowledgement purposes only. 3991 [V02] A. Venkataramani, R. Kokku, and M. Dahlin. TCP Nice: A 3992 Mechanism for Background Transfers. OSDI 2002. 3994 [VH97] V. Visweswaraiah and J. Heidemann, Improving Restart of Idle 3995 TCP Connections, Technical Report 97-661, University of Southern 3996 California, November 1997. 3998 [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed 3999 Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE 4000 International Performance, Computing, And Communications 4001 Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL 4002 "http://www.welzl.at/research/publications/". 4004 [ZDPS01] Y. Zhang, N. Duffield, V. Paxson, and S. Shenker, On the 4005 Constancy of Internet Path Properties, Proc. ACM SIGCOMM Internet 4006 Measurement Workshop, November 2001. 4008 [ZQK00] Y. Zhang, L. Qiu, and S. Keshav, Speeding Up Short Data 4009 Transfers: Theory, Architectural Support, and Simulation Results, 4010 NOSSDAV 2000, June 2000. 4012 AUTHORS' ADDRESSES 4014 Sally Floyd 4015 Phone: +1 (510) 666-2989 4016 ICIR (ICSI Center for Internet Research) 4017 Email: floyd@icir.org 4018 URL: http://www.icir.org/floyd/ 4020 Mark Allman 4021 ICSI Center for Internet Research 4022 1947 Center Street, Suite 600 4023 Berkeley, CA 94704-1198 4024 Phone: (440) 235-1792 4025 Email: mallman@icir.org 4026 URL: http://www.icir.org/mallman/ 4028 Amit Jain 4029 F5 Networks 4030 Email : a.jain@f5.com 4031 Pasi Sarolahti 4032 Nokia Research Center 4033 P.O. Box 407 4034 FI-00045 NOKIA GROUP 4035 Finland 4036 Phone: +358 50 4876607 4037 Email: pasi.sarolahti@iki.fi 4039 Full Copyright Statement 4041 Copyright (C) The Internet Society 2006. This document is subject 4042 to the rights, licenses and restrictions contained in BCP 78, and 4043 except as set forth therein, the authors retain all their rights. 4045 This document and the information contained herein are provided on 4046 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 4047 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 4048 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 4049 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4050 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4051 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4053 Intellectual Property 4055 The IETF takes no position regarding the validity or scope of any 4056 Intellectual Property Rights or other rights that might be claimed 4057 to pertain to the implementation or use of the technology described 4058 in this document or the extent to which any license under such 4059 rights might or might not be available; nor does it represent that 4060 it has made any independent effort to identify any such rights. 4061 Information on the procedures with respect to rights in RFC 4062 documents can be found in BCP 78 and BCP 79. 4064 Copies of IPR disclosures made to the IETF Secretariat and any 4065 assurances of licenses to be made available, or the result of an 4066 attempt made to obtain a general license or permission for the use 4067 of such proprietary rights by implementers or users of this 4068 specification can be obtained from the IETF on-line IPR repository 4069 at http://www.ietf.org/ipr. 4071 The IETF invites any interested party to bring to its attention any 4072 copyrights, patents or patent applications, or other proprietary 4073 rights that may cover technology that may be required to implement 4074 this standard. Please address the information to the IETF at ietf- 4075 ipr@ietf.org.