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