idnits 2.17.1 draft-ietf-tsvwg-quickstart-01.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 3341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3365. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3333), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([KHR02]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 81: '... say that sender SHOULD send one packe...' RFC 2119 keyword, line 83: '... say that the TCP sender SHOULD use an...' RFC 2119 keyword, line 101: '... SHOULD delete the Quick-Start o...' RFC 2119 keyword, line 102: '... possible, SHOULD zero the QS TT...' RFC 2119 keyword, line 111: '... Added that "TCP SHOULD NOT use Quick-...' (56 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (13 October 2005) is 6763 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 618, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'T1' is mentioned on line 1602, but not defined == Missing Reference: 'T2' is mentioned on line 1600, but not defined == Missing Reference: 'T0' is mentioned on line 1602, but not defined == Unused Reference: 'RFC2246' is defined on line 3104, but no explicit reference was found in the text == Unused Reference: 'RFC2309' is defined on line 3106, but no explicit reference was found in the text == Unused Reference: 'RFC2416' is defined on line 3128, but no explicit reference was found in the text == Unused Reference: 'FF99' is defined on line 3176, but no explicit reference was found in the text == Unused Reference: 'PK98' is defined on line 3239, but no explicit reference was found in the text == Unused Reference: 'W03' is defined on line 3269, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Downref: Normative reference to an Experimental RFC: RFC 3742 -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2463 (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 Summary: 11 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 A. Jain 2 INTERNET-DRAFT F5 Networks 3 draft-ietf-tsvwg-quickstart-01.txt S. Floyd 4 Expires: April 2006 M. Allman 5 ICIR 6 P. Sarolahti 7 Nokia Research Center 8 13 October 2005 10 Quick-Start for TCP and IP 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This document specifies an optional Quick-Start mechanism for 44 transport protocols, in cooperation with routers, to determine an 45 allowed sending rate at the start and at times in the middle of a 46 data transfer (e.g., after an idle period). While Quick-Start is 47 designed to be used by a range of transport protocols, in this 48 document we describe its use with TCP. By using Quick-Start, a TCP 49 host, say, host A, would indicate its desired sending rate in bytes 50 per second, using a Quick Start Request option in the IP header of a 51 TCP packet. Each router along the path could, in turn, either 52 approve the requested rate, reduce the requested rate, or indicate 53 that the Quick-Start request is not approved. If the Quick-Start 54 request is not approved, then the sender would use the default 55 congestion control mechanisms. The Quick-Start mechanism can 56 determine if there are routers along the path that do not understand 57 the Quick-Start Request option, or have not agreed to the Quick- 58 Start rate request. TCP host B communicates the final rate request 59 to TCP host A in a transport-level Quick-Start Response in an 60 answering TCP packet. Quick-Start is designed to allow connections 61 to use higher sending rates when there is significant unused 62 bandwidth along the path, and all of the routers along the path 63 support the Quick-Start Request. 65 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 66 Changes from draft-ietf-tsvwg-quickstart-00: 67 * Added a 30-bit QS Nonce. Based on feedback from Guohan Lu 68 and Gorry Fairhurst (and deleted the text about a possible 69 four-bit QS nonce). 70 * Added a new section "Quick-Start and IPsec AH", based on feedback 71 from Joe Touch and David Black. 72 * Revised "Quick-Start in IP Tunnels" Section, based on feedback 73 from Joe Touch and David Black. 74 * Added a section about "Possible Uses for the Reserved Fields". 75 * Changes from feedback from Gorry Fairhurst: 76 - Section 4.4, revised the explanation for reducing the 77 congestion window when the first ACK for a Quick-Start 78 packet is received. 79 - Section 6.4, deleted the last sentence. 80 - Minor editing changes. 81 - Revised Section 4.6.2 to say that sender SHOULD send one packet 82 with an initial RTO of three seconds. 83 - Revised Section 4.6.3 to say that the TCP sender SHOULD use an 84 initial RTO setting of three seconds. 85 - Added text to Section 6.2 on Multiple Paths, discussing 86 multi-path routing. 87 - Clarified about GPRS round-trip times. 88 - Clarified about PMTUD and the first window of data. 89 - A small reorganization, rearranging sections. 90 * Changes from feedback from Martin Duke: 91 - Revised text about the size of QS requests. 92 - Added some text to Section 4.1, about when to send QS requests. 94 Changes from draft-amit-quick-start-04.txt: 95 * A significant amount of general editing. 96 * Because the Rate Request field only uses four bits, specified 97 that the other four bits are reserved, and talked about a 98 possible use for them. This is discussed in a new section on 99 "A Rate-Reduced Nonce?" 100 * Specified that a Quick-Start-capable router denying a request 101 SHOULD delete the Quick-Start option, and if this is not 102 possible, SHOULD zero the QS TTL and the Rate Request fields. 103 * Made the following change: If the Quick-Start Response is lost 104 in the network, it is not retransmitted. 105 * For PMTUD, in Section 4.6, added a suggestion to send one large 106 packet in the initial window for PMTUD, and to send the other 107 packets at 576 bytes. 108 * Added a paragraph to Section 4.6.3 on retransmitted SYN packets, 109 saying they should use an RTO of three seconds and a new ISN 110 on the retransmitted SYN packet. 111 * Added that "TCP SHOULD NOT use Quick-Start" after an 112 application-limited period at this time, in Section 4.1, in 113 addition to the old sentence that this "requires further thought 114 and investigation". 115 * Added an appendix on "Possible Router Algorithm". 116 * Moved the section on "Quick-Start with DCCP" to the appendix. 117 * Name changed from draft-amit-quick-start-04.txt to 118 draft-tsvwg-quickstart-00.txt. 120 Changes from draft-amit-quick-start-03.txt: 121 * Added a citation to the paper on "Evaluating Quick-Start for 122 TCP", and added pointers to the work in that paper. 123 This work includes: 124 - Discussions of router algorithms. 125 - Discussions of sizing Quick-Start requests. 126 * Added sections on "Misbehaving Middleboxes", and on "Attacks on 127 Quick-Start". 129 Changes from draft-amit-quick-start-02.txt: 130 * Added a discussion on Using Quick-Start in the Middle of a 131 Connection. The request would be on the total rate, 132 not on the additional rate. 133 * Changed name "Initial Rate" to "Rate Request", and changed 134 the units from packets per second to bytes per second. 135 * The following sections are new: 136 - The Quick-Start Request Option for IPv6 137 - Quick-Start in IP Tunnels 138 - When to Use Quick-Start 139 - TCP: Responding to a Loss of a Quick-Start Packet 140 - TCP: A Quick-Start Request for a Larger Initial Window 141 - TCP: A Quick-Start Request after an Idle Period 142 - The Quick-Start Mechanisms in DCCP and other Transport 143 Protocols 144 - Quick-Start with DCCP 145 - Implementation and Deployment Issues 146 - Design Decisions 147 * Added a discussion of Kunniyur's Anti-ECN proposal. 148 * Added a section on simulations, with a brief discussion of the 149 simulations by Srikanth Sundarrajan. 151 Changes from draft-amit-quick-start-01.txt: 152 * Added a discussion in the related work section about the 153 possibility of optimistically sending a large initial window, 154 without explicit permission of routers. 155 * Added a discussion in the related work section about the 156 tradeoffs of XCP vs. Quick-Start. 157 * Added a section on "The Quick-Start Request: Packets or Bytes?" 159 Changes from draft-amit-quick-start-00.txt: 160 * The addition of a citation to [KHR02]. 162 * The addition of a Related Work section. 163 * Deleted the QS Nonce, in favor of a random initial value for the 164 QS TTL. 166 Table of Contents 168 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9 169 2. Assumptions and General Principles. . . . . . . . . . . . . . 10 170 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 11 171 3. The Quick-Start Request in IP . . . . . . . . . . . . . . . . 14 172 3.1. The Quick-Start Request Option for IPv4. . . . . . . . . 14 173 3.2. The Quick-Start Request Option for IPv6. . . . . . . . . 16 174 3.3. Processing the Quick-Start Request at 175 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 176 3.4. The QS Nonce . . . . . . . . . . . . . . . . . . . . . . 18 177 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 20 178 4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 21 179 4.2. The Quick-Start Response Option in the TCP 180 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 181 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 24 182 4.4. TCP: Receiving and Using the Quick-Start 183 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 24 184 4.5. TCP: Responding to a Loss of a Quick-Start 185 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 186 4.6. TCP: A Quick-Start Request for a Larger Ini- 187 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 27 188 4.6.1. Interactions with Path MTU Discovery. . . . . . . . 27 189 4.6.2. Quick-Start Request Packets that are 190 Discarded by Middleboxes . . . . . . . . . . . . . . . . . 27 191 4.7. TCP: A Quick-Start Request in the Middle of 192 Connection. . . . . . . . . . . . . . . . . . . . . . . . . . 29 193 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 29 194 5. Quick-Start and IPsec AH. . . . . . . . . . . . . . . . . . . 30 195 6. Quick-Start in IP Tunnels . . . . . . . . . . . . . . . . . . 31 196 6.1. Simple Tunnels That Are Compatible with 197 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 33 198 6.1.1. Simple Tunnels that are Aware of Quick- 199 Start. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 200 6.2. Simple Tunnels That Are Not Compatible with 201 Quick-Start . . . . . . . . . . . . . . . . . . . . . . . . . 34 202 6.3. Tunnels That Support Quick-Start . . . . . . . . . . . . 35 203 7. The Quick-Start Mechanism in other Transport Pro- 204 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 205 8. Using Quick-Start . . . . . . . . . . . . . . . . . . . . . . 37 206 8.1. Determining the Rate to Request. . . . . . . . . . . . . 37 207 8.2. Deciding the Permitted Rate Request at a 208 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 209 9. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 38 210 9.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 39 211 9.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 39 212 9.3. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 41 213 9.4. Protection against Misbehaving Nodes . . . . . . . . . . 41 214 9.4.1. Receivers Lying about Whether the 215 Request was Approved . . . . . . . . . . . . . . . . . . . 41 216 9.4.2. Receivers Lying about the Approved 217 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 218 9.4.3. Collusion between Misbehaving Routers . . . . . . . 43 219 9.4.4. Misbehaving Middleboxes and the IP 220 TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 221 9.5. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 45 222 9.6. Simulations with Quick-Start . . . . . . . . . . . . . . 45 223 10. Implementation and Deployment Issues . . . . . . . . . . . . 46 224 10.1. Implementation Issues for Sending Quick- 225 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 46 226 10.2. Implementation Issues for Processing Quick- 227 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 47 228 10.3. Possible Deployment Scenarios . . . . . . . . . . . . . 47 229 10.4. Would QuickStart packets take the slow path 230 in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 48 231 10.5. A Comparison with the Deployment Problems 232 of ECN. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 233 11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 49 234 11.1. Fast Start-ups without Explicit Information 235 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 49 236 11.2. Optimistic Sending without Explicit Infor- 237 mation from Routers . . . . . . . . . . . . . . . . . . . . . 50 238 11.3. Fast Start-ups with other Information from 239 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 240 11.4. Fast Start-ups with more Fine-Grained Feed- 241 back from Routers . . . . . . . . . . . . . . . . . . . . . . 52 242 12. Security Considerations. . . . . . . . . . . . . . . . . . . 52 243 13. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 53 244 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 245 A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 54 246 A.1. Alternate Mechanisms for the Quick-Start 247 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 54 248 A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 54 249 A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 56 250 A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 57 251 A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 58 252 A.4. Quick-Start Semantics: Total Rate or Addi- 253 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 59 254 A.5. Alternate Responses to the Loss of a Quick- 255 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 60 256 A.6. Why Not Include More Functionality?. . . . . . . . . . . 61 257 A.7. The Earlier QuickStart Nonce . . . . . . . . . . . . . . 64 258 B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 65 259 C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 67 260 D. Possible Uses for the Reserved Fields . . . . . . . . . . . . 68 261 Normative References . . . . . . . . . . . . . . . . . . . . . . 70 262 Informative References . . . . . . . . . . . . . . . . . . . . . 70 263 E. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 264 E.1. IP Option. . . . . . . . . . . . . . . . . . . . . . . . 74 265 E.2. TCP Option . . . . . . . . . . . . . . . . . . . . . . . 75 266 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 75 267 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 75 268 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 76 270 1. Introduction 272 Each TCP connection begins with a question: "What is the appropriate 273 sending rate for the current network path?" The question is not 274 answered explicitly for TCP, but each TCP connection determines the 275 sending rate by probing the network path and altering the congestion 276 window (cwnd) based on perceived congestion. Each connection starts 277 with a pre-configured initial congestion window (ICW). Currently, 278 TCP allows an initial window of between one and four MSS-sized 279 segments [RFC2581,RFC3390]. The TCP connection then probes the 280 network for available bandwidth using the slow-start procedure 281 [Jac88,RFC2581], doubling cwnd during each congestion-free round- 282 trip time (RTT). 284 The slow-start algorithm can be time-consuming --- especially over 285 networks with large bandwidth or long delays. It may take a number 286 of RTTs in slow-start before the TCP connection begins to fully use 287 the available bandwidth of the network. For instance, it takes 288 log_2(N) - 2 round-trip times to build cwnd up to N segments, 289 assuming an initial congestion window of 4 segments. This time in 290 slow-start is not a problem for large file transfers, where the 291 slow-start stage is only a fraction of the total transfer time. 292 However, in the case of moderate-sized transfers the connection 293 might carry out its entire transfer in the slow-start phase, taking 294 many round-trip times, where one or two RTTs might have been 295 appropriate in the current network conditions. 297 A fair amount of work has already been done to address the issue of 298 choosing the initial congestion window for TCP, with RFC 3390 299 allowing an initial window of up to four segments based on the MSS 300 used by the connection [RFC3390]. Our underlying premise is that 301 explicit feedback from all of the routers along the path would be 302 required, in the current architecture, for best-effort connections 303 to use initial windows significantly larger than those allowed by 304 [RFC3390], in the absence of other information about the path. 306 The Congestion Manager [RFC3124] and TCP control block sharing 307 [RFC2140] both propose sharing congestion information among multiple 308 TCP connections with the same endpoints. With the Congestion 309 Manager, a new TCP connection could start with a high initial cwnd 310 if it was sharing the path and the cwnd with a pre-existing TCP 311 connection to the same destination that had already obtained a high 312 congestion window. RFC 2140 discusses ensemble sharing, where an 313 established connection's congestion window could be `divided up' to 314 be shared with a new connection to the same host. However, neither 315 of these approaches addresses the case of a connection to a new 316 destination, with no existing or recent connection (and therefore 317 congestion control state) to that destination. 319 Quick-Start would not be the first mechanism for explicit 320 communication from routers to transport protocols about sending 321 rates. Explicit Congestion Notification (ECN) gives explicit 322 congestion control feedback from routers to transport protocols, 323 based on the router detecting congestion before buffer overflow 324 [RFC3168]. In contrast, routers would not use Quick-Start to get 325 congestion information, but instead would use Quick-Start as an 326 optional mechanism to give permission to transport protocols to use 327 higher sending rates, based on the ability of all the routers along 328 the path to determine if their respective output links are 329 significantly underutilized. 331 2. Assumptions and General Principles 333 This section describes the assumptions and general principles behind 334 the design of the Quick-Start mechanism. 336 Assumptions: 338 * The data transfer in the two directions of a connection traverses 339 different queues, and possibly even different routers. Thus, any 340 mechanism for determining the allowed sending rate would have to be 341 used independently for each direction. 343 * The path between the two endpoints is relatively stable, such that 344 the path used by the Quick-Start request is generally the same path 345 used by the Quick-Start packets one round-trip time later. [ZPS00] 346 shows this assumption should be generally valid, although [RFC3819] 347 discusses a range of Bandwidth on Demand subnets. 349 * Any new mechanism must be incrementally deployable, and might not 350 be supported by all of the routers and/or end-hosts. Thus, any new 351 mechanism must be able to accommodate non-supporting routers or end- 352 hosts without disturbing the current Internet semantics. 354 General Principles: 356 * Our underlying premise is that explicit feedback from all of the 357 routers along the path would be required, in the current 358 architecture, for best-effort connections to use initial windows 359 significantly larger than those allowed by [RFC3390], in the absence 360 of other information about the path. 362 * A router should only approve a request for a higher sending rate 363 if the output link is underutilized. Any other approach will result 364 in either per-flow state at the router, or the possibility of a 365 (possibly transient) queue at the router. 367 * No per-flow state should be required at the router. Note that 368 while per-flow state is not required we also do not preclude a 369 router from storing per-flow state for making Quick-Start decisions. 371 There are also a number of questions regarding the Quick-Start 372 mechanism that are discussed later in this document. 374 Questions: 376 * Would the benefits of the Quick-Start mechanism be worth the added 377 complexity? 379 The benefits and drawbacks of Quick-Start are discussed in more 380 detail in Section 9 on "Evaluation of Quick-Start". 382 * One practical consideration is that packets with known and unknown 383 IP options are often dropped in the current Internet [MAF04]. 385 This does not preclude using Quick-Start in Intranets. Further, 386 [MAF04] also shows that over time the blocking of packets 387 negotiating ECN has become less common, and therefore an incremental 388 deployment story for Quick-Start based on IP Options is not out of 389 the question. Appendix A.1 on "Alternate Mechanisms for the Quick- 390 Start Request" discusses the possibility of using RSVP or ICMP 391 instead of IP Options for carrying Quick-Start Requests to routers. 393 * A second practical consideration is that packets could be dropped 394 at non-IP queues along the path. 396 This is discussed in more detail in Section 9.2 . 398 * Apart from the merits and shortcomings of the Quick-Start 399 mechanism, is there likely to be a compelling need to add explicit 400 congestion-related feedback from routers over and above the one-bit 401 feedback from ECN? 403 If the answer to the question above is yes, should we be considering 404 ways to incorporate Quick-Start in mechanisms that, while more 405 complex, are also sufficiently more powerful than Quick-Start, or 406 should Quick-Start be considered as orthogonal to such mechanisms? 407 This is discussed further in Appendix A.6 on "Why Not Include More 408 Functionality". 410 2.1. Overview of Quick-Start 412 In this section we give an overview of the use of Quick-Start with 413 TCP, to request a higher congestion window. The description in this 414 section is non-normative; the normative description of Quick-Start 415 with IP and TCP follows in Sections 3 and 4. Quick-Start can be used 416 in the middle of a connection, e.g., after an idle or underutilized 417 period, as well as for the initial sending rate; these uses of 418 Quick-Start are discussed later in the document. 420 Quick-Start requires end-points and routers to work together, with 421 end-points requesting a higher sending rate in the Quick-Start 422 Request (QSR) option in IP, and routers along the path approving, 423 modifying, discarding or ignoring (and therefore disallowing) the 424 Quick-Start Request. The receiver uses reliable, transport-level 425 mechanisms to inform the sender of the status of the Quick-Start 426 Request. In addition, Quick-Start assumes a unicast, congestion- 427 controlled transport protocol; we do not consider the use of Quick- 428 Start for multicast traffic. 430 The Quick-Start Request Option includes a request for a sending rate 431 in bytes per second, and a Quick-Start TTL (QS TTL) to be 432 decremented by every router along the path that understands the 433 option and approves the request. The Quick-Start TTL is initialized 434 by the sender to a random value. The transport receiver returns the 435 rate and information about the TTL to the sender using transport- 436 level mechanisms. In particular, the receiver computes the 437 difference between the Quick-Start TTL and the IP TTL (the TTL in 438 the IP header) of the Quick-Start request packet, and returns this 439 in the Quick-Start response. The sender uses this information to 440 determine if all of the routers along the path decremented the 441 Quick-Start TTL, approving the Quick-Start Request. 443 If the request is approved by all of the routers along the path, 444 then the TCP sender combines this allowed rate with the measurement 445 of the round-trip time, and ends up with an allowed TCP congestion 446 window. This window is sent rate-paced over the next round-trip 447 time, or until an ACK packet is received. 449 Figure 1 shows a successful use of Quick-Start, with both routers 450 along the path approving the Quick-Start Request. In this example, 451 Quick-Start is used by TCP to establish the initial congestion 452 window. 454 Sender Router 1 Router 2 Receiver 455 ------ -------- -------- -------- 456 | 457 | 458 | 459 | Quick-Start Request 460 | in SYN or SYN/ACK --> 461 | 462 | Decrement 463 | QS TTL 464 | to approve 465 | request --> 466 | 467 | Decrement 468 | QS TTL 469 | to approve 470 | request --> 471 | 472 | 473 | 474 | 475 | Return Quick-Start 476 | info to sender in 477 | <-- TCP ACK packet. 478 | 479 | 480 | Quick-Start approved, 481 | translate to cwnd. 482 V Send cwnd paced over one RTT. --> 484 Figure 1: A successful Quick-Start Request. 486 Figure 2 shows an unsuccessful use of Quick-Start, with one of the 487 routers along the path not approving the Quick-Start Request. If 488 the Quick-Start Request is not approved, then the sender uses the 489 default congestion control mechanisms for that transport protocol, 490 including the default initial congestion window, response to idle 491 periods, etc. 493 Sender Router 1 Router 2 Receiver 494 ------ -------- -------- -------- 495 | 496 | 497 | 498 | Quick-Start Request 499 | in SYN or SYN/ACK --> 500 | 501 | Decrement 502 | QS TTL 503 | to approve 504 | request --> 505 | 506 | Forward packet 507 | without modifying 508 | Quick-Start Option. --> 509 | 510 | 511 | 512 | 513 | Return Quick-Start 514 | info to sender in 515 | <-- TCP ACK packet. 516 | 517 | 518 | Quick-Start not approved. 519 V Use default initial cwnd. --> 521 Figure 2: An unsuccessful Quick-Start Request. 523 3. The Quick-Start Request in IP 525 3.1. The Quick-Start Request Option for IPv4 527 The Quick-Start Request for IPv4 is defined as follows: 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Option | Length=8 | QS TTL | Resv. | Rate | 533 | | | | |Request| 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | QS Nonce | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 3. The Quick-Start Request Option for IPv4. 540 The first byte contains the option field, which includes the one-bit 541 copy flag, the 2-bit class field, and the 5-bit option number (to be 542 assigned by IANA). 544 The second byte contains the length field, indicating an option 545 length of eight bytes. 547 The third byte contains the Quick-Start TTL (QS TTL) field. The 548 sender MUST set the QS TTL field to a random value. Routers that 549 approve the Quick-Start Request decrement the QS TTL (mod 256). The 550 QS TTL is used by the sender to detect if all of the routers along 551 the path understood and approved the Quick-Start option. 553 The transport sender MUST calculate and store the TTL Diff, the 554 difference between the IP TTL value and the QS TTL value in the 555 Quick-Start request packet, as follows: 557 TTL Diff = ( IP TTL - QS TTL ) mod 256 (1) 559 The fourth byte includes a four-bit Reserved field, and a four-bit 560 Rate Request field. The second four bytes contain a 30-bit QS Nonce 561 and a two-bit Reserved field. The sender SHOULD set the reserved 562 fields to zero, and routers SHOULD ignore the reserved fields. The 563 sender SHOULD set the 30-bit QS Nonce to a random value. 565 The sender initializes the Rate Request to the desired sending rate, 566 including an estimate of the transport and IP header overhead. The 567 encoding function for the Rate Request sets the request rate to 568 K*2^N bps (bits per second), for N the value in the Rate Request 569 field, and for K set to 40,000. For N=0, the rate request would be 570 set to zero, regardless of the encoding function. This is 571 illustrated in Table 1 below. For the four-bit Rate Request field, 572 the request range is from 80 Kbps to 1.3 Gbps. Alternate encodings 573 that were considered for the Rate Request are given in Appendix A.2. 575 N Rate Request (in Kbps) 576 --- ------------------- 577 0 0 578 1 80 579 2 160 580 3 320 581 4 640 582 5 1,280 583 6 2,560 584 7 5,120 585 8 10,240 586 9 20,480 587 10 40,960 588 11 81,920 589 12 163,840 590 13 327,680 591 14 655,360 592 15 1,310,720 594 Table 1: Mapping from Rate Request field to rate request in Kbps. 596 Routers can approve the Quick-Start Request for a lower rate by 597 decreasing the Rate Request in the Quick-Start Request. 599 We note that unlike a Quick-Start Request sent at the beginning of a 600 connection, when a Quick-Start Request is sent in the middle of a 601 connection, the connection could already have an established 602 congestion window or sending rate. The Rate Request is the 603 requested total rate for the connection, including the current rate 604 of the connection; the Rate Request is *not* a request for an 605 additional sending rate over and above the current sending rate. If 606 the Rate Request is denied, or lowered to a value below the 607 connection's current sending rate, then the sender ignores the 608 request, and reverts to the default congestion control mechanisms of 609 the transport protocol. 611 In IPv4, a change in IP options at routers requires recalculating 612 the IP header checksum. 614 3.2. The Quick-Start Request Option for IPv6 616 The Quick-Start Request Option for IPv6 is placed in the Hop-by-Hop 617 Options extension header that is processed at every network node 618 along the communication path [RFC 2460]. The option format following 619 the generic Hop-by-Hop Options header is similar to the IPv4 format 620 with the exception that the Length field should exclude the common 621 type and length fields in the option format and be set to 6 bytes. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Option | Length=6 | QS TTL | Resv. | Rate | 627 | | | | |Request| 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | QS Nonce | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 4. The Quick-Start Request Option for IPv6. 634 The transport receiver compares the Quick-Start TTL with the IPv6 635 Hop Limit field in order to calculate the TTL Diff. (The Hop Limit 636 in IPv6 is the equivalent of the TTL in IPv4.) That is, TTL Diff 637 MUST be calculated and stored as follows: 639 TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2) 641 Unlike IPv4, modifying or deleting the Quick-Start Request IPv6 642 Option does not require checksum re-calculation, because the IPv6 643 header does not have a checksum field, and modifying the Quick-Start 644 Request in the IPv6 Hop-by-Hop options header does not affect the 645 IPv6 pseudo-header checksum used in upper-layer checksum 646 calculations. 648 Note that [RFC2460] specifies that when a specific flow label has 649 been assigned to packets, the contents of the Hop-by-Hop options, 650 excluding the next header field, must originate with the same 651 contents throughout the IP flow lifetime. However, the Quick-Start 652 Request option would be included in only a small fraction of the 653 packets during a flow lifetime. Thus, Quick-Start SHOULD NOT be 654 used in an IPv6 connection that uses flow labels unless the 655 experimental specification of flow labels in Appendix A of RFC 2460 656 is changed. We note that RFC 2460 states that the use of the flow 657 label field in IPv6 "is, at the time of writing, still experimental 658 and subject to change as the requirements for flow support in the 659 Internet become clearer" [RFC2460]. 661 3.3. Processing the Quick-Start Request at Routers 663 Each participating router can either terminate or approve the Quick- 664 Start Request. The router terminates the Quick-Start Request if the 665 router is not underutilized, and therefore has decided not to grant 666 the Quick-Start Request. 668 A router that wishes to terminate the Quick-Start Request SHOULD 669 delete the Quick-Start Request from the IP header. This saves 670 resources as downstream routers will have no option to process. If 671 a Quick-Start-capable router wishes to deny the request but doesn't 672 delete the Quick-Start Request from the IP header, then the router 673 SHOULD zero the QS TTL, QS Nonce, and Rate Request fields. This may 674 be more efficient for routers to implement than deleting the Quick- 675 Start option. A router that doesn't understand the Quick-Start 676 option will simply forward the packet with the Quick-Start Request 677 unchanged. 679 If the participating router has decided to approve the Quick-Start 680 Request, it does the following: 682 * The router MUST decrement the QS TTL by one. 684 * If the router is only willing to approve a Rate Request less than 685 that in the Quick-Start Request, then the router replaces the Rate 686 Request with a smaller value. The router MUST NOT increase the Rate 687 Request in the Quick-Start Request. If the router decreases the 688 Rate Request, the router MUST also modify the QS Nonce, as described 689 in Section 3.4. 691 * In IPv4, the router MUST update the IP header checksum. 693 A non-participating router forwards the Quick-Start Request 694 unchanged, without decrementing the QS TTL. The non-participating 695 router still decrements the TTL field in the IP header, as is 696 required for all routers [RFC1812]. As a result, the sender will be 697 able to detect that the Quick-Start Request had not been understood 698 or approved by all of the routers along the path. 700 3.4. The QS Nonce 702 The QS Nonce gives the Quick-Start sender some protection against 703 receivers lying about the value of the received Rate Request. This 704 is particularly important if the receiver knows the original value 705 of the Rate Request (e.g., when the sender always requests the same 706 value, and the receiver has a long history of communication with 707 that sender.) Without the QS Nonce, there is nothing to prevent the 708 receiver from reporting back to the sender a Rate Request of K, when 709 the received Rate Request was in fact less than K. This version of 710 the nonce is based on a proposal from Guohan Lu [L05]. Initial 711 versions of this document contained an eight-bit QS Nonce, and 712 subsequent versions discussed the possibility of a four-bit QS 713 Nonce. 715 Table 2 gives the format for the 30-bit QS Nonce. 717 Bits Purpose 718 --------- ------------------ 719 Bits 0-1: Rate 15 -> Rate 14 720 Bits 2-3: Rate 14 -> Rate 13 721 Bits 4-5: Rate 13 -> Rate 12 722 Bits 6-7: Rate 12 -> Rate 11 723 Bits 8-9: Rate 11 -> Rate 10 724 Bits 10-11: Rate 10 -> Rate 9 725 Bits 12-13: Rate 9 -> Rate 8 726 Bits 14-15: Rate 8 -> Rate 7 727 Bits 16-17: Rate 7 -> Rate 6 728 Bits 18-19: Rate 6 -> Rate 5 729 Bits 20-21: Rate 5 -> Rate 4 730 Bits 22-23: Rate 4 -> Rate 3 731 Bits 24-25: Rate 3 -> Rate 2 732 Bits 26-27: Rate 2 -> Rate 1 733 Bits 28-29: Rate 1 -> Rate 0 735 Table 2: The QS Nonce. 737 The transport sender MUST initialize the QS Nonce to a random value. 738 If the router reduces the Rate Request from rate K to rate K-1, then 739 the router MUST set the field in the QS Nonce for "Rate K -> Rate 740 K-1" to a new random value. Similarly, if the router reduces the 741 Rate Request by N steps, the router MUST set the 2N bits in the 742 relevant fields in the QS Nonce to a new random value. The receiver 743 MUST report the QS Nonce back to the sender. 745 If the Rate Request was not decremented in the network, then the QS 746 Nonce should have its original value. Similarly, if the Rate 747 Request was decremented by N steps in the network, and the receiver 748 reports back a Rate Request of K, then the last 2K bits of the QS 749 Nonce should have their original value. 751 With the QS Nonce, the receiver has a 1/4 chance of cheating about 752 each step change in the rate request. Thus, if the rate request was 753 reduced by two steps in the network, the receiver has a 1/16 chance 754 of successfully reporting that the original request was approved, as 755 this requires reporting the original value for the QS nonce. 756 Similarly, if the rate request is reduced many steps in the network, 757 and the receiver receives a QS Option with a rate request of K, the 758 receiver has a 1/16 chance of guessing the original values for the 759 fields in the QS nonce for "Rate K+2 -> Rate K+1" and "Rate K+1 -> 760 Rate K". Thus, the receiver has a 1/16 chance in successfully lying 761 and saying that the received rate request was K+2 instead of K. 763 We note that the protection offered by the QS Nonce is the same 764 whether one router makes all of the decrements in the rate request, 765 or whether they are made at different routers along the path. 767 The requirements for randomization for the sender and routers in 768 setting `random' values in the QS Nonce are not stringent - almost 769 any form of pseudo-random numbers would do. The requirement from 770 the sender is that the original value for the QS Nonce is not easily 771 guessable by the receiver. Thus, if two bits of the QS Nonce are 772 changed by a router along the path, the receiver should not be able 773 to guess those two bits from the other 28 bits in the QS Nonce. 775 A requirement of the routers is that the receiver can not be able to 776 tell, from the QS Nonce itself, which numbers in the QS Nonce were 777 generated by the sender, and which were generated by routers along 778 the path. This makes it harder for the receiver to infer the value 779 of the original rate request, making it one step harder for the 780 receiver to cheat. 782 Section 9.4 also considers issues of receiver cheating in more 783 detail. 785 4. The Quick-Start Mechanisms in TCP 787 This section describes how the Quick-Start mechanism would be used 788 in TCP. We first sketch the procedure and then tightly define it in 789 the subsequent subsections. 791 If a TCP sender, say host A, would like to use Quick-Start, the TCP 792 sender puts the requested sending rate in bytes per second, 793 appropriately formatted, in the Quick-Start Request option in the IP 794 header of the TCP packet, called the Quick-Start request packet. 795 (We will be somewhat loose in our use of "packet" vs. "segment" in 796 this section.) The Quick-Start Request also includes random values 797 for the QS TTL and the QS Nonce. When used for initial start-up, 798 the Quick-Start request packet can be either the SYN or SYN/ACK 799 packet, as described above. The requested rate includes an estimate 800 for the transport and IP header overhead. The TCP receiver, say 801 host B, returns the Quick-Start Response option in the TCP header in 802 the responding SYN/ACK packet or ACK packet, called the Quick-Start 803 response packet, informing host A of the results of their request. 805 If the acknowledging packet does not contain a Quick-Start Response, 806 or contains a Quick-Start Response with the wrong value for the TTL 807 Diff or the QS Nonce, then host A MUST assume that its Quick-Start 808 request failed. In this case, host A uses TCP's default congestion 809 control procedure. For initial start-up, host A uses the default 810 initial congestion window. 812 If the returning packet contains a valid Quick-Start Response, then 813 host A uses the information in the response, along with its 814 measurement of the round-trip time, to determine the Quick-Start 815 congestion window (QS-cwnd). Quick-Start packets are defined as 816 packets sent as the result of a successful Quick-Start request, up 817 to the time when the first Quick-Start packet is acknowledged. In 818 order to use Quick-Start, the TCP host MUST use rate-based pacing to 819 transmit Quick-Start packets at the rate indicated in the Quick- 820 Start Response, at the level of granularity possible by the sending 821 host. We note that the limitations of interrupt timing on computers 822 can limit the ability of the TCP host in rate-pacing the outgoing 823 packets. 825 The two TCP end-hosts can independently decide whether to request 826 Quick-Start. For example, host A could sent a Quick-Start Request 827 in the SYN packet, and host B could also send a Quick-Start Request 828 in the SYN/ACK packet. 830 4.1. When to Use Quick-Start 832 In addition to the use of Quick-Start when a connection is 833 established, there are several additional points in a connection 834 when a transport protocol may want to issue a Rate Request. We 835 first re-iterate the notion that Quick-Start is a coarse-grained 836 mechanism. That is, Quick-Start's Rate Requests are not meant to be 837 used for fine-grained control of the transport's sending rate. 838 Rather, the transport MAY issue a Rate Request when no information 839 about the appropriate sending rate is available, and the default 840 congestion control mechanisms might be significantly underestimating 841 the appropriate sending rate. 843 The following are potential points where Quick-Start may be useful: 845 (1) At or soon after connection initiation, when the transport 846 has no idea of the capacity of the network, as discussed above. 847 (A transport that uses TCP Control Block sharing, the Congestion 848 Manager, or the like may not need Quick-Start to determine an 849 appropriate rate.) 850 (2) After an idle period when the transport no longer has a 851 validated estimate of the available bandwidth for this flow. 852 (An example could be a persistent-HTTP connection when a new 853 HTTP request is received after an idle period.) 855 (3) After a host has received explicit indications that one of 856 the endpoints has moved its point of network attachment. This 857 can happen due to some underlying mobility mechanism like Mobile 858 IP [RFC3344,RFC3775]. Some transports, such as SCTP [RFC2960], 859 may associate with multiple IP addresses and can switch 860 addresses (and, therefore network paths) in mid-connection. If 861 the transport has concrete knowledge of a changing network path 862 then the current sending rate may not be appropriate and the 863 transport sender may use Quick-Start to probe the network for 864 the appropriate rate at which to send. (Alternatively, 865 traditional slow-start should be used in this case when Quick- 866 Start is not available.) 868 (4) After an application-limited period when the sender has been 869 using only a small amount of its appropriate share of the 870 network capacity, and has no valid estimate for its fair share. 871 In this case, Quick-Start may be an appropriate mechanism to 872 assess the available capacity on the network path. For 873 instance, consider an application that steadily exchanges low- 874 rate control messages and suddenly needs to transmit a large 875 amount of data. 877 Of the above, this document recommends that a TCP sender MAY attempt 878 to use Quick-Start in cases (1) and (2). It is NOT RECOMMENDED that 879 a TCP sender use Quick-Start for case (3) at the current time. Case 880 (3) requires external notifications not presently defined for TCP or 881 other transport protocols. Finally, a TCP SHOULD NOT use Quick- 882 Start for case (4) at the current time. Case (4) requires further 883 thought and investigation with regard to how the transport protocol 884 could determine it was in a situation that would warrant 885 transmitting a Quick-Start Rate Request. 887 As a general guideline, a TCP sender SHOULD NOT send a Quick-Start 888 request until it has confirmed that is ready to transmit enough data 889 to use the requested rate over the round-trip time of the connection 890 (or over 100 ms, if the round-trip time is not known). In any 891 circumstances, the sender MUST NOT make a QS request if it has made 892 a QS request within the most recent round-trip time. 894 Section 4.6 discusses some of the issues of using Quick-Start at 895 connection initiation, and Section 4.7 discusses issues that arise 896 when Quick-Start is used to request a larger sending rate after an 897 idle period. 899 4.2. The Quick-Start Response Option in the TCP header 901 TCP's Quick-Start Response option is defined as follows: 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Kind | Length=8 | Resv. | Rate | TTL Diff | 907 | | | |Request| | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | QS Nonce | | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 Figure 6. The Quick-Start Response option in the TCP header. 914 The first byte of the Quick-Start Response option contains the 915 option kind, identifying the TCP option (to be assigned by IANA). 917 The second byte of the Quick-Start Response option contains the 918 option length in bytes. The length field MUST be set to four bytes. 920 The third byte of the Quick-Start Response option contains a four- 921 bit Reserved field, and the four-bit allowed Rate Request, formatted 922 as in the Quick-Start Request option. 924 The fourth byte of the TCP option contains the TTL Diff. The TTL 925 Diff contains the difference between the IP TTL and QS TTL fields in 926 the received Quick-Start request packet, as calculated in equations 927 (1) or (2) (depending on whether IPv4 or IPv6 is used). 929 The last four bytes of the TCP option contain the 30-bit QS Nonce 930 and a two-bit Reserved field. 932 We note that the Quick-Start Response Option for TCP contains eight 933 bytes, and the length of the TCP option field is generally at most 934 40 bytes. Other TCP options that might be used include Time Stamp 935 (ten bytes), Window Scale (three bytes), Maximum Segment Size (four 936 bytes), Selective Acknowledgments Data (at least ten bytes), and 937 Selective Acknowledgments Permitted (two bytes). 939 4.3. TCP: Sending the Quick-Start Response 941 An end host, say host B, that receives an IP packet containing a 942 Quick-Start Request passes the Quick-Start Request, along with the 943 value in the IP TTL field, to the receiving TCP layer. 945 If the TCP host is willing to permit the Quick-Start Request, then a 946 Quick-Start Response option is included in the TCP header of the 947 corresponding acknowledgement packet. The Rate Request in the 948 Quick-Start Response option is set to the received value of the Rate 949 Request in the Quick-Start Request option, or to a lower value if 950 the TCP receiver is only willing to allow a lower Rate Request. The 951 TTL Diff in the Quick-Start Response is set to the difference 952 between the IP TTL value and the QS TTL value as given in equation 953 (1) or (2) (depending on whether IPv4 or IPv6 is used). The QS 954 Nonce in the Response is set to the received value of the QS Nonce 955 in the Quick-Start Request option. 957 The Quick-Start Response will NOT be resent if it is lost in the 958 network. Packet loss is an indication of congestion on the return 959 path, in which case it is better not to approve the Quick-Start 960 Request. 962 4.4. TCP: Receiving and Using the Quick-Start Response Packet 964 A TCP host, say TCP host A, that sent a Quick-Start Request and 965 receives a Quick-Start Response in an acknowledgement first checks 966 that the Quick-Start Response is valid. The Quick-Start Response is 967 valid if it contains the correct value for the TTL Diff, and an 968 equal or lesser value for the Rate Request than that transmitted in 969 the Quick-Start Request. In addition, if the received Rate Request 970 is K, then the the rightmost 2K bits of the QS Nonce must match 971 those bits in the QS Nonce sent in the Quick-Start Request. If 972 these checks are not successful, then the Quick-Start request 973 failed, and the TCP host MUST use the default TCP congestion window 974 that it would have used without Quick-Start. 976 If the checks of the TTL Diff and the Rate Request are successful, 977 then the TCP host sets its Quick-Start congestion window (in terms 978 of MSS-sized segments), QS-cwnd, as follows: 980 QS-cwnd = (R * T) / (MSS + H) (3) 982 where R the Rate Request in bytes per second, T the measured round- 983 trip time in seconds, and H the estimated TCP/IP header size in 984 bytes (e.g., 40 bytes). 986 Derivation: the sender is allowed to transmit at R bytes per second 987 including packet headers, but only R*MSS/(MSS+H) bytes per second, 988 or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of 989 application data. 991 The TCP host SHOULD set its congestion window cwnd to QS-cwnd only 992 if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. When 993 Quick-Start is used at the beginning of a connection, before any 994 packet marks or losses have been reported, the TCP host MAY use the 995 reported Rate Request to set the slow-start threshold to a desired 996 value, e.g., to some small multiple of the congestion window. (The 997 initial value of ssthresh is allowed to be arbitrarily high, and 998 some TCP implementations use the size of the advertised window for 999 ssthresh [RFC2581].) 1001 If QS-cwnd is used, the TCP host sets a flag that it is in Quick- 1002 Start mode, and while in Quick-Start mode the TCP sender MUST use 1003 rate-based pacing to pace out Quick-Start packets at the specified 1004 Rate Request. If, during Quick-Start mode, the TCP sender receives 1005 ACKs for packets sent before this Quick-Start mode was entered, 1006 these ACKs are processed as usual, following the default congestion 1007 control mechanisms. Quick-Start mode ends when the TCP host 1008 receives an ACK for one of the Quick-Start packets. 1010 If the congestion window has not been fully used when the first ack 1011 arrives ending the Quick-Start mode, then the congestion window is 1012 decreased to the amount that has actually been used so far. This is 1013 necessary because when the Quick-Start Response is received, the TCP 1014 sender's round-trip-time estimate might be longer than for 1015 succeeding round-trip times, e.g., because of delays at routers 1016 processing the IP QuickStart option, or because of delays at the 1017 receiver in responding to the Quick-Start Request packet. In this 1018 case, an overly-large round-trip-time estimate could have caused the 1019 TCP sender to translate the approved Quick-Start sending rate in 1020 bytes per second into a congestion window that is larger than 1021 needed, with the TCP sender receiving an ACK for the first Quick- 1022 Start packet before the entire congestion window has been used. 1023 Thus, when the TCP sender receives the first ACK for a Quick-Start 1024 packet, the sender reduces its congestion window to the amount that 1025 has actually been used. 1027 As an example, a TCP sender with an approved Quick-Start request of 1028 R KBps, B-byte packets including headers, and an RTT estimate of T 1029 seconds, would translate the Rate Request of R KBps to a congestion 1030 window of R*T/B packets. The TCP sender would send the Quick-Start 1031 packets rate-paced at R KBps. However, if the actual current round- 1032 trip time was T/2 seconds instead of T seconds, then the sender 1033 would begin to receive acknowledgements for Quick-Start packets 1034 after T/2 seconds. Following the paragraph above, the TCP sender 1035 would then reduce its congestion window from R*T/B to R*T/(B*2) 1036 packets, the actual number of packets that were needed to fill the 1037 pipe at a sending rate of R KBps. 1039 After Quick-Start mode is exited and the congestion window adjusted 1040 if necessary, the TCP sender returns to using the default congestion 1041 control mechanisms, processing further incoming ACK packets as 1042 specified by those congestion control mechanisms. For example, if 1043 the TCP sender was in slow-start prior to the Quick-Start request, 1044 and no packets were lost or marked since that time, then the sender 1045 continues in slow-start after exiting Quick-Start mode, as allowed 1046 by ssthresh. 1048 To add robustness, the TCP sender MUST use Limited Slow-Start 1049 [RFC3742] along with Quick-Start. With Limited Slow-Start, the TCP 1050 sender limits the number of packets by which the congestion window 1051 is increased for one window of data during slow-start. 1053 4.5. TCP: Responding to a Loss of a Quick-Start Packet 1055 For TCP, we have defined a ``Quick-Start packet'' as one of the 1056 packets sent in the window immediately following a successful Quick- 1057 Start request. After detecting the loss of a Quick-Start packet, 1058 TCP MUST revert to the default congestion control procedures that 1059 would have been used if the Quick-Start request had not been 1060 approved. For example, if Quick-Start is used for setting the 1061 initial window, and a packet from the initial window is lost, then 1062 the TCP sender MUST then slow-start with the default initial window 1063 that would have been used if Quick-Start had not been used. In 1064 addition to reverting to the default congestion control mechanisms, 1065 the sender MUST take into account that the Quick-Start congestion 1066 window was too large. Thus, the sender SHOULD decrease ssthresh to 1067 at most half the number of Quick-Start packets that were 1068 successfully transmitted. Section A.5 discusses possible 1069 alternatives in responding to the loss of a Quick-Start packet. 1071 We note that ECN [RFC3168] MAY be used with Quick-Start. As is 1072 always the case with ECN, the sender's congestion control response 1073 to an ECN-marked Quick-Start packet is the same as the response to a 1074 dropped Quick-Start packet, thus reverting to slow start in the case 1075 of Quick-Start packets marked as experiencing congestion. 1077 4.6. TCP: A Quick-Start Request for a Larger Initial Window 1079 Some of the issues of using Quick-Start are related to the specific 1080 scenario in which Quick-Start is used. This section discusses the 1081 following issues that arise when Quick-Start is used by TCP to 1082 request a larger initial window: (1) interactions with Path MTU 1083 Discovery (PMTUD); and (2) Quick-Start request packets that are 1084 discarded by middleboxes. 1086 4.6.1. Interactions with Path MTU Discovery 1088 One issue when Quick-Start is used to request a large initial window 1089 concerns the interactions between the large initial window and Path 1090 MTU Discovery. Some of the issues are discussed in RFC 3390: 1092 "When larger initial windows are implemented along with Path MTU 1093 Discovery [RFC1191], alternatives are to set the "Don't 1094 Fragment" (DF) bit in all segments in the initial window, or to 1095 set the "Don't Fragment" (DF) bit in one of the segments. It is 1096 an open question as to which of these two alternatives is best." 1098 If the sender knows the Path MTU when the initial window is sent 1099 (e.g., from a PMTUD cache or from some other IETF-approved method), 1100 then the sender should use that MTU for segments in the initial 1101 window. Unfortunately, the sender doesn't necessarily know the Path 1102 MTU when it sends packets in the initial window. In this case, the 1103 sender should be conservative in the packet size used. Sending a 1104 large number of overly-large packets with the DF bit set is not 1105 desirable, but sending a large number of packets that are fragmented 1106 in the network can be equally undesirable. 1108 The sender SHOULD send one large packet in the initial window with 1109 the DF bit set, and send the remaining packets in the initial window 1110 with a smaller MTU of 576 bytes (or 1280 bytes with IPv6). 1112 A second possibility would be for the sender to delay sending the 1113 Quick-Start Request for one round-trip time, sending the Quick-Start 1114 Request with the first window of data while also doing Path MTU 1115 Discovery. 1117 4.6.2. Quick-Start Request Packets that are Discarded by Middleboxes 1119 It is always possible for a TCP SYN packet carrying a Quick-Start 1120 request to be dropped in the network due to congestion, or to be 1121 blocked due to interactions with middleboxes, where a middlebox is 1122 defined as any intermediary box performing functions apart from 1123 normal, standard functions of an IP router on the data path between 1124 a source host and destination host [RFC3234]. Measurement studies 1125 of interactions between transport protocols and middleboxes [MAF04] 1126 show that for 70% of the web servers investigated, no connection is 1127 established if the TCP SYN packet contains an unknown IP option (and 1128 for 43% of the web servers, no connection is established if the TCP 1129 SYN packet contains an IP TimeStamp Option). In both cases, this is 1130 presumably due to middleboxes along that path. 1132 If the TCP sender doesn't receive a response to the SYN or SYN/ACK 1133 packet containing the Quick-Start Request, then the TCP sender 1134 SHOULD resend the SYN or SYN/ACK packet without the Quick-Start 1135 Request. Similarly, if the TCP sender receives a TCP reset in 1136 response to the SYN or SYN/ACK packet containing the Quick-Start 1137 Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet 1138 without the Quick-Start Request [RFC3360]. 1140 RFC 1122 and 2988 recommend that the sender should set the initial 1141 RTO to three seconds, though many TCP implementations set the 1142 initial RTO to one second. For a TCP SYN packet sent with a Quick- 1143 Start request, the TCP sender SHOULD use an initial RTO of three 1144 seconds. 1146 In the case of a retransmission, in addition to resending the SYN or 1147 SYN/ACK packet without the Quick-Start Request, the TCP sender 1148 SHOULD use an RTO of three seconds and a different Initial Sequence 1149 Number. Using this scheme the TCP sender MUST keep track of when 1150 each of the SYN (or SYN/ACKs) was transmitted. In this way, an 1151 acknowledgement for the retransmitted SYN or SYN/ACK packet can be 1152 matched with the SYN or SYN/ACK being acknowledged, and the 1153 transmission time of the SYN (or SYN/ACK) being acknowledged can be 1154 used for an RTT measurement to seed the RTO. If only the 1155 retransmitted SYN or SYN/ACK is acknowledged, the TCP sender can 1156 reasonably assume that the earlier SYN or SYN/ACK with the Quick- 1157 Start option was dropped by the network because of the option and 1158 not because of congestion. In this case, the TCP sender can refrain 1159 from performing TCP's standard congestion control state changes. 1161 We note that if the TCP SYN packet is using the IP Quick-Start 1162 Option for a Quick-Start request, and it is also using bits in the 1163 TCP header to negotiate ECN-capability with the TCP host at the 1164 other end, then the drop of a TCP SYN packet could be due to 1165 congestion, to a middlebox dropping the packet because of the IP 1166 Option, or because of a middlebox dropping the packet because of the 1167 information in the TCP header negotiating ECN. In this case, the 1168 sender could resend the dropped packet without either the Quick- 1169 Start or the ECN requests. Alternately, the sender could resend the 1170 dropped packet with only the ECN request in the TCP header, 1171 resending the TCP SYN packet without either the Quick-Start or the 1172 ECN requests if the second TCP SYN packet is dropped. The second 1173 choice seems reasonable, given that a TCP SYN packet today is more 1174 likely to be blocked due to IP Options than due to an ECN request in 1175 the TCP header [MAF04]. 1177 4.7. TCP: A Quick-Start Request in the Middle of Connection 1179 This section discusses the following issues that arise when Quick- 1180 Start is used by TCP to request a larger window in the middle of 1181 connection, for example after an idle period: (1) determining the 1182 rate to request; and (2) the response if Quick-Start packets are 1183 dropped; 1185 (1) Determining the rate to request: 1186 In the middle of connection, an easy rule of thumb would be for the 1187 TCP sender to determine the largest congestion window that the TCP 1188 connection achieved since the last packet drop, to translate this 1189 congestion window to a sending rate, and use this rate in the Quick- 1190 Start request. If the request is granted, then the sender 1191 essentially restarts with its old congestion window from before it 1192 was reduced, for example during an idle period. 1194 In the case of an idle period, the sender SHOULD NOT use Quick-Start 1195 if the idle period has been less than an RTO, and the congestion 1196 window has not decayed down to less than half of its value at the 1197 start of the idle period. Such a use of Quick-Start requires 1198 further investigation. 1200 (2) Response if Quick-Start packets are dropped: 1201 If Quick-Start packets are dropped in the middle of connection, then 1202 the sender MUST revert to half of the Quick-Start window, or to the 1203 congestion window that the sender would have used if the Quick-Start 1204 request had not been approved, whichever is smaller. 1206 We note that a packet in the middle of a connection carrying a 1207 Quick-Start Request might or might not carry a data payload. For 1208 example, for TCP, the Quick-Start Request could be carried by a data 1209 packet, or by a pure acknowledgement packet. 1211 4.8. An Example Quick-Start Scenario with TCP 1213 The following is an example scenario in the case when both hosts 1214 request Quick-Start for setting their initial windows. This is 1215 similar to Figures 1 and 2 in Section 2.1, except that it 1216 illustrates a TCP connection with both TCP hosts sending Quick-Start 1217 Requests. 1219 * The TCP SYN packet from Host A contains a Quick-Start Request in 1220 the IP header. 1222 * Routers along the forward path modify the Quick-Start Request as 1223 appropriate. 1225 * Host B receives the Quick-Start Request in the SYN packet, and 1226 calculates the TTL Diff. If Host B approves the Quick-Start 1227 Request, then Host B sends a Quick-Start Response in the TCP header 1228 of the SYN/ACK packet. Host B also sends a Quick-Start Request in 1229 the IP header of the SYN/ACK packet. 1231 * Routers along the reverse path modify the Quick-Start Request as 1232 appropriate. 1234 * Host A receives the Quick-Start Response in the SYN/ACK packet, 1235 and checks the TTL Diff, Rate Request, and QS Nonce for validity. 1236 If they are valid, then Host A sets its initial congestion window 1237 appropriately, and sets up rate-based pacing to be used with the 1238 initial window. If the Quick-Start Response is not valid, then Host 1239 A uses TCP's default initial window. 1241 Host A also calculates the TTL Diff for the Quick-Start Request in 1242 the incoming SYN/ACK packet, and sends a Quick-Start Response in the 1243 TCP header of the ACK packet. 1245 * Host B receives the Quick-Start Response in an ACK packet, and 1246 checks the TTL Diff, Rate Request, and QS Nonce for validity. If 1247 the Quick-Start Response is valid, then Host B sets its initial 1248 congestion window appropriately, and sets up rate-based pacing to be 1249 used with its initial window. If the Quick-Start Response is not 1250 valid, then Host B uses TCP's default initial window. 1252 5. Quick-Start and IPsec AH 1254 This section shows that Quick-Start is compatible with IPsec AH 1255 (Authentication Header). AH uses an Integrity Check Value (ICV) in 1256 the IPsec Authentication Header to verify both message 1257 authentication and integrity [RFC2402,2402bis]. Changes to the 1258 Quick-Start option in the IP header do not affect this AH ICV. The 1259 tunnel considerations in Section 3.6 below apply to all IPsec 1260 tunnels, regardless of what IPsec headers or processing are used in 1261 conjunction with the tunnel. 1263 Because the contents of the Quick-Start Request option can change 1264 along the path, it is important that these changes not affect the 1265 IPsec Authentication Header Integrity Check Value (AH ICV). For 1266 IPv4, RFC 2402 requires that unrecognized IPv4 options be zeroed for 1267 AH ICV computation purposes, so Quick-Start IP Option data changing 1268 en route does not cause problems with existing IPsec AH 1269 implementations for IPv4. If the Quick-Start Request option is 1270 recognized, it MUST be treated as a mutable IPv4 option, and hence 1271 be completely zeroed for AH ICV calculation purposes. IPv6 option 1272 numbers explicitly indicate whether the option is mutable; the 3rd 1273 highest order bit in the IANA-allocated option type has the value 1 1274 to indicate that the Quick-Start Request option data can change en 1275 route. RFC 2402 requires that the option data of any such option be 1276 zeroed for AH ICV computation purposes. Therefore changes to the 1277 Quick-Start option in the IP header do not affect the calculation of 1278 the AH ICV. 1280 6. Quick-Start in IP Tunnels 1282 This section considers interactions between Quick-Start and IP 1283 tunnels, including IPsec [RFC2401,2401bis] and IP in IP [RFC2003]. 1285 In the discussion, we use TTL Diff, defined earlier as the 1286 difference between the IP TTL and the Quick-Start TTL, mod 256. 1287 Recall that the sender considers the Quick-Start request approved 1288 only if the value of TTL Diff for the packet entering the network is 1289 the same as the value of TTL Diff for the packet exiting the 1290 network. 1292 Simple tunnels: IP tunnel modes are generally based on adding a new 1293 "outer" IP header that encapsulates the original or "inner" IP 1294 header and its associated packet. In many cases, the new "outer" IP 1295 header may be added and removed at intermediate points along a 1296 connection, enabling the network to establish a tunnel without 1297 requiring endpoint participation. We denote tunnels that specify 1298 that the outer header be discarded at tunnel egress as "simple 1299 tunnels", and we denote tunnels where the egress saves and uses 1300 information from the outer header before discarding it as "non- 1301 simple tunnels". An example of a "non-simple tunnel" would be a 1302 tunnel configured to support ECN, where the egress router might copy 1303 the ECN codepoint in the outer header to the inner header before 1304 discarding the outer header [RFC3168]. 1306 __ Tunnels Compatible with Quick-Start 1307 / 1308 Simple Tunnels __/ 1309 \ 1310 \__ Tunnels Not Compatible with Quick-Start 1311 (False Positives!) 1313 __ Tunnels Supporting Quick-Start 1314 / 1315 / 1316 Non-Simple Tunnels __/_____ Tunnels Compatible with Quick-Start, 1317 \ but Not Supporting Quick-Start 1318 \ 1319 \__ Tunnels Not Compatible with Quick-Start? 1321 Figure 5: Categories of Tunnels. 1323 Tunnels that are compatible with Quick-Start: We say that an IP 1324 tunnel `is not compatible with Quick-Start' if the use of a Quick- 1325 Start Request over such a tunnel allows false positives, where the 1326 TCP sender incorrectly believes that the Quick-Start Request was 1327 approved by all routers along the path. If the use of Quick-Start 1328 over the tunnel does not cause false positives, we say that the IP 1329 tunnel `is compatible with Quick-Start'. 1331 If the IP TTL of the inner header is decremented during forwarding 1332 before tunnel encapsulation takes place, then the simple tunnel is 1333 compatible with Quick-Start, with Quick-Start requests being 1334 rejected. Section 6.1 describes in more detail the ways that a 1335 simple tunnel can be compatible with Quick-Start. 1337 There are some simple tunnels that are not compatible with with 1338 Quick-Start, allowing `false positives' where the TCP sender 1339 incorrectly believes that the Quick-Start Request was approved by 1340 all routers along the path. This is discussed in Section 6.2 below. 1342 One of our tasks in the future will be to investigate the occurrence 1343 of tunnels that are not compatible with Quick-Start, and to track 1344 the extent to which such tunnels are modified over time. The 1345 evaluation of the problem of false positives from tunnels that are 1346 not compatible with Quick-Start will affect the progression of 1347 Quick-Start from Experimental to Proposed Standard, and will affect 1348 the degree of deployment of Quick-Start while in Experimental mode. 1350 Tunnels that support Quick-Start: We say that an IP tunnel `supports 1351 Quick-Start' if it allows routers along the tunnel path to process 1352 the Quick-Start Request and give feedback, resulting in the 1353 appropriate possible acceptance of the Quick-Start request. Some 1354 tunnels that are compatible with Quick-Start support Quick-Start, 1355 while others do not. We note that a simple tunnel is not able to 1356 support Quick-Start. 1358 From a security point of view, the use of Quick-Start in the outer 1359 header of an IP tunnel might raise security concerns because an 1360 adversary could tamper with the Quick-Start information that 1361 propagates beyond the tunnel endpoint, or because the Quick-Start 1362 Option exposes information to network scanners. Our approach is to 1363 make supporting Quick-Start an option for IP tunnels. That is, in 1364 environments or tunneling protocols where the risks of using Quick- 1365 Start are judged to outweigh its benefits, the tunnel can simply 1366 delete the Quick-Start option or zero the Quick-Start rate request 1367 and QS TTL fields before encapsulation. The result is that there 1368 are two viable options for IP tunnels to be compatible with Quick- 1369 Start. The first option is the simple tunnel described above and in 1370 Section 6.1, where the tunnel is compatible with Quick-Start but 1371 does not support Quick-Start, where all Quick-Start requests along 1372 the path will be rejected. The second approach is a Quick-Start- 1373 capable mode, described in Section 6.3, where the tunnel actively 1374 supports Quick-Start. 1376 6.1. Simple Tunnels That Are Compatible with Quick-Start 1378 This section describes the ways that a simple tunnel can be 1379 compatible with Quick-Start but not support Quick-Start, resulting 1380 in the rejection of all Quick-Start requests that traverse the 1381 tunnel. 1383 If the tunnel ingress for the simple tunnel is at a router, the IP 1384 TTL of the inner header is generally decremented during forwarding 1385 before tunnel encapsulation takes place. In this case TTL Diff will 1386 be changed, correctly causing the Quick-Start request to be 1387 rejected. For a simple tunnel it is preferable if the Quick-Start 1388 Request is not copied to the outer header, saving the routers within 1389 the tunnel from unnecessarily processing the Quick-Start request. 1390 However, the Quick-Start request will be rejected correctly in this 1391 case whether or not the Quick-Start Request is copied to the outer 1392 header. 1394 6.1.1. Simple Tunnels that are Aware of Quick-Start 1396 If a tunnel ingress is aware of Quick-Start, but does not want to 1397 support Quick-Start, then the tunnel ingress MUST either zero the 1398 Quick-Start rate request, QS TTL, and QS Nonce fields or remove the 1399 Quick-Start option from the inner header before encapsulation. 1400 Section 6.3 describes the procedures for a tunnel that does want to 1401 support Quick-Start. 1403 Deleting the Quick-Start option or zeroing the Quick-Start rate 1404 request *after decapsulation* also serves to prevent the propagation 1405 of Quick-Start information, and is compatible with Quick-Start. If 1406 the outer header does not contain a Quick-Start Request, a Quick- 1407 Start-aware tunnel egress MUST reject the inner Quick-Start Request 1408 by resetting the Rate Request field in the inner header, or by 1409 deleting the Quick-Start Request option. 1411 If the tunnel ingress is at a sending host or router where the IP 1412 TTL is not decremented prior to encapsulation, and neither tunnel 1413 endpoint is aware of Quick-Start, then this allows false positives, 1414 described in the section below. 1416 6.2. Simple Tunnels That Are Not Compatible with Quick-Start 1418 Sometimes a tunnel implementation that does not support Quick-Start 1419 is independent of the TCP sender or a router implementation that 1420 supports Quick-Start. In these cases it is possible that a Quick- 1421 Start Request gets erroneously approved without the routers in the 1422 tunnel having individually approved the request, causing a false 1423 positive. 1425 If a tunnel ingress is a separate component from the TCP sender or 1426 IP forwarding, it is possible that a packet with a Quick-Start 1427 option is encapsulated without the IP TTL being decremented first, 1428 or with both IP TTL and QS TTL being decremented before the tunnel 1429 encapsulation takes place. If the tunnel ingress does not know about 1430 Quick-Start, a valid Quick-Start Request with unchanged TTL Diff 1431 traverses in the inner header, while the outer header most likely 1432 does not carry a Quick-Start Request. If the tunnel egress also 1433 does not support Quick-Start, it remains possible that the Quick- 1434 Start Request would be falsely approved, because the packet is 1435 decapsulated using the Quick-Start request from the inner header, 1436 and the value of TTL Diff echoed to the sender remains unchanged. 1437 For example, such a scenario can occur with a Bump-In-The-Stack 1438 (BITS), an IPSec encryption implementation where the data encryption 1439 occurs between the network drivers and the TCP/IP protocol stack 1440 [RFC2401]. 1442 As one example, if a remote access VPN client uses a BITS structure, 1443 then Quick-Start obstacles between the client and the VPN gateway 1444 won't be seen. This is a particular problem because the path 1445 between the client and the VPN gateway is likely to contain the most 1446 congested part of the path. Because most VPN clients are reported 1447 to use BITS [H05], we will explore this in more detail. 1449 A Bump-In-The-Wire (BITW) is an IPSec encryption implementation 1450 where the encryption occurs on an outboard processor, offloading the 1451 encryption processing overhead from the host or router [RFC2401]. 1452 The BITW device is usually IP addressable, which means that the IP 1453 TTL is decremented before the packet is passed to the BITW. If the 1454 QS TTL is not decremented, then the value of TTL Diff is changed, 1455 and the Quick-Start request will be denied. However, if the BITW 1456 supports a host and does not have its own IP address, then the IP 1457 TTL is not decremented before the packet is passed from the host to 1458 the BITW, and a false positive could occur. 1460 Other tunnels that need to be looked at are IP tunnels over non- 1461 network protocols, such as IP over TCP and IP over UDP [RFC3948], 1462 and tunnels using the Layer Two Tunneling Protocol [RFC2661]. 1464 Section 6.2 discusses the related issue of non-IP queues, such as 1465 layer-two Ethernet or ATM networks, as another instance of possible 1466 bottlenecks that do not participate in the Quick-Start feedback. 1468 6.3. Tunnels That Support Quick-Start 1470 This section discusses tunnels configured to support Quick-Start. 1472 If the tunnel ingress node chooses to locally approve the Quick- 1473 Start request, then the ingress node MUST decrement the Quick-Start 1474 TTL at the same time it decrements the IP TTL, and MUST copy IP TTL 1475 and the Quick-Start option from the inner IP header to the outer 1476 header. During encapsulation, the tunnel ingress MUST zero the 1477 Quick-Start rate request field in the inner header to ensure that 1478 the Quick-Start request will be rejected if the tunnel egress does 1479 not support Quick-Start. 1481 If the tunnel ingress node does not choose to locally approve the 1482 Quick-Start request, then it MUST either delete the Quick-Start 1483 option from the inner header before encapsulation, or zero the QS 1484 TTL and the Rate Request fields before encapsulation. 1486 Upon decapsulation, if the outer header contains a Quick-Start 1487 option, the tunnel egress MUST copy the IP TTL and the Quick-Start 1488 option from the outer IP header to the inner header. 1490 IPsec uses the IKE (Internet Key Exchange) Protocol for security 1491 associations. We do not consider the interactions between Quick- 1492 Start and IPsec with IKEv1 [RFC2409] in this document. When the RFC 1493 for IKEv2 [IKEv2] is published, we will specify a modification of 1494 IPsec to allow the support of Quick-Start to be negotiated; this 1495 modification will specify the negotiation between tunnel endpoints 1496 to allow or forbid support for Quick-Start within the tunnel. This 1497 was done for ECN for IPsec tunnels, with IKEv1 [RFC3168, Section 1498 9.2]. This negotiation of Quick-Start capability in an IPsec tunnel 1499 will be specified in a separate IPsec document. This document will 1500 also include a discussion of the potential effects of an adversary's 1501 modifications of the Quick-Start field (as in Sections 18 and 19 of 1502 RFC 3168), and of the security considerations of exposing the Quick- 1503 Start rate request to network scanners. 1505 7. The Quick-Start Mechanism in other Transport Protocols 1507 The section earlier specified the use of Quick-Start in TCP. In 1508 this section, we generalize this to give guidelines for the use of 1509 Quick-Start with other transport protocols. We also discuss briefly 1510 how Quick-Start could be specified for other transport protocols. 1512 The general guidelines for Quick-Start in transport protocols are as 1513 follows: 1515 * Quick-Start is only specified for unicast transport protocols with 1516 appropriate congestion control mechanisms. Note: Quick-Start is not 1517 a replacement for standard congestion control techniques, but meant 1518 to augment their operation. 1520 * A transport-level mechanism is needed for the Quick-Start response 1521 from the receiver to the sender. This response contains the Rate 1522 Request, TTL Diff, and QS Nonce. 1524 * The sender checks the validity of the Quick-Start response. 1526 * The sender has an estimate of the round-trip time, and translates 1527 the Quick-Start response into an allowed window or allowed sending 1528 rate. The sender starts sending Quick-Start packets, rate-paced out 1529 at the approved sending rate. 1531 * After the sender receives the first acknowledgement packet for a 1532 Quick-Start packet, no more Quick-Start packets are sent. The 1533 sender adjusts its current congestion window or sending rate to be 1534 consistent with the actual amount of data that was transmitted in 1535 that round-trip time. 1537 * When the last Quick-Start packet is acknowledged, the sender 1538 continues using the standard congestion control mechanisms of that 1539 protocol. 1541 * If one of the Quick-Start packets is lost, then the sender reverts 1542 to the standard congestion control method of that protocol that 1543 would have been used if the Quick-Start request had not been 1544 approved. In addition, the sender takes into account the 1545 information that the Quick-Start congestion window was too large 1546 (e.g., by decreasing ssthresh in TCP). 1548 8. Using Quick-Start 1550 8.1. Determining the Rate to Request 1552 As discussed in [SAF05], the data sender does not necessarily have 1553 information about the size of the data transfer at connection 1554 initiation; for example, in request-response protocols such as HTTP, 1555 the server doesn't know the size or name of the requested object 1556 during connection initiation. [SAF05] explores some of the 1557 performance implications of overly-large Quick-Start requests, and 1558 discusses heuristics that end-nodes could use to size their requests 1559 appropriately. For example, the sender might have information about 1560 the bandwidth of the last-mile hop, the size of the local socket 1561 buffer, or of the TCP receive window, and could use this information 1562 in determining the rate to request. Web servers that mostly have 1563 small objects to transfer might decide not to use Quick-Start at 1564 all, since Quick-Start would be of little benefit to them. 1566 Quick-Start will be more effective if Quick-Start requests are not 1567 larger than necessary; every Quick-Start request that is approved 1568 but not used (or not fully used) takes away from the bandwidth pool 1569 available for granting successive Quick-Start requests. Following 1570 Section 4.1, the sender SHOULD NOT request a sending rate larger 1571 than it is able to use over the round-trip time of the connection 1572 (or over 100 ms, if the round-trip time is not known), except as 1573 required to round up the desired sending rate to the next-highest 1574 allowable request. 1576 8.2. Deciding the Permitted Rate Request at a Router 1578 In this section we briefly outline how a router might decide whether 1579 or not to approve a Quick-Start Request. As an example, the router 1580 could ask the following questions: 1582 * Has the router's output link been underutilized for some time 1583 (e.g., several seconds). 1585 * Would the output link remain underutilized if the arrival rate was 1586 to increase by the aggregate rate requests that the router has 1587 approved over the last fraction of a second? 1589 In order to answer this question, the router must have some 1590 knowledge of the available bandwidth on the output link and of the 1591 Quick-Start bandwidth that could arrive due to recently-approved 1592 Quick-Start Requests. In this way, if an underutilized router 1593 experiences a flood of Quick-Start requests, the router can begin to 1594 deny Quick-Start requests while the output link is still 1595 underutilized. 1597 A simple way for the router to keep track of the potential bandwidth 1598 from recently-approved requests is to maintain two counters, one for 1599 the total aggregate Rate Requests that have been approved in the 1600 current time interval [T1, T2], for the current time between T1 and 1601 T2, and one for the total aggregate Rate Requests approved over a 1602 previous time interval [T0, T1]. However, this document doesn't 1603 specify router algorithms for approving Quick-Start requests, or 1604 make requirements for the appropriate time intervals for remembering 1605 the aggregate approved Quick-Start bandwidth. A possible router 1606 algorithm is given in Appendix C, and more discussion of these 1607 issues is available in [SAF05].) 1609 * If the router's output link has been underutilized and the 1610 aggregate Quick Start Request Rate options granted is low enough to 1611 prevent a near-term bandwidth shortage, then the router could 1612 approve the Quick-Start Request. 1614 Section 10.2 discusses some of the implementation issues in 1615 processing Quick-Start requests at routers. [SAF05] discusses the 1616 range of possible Quick-Start algorithms at the router for deciding 1617 whether to approve a Quick-Start request. In order to explore the 1618 limits of the possible functionality at routers, [SAF05] also 1619 discusses Extreme Quick-Start mechanisms at routers, where the 1620 router would keep per-flow state concerning approved Quick-Start 1621 requests. 1623 9. Evaluation of Quick-Start 1624 9.1. Benefits of Quick-Start 1626 The main benefit of Quick-Start is the faster start-up for the 1627 transport connection itself. For a small TCP transfer of one to 1628 five packets, Quick-Start is probably of very little benefit; at 1629 best, it might shorten the connection lifetime from three to two 1630 round-trip times (including the round-trip time for connection 1631 establishment). Similarly, for a very large transfer, where the 1632 slow-start phase would have been only a small fraction of the 1633 connection lifetime, Quick-Start would be of limited benefit. 1634 Quick-Start would not significantly shorten the connection lifetime, 1635 but it might eliminate or at least shorten the start-up phase. 1636 However, for moderate-sized connections in a well-provisioned 1637 environment, Quick-Start could possibly allow the entire transfer of 1638 M packets to be completed in one round-trip time (after the initial 1639 round-trip time for the SYN exchange), instead of the log_2(M)-2 1640 round-trip times that it would normally take for the data transfer, 1641 in an uncongested environments (assuming an initial window of four 1642 packets). 1644 9.2. Costs of Quick-Start 1646 This section discusses the costs of Quick-Start for the connection 1647 and for the routers along the path. 1649 The cost of having a Quick-Start packet dropped: 1650 For the sender the biggest risk in using Quick-Start lies in the 1651 possibility of suffering from congestion-related losses of the 1652 Quick-Start packets. This should be an unlikely situation because 1653 routers are expected to approve Quick-Start Requests only when they 1654 are significantly underutilized. However, a transient increase in 1655 cross-traffic in one of the routers, a sudden decrease in available 1656 bandwidth on one of the links, or congestion at a non-IP queue could 1657 result in packet losses even when the Quick-Start Request was 1658 approved by all of the routers along the path. If a Quick-Start 1659 packet is dropped, then the sender reverts to the congestion control 1660 mechanisms it would have used if the Quick-Start request has not 1661 been approved, so the performance cost to the connection of having a 1662 Quick-Start packet dropped is small, compared to the performance 1663 without Quick-Start. (On the other hand, the performance difference 1664 between Quick-Start with a Quick-Start packet dropped and Quick- 1665 Start with no Quick-Start packet dropped can be considerable.) 1667 Added complexity at routers: 1668 The main cost of Quick-Start at routers concerns the costs of added 1669 complexity. The added complexity at the end-points is moderate, and 1670 might easily be outweighed by the benefit of Quick-Start to the end 1671 hosts. The added complexity at the routers is also somewhat 1672 moderate; it involves estimating the unused bandwidth on the output 1673 link over the last several seconds, processing the Quick-Start 1674 request, and keeping a counter of the aggregate Quick-Start rate 1675 approved over the last fraction of a second. However, this added 1676 complexity at routers adds to the development cycle, and could 1677 prevent the addition of other competing functionality to routers. 1678 Thus, careful thought would have to be given to the addition of 1679 Quick-Start to IP. 1681 The slow path in routers: 1682 Another drawback of Quick-Start is that packets containing the 1683 Quick-Start Request message might not take the fast path in routers, 1684 particularly in the beginning of Quick-Start's deployment in the 1685 Internet. This would mean some extra delay for the end hosts, and 1686 extra processing burden for the routers. However, as discussed in 1687 Sections 4.1 and 4.6, not all packets would carry the Quick-Start 1688 Request option. In addition, for the underutilized links where 1689 Quick-Start Requests could actually be approved, or in typical 1690 environments where most of the packets belong to large flows, the 1691 burden of the Quick-Start Option on routers would be considerably 1692 reduced. Nevertheless, it is still conceivable, in the worst case, 1693 that many packets would carry Quick-Start requests; this could slow 1694 down the processing of Quick-Start packets in routers considerably. 1695 As discussed in Section 9.5, routers can easily protect against this 1696 by enforcing a limit on the rate at which Quick-Start requests will 1697 be considered. 1699 Multiple paths: 1700 One limitation of Quick-Start is that it presumes that the data 1701 packets of a connection will follow the same path as the Quick-Start 1702 request packet. If this is not the case, then the connection could 1703 be sending the Quick-Start packets, at the approved rate, along a 1704 path that was already congested, or that became congested as a 1705 result of this connection. This is, however, similar to what would 1706 happen, for a connection with sufficient data, if the connection's 1707 path was changed in the middle of the connection, when the 1708 connection had already established the allowed initial rate. 1710 A router that uses multipath routing for packets within a single 1711 connection MUST NOT approve a Quick-Start request. Quick-Start 1712 would not perform robustly in an environment with multipath routing, 1713 where different packets in a connection routinely follow different 1714 paths. In such an environment, the Quick-Start request and some 1715 fraction of the packets in the connection might take an 1716 underutilized path, while the rest of the packets take an alternate, 1717 congested path. 1719 As discussed in Section 6.2, Quick-Start could also give poor 1720 performance when there is a routing change immediately after the 1721 Quick-Start request is approved, and the Quick-Start data packets 1722 follow a different path from that of the original Quick-Start 1723 Request. However, as noted in Section 6.2, this is similar to what 1724 can happen without Quick-Start when a connection path is changed 1725 after the connection had already established a certain sending rate 1726 on the original path. 1728 Non-IP queues: 1729 A problem of any mechanism for feedback from routers at the IP level 1730 is that there can be queues and bottlenecks in the end-to-end path 1731 that are not in IP-level routers. As an example, these include 1732 queues in layer-two Ethernet or ATM networks. One possibility would 1733 be that an IP-level router adjacent to such a non-IP queue or 1734 bottleneck would be configured to reject Quick-Start requests if 1735 that was appropriate. One would hope that in general, IP networks 1736 are configured so that non-IP queues between IP routers do not end 1737 up being the congested bottlenecks. 1739 9.3. Quick-Start with QoS-enabled Traffic 1741 The discussion in this document has largely been of Quick-Start with 1742 default, best-effort traffic. However, Quick-Start could also be 1743 used by traffic using some form of differentiated services, and 1744 routers could take the traffic class into account when deciding 1745 whether or not to grant the Quick-Start request. We don't address 1746 this context further in this paper, since it is orthogonal to the 1747 specification of Quick-Start. 1749 9.4. Protection against Misbehaving Nodes 1751 In this section we discuss the protection against receivers or 1752 colluding middleboxes lying about the Quick-Start Request. First, 1753 we note that it is not necessarily in the receiver's interest to lie 1754 about the Quick-Start Request. If the sender sends at too-high of 1755 an initial rate, and has a packet dropped, this does not necessarily 1756 improve the performance of the connection, relative to the case when 1757 the Quick-Start Request was not approved. 1759 9.4.1. Receivers Lying about Whether the Request was Approved 1761 One form of misbehavior would be for the receiver to lie to the 1762 sender about whether the Quick-Start Request was approved, by 1763 falsely reporting the TTL Diff and QS Nonce. If a router that 1764 understands the Quick-Start Request denies the request by deleting 1765 the request or by zeroing the QS TTL and QS Nonce, then the receiver 1766 can ``lie" about whether the request was approved only by 1767 successfully guessing the value of the TTL Diff and QS Nonce to 1768 report. The chance of the receiver successfully guessing the 1769 correct value for the TTL Diff is 1/256, and the chance of the 1770 receiver successfully guessing the QS nonce for a reported rate 1771 request of K is 1/(2K). 1773 However, if the Quick-Start request is denied only by a non-Quick- 1774 Start-capable router, or by a router that is unable to zero the QS 1775 TTL and QS Nonce fields, the the receiver could lie about whether 1776 the Quick-Start Requests were approved by modifying the QS TTL in 1777 successive requests received from the same host. In particular, if 1778 the sender does not act on a Quick-Start Request, then the receiver 1779 could decrement the QS TTL by one in the next request received from 1780 that host before calculating the TTL Diff, and decrement the QS TTL 1781 by two in the following received request, until the sender acts on 1782 one of the Quick-Start Requests. 1784 Unfortunately, if a router doesn't understand Quick-Start, then it 1785 is not possible for that router to take an active step such as 1786 zeroing the QS TTL and QS Nonce to deny a request. As a result, the 1787 QS TTL is not a fail-safe mechanism for preventing lying by 1788 receivers in the case of non-Quick-Start-capable routers. 1790 9.4.2. Receivers Lying about the Approved Rate 1792 A second form of misbehavior would be for the receiver to lie to the 1793 sender about the Rate Request for an approved Quick-Start Request, 1794 by increasing the value of the Rate Request field. However, the 1795 receiver doesn't necessarily know the Rate Request in the original 1796 Quick-Start Request sent by the sender, and a higher Rate Request 1797 reported by the receiver will only be considered valid by the sender 1798 if it is no higher than the Rate Request originally requested by the 1799 sender. For example, if the sender sends a Quick-Start Request with 1800 a Rate Request of X, and the receiver reports receiving a Quick- 1801 Start Request with a Rate Request of Y > X, then the sender knows 1802 that either some router along the path malfunctioned (increasing the 1803 Rate Request inappropriately), or the receiver is lying about the 1804 Rate Request in the received packet. 1806 If the sender sends a Quick-Start Request with a Rate Request of Z, 1807 the receiver receives the Quick-Start Request with an approved Rate 1808 Request of X, and reports a Rate Request of Y, for X < Y <= Z, then 1809 the receiver only succeeds in lying to the sender about the approved 1810 rate if the receiver successfully reports the rightmost 2Y bits in 1811 the QS nonce. 1813 If senders often use a configured default value for the Rate 1814 Request, then receivers would often be able to guess the original 1815 Rate Request, and this would make it easier for the receiver to lie 1816 about the value of the Rate Request field. Similarly, if the 1817 receiver often communicates with a particular sender, and the sender 1818 always uses the same Rate Request for that receiver, then the 1819 receiver might over time be able to infer the original Rate Request 1820 used by the sender. 1822 There are several possible additional forms of protection against 1823 receivers lying about the value of the Rate Request. One possible 1824 additional protection would be for a router that decreases a Rate 1825 Request in a Quick-Start Request to report the decrease directly to 1826 the sender. However, this could lead to many reports back to the 1827 sender for a single request, and could also be used in address- 1828 spoofing attacks. 1830 A second limited form of protection would be for senders to use some 1831 degree of randomization in the requested Rate Request, so that it is 1832 difficult for receivers to guess the original value for the Rate 1833 Request. However, this is difficult because there is a fairly 1834 coarse granularity in the set of rate requests available to the 1835 sender, and randomizing the initial request only offers limited 1836 protection in any case. 1838 9.4.3. Collusion between Misbehaving Routers 1840 In addition to protecting against misbehaving receivers, it is 1841 necessary also to protect against misbehaving routers. Consider 1842 collusion between an ingress router and an egress router belonging 1843 to the same Intranet. The ingress router could decrement the Rate 1844 Request at the ingress, with the egress router increasing it again 1845 at the egress. The routers between the ingress and egress that 1846 approved the decremented rate request might not have been willing to 1847 approve the larger, original request. 1849 Another form of collusion would be for the ingress router to inform 1850 the egress router out-of-band of the TTL Diff and QS Nonce for the 1851 request packet at the ingress. This would enable the egress router 1852 to modify the QS TTL and QS Nonce so that it appeared that all of 1853 the routers along the path had approved the request. There does not 1854 appear to be any protection against a colluding ingress and egress 1855 router. Even if an intermediate router had deleted the Quick-Start 1856 Request Option from the packet, the ingress router could have sent 1857 the Quick-Start Request Option to the egress router out-of-band, 1858 with the egress router inserting the Quick-Start Request Option, 1859 with a modified QS TTL field, back in the packet. 1861 However, unlike ECN, there is somewhat less incentive for 1862 cooperating ingress and egress routers to collude to falsely modify 1863 the Quick-Start Request so that it appears to have been approved by 1864 all of the routers along the path. With ECN, a colluding ingress 1865 router could falsely mark a packet as ECN-capable, with the 1866 colluding egress router returning the ECN field in the IP header to 1867 its original non-ECN-capable codepoint, and congested routers along 1868 the path could have been fooled into not dropping that packet. This 1869 collusion would give an unfair competitive advantage to the traffic 1870 protected by the colluding ingress and egress routers. 1872 In contrast, with Quick-Start, the collusion of the ingress and 1873 egress routers to make it falsely appear that a Quick-Start request 1874 was approved does not necessarily give an advantage to the traffic 1875 covered by that collusion. If some router along the path really 1876 does not have enough available bandwidth to approve the Quick-Start 1877 request, then the Quick-Start packets sent as a result of the 1878 falsely-approved request could be dropped in the network, to the 1879 resulting disadvantage of the connection. Thus, while the ingress 1880 and egress routers could collude to prevent intermediate routers 1881 from denying a Quick-Start request, it would not necessarily be to 1882 the connection's advantage for this to happen. In addition, the 1883 router between the ingress and egress nodes that denied the request 1884 could be monitoring connection performance, actively penalizing 1885 nodes that seem to be using Quick-Start after a Quick-Start request 1886 was denied. 1888 If the congested router was ECN-capable, and the colluding ingress 1889 and egress routers were lying about ECN-capability as well as about 1890 Quick-Start, then the result could be that the Quick-Start request 1891 falsely appears to the sender to have been approved, and the Quick- 1892 Start packets falsely appear to the congested router to be ECN- 1893 capable. In this case, the colluding routers might succeed in 1894 giving a competitive advantage to the traffic protected by their 1895 collusion (if no intermediate router is monitoring to catch such 1896 misbehavior). 1898 9.4.4. Misbehaving Middleboxes and the IP TTL 1900 A separate possibility is that of traffic normalizers [HKP01] or 1901 other middleboxes along that path that re-write IP TTLs, in order to 1902 foil other kinds of attacks in the network. If such a traffic 1903 normalizer re-wrote the IP TTL, but did not adjust the Quick-Start 1904 TTL by the same amount, then the sender's mechanism for determining 1905 if the request was approved by all routers along the path would no 1906 longer be reliable. Re-writing the IP TTL could result in false 1907 positives (with the sender incorrectly believing that the Quick- 1908 Start request was approved) as well as false negatives (with the 1909 sender incorrectly believing that the Quick-Start request was 1910 denied). 1912 9.5. Attacks on Quick-Start 1914 As discussed in [SAF05], Quick-Start is vulnerable to two kinds of 1915 Quick-Start attacks: (1) attacks to increase the routers' 1916 processing and state load; and (2) attacks with bogus Quick-Start 1917 requests to temporarily tie up available Quick-Start bandwidth, 1918 preventing routers from approving Quick-Start requests from other 1919 connections. Routers can protect against the first kind of attack 1920 by applying a simple limit on the rate at which Quick-Start requests 1921 will be considered by the router. 1923 The second kind of attack, attacks to tie up the available Quick- 1924 Start bandwidth, is more difficult to defend against. As discussed 1925 in [SAF05]. Quick-Start Requests that are not going to be used, 1926 either because they are from malicious attackers or because they are 1927 denied by routers downstream, can result in `wasting' potential 1928 Quick-Start bandwidth, resulting in routers denying subsequent 1929 Quick-Start Requests that if approved would in fact have been used. 1930 We note that the likelihood of malicious attacks would be minimized 1931 significantly when Quick-Start was deployed in a controlled 1932 environment such as an Intranet, where there was some form of 1933 centralized control over the users in the system. We also note that 1934 this form of attack could potentially make Quick-Start unusable, but 1935 it would not do any further damage; in the worst case, the network 1936 would function as a network without Quick-Start. 1938 [SAF05] considers the potential of Extreme Quick-Start algorithms at 1939 routers, which keep per-flow state for Quick-Start connections, in 1940 protecting the availability of Quick-Start bandwidth in the face of 1941 frequent overly-larqe Quick-Start requests. 1943 9.6. Simulations with Quick-Start 1945 Quick-Start was added to the NS simulator [SH02] by Srikanth 1946 Sundarrajan, and additional functionality was added by Pasi 1947 Sarolahti. The validation test is at `test-all-quickstart' in the 1948 `tcl/test' directory in NS. The initial simulation studies from 1949 [SH02] show a significant performance improvement using Quick-Start 1950 for moderate-sized flows (between 4KB and 128KB) in under-utilized 1951 environments. These studies are of file transfers, with the 1952 improvement measured as the relative increase in the overall 1953 throughput for the file transfer. The study shows that potential 1954 improvement from Quick-Start is proportional to the delay-bandwidth 1955 product of the path. 1957 The Quick-Start simulations in [SAF05] explore the following: the 1958 potential benefit of Quick-Start for the connection; the relative 1959 benefits of different router-based algorithms for approving Quick- 1960 Start requests; and the effectiveness of Quick-Start as a function 1961 of the senders' algorithms for choosing the size of the rate 1962 request. 1964 10. Implementation and Deployment Issues 1966 This section discusses some of the implementation issues with Quick- 1967 Start. This section also discusses some of the key deployment 1968 issues, such as the chicken-and-egg deployment problems of 1969 mechanisms that have to be deployed in both routers and end nodes in 1970 order to work, and the problems posed by the wide deployment of 1971 middleboxes today that block the use of known or unknown IP Options. 1973 10.1. Implementation Issues for Sending Quick-Start Requests 1975 Section 4.6 discusses some of the issues with deciding the initial 1976 sending rate to request. Quick-Start raises additional issues about 1977 the communication between the transport protocol and the 1978 application, and about the use of the past history with Quick-Start 1979 in the end node. 1981 One possibility is that a protocol implementation could provide an 1982 API for applications to indicate when they want to request Quick- 1983 Start, and what rate they would like to request. In the 1984 conventional socket API this could be a socket option that is set 1985 before a connection is established. Some applications, such those 1986 that use TCP for bulk transfers, do not have interest in the 1987 transmission rate, but they might know the amount of data that can 1988 be sent immediately. Based on this, the sender implementation could 1989 decide whether Quick-Start would be useful, and what rate should be 1990 requested. Datagram-based real-time streaming applications, on the 1991 other hand, may have a specific preference on the transmission rate 1992 and they could indicate the required rate explicitly to the 1993 transport protocol to be used in the Quick-Start Request. 1995 We note that when Quick-Start is used, the TCP sender is required to 1996 implement an additional timer for the paced transmission of Quick- 1997 Start packets. 1999 10.2. Implementation Issues for Processing Quick-Start Requests 2001 A router or other network host must be able to determine the 2002 approximate bandwidth of its outbound network interfaces in order to 2003 process incoming Quick-Start rate requests, including those that 2004 originate from the host itself. One possibility would be for hosts 2005 to rely on configuration information to determine link bandwidths; 2006 this has the drawback of not being robust to errors in 2007 configuration. Another possibility would be for network device 2008 drivers to infer the bandwidth for the interface and to communicate 2009 this to the IP layer. 2011 Particular issues will arise for wireless links with variable 2012 bandwidth, where decisions will have to be made about how frequently 2013 the network host gets updates of the changing bandwidth. It seems 2014 appropriate that Quick-Start Requests would be handled particularly 2015 conservatively for links with variable bandwidth, to avoid cases 2016 where Quick-Start Requests are approved, the link bandwidth is 2017 reduced, and the data packets that are send end up being dropped. 2019 10.3. Possible Deployment Scenarios 2021 Because of possible problems discussed above concerning using Quick- 2022 Start over some network paths, the most realistic initial deployment 2023 of Quick-Start would likely to take place in Intranets and other 2024 controlled environments. Quick-Start is most useful on high 2025 bandwidth-delay paths that are significantly underutilized. The 2026 primary initial users of Quick-Start would likely be in 2027 organizations that provide network services to their users and also 2028 have control over a large portion of the network path. 2030 Below are a few examples of networking environments where Quick- 2031 Start would potentially be useful. These are the environments that 2032 might consider an initial deployment of Quick-Start in the routers 2033 and end-nodes, where the incentives for routers to deploy Quick- 2034 Start might be the most clear. 2036 * Centrally-administrated organizational Intranets often have large 2037 network capacity and the networks are underutilized for most of the 2038 time. Such Intranets might also include high-bandwidth and high- 2039 delay paths to remote sites. In such an environment, Quick-Start 2040 would be of benefit to users, and there would be a clear incentive 2041 for the deployment of Quick-Start in routers. For example, Quick- 2042 Start could be quite useful in high-bandwidth networks used for 2043 scientific computing. 2045 * Quick-Start could also be useful in high-delay environments of 2046 Cellular Wide-Area Wireless Networks such as the GPRS [BW97] and 2047 their enhancements and next generations. For example, GPRS EDGE 2048 (Enhanced Data for GSM Evolution) is expected to provide wireless 2049 bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per 2050 second) while the GPRS round-trip times range typically from few 2051 hundred milliseconds to over a second excluding any possible 2052 queueing delays in the network [GPAR02]. In addition, these networks 2053 sometimes have variable additional delays due to resource allocation 2054 that could be avoided by keeping the connection path constantly 2055 utilized, starting from initial slow-start. Thus, Quick-Start could 2056 be of significant benefit to users in these environments. 2058 * Geostationary Orbit (GEO) satellite links have one-way propagation 2059 delays on the order of 250 ms while the bandwidth can be measured in 2060 megabits per second [RFC2488]. Because of the considerable 2061 bandwidth-delay product on the link, TCP's slow-start is a major 2062 performance limitation in the beginning of the connection. A large 2063 initial congestion window would be useful to users of such satellite 2064 links. 2066 10.4. Would QuickStart packets take the slow path in routers? 2068 How much delay would the slow path add to the processing time for 2069 this packet? Similarly, if QuickStart packets took the slow path, 2070 how much stress would it add to routers for there to be many more 2071 packets on the slow path, because of the number of packets using 2072 QuickStart? These are both questions to be explored while 2073 experimenting with Quick-Start in the Internet. 2075 10.5. A Comparison with the Deployment Problems of ECN 2077 Given the glacially slow rate of deployment of ECN in the Internet 2078 to date [MAF05], it is disconcerting to note that some of the 2079 deployment problems of Quick-Start are even greater than those of 2080 ECN. First, unlike ECN, which can be of benefit even if it is only 2081 deployed on one of the routers along the end-to-end path, a 2082 connection's use of Quick-Start requires its deployment on all of 2083 the routers along the end-to-end path. Second, unlike ECN, which 2084 uses an allocated field in the IP header, Quick-Start requires the 2085 extra complications of an IP Option. 2087 However, in spite of these issues, there is some hope for the 2088 deployment of Quick-Start, at least in protected corners of the 2089 Internet, because the potential benefits of Quick-Start to the user 2090 are considerably more dramatic than those of ECN. Rather than 2091 simply replacing the occasional dropped packet by an ECN-marked 2092 packet, Quick-Start is capable of dramatically increasing the 2093 throughput of connections in underutilized environments. 2095 11. Related Work 2097 The Quick-Start proposal, taken together with HighSpeed TCP [F03] or 2098 other transport protocols for high-bandwidth transfers,, could go a 2099 significant way towards extending the range of performance for best- 2100 effort traffic in the Internet. However, there are many things that 2101 the Quick-Start proposal would not accomplish. Quick-Start is not a 2102 congestion control mechanism, and would not help in making more 2103 precise use of the available bandwidth, that is, of achieving the 2104 goal of high throughput with low delay and low packet loss rates. 2105 Quick-Start would not give routers more control over the decrease 2106 rates of active connections. % One of the open questions addressed 2107 later in this % document is whether the % limited capabilities of 2108 Quick-Start are sufficient to warrant % standardization and 2109 deployment, or whether more work is % needed first to explore the 2110 space of potential mechanisms. 2112 In addition, any evaluation of Quick-Start must include a discussion 2113 of the relative benefits of approaches that use no explicit 2114 information from routers, and of approaches that use more fine- 2115 grained feedback from routers as part of a larger congestion control 2116 mechanism. We discuss three classes of proposals (no explicit 2117 feedback from routers; explicit feedback about the initial rate; and 2118 more fine-grained feedback from routers) in the sections below. 2120 11.1. Fast Start-ups without Explicit Information from Routers 2122 One possibility would be for senders to use information from the 2123 packet streams to learn about the available bandwidth, without 2124 explicit information from routers. These techniques would not allow 2125 a start-up as fast as that available from Quick-Start in an 2126 underutilized environment; one has to have sent some packets 2127 already to use the packet stream to learn about available bandwidth. 2128 However, these techniques could allow a start-up considerably faster 2129 than the current slow-start. While it seems clear that approaches 2130 *without* explicit feedback from the routers will be strictly less 2131 powerful that is possible *with* explicit feedback, it is also 2132 possible that approaches that are more aggressive than slow-start 2133 are possible without explicit feedback from routers. 2135 Periodic packet streams: 2136 [JD02] explores the use of periodic packet streams to estimate the 2137 available bandwidth along a path. The idea is that the one-way 2138 delays of a periodic packet stream show an increasing trend when the 2139 stream's rate is higher than the available bandwidth. While [JD02] 2140 states that the proposed mechanism does not cause significant 2141 increases in network utilization, losses, or delays when done by one 2142 flow at a time, the approach could be problematic if conducted 2143 concurrently by a number of flows. [JD02] also gives an overview of 2144 some of the earlier work on inferring the available bandwidth from 2145 packet trains. 2147 Swift-Start: 2148 The Swift Start proposal from [PRAKS02] combines packet-pair and 2149 packet-pacing techniques. An initial congestion window of four 2150 segments is used to estimate the available bandwidth along the path. 2151 This estimate is then used to dramatically increase the congestion 2152 window during the second RTT of data transmission. 2154 While continued research on the limits of the ability of TCP and 2155 other transport protocols to learn of available bandwidth without 2156 explicit feedback from the router seems useful, we note that there 2157 are several fundamental advantages of explicit feedback from 2158 routers. 2160 (1) Explicit feedback is faster than implicit feedback: 2161 One advantage of explicit feedback from the routers is that it 2162 allows the transport sender to reliably learn of available bandwidth 2163 in one round-trip time. 2165 (2) Explicit feedback is more reliable than implicit feedback: 2166 A second advantage of explicit feedback from the routers is that the 2167 available bandwidth along the path does not necessarily map to the 2168 allowed sending rate for an individual flow. As an example, if the 2169 TCP sender sends four packets back-to-back in the initial window, 2170 and the TCP receiver reports that the data packets were received 2171 with roughly the same spacing as they were transmitted, does this 2172 mean that the flow can infer an underutilized path? And how fast 2173 can the flow send in the next round-trip time? Do the results 2174 depend on the level of statistical multiplexing at the congested 2175 link, and on the number of flows attempting a faster start-up at the 2176 same time? 2178 11.2. Optimistic Sending without Explicit Information from Routers 2180 Another possibility that has been suggested [S02] is for the sender 2181 to start with a large initial window without explicit permission 2182 from the routers and without bandwidth estimation techniques, and 2183 for the first packet of the initial window to contain information 2184 such as the size or sending rate of the initial window. The 2185 proposal would be that congested routers would use this information 2186 in the first data packet to drop or delay many or all of the packets 2187 from that initial window. In this way a flow's optimistically-large 2188 initial window would not force the router to drop packets from 2189 competing flows in the network. Such an approach would seem to 2190 require some mechanism for the sender to ensure that the routers 2191 along the path understood the mechanism for marking the first packet 2192 of a large initial window. 2194 Obviously there would be a number of questions to consider about an 2195 approach of optimistic sending. 2197 (1) Incremental deployment: 2198 One question would be the potential complications of incremental 2199 deployment, where some of the routers along the path might not 2200 understand the packet information describing the initial window. 2202 (2) Congestion collapse: 2203 There could also be concerns about congestion collapse if many flows 2204 used large initial windows, many packets were dropped from 2205 optimistic initial windows, and many congested links ended up 2206 carrying packets that are only going to be dropped downstream. 2208 (3) Distributed Denial of Service attacks: 2209 A third key question would be the potential role of optimistic 2210 senders in amplifying the damage done by a Distributed Denial of 2211 Service (DDoS) attack. 2213 (4) Performance hits if a packet is dropped: 2214 A fourth issue would be to quantify the performance hit to the 2215 connection when a packet is dropped from one of the initial windows. 2217 11.3. Fast Start-ups with other Information from Routers 2219 There have been several proposals somewhat similar to Quick-Start, 2220 where the transport protocol collects explicit information from the 2221 routers along the path. 2223 An IP Option about the free buffer size: 2224 In related work, [P00] investigates the use of a slightly different 2225 IP option for TCP connections to discover the available bandwidth 2226 along the path. In that proposal, the IP option would query the 2227 routers along the path about the smallest available free buffer 2228 size. Also, the IP option would have been sent after the initial SYN 2229 exchange, when the TCP sender already had an estimate of the round- 2230 trip time. 2232 The Performance Transparency Protocol: 2233 The Performance Transparency Protocol (PTP) includes a proposal for 2234 a single PTP packet that would collect information from routers 2235 along the path from the sender to the receiver [W00]. For example, 2236 a single PTP packet could be used to determine the bottleneck 2237 bandwidth along a path. 2239 ETEN: 2240 Additional proposals for end nodes to collect explicit information 2241 from routers include Explicit Transport Error Notification (ETEN), 2242 which includes a cumulative mechanism to notify endpoints of 2243 aggregate congestion statistics along the path [KAPS02]. 2245 11.4. Fast Start-ups with more Fine-Grained Feedback from Routers 2247 Proposals for more fine-grained congestion-related feedback from 2248 routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking 2249 [K03]. Section A.6 discusses in more detail the relationship 2250 between Quick-Start and proposals for more fine-grained per-packet 2251 feedback from routers. 2253 XCP: 2254 Proposals such as XCP for new congestion control mechanisms based on 2255 more feedback from routers are more powerful than Quick-Start, but 2256 also are more complex to understand and more difficult to deploy. 2257 XCP routers maintain no per-flow state, but provide more fine- 2258 grained feedback to end-nodes than the one-bit congestion feedback 2259 of ECN. The per-packet feedback from XCP can be positive or 2260 negative, and specifies the increase or decrease in the sender's 2261 congestion window when this packet is acknowledged. 2263 AntiECN: 2264 The AntiECN proposal is for a single bit in the packet header that 2265 routers could set to indicate that they are underutilized. For each 2266 TCP ACK arriving at the sender indicating that a packet has been 2267 received with the Anti-ECN bit set, the sender would be able to 2268 increase its congestion window by one packet, as it would during 2269 slow-start. 2271 12. Security Considerations 2273 Sections 9.4 and 9.5 discuss the security considerations related to 2274 Quick-Start. Section 9.4 discusses the potential abuse of Quick- 2275 Start of receivers lying about whether the request was approved or 2276 about the approved rate; of routers in collusion to misuse Quick- 2277 Start; and of potential problems with traffic normalizers that 2278 rewrite IP TTLs in packet headers. All of these problems could 2279 result in the sender using a Rate Request that was inappropriately 2280 large, or thinking that a request was approved when it was in fact 2281 denied by at least one router along the path. This inappropriate 2282 use of Quick-Start would result in congestion and an unacceptable 2283 level of packet drops along the path, Such congestion could also be 2284 part of a Denial of Service attack. 2286 Section 9.5 discusses a potential attack on the routers' processing 2287 and state load from an attack of Quick-Start Requests. Section 9.5 2288 also discusses a potential attack on the available Quick-Start 2289 bandwidth by sending bogus Quick-Start requests for bandwidth that 2290 will not in fact be used. 2292 Section 4.6.2 discusses the potential problem of packets with Quick- 2293 Start Requests dropped by middleboxes along the path. 2295 As discussed in Section 5, for IPv4 IPsec Authentication Header 2296 Integrity Check Value (AH ICV) calculation, the Quick-Start Request 2297 option MUST be treated as a mutable IPv4 option, and hence 2298 completely zeroed for AH ICV calculation purposes; this is also the 2299 treatment required by RFC 2402 for unrecognized IPv4 options. The 2300 IPv6 Quick-Start Request option's IANA-allocated option type 2301 indicates that it is a mutable option, hence, according to RFC 2402, 2302 its option data MUST be zeroed for AH ICV computation purposes. See 2303 RFC 2402 for further explanation. 2305 Section 6.2 discusses possible problems of Quick-Start used by 2306 connections carried over simple tunnels that are not compatible with 2307 Quick-Start. In this case it is possible that a Quick-Start 2308 Request is erroneously considered approved by the sender without the 2309 routers in the tunnel having individually approved the request, 2310 causing a false positive. 2312 13. Conclusions 2314 We are presenting the Quick-Start mechanism as a simple, 2315 understandable, and incrementally-deployable mechanism that would be 2316 sufficient to allow some connections to start up with large initial 2317 rates, or large initial congestion windows, in overprovisioned, 2318 high-bandwidth environments. We expect there will be an increasing 2319 number of overprovisioned, high-bandwidth environments where the 2320 Quick-Start mechanism, or another mechanism of similar power, could 2321 be of significant benefit to a wide range of traffic. We are 2322 presenting the Quick-Start mechanism as a request for the community 2323 to provide feedback and experimentation on issues relating to Quick- 2324 Start. 2326 14. Acknowledgements 2328 The authors wish to thank Mark Handley for discussions of these 2329 issues. The authors also thank the End-to-End Research Group, the 2330 Transport Services Working Group, and members of IPAM's program on 2331 Large Scale Communication Networks for both positive and negative 2332 feedback on this proposal. We thank Srikanth Sundarrajan for the 2333 initial implementation of Quick-Start in the NS simulator, and for 2334 the initial simulation study. Many thanks to David Black and Joe 2335 Touch for extensive feedback on QuickStart and IP tunnels. We also 2336 thank Mohammed Ashraf, John Border, Martin Duke, Tom Dunigan, Gorry 2337 Fairhurst, John Heidemann, Paul Hyder, Dina Katabi and Vern Paxson, 2338 for feedback. This draft builds upon the concepts described in 2339 [RFC3390], [AHO98], [RFC2415], and [RFC3168]. Some of the text on 2340 Quick-Start in tunnels was borrowed directly from RFC 3168. 2342 This is a modification of a draft originally by Amit Jain for 2343 Initial Window Discovery. 2345 A. Design Decisions 2347 A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP 2349 This document has proposed using an IP Option for the Quick-Start 2350 Request from the sender to the receiver, and using transport 2351 mechanisms for the Quick-Start Response from the receiver back to 2352 the sender. In this section we discuss alternate mechanisms, and 2353 consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols 2354 could be used for delivering the Quick-Start Request. 2356 A.1.1. ICMP 2358 Being a control protocol used between Internet nodes, one could 2359 argue that ICMP is the ideal method for requesting a permission for 2360 faster startup from routers. The ICMP header is above the IP 2361 header. Quick-Start could be accomplished with ICMP as follows: If 2362 the ICMP protocol is used to implement Quick-Start, the equivalent 2363 of the Quick-Start IP option would be carried in the ICMP header of 2364 the ICMP Quick-Start Request. The ICMP Quick-Start Request would 2365 have to pass by the routers on the path to the receiver; for now, we 2366 don't address the mechanisms that would be needed to accomplish this 2367 task. A router that approves the Quick-Start Request would take the 2368 same actions as in the case with the Quick-Start IP Option, and 2369 forward the packet to the next router along the path. A router that 2370 does not approve the Quick-Start Request, even with a decreased 2371 value for the Requested Rate, would delete the ICMP Quick-Start 2372 Request, and send an ICMP Reply to the sender that the request was 2373 not approved. If the ICMP Reply was dropped in the network, and did 2374 not reach the receiver, the sender would still know that the request 2375 was not approved from the absence of feedback from the receiver. If 2376 the ICMP Quick-Start request was dropped in the network due to 2377 congestion, the sender would assume that the request was not 2378 approved. If the ICMP Quick-Start Request reached the receiver, the 2379 receiver would use transport-level mechanisms to send a response to 2380 the sender, exactly as with the IP Option. 2382 One benefit of using ICMP would be that the delivery of the TCP SYN 2383 packet or other initial packet would not be delayed by IP option 2384 processing at routers. A greater advantage is that if middleboxes 2385 were blocking packets with Quick-Start Requests, using the Quick- 2386 Start Request in a separate ICMP packet would mean that the 2387 middlebox behavior would not affect the connection as a whole. (To 2388 get this robustness to middleboxes with TCP using an IP Quick-Start 2389 Option, one would have to have a TCP-level Quick-Start Request 2390 packet that was sent concurrently but separately from the TCP SYN 2391 packet.) 2393 However, there are a number of disadvantages to using ICMP. Some 2394 firewalls and middleboxes may not forward the ICMP Quick-Start 2395 Request packets. (If an ICMP Reply packet from a router to the 2396 sender is dropped in the network, the sender would still know that 2397 the request was not approved, as stated earlier, so this would not 2398 be a problem.) In addition, it would be difficult, if not 2399 impossible, for a router in the middle of an IP tunnel to deliver an 2400 ICMP Reply packet to the actual source, for example when the inner 2401 IP header is encrypted as in IPsec tunnel mode [RFC2401]. Again, 2402 however, the ICMP Reply packet would not be essential to the correct 2403 operation of ICMP Quick-Start. 2405 Unauthenticated out-of-band ICMP messages could enable some types of 2406 attacks by third-party malicious hosts that are not possible when 2407 the control information is carried in-band with the IP packets that 2408 can only be altered by the routers on the connection path. Finally, 2409 as a minor concern, using ICMP would cause a small amount of 2410 additional traffic in the network, which is not the case when using 2411 IP options. 2413 A.1.2. RSVP 2415 With some modifications RSVP [RFC2205] could be used as a bearer 2416 protocol for carrying the Quick-Start Requests. Because routers are 2417 expected to process RSVP packets more extensively than the normal 2418 transport protocol IP packets, delivering a Quick-Start rate request 2419 using an RSVP packet would seem an appealing choice. However, Quick- 2420 Start with RSVP would require a few differences from the 2421 conventional usage of RSVP. Quick-Start would not require periodical 2422 refreshing of soft state, because Quick-Start does not require per- 2423 connection state in routers. Quick-Start Requests would be 2424 transmitted downstream from the sender to receiver in the RSVP Path 2425 messages, which is different from the conventional RSVP model where 2426 the reservations originate from the receiver. Furthermore, the 2427 Quick-Start Response would be sent using the transport-level 2428 mechanisms instead of using the RSVP Resv message. 2430 If RSVP was used for carrying a Quick-Start Request, a new "Quick- 2431 Start Request" class object would be included in the RSVP Path 2432 message that is sent from the sender to receiver. The object would 2433 contain the rate request field in addition to the common length and 2434 type fields. The Send_TTL field in the RSVP common header could be 2435 used as the equivalent of the QS TTL field. The Quick-Start capable 2436 routers along the path would inspect the Quick-Start Request object 2437 in the RSVP Path message, decrement Send_TTL and adjust the rate 2438 request field if needed. If an RSVP router did not understand the 2439 Quick-Start Request object, it would reject the entire RSVP message 2440 and send an RSVP PathErr message back to the sender. When an RSVP 2441 message with the Quick-Start Request object reaches the receiver, 2442 the receiver sends a Quick-Start Reply message in the corresponding 2443 transport protocol header in the same way as described in the 2444 context of IP options earlier. If the RSVP message with the Quick- 2445 Start Request object was dropped along the path, the transport 2446 sender would simply proceed with the normal congestion control 2447 procedures. 2449 Much of the discussion about benefits and drawbacks of using ICMP 2450 for making the Quick-Start Request also applies to the RSVP case. If 2451 the Quick-Start Request was transmitted in a separate packet instead 2452 of as an IP option, the transport protocol packet delivery would not 2453 be delayed due to IP option processing at the routers, and the 2454 initial transport packets would reach their destination more 2455 reliably. The possible disadvantages of using ICMP and RSVP are also 2456 expected to be similar: middleboxes in the network may not be able 2457 to forward the Quick-Start Request messages, and the IP tunnels 2458 might cause problems for processing the Quick-Start Requests. 2460 A.2. Alternate Encoding Functions 2462 In this section we look at alternate encoding functions for the Rate 2463 Request field in the Quick-Start Request. The main requirements for 2464 this function is that it should have a sufficiently wide range for 2465 the requested rate. There is no need for overly-fine-grained 2466 precision in the requested rate. Similarly, while it would be 2467 attractive for the encoding function to be easily computable, it is 2468 also possible for end-nodes and routers to simply store the table 2469 giving the mapping between the value N in the Rate Request field, 2470 and the actual rate request f(N). In this section we consider both 2471 four-bit and eight-bit Rate Request fields. 2473 Linear functions: 2474 The Quick-Start Request contains an 8-bit field for the Rate 2475 Request. One possible proposal would be for this field to be 2476 formatted in bits per second, scaled so that one unit equals 80 2477 Kbps. Thus, for the value N in the Rate Request field, the 2478 requested rate is 80,000*N bps. This gives a request range between 2479 80 Kbps and 20.48 Mbps. For 1500-byte packets, this corresponds to 2480 a request range between 6 and 1706 packets per second. 2482 Powers of two: 2483 If a granularity of factors of two is sufficient for the Rate 2484 Request, then the encoding function with the most range would be for 2485 the requested rate to be K*2^N, for N the value in the Rate Request 2486 field, and for K some constant. For N=0, the rate request would be 2487 set to zero, regardless of the encoding function. For example, for 2488 K=40,000, the request range would be from 80 Kbps to 40*2^256 Kbps. 2489 This clearly would be an unnecessarily large request range. 2491 For a four-bit Rate Request field, the upper limit on the rate 2492 request is 1.3 Gbps. It is possible that an upper limit of 1.3 Gbps 2493 would be fine for the Quick-Start rate request, and that connections 2494 wishing to start up with a higher initial sending rate should be 2495 encouraged to use other mechanisms, such as the explicit reservation 2496 of bandwidth. If an upper limit of 1.3 Gbps is not acceptable, then 2497 five bits could be used for the Rate Request field. 2499 If the granularity of factors of two is too coarse, then the 2500 encoding function could use a base less than two. An alternate form 2501 for the encoding function would be to use a hybrid of linear and 2502 exponential functions. 2504 We note that the Rate Request also has to be constrained by the 2505 abilities of the transport protocol. For example, for TCP with 2506 Window Scaling, the maximum window is at most 2**30 bytes. For a 2507 TCP connection with a long, 1 second round-trip time, this would 2508 give a maximum sending rate of 1.07 Gbps. 2510 A.3. The Quick-Start Request: Packets or Bytes? 2512 One of the design questions is whether the Rate Request field should 2513 be in bytes per second or in packets per second. We will discuss 2514 this separately from the perspective of the transport, and from the 2515 perspective of the router. 2517 For TCP, the results from the Quick-Start Request are translated 2518 into a congestion window in bytes, using the measured round-trip 2519 time and the MSS. This window applies only to the bytes of data 2520 payload, and does not include the bytes in the TCP or IP packet 2521 headers. Other transport protocols would conceivably use the Quick- 2522 Start Request directly in packets per second, or could translate the 2523 Quick-Start Request to a congestion window in packets. 2525 The assumption of this draft is that the router only approves the 2526 Quick-Start Request when the output link is significantly 2527 underutilized. For this, the router could measure the available 2528 bandwidth in bytes per second, or could convert between packets and 2529 bytes by some mechanism. 2531 If the Quick-Start Request was in bytes per second, and applied only 2532 to the data payload, then the router would have to convert from 2533 bytes per second of data payload, to bytes per second of packets on 2534 the wire. If the Rate Request field was in bytes per second and the 2535 sender ended up using very small packets, this could translate to a 2536 significantly larger number in terms of bytes per second on the 2537 wire. Therefore, for a Quick-Start Request in bytes per second, it 2538 makes most sense for this to include the transport and IP headers as 2539 well as the data payload. Of course, this will be at best a rough 2540 approximation on the part of the sender; the transport-level sender 2541 might not know the size of the transport and IP headers in bytes, 2542 and might know nothing at all about the separate headers added in IP 2543 tunnels downstream. This rough estimate seems sufficient, however, 2544 given the overall lack of fine precision in Quick-Start 2545 functionality. 2547 It has been suggested that the router could possibly use information 2548 from the MSS option in the TCP packet header of the SYN packet to 2549 convert the Quick-Start Request from packets per second to bytes per 2550 second, or vice versa. The MSS option is defined as the maximum MSS 2551 that the TCP sender expects to receive, not the maximum MSS that the 2552 TCP sender plans to send [RFC793]. However, it is probably often 2553 the case that this MSS also applies as an upper bound on the MSS 2554 used by the TCP sender in sending. 2556 We note that the sender does not necessarily know the Path MTU when 2557 the Quick-Start Request is sent, or when the initial window of data 2558 is sent. Thus, with IPv4, packets from the initial window could end 2559 up being fragmented in the network if the "Don't Fragment" (DF) bit 2560 is not set [RFC1191]. A Rate Request in bytes per second is 2561 reasonably robust to fragmentation. Clearly a Rate Request in 2562 packets per second is less robust in the presence of fragmentation. 2563 Interactions between larger initial windows and Path MTU Discovery 2564 are discussed in more detail in RFC 3390 [RFC3390]. 2566 For a Quick-Start Request in bytes per second, the transport senders 2567 would have the additional complication of estimating the bandwidth 2568 usage added by the packet headers. 2570 We have chosen a Rate Request field in bytes per second rather than 2571 in packets per second because it seems somewhat more robust, 2572 particularly to routers. 2574 A.4. Quick-Start Semantics: Total Rate or Additional Rate? 2576 For a Quick-Start Request sent in the middle of a connection, there 2577 are two possible semantics for the Rate Request field, as follows: 2579 (1) Total Rate: The requested Rate Request is the requested total 2580 rate for the connection, including the current rate; or 2582 (2) Additional Rate: The requested Rate Request is the requested 2583 increase in the total rate for that connection, over and above the 2584 current sending rate. 2586 When the Quick-Start Request is sent after an idle period, the 2587 current sending rate is zero, and there is no difference between (1) 2588 and (2) above. However, a Quick-Start Request can also be sent in 2589 the middle of a connection that has not been idle, e.g., after a 2590 mobility event, or after an application-limited period when the 2591 sender is suddenly ready to send at a much higher rate. In this 2592 case, there can be a significant difference between (1) and (2) 2593 above. In this section we consider briefly the tradeoffs between 2594 these two options, and explain why we have chosen the `Total Rate' 2595 semantics. 2597 The Total Rate semantics makes it easier for routers to ``allocate'' 2598 the same rate to all connections. This lends itself to fairness, 2599 and improves convergence times between old and new connections. 2600 With the Additional Rate semantics, the router would not necessarily 2601 know the current sending rates of the flows requesting additional 2602 rates, and therefore would not have sufficient information to use 2603 fairness as a metric in granting rate requests. With the Total Rate 2604 semantics, the fairness is automatic; the router is not granting 2605 rate requests for *additional* bandwidth without knowing the current 2606 sending rates of the different flows. 2608 The Additional Rate semantics also lends itself to gaming by the 2609 connection, with senders sending frequent Quick-Start Requests in 2610 the hope of gaining a higher rate. If the router is granting the 2611 same maximum rate for all rate requests, then there is little 2612 benefit to a connection of sending a rate request over and over 2613 again. However, if the router is granting an *additional* rate with 2614 each rate request, over and above the current sending rate, then it 2615 is in a connection's interest to send as many rate requests as 2616 possible, even if very few of them are in fact granted. 2618 For either of these alternatives, there would not be room to report 2619 the current sending rate in the Quick-Start Option using the current 2620 minimal format for the Quick-Start Request. Thus, either the Quick- 2621 Start Option would have to take more than four bytes to include a 2622 report of the current sending rate, or the current sending rate 2623 would not be reported to the routers. 2625 A.5. Alternate Responses to the Loss of a Quick-Start Packet 2627 Section 4.5 discusses TCP's response to the loss of a Quick-Start 2628 packet in the initial window. This section discusses several 2629 alternate responses. 2631 One possible alternative to reverting to the default slow-start 2632 after the loss of a Quick-Start packet from the initial window would 2633 have been to halve the congestion window and continue in congestion 2634 avoidance. However, we note that this would not have been a 2635 desirable response for either the connection or for the network as a 2636 whole. The packet loss in the initial window indicates that Quick- 2637 Start failed in finding an appropriate congestion window, meaning 2638 that the congestion window after halving may easily also be wrong. 2640 A more moderate alternate would be to continue in congestion 2641 avoidance from a window of (W-D)/2, where W is the Quick-Start 2642 congestion window, and D is the number of packets dropped or marked 2643 from that window. However, such an approach would implicitly assume 2644 that the number of Quick-Start packets delivered is a good 2645 indication of the appropriate available bandwidth for that flow, 2646 even though other packets from that window were dropped in the 2647 network. We believe that such an assumption would require more 2648 analysis at this point, particularly in a network with a range of 2649 packet dropping mechanisms at the router, and we cannot recommend it 2650 at this time. 2652 Another drawback of approaches that don't revert back to slow-start 2653 when a Quick-Start packet in the initial window is dropped is that 2654 any such approaches could give the TCP receiver an incentive to lie 2655 about the Quick-Start request. That is, if the sender reverts to 2656 slow-start when a Quick-Start packet is dropped, then it is 2657 generally not to the receiver's advantage to report a larger rate 2658 request than was actually approved if the result is going to be a 2659 Quick-Start packet dropped in the network. However, if the receiver 2660 benefits from a larger Quick-Start window even when the larger 2661 window results in Quick-Start packets dropped in the network, then 2662 the receiver has a greater incentive to lie about the received rate 2663 request, in an effort to get the sender to use a larger initial 2664 sending rate. 2666 A.6. Why Not Include More Functionality? 2668 This proposal for Quick-Start is a rather coarse-grained mechanism 2669 that would allow connections to use higher sending rates along 2670 underutilized paths, but that does not attempt to provide a next- 2671 generation transport protocol, and does not attempt the goal of 2672 providing very high throughput with very low delay. As Section 11.4 2673 discusses, there are a number of proposals such as XCP, MaxNet, and 2674 AntiECN for more fine-grained per-packet feedback from routers that 2675 the current congestion control mechanisms, that do attempt these 2676 more ambitious goals. 2678 Compared to proposals such as XCP and AntiECN, Quick-Start offers 2679 much less control. Quick-Start does not attempt to provide a new 2680 congestion control mechanism, but simply to get permission from 2681 routers for a higher sending rate at start-up, or after an idle 2682 period. Quick-Start can be thought of as an "anti-congestion- 2683 control" mechanism, that is only of any use when all of the routers 2684 along the path are significantly under-utilized. Thus, Quick-Start 2685 is of no use towards a target of high link utilization, or fairness 2686 in a high-utilization scenario, or controlling queueing delay during 2687 high-utilization, or anything of the like. 2689 At the same time, Quick-Start would allow larger initial windows 2690 than would proposals such as AntiECN, requires less input to routers 2691 than XCP, and would require less frequent feedback from routers than 2692 any new congestion control mechanism. Thus, Quick-Start is 2693 significantly less powerful than proposals for new congestion 2694 control mechanisms such as XCP and AntiECN, but as powerful or more 2695 powerful in terms of the specific issue of allowing larger initial 2696 windows, and (we think) more amenable to incremental deployment in 2697 the current Internet. 2699 We do not discuss proposals such as XCP in detail, but simply note 2700 that there are a number of open questions. One question concerns 2701 whether there is a pressing need for more sophisticated congestion 2702 control mechanisms such as XCP in the Internet. Quick-Start is 2703 inherently a rather crude tool that does not deliver assurances 2704 about maintaining high link utilization and low queueing delay; 2705 Quick-Start is designed for use in environments that are 2706 significantly underutilized, and addresses the single question of 2707 whether a higher sending rate is allowed. New congestion control 2708 mechanisms with more fine-grained feedback from routers could allow 2709 faster startups even in environments with rather high link 2710 utilization. Is this a pressing requirement? Are the other 2711 benefits of more fine-grained congestion control feedback from 2712 routers a pressing requirement? 2714 We would argue that even if more fine-grained per-packet feedback 2715 from routers was implemented, it is reasonable to have a separate 2716 mechanism such as Quick-Start for indicating an allowed initial 2717 sending rate, or an allowed total sending rate after an idle or 2718 underutilized period. 2720 One difference between Quick-Start and current proposals for fine- 2721 grained per-packet feedback such as XCP is that XCP is designed to 2722 give robust performance even in the case where different packets 2723 within a connection routinely follow different paths. XCP achieves 2724 relatively robust performance in the presence of multi-path routing 2725 by using per-packet feedback, where the feedback carried in a single 2726 packet is about the relative increase or decrease in the rate or 2727 window to take effect when that particular packet is acknowledged, 2728 not about the allowed sending rate for the connection as a whole. 2730 In contrast, Quick-Start sends a single Quick-Start request, and the 2731 answer to that request gives the allowed sending rate for an entire 2732 window of data. As a result, Quick-Start could be problematic in an 2733 environment where some fraction of the packets in a window of data 2734 take path A, and the rest of the packets take path B; for example, 2735 the Quick-Start Request could have travelled on path A, while half 2736 of the Quick-Start packets sent in the succeeding round-trip time 2737 are routed on path B. 2739 There are also differences between Quick-Start and some of the 2740 proposals for per-packet feedback in terms of the number of bits of 2741 feedback required from the routers to the end-nodes. Quick-Start 2742 uses four bits of feedback in the rate request field to indicate the 2743 allowed sending rate. XCP allocates a byte for per-packet feedback, 2744 though there has been discussion of variants of XCP with less per- 2745 packet feedback. This would be more like other proposals such as 2746 anti-ECN that use a single bit of feedback from routers to indicate 2747 that the sender can increase as fast as slow-starting, in response 2748 to this particular packet acknowledgement. In general, there is 2749 probably considerable power in fine-grained proposals with only two 2750 bits of feedback, indicating that the sender should decrease, 2751 maintain, or increase the sending rate or window when this packet is 2752 acknowledged. However, the power of Quick-Start would be 2753 considerably limited if it was restricted to only two bits of 2754 feedback; it seems likely that determining the initial sending rate 2755 fundamentally requires more bits of feedback from routers than does 2756 the steady-state, per-packet feedback to increase or decrease the 2757 sending rate. 2759 On a more practical level, one difference between Quick-Start and 2760 proposals for per-packet feedback is that there are fewer open 2761 issues with Quick-Start than there would be with a new congestion 2762 control mechanism. For example, for a mechanism for requesting a 2763 initial sending rate in an underutilized environment, the fairness 2764 issues of a general congestion control mechanism go away, and there 2765 is no need for the end nodes to tell the routers the round-trip time 2766 and congestion window, as is done in XCP; all that is needed is for 2767 the end nodes to report the requested sending rate. 2769 Table 2 provides a summary of the differences between Quick-Start 2770 and proposals for per-packet congestion control feedback. 2772 Proposals for 2773 Quick-Start Per-Packet Feedback 2774 +------------------+----------------------+----------------------+ 2775 Semantics: | Allowed sending rate | Change in rate/window, 2776 | per connection. | per-packet. 2777 +------------------+----------------------+----------------------+ 2778 Relationship to | In addition. | Replacement. 2779 congestion ctrl: | | 2780 +------------------+----------------------+----------------------+ 2781 Frequency: | Start-up, or after | Every packet. 2782 | an idle period. | 2783 +------------------+----------------------+----------------------+ 2784 Limitations: | Only useful on | General congestion 2785 | underutilized paths.| control mechanism. 2786 +------------------+----------------------+----------------------+ 2787 Input to routers: | Rate request. |RTT, cwnd, request (XCP) 2788 | | None (Anti-ECN). 2789 +------------------+----------------------+----------------------+ 2790 Bits of feedback: | Four bits for | A few bits would 2791 | rate request. | suffice? 2792 +------------------+----------------------+----------------------+ 2794 Table 2: Differences between Quick-Start and Proposals for 2795 Fine-Grained Per-Packet Feedback. 2797 A separate question concerns whether mechanisms such as Quick-Start, 2798 in combination with HighSpeed TCP and other changes in progress, 2799 would make a significant contribution towards meeting some of these 2800 needs for new congestion control mechanisms. This could be viewed 2801 as a positive step of meeting some of the current needs with a 2802 simple and reasonably deployable mechanism, or alternately, as a 2803 negative step of unnecessarily delaying more fundamental changes. 2804 Without answering this question, we would note that our own approach 2805 tends to favor the incremental deployment of relatively simple 2806 mechanisms, as long as the simple mechanisms are not short-term 2807 hacks but mechanisms that lead the overall architecture in the 2808 fundamentally correct direction. 2810 A.7. The Earlier QuickStart Nonce 2812 An earlier version of this document included a Request-Approved 2813 QuickStart Nonce (QS Nonce) that was initialized by the sender to a 2814 non-zero, `random' eight-bit number, along with a QS TTL that was 2815 initialized to the same value as the TTL in the IP header. The 2816 Request-Approved QuickStart Nonce would have been returned by the 2817 transport receiver to the transport sender in the Quick-Start 2818 Response. A router could deny the Quick-Start request by failing to 2819 decrement the QS TTL field, by zeroing the QS Nonce field, or by 2820 deleting the Quick-Start Request from the packet header. The QS 2821 Nonce was included to provide some protection against broken 2822 downstream routers, or against misbehaving TCP receivers that might 2823 be inclined to lie about whether the Rate Request was approved. 2824 This protection is now provided by the QS Nonce, by the use of a 2825 random initial value for the QS TTL field, and by Quick-Start- 2826 capable routers hopefully either deleting the Quick-Start Option or 2827 zeroing the QS TTL and QS Nonce fields when they deny a request. 2829 With the old Request-Approved QuickStart Nonce, along with the QS 2830 TTL field set to the same value as the TTL field in the IP header, 2831 the Quick-Start Request mechanism would have been self-terminating; 2832 the Quick-Start Request would terminate at the first participating 2833 router after a non-participating router had been encountered on the 2834 path. This minimizes unnecessary overhead incurred by routers 2835 because of option processing for the Quick-Start Request. In the 2836 current specification, this "self-terminating" property is provided 2837 by Quick-Start-capable routers hopefully either deleting the Quick- 2838 Start Option or zeroing the Rate Request field when they deny a 2839 request. Because the current specification uses a random initial 2840 value for the QS TTL, Quick-Start-capable routers can't tell if the 2841 Quick-Start Request is invalid because of non-Quick-Start-capable 2842 routers upstream. This is the cost of using a design that makes it 2843 difficult for the receiver to cheat about the value of the QS TTL. 2845 B. Quick-Start with DCCP 2847 DCCP is a new transport protocol for congestion-controlled, 2848 unreliable datagrams, intended for applications such as streaming 2849 media, Internet telephony, and on-line games. In DCCP, the 2850 application has a choice of congestion control mechanisms, with the 2851 currently-specified Congestion Control Identifiers (CCIDs) being 2852 CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an 2853 equation-based form of congestion control. We refer the reader to 2854 [KHF05] for a more detailed description of DCCP, and of the 2855 congestion control mechanisms. 2857 Because CCID 3 uses a rate-based congestion control mechanism, it 2858 raises some new issues about the use of Quick-Start with transport 2859 protocols. In this document we don't attempt to specify the use of 2860 Quick-Start with DCCP. However, we do discuss some of the issues 2861 that might arise. 2863 In considering the use of Quick-Start with CCID 3 for requesting a 2864 higher initial sending rate, the following questions arise: (1) how 2865 does the sender respond if a Quick-Start packet is dropped; and (2) 2866 when does the sender determine that there has been no feedback from 2867 the receiver, and reduce the sending rate? 2869 (1) How does the sender respond if a Quick-Start packet is dropped: 2870 As in TCP, if an initial Quick-Start packet is dropped, the CCID 3 2871 sender should revert to the congestion control mechanisms it would 2872 have used if the Quick-Start request had not been approved. 2874 (2) When does the sender decide there has been no feedback from the 2875 receiver: 2876 Unlike TCP, CCID 3 does not use acknowledgements for every packet, 2877 or for every other packet. In contrast, the CCID 3 receiver sends 2878 feedback to the sender roughly once per round-trip time. In CCID 3, 2879 the allowed sending rate is halved if no feedback is received from 2880 the receiver in at least four round-trip times (when the sender is 2881 sending at least one packet every two round-trip times). When a 2882 Quick-Start request is used, it would seem prudent to use a smaller 2883 time interval, e.g., to reduce the sending rate if no feedback is 2884 received from the receiver in at least two round-trip times. 2886 The question also arises of how the sending rate should be reduced 2887 after a period of no feedback from the receiver. As with TCP, the 2888 default CCID 3 response of halving the sending rate is not 2889 necessarily sufficient; an alternative is to reduce the sending rate 2890 to the sending rate that would have been used if no Quick-Start 2891 request had been approved. That is, if a CCID 3 sender uses a 2892 Quick-Start request, special rules might be required to handle the 2893 sender's response to a period of no feedback from the receiver 2894 regarding the Quick-Start packets. 2896 Similarly, in considering the use of Quick-Start with CCID 3 for 2897 requesting a higher sending rate after an idle period, the following 2898 questions arise: (1) what rate does the sender request; (2) what is 2899 the response to a loss; and (3) when does the sender determine that 2900 there has been no feedback from the receiver, and the sending rate 2901 must be reduced? 2903 (1) What rate does the sender request: 2904 As in TCP, there is a straightforward answer to the rate request 2905 that the CCID 3 sender should use in requesting a higher sending 2906 rate after an idle period. The sender knows the current loss event 2907 rate, either from its own calculations or from feedback from the 2908 receiver, and can determine the sending rate allowed by that loss 2909 event rate. This is the upper bound on the sending rate that should 2910 be requested by the CCID 3 sender. A Quick-Start request is useful 2911 with CCID 3 when the sender is coming out of an idle or 2912 underutilized period, because in standard operation CCID 3 does not 2913 allow the sender to send more that twice as fast as the receiver has 2914 reported received in the most recent feedback message. 2916 (2) What is the response to loss: 2917 The response to the loss of Quick-Start packets should be to return 2918 to the sending rate that would have been used if Quick-Start had not 2919 been requested. 2921 (3) When does the sender decide there has been no feedback from the 2922 receiver: 2923 As in the case of the initial sending rate, it would seem prudent to 2924 reduce the sending rate if no feedback is received from the receiver 2925 in at least two round-trip times. It seems likely that in this 2926 case, the sending rate should be reduced to the sending rate that 2927 would have been used if no Quick-Start request had been approved. 2929 C. Possible Router Algorithm 2931 This specification does not tightly define the algorithm a router 2932 uses when deciding whether to approve a Quick-Start Rate Request or 2933 whether and how to reduce a Rate Request. A range of algorithms is 2934 likely useful in this space and we consider the algorithm a 2935 particular router uses to be a local policy decision. In addition, 2936 we believe that additional experimentation with router algorithms is 2937 necessary to have a solid understanding of the dynamics various 2938 algorithms impose. However, we provide one particular algorithm in 2939 this appendix as an example and as a framework for thinking about 2940 additional mechanisms. 2942 [SAF05] provides several algorithms routers can use to consider 2943 incoming Rate Requests. The decision process involves two 2944 algorithms. First, the router needs to track the link utilization 2945 over the recent past. Second, this utilization needs to be updated 2946 by the potential new bandwidth from recent Quick-Start approvals, 2947 and then compared with the router's notion of when it is 2948 underutilized enough to approve Quick-Start requests (of some size). 2950 First, we define the "peak utilization" estimation technique (from 2951 [SAF05]). This mechanism records the utilization of the link every 2952 S seconds and stores the most recent N of these measurements. The 2953 utilization is then taken as the highest utilization of the N 2954 samples. This method, therefore, keeps N*S seconds of history. 2955 This algorithm reacts rapidly to increases in the link utilization. 2956 In [SAF05] S is set to 0.15 seconds, and experiments use values for 2957 N ranging from 3 to 20. 2959 Second, we define the "target" algorithm for processing incoming 2960 Quick-Start Rate Requests (also from [SAF05]). The algorithm relies 2961 on knowing the bandwidth of the outgoing link (which in many cases 2962 can be easily configured), the utilization of the outgoing link 2963 (from an estimation technique such as given above) and an estimate 2964 of the potential bandwidth from recent Quick-Start approvals. 2966 Tracking the potential bandwidth from recent Quick-Start approvals 2967 is another case where local policy dictates how it should be done. 2968 The simpliest method, outlined in Section 8.2, is for the router to 2969 keep track of the aggregate Quick-Start rate requests approved in 2970 the most recent two or more time intervals, including the current 2971 time interval, and to use the sum of the aggregate rate requests 2972 over these time intervals as the estimate of the approved Rate 2973 Requests. The experiments in [SAF05] keep track of the aggregate 2974 approved Rate Requests over the most recent two time intervals, for 2975 intervals of 150~msec. 2977 The target algorithm also depends on a threshold (qs_thresh) that is 2978 the fraction of the outgoing link bandwidth that represents the 2979 router's notion of "significantly underutilized". If the 2980 utilization, augmented by the potential bandwidth from recent Quick- 2981 Start approvals, is above this threshold then no Quick-Start Rate 2982 Requests will be approved. If the utilization is less than the 2983 threshold then Rate Requests will be approved. The Rate Requests 2984 will be reduced such that the bandwidth allocated would not drive 2985 the utilization to more than the given threshold. The algorithm is: 2987 util_bw = bandwidth * utilization; 2988 util_bw = util_bw + recent_qs_approvals; 2989 if (util_bw < (qs_thresh * bandwidth)) 2990 { 2991 approved = (qs_thresh * bandwidth) - util_bw; 2992 if (rate_request < approved) 2993 approved = rate_request; 2994 approved = round_down (approved); 2995 recent_qs_approvals += approved; 2996 } 2998 Also note that given that Rate Requests are fairly gross the 2999 approved rate should be rounded down when it does not fall exactly 3000 on one of the rates allowed by the encoding scheme. 3002 D. Possible Uses for the Reserved Fields 3004 The Quick-Start Request Option contains a four-bit Reserved field in 3005 the first four bytes, and a two-bit Reserved field in the last four 3006 bytes. In this section we discuss some of the possible uses that 3007 have been discussed for these Reserved bits. 3009 Reporting Approved Rate: A Quick-Start Request with the Reporting 3010 Approved Rate bit set would not be requesting Quick-Start bandwidth, 3011 but would be reporting the approved rate for Quick-Start bandwidth 3012 that was approved one round-trip time earlier. This could be used 3013 by routers to track which Quick-Start requests were actually 3014 approved and in use, along with the approved rate. 3016 Report of Current Sending Rate: A Quick-Start Request with the 3017 `Report of Current Sending Rate' bit set would be using the Rate 3018 Request field to report the current estimated sending rate for that 3019 connection. This could accompany a second Quick-Start Request in 3020 the same packet containing a standard rate request, for a connection 3021 that is using Quick-Start to increase its current sending rate. 3023 Request to Increase Sending Rate: A bit for `Request to Increase 3024 Sending Rate' would indicate that the connection is not idle or just 3025 starting up, but is attemmpting to use Quick-Start to increase its 3026 current sending rate. This bit would not change the semantics of 3027 the Rate Request field. 3029 RTT Estimate: A field for the RTT Estimate would contain one or more 3030 bits giving the sender's rough estimate of the round-trip time, if 3031 known. E.g., the sender could estimate whether the RTT was greater 3032 or less than 200 ms. 3034 Informational Request: An Informational Request bit would indicate 3035 that a request is purely informational, for the sender to find out 3036 if a rate request would be approved, and what size rate request 3037 would be approved, when the Informational Request is sent. For 3038 example, an Informational Request could be followed one round-trip 3039 time later by a standard Quick-Start Request. A router approving an 3040 Informational Request would not consider this as an approval for 3041 Quick-Start bandwidth to be used, and would not be under any 3042 obligation to approve a similar standard Quick-Start Request one 3043 round-trip time later. 3045 Use Format X for the Rate Request Field: A Quick-Start bit for `Use 3046 Format X for the Rate Request Field' would indicate that an 3047 alternate format was being used for the Rate Request field. 3049 Do Not Decrement: A Do Not Decrement bit could be set in a Quick- 3050 Start request if the sender would rather have the request denied 3051 than to have the rate request decremented in the network. This 3052 could be used if the sender was only interested in using Quick-Start 3053 if the original rate request was approved. 3055 If any of these functions were standardized for Quick-Start, the 3056 standardization would also have to address the issue of backwards 3057 compatibility with older Quick-Start routers or end-nodes that do 3058 not understand the newly-added function. 3060 Normative References 3062 [RFC793] J. Postel, Transmission Control Protocol, RFC 793, 3063 September 1981. 3065 [RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191, 3066 November 1990. 3068 [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 3069 (IPv6) Specification. RFC 2460, December 1998. 3071 [RFC2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 3072 Control. RFC 2581. April 1999. 3074 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D. The Addition 3075 of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed 3076 Standard, September 2001. 3078 [RFC3390] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's 3079 Initial Window. RFC 3390, October 2002. 3081 [RFC3742] Floyd, S., Limited Slow-Start for TCP with Large 3082 Congestion Windows, RFC 3742, Experimental, March 2004. 3084 Informative References 3086 [RFC792] J. Postel. Internet Control Message Protocol. RFC 792, 3087 September 1981. 3089 [RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC 3090 1812, June 1995. 3092 [RFC2003] Perkins, C., IP Encapsulation within IP, RFC 2003, 3093 October 1996. 3095 [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. 3096 April 1997. 3098 [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- 3099 Version 1 Functional Specification. RFC 2205, September 1997. 3101 [RFC2409] D. Harkins and D. Carrel, The Internet Key Exchange (IKE), 3102 RFC 2409, November 1998. 3104 [RFC2246] T. Dierks and C. Allen, The TLS Protocol, RFC 2246. 3106 [RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, 3107 D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. 3108 Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, 3109 Recommendations on Queue Management and Congestion Avoidance in the 3110 Internet, RFC 2309, April 1998. 3112 [RFC2401] S. Kent and R. Atkinson. Security Architecture for the 3113 Internet Protocol. RFC 2401, November 1998. 3115 [2401bis] S. Kent and K. Seo, Security Architecture for the Internet 3116 Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt, work- 3117 in-progress, March 2005. 3119 [RFC2402] S. Kent and R. Atkinson. IP Authentication Header. RFC 3120 2402, November 1998. 3122 [2402bis] S. Kent, IP Authentication Header, internet-draft draft- 3123 ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005. 3125 [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased 3126 Initial TCP Window Size. RFC 2415. September 1998. 3128 [RFC2416] T. Shepard and C. Partridge. When TCP Starts Up With Four 3129 Packets Into Only Three Buffers. RFC 2416. September 1998. 3131 [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol 3132 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. 3133 RFC 2463, December 1998. 3135 [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over 3136 Satellite Channels using Standard Mechanisms. RFC 2488. January 3137 1999. 3139 [RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and 3140 B. Palter, Layer Two Tunneling Protocol "L2TP", RFC 2661, August 3141 1999. 3143 [RFC2960] R. Stewart, et. al. Stream Control Transmission Protocol. 3144 RFC 2960, October 2000. 3146 [RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC 3147 3124. June 2001. 3149 [RFC3234] B. Carpenter and S. Brim, Middleboxes: Taxonomy and 3150 Issues, RFC 3234, February 2002. 3152 [RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344, 3153 August 2002. 3155 [RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. 3156 RFC 3360, August 2002. 3158 [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in 3159 IPv6. RFC 3775, June 2004. 3161 [RFC3819] P. Karn et al., "Advice for Internet Subnetwork 3162 Designers", July 2004. 3164 [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. 3165 Stenberg, UDP Encapsulation of IPsec ESP Packets, RFC 3948, January 3166 2005. 3168 [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP 3169 with Larger Initial Windows. ACM Computer Communication Review, July 3170 1998. 3172 [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of 3173 the new GSM Phase 2+ General Packet Radio Service. IEEE 3174 Communications Magazine, pages 94--104, August 1997. 3176 [FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End 3177 Congestion Control in the Internet, IEEE/ACM Transactions on 3178 Networking, August 1999. 3180 [F03] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC 3181 3649, December 2003. 3183 [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi- 3184 Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE 3185 Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, 3186 September 2002. 3188 [H05] P. Hoffman, email, October 2005. Citation for acknowledgement 3189 purposes only. 3191 [HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion 3192 Detection: Evasion, Traffic Normalization, and End-to-End Protocol 3193 Semantics, Proc. USENIX Security Symposium 2001. 3195 [IKEv2] Kaufman, C., (ed.), "Internet Key Exchange (IKEv2) 3196 Protocol", draft-ietf-ipsec-ikev2-17.txt, Internet draft (work in 3197 progress), September 2004. 3199 [Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM 3201 [JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available 3202 Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP 3203 Throughput, SIGCOMM 2002. 3205 [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet 3206 Congestion Control for Future High Bandwidth-Delay Product 3207 Environments. ACM Sigcomm 2002, August 2002. URL 3208 "http://ana.lcs.mit.edu/dina/XCP/". 3210 [KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion 3211 Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt, 3212 work in progress, March 2005. 3214 [K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High 3215 Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. 3216 URL "http://www.seas.upenn.edu/~kunniyur/". 3218 [KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. 3219 Sterbenz. Explicit Transport Error Notification (ETEN) for Error- 3220 Prone Wireless and Satellite Networks. Technical Report No. 8333, 3221 BBN Technologies, March 2002. URL 3222 "http://www.icir.org/mallman/papers/". 3224 [L05] Guohan Lu, Nonce in TCP Quick Start, draft, September 2005. 3225 URL "http://www.net-glyph.org/~lgh/nonce-usage.pdf". 3227 [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring 3228 Interactions Between Transport Protocols and Middleboxes, Internet 3229 Measurement Conference 2004, August 2004. URL 3230 "http://www.icir.org/tbit/". 3232 [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the 3233 Evolution of Transport Protocols in the Internet. To appear in 3234 Computer Communications Review, April 2004. 3236 [MaxNet] MaxNet Home Page, URL 3237 "http://netlab.caltech.edu/~bartek/maxnet.htm". 3239 [PK98] Venkata N. Padmanabhan and Randy H. Katz, TCP Fast Start: A 3240 Technique For Speeding Up Web Transfers, IEEE GLOBECOM '98, November 3241 1998. 3243 [P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection, 3244 report to John Jeidemann, 2000, private communication. Citation for 3245 acknowledgement purposes only. 3247 [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh 3248 Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical 3249 Report No. 8339, BBN Technologies, March 2002. URL 3250 "http://www.icir.org/mallman/papers/". 3252 [S02] Ion Stoica, private communication, 2002. Citation for 3253 acknowledgement purposes only. 3255 [SAF05] Pasi Sarolahti, Mark Allman, and Sally Floyd. Evaluating 3256 Quick-Start for TCP. Under submission, May 2005. URL 3257 "http://www.icir.org/floyd/quickstart.html". 3259 [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick 3260 Start with NS-2. Class Project, December 2002. Not publically 3261 available; citation for acknowledgement purposes only. 3263 [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed 3264 Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE 3265 International Performance, Computing, And Communications 3266 Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL 3267 "http://informatik.uibk.ac.at/users/c70370/research/publications/". 3269 [W03] Michael Welzl, PMTU-Options: Path MTU Discovery Using Options, 3270 expired internet-draft draft-welzl-pmtud-options-01.txt, work-in- 3271 progress. February 2003. 3273 [ZPS00] Y. Zhang, V. Paxson, and S. Shenker, The Stationarity of 3274 Internet Path Properties: Routing, Loss, and Throughput, ACIRI 3275 Technical Report, May 2000. 3277 E. IANA Considerations 3279 Quick-Start requires an IP Option and a TCP Option. 3281 E.1. IP Option 3283 Quick-Start requires that both an IPv4 and an IPv6 Option Number be 3284 allocated. The IPv4 Option would have a copied flag of 0, a class 3285 field of 00, and the assigned five-bit option number. The IPv6 3286 Option would have the first three bits of "001" [RFC 2460, Section 3287 4.2], with the first two bits indicating that the IPv6 node skip 3288 over this option and continue processing the header if it doesn't 3289 recognize the option type, and the third bit indicating that the 3290 Option Data may change en-route. 3292 In both cases the name of the option would be "QSR - Quick-Start 3293 Request", with this document as the reference document. 3295 E.2. TCP Option 3297 Quick-Start also requires that a TCP Option Number be allocated. 3298 The Length would be 4, and the Meaning would be "Quick-Start 3299 Request", with this document as the reference document. 3301 AUTHORS' ADDRESSES 3303 Amit Jain 3304 F5 Networks 3305 Email : a.jain@f5.com 3307 Sally Floyd 3308 Phone: +1 (510) 666-2989 3309 ICIR (ICSI Center for Internet Research) 3310 Email: floyd@icir.org 3311 URL: http://www.icir.org/floyd/ 3313 Mark Allman 3314 ICSI Center for Internet Research 3315 1947 Center Street, Suite 600 3316 Berkeley, CA 94704-1198 3317 Phone: (440) 243-7361 3318 Email: mallman@icir.org 3319 URL: http://www.icir.org/mallman/ 3321 Pasi Sarolahti 3322 Nokia Research Center 3323 P.O. Box 407 3324 FI-00045 NOKIA GROUP 3325 Finland 3326 Phone: +358 50 4876607 3327 Email: pasi.sarolahti@iki.fi 3329 Full Copyright Statement 3331 Copyright (C) The Internet Society 2005. This document is subject 3332 to the rights, licenses and restrictions contained in BCP 78, and 3333 except as set forth therein, the authors retain all their rights. 3335 This document and the information contained herein are provided on 3336 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3337 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3338 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3339 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3340 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3341 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3343 Intellectual Property 3345 The IETF takes no position regarding the validity or scope of any 3346 Intellectual Property Rights or other rights that might be claimed 3347 to pertain to the implementation or use of the technology described 3348 in this document or the extent to which any license under such 3349 rights might or might not be available; nor does it represent that 3350 it has made any independent effort to identify any such rights. 3351 Information on the procedures with respect to rights in RFC 3352 documents can be found in BCP 78 and BCP 79. 3354 Copies of IPR disclosures made to the IETF Secretariat and any 3355 assurances of licenses to be made available, or the result of an 3356 attempt made to obtain a general license or permission for the use 3357 of such proprietary rights by implementers or users of this 3358 specification can be obtained from the IETF on-line IPR repository 3359 at http://www.ietf.org/ipr. 3361 The IETF invites any interested party to bring to its attention any 3362 copyrights, patents or patent applications, or other proprietary 3363 rights that may cover technology that may be required to implement 3364 this standard. Please address the information to the IETF at ietf- 3365 ipr@ietf.org.