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