idnits 2.17.1 draft-ietf-tsvwg-quickstart-00.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2922. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2890), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 74: '... SHOULD delete the Quick-Start o...' RFC 2119 keyword, line 75: '... possible, SHOULD zero the QS TT...' RFC 2119 keyword, line 84: '... Added that "TCP SHOULD NOT use Quick-...' RFC 2119 keyword, line 505: '... sender MUST set the QS TTL field t...' RFC 2119 keyword, line 510: '...transport sender MUST calculate and st...' (29 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 (31 May 2005) is 6905 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 572, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'T1' is mentioned on line 675, but not defined == Missing Reference: 'T2' is mentioned on line 673, but not defined == Missing Reference: 'T0' is mentioned on line 675, but not defined == Unused Reference: 'RFC2309' is defined on line 2702, but no explicit reference was found in the text == Unused Reference: 'RFC2416' is defined on line 2715, but no explicit reference was found in the text == Unused Reference: 'FF99' is defined on line 2749, but no explicit reference was found in the text == Unused Reference: 'PK98' is defined on line 2802, 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 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2463 (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-11 Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 14 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-00.txt S. Floyd 4 Expires: November 2005 M. Allman 5 ICIR 6 P. Sarolahti 7 Nokia Research Center 8 31 May 2005 10 Quick-Start for TCP and IP 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she becomes aware will be disclosed, in accordance with 19 Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document specifies an optional Quick-Start mechanism for 46 transport protocols, in cooperation with routers, to determine an 47 allowed sending rate at the start and at times in the middle of a 48 data transfer. While Quick-Start is designed to be used by a range 49 of transport protocols, in this document we describe its use with 50 TCP. By using Quick-Start, a TCP host, say, host A, would indicate 51 its desired sending rate in bytes per second, using a Quick Start 52 Request option in the IP header of a TCP packet. Each router along 53 the path could, in turn, either approve the requested rate, reduce 54 the requested rate, or indicate that the Quick-Start request is not 55 approved. If the Quick-Start request is not approved, then the 56 sender would use the default congestion control mechanisms. The 57 Quick-Start mechanism can determine if there are routers along the 58 path that do not understand the Quick-Start Request option, or have 59 not agreed to the Quick-Start rate request. TCP host B communicates 60 the final rate request to TCP host A in a transport-level Quick- 61 Start Response in an answering TCP packet. Quick-Start is designed 62 to allow connections to use higher sending rates when there is 63 significant unused bandwidth along the path, and all of the routers 64 along the path support the Quick-Start Request. 66 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 67 Changes from draft-amit-quick-start-04.txt: 68 * A significant amount of general editing. 69 * Because the Rate Request field only uses four bits, specified 70 that the other four bits are reserved, and talked about a 71 possible use for them. This is discussed in a new section on 72 "A Rate-Reduced Nonce?" 73 * Specified that a Quick-Start-capable router denying a request 74 SHOULD delete the Quick-Start option, and if this is not 75 possible, SHOULD zero the QS TTL and the Rate Request fields. 76 * Made the following change: If the Quick-Start Response is lost 77 in the network, it is not retransmitted. 78 * For PMTUD, in Section 4.6, added a suggestion to send one large 79 packet in the initial window for PMTUD, and to send the other 80 packets at 576 bytes. 81 * Added a paragraph to Section 4.6.3 on retransmitted SYN packets, 82 saying they should use an RTO of three seconds and a new ISN 83 on the retransmitted SYN packet. 84 * Added that "TCP SHOULD NOT use Quick-Start" after an 85 application-limited period at this time, in Section 4.1, in 86 addition to the old sentence that this "requires further thought 87 and investigation". 88 * Added an appendix on "Possible Router Algorithm". 89 * Moved the section on "Quick-Start with DCCP" to the appendix. 90 * Name changed from draft-amit-quick-start-04.txt to 91 draft-tsvwg-quickstart-00.txt. 93 Changes from draft-amit-quick-start-03.txt: 94 * Added a citation to the paper on "Evaluating Quick-Start for 95 TCP", and added pointers to the work in that paper. 96 This work includes: 97 - Discussions of router algorithms. 98 - Discussions of sizing Quick-Start requests. 99 * Added sections on "Misbehaving Middleboxes", and on "Attacks on 100 Quick-Start". 102 Changes from draft-amit-quick-start-02.txt: 103 * Added a discussion on Using Quick-Start in the Middle of a 104 Connection. The request would be on the total rate, 105 not on the additional rate. 106 * Changed name "Initial Rate" to "Rate Request", and changed 107 the units from packets per second to bytes per second. 108 * The following sections are new: 109 - The Quick-Start Request Option for IPv6 110 - Quick-Start in IP Tunnels 111 - When to Use Quick-Start 112 - TCP: Responding to a Loss of a Quick-Start Packet 113 - TCP: A Quick-Start Request for a Larger Initial Window 114 - TCP: A Quick-Start Request after an Idle Period 115 - The Quick-Start Mechanisms in DCCP and other Transport 116 Protocols 117 - Quick-Start with DCCP 118 - Implementation and Deployment Issues 119 - Design Decisions 120 * Added a discussion of Kunniyur's Anti-ECN proposal. 121 * Added a section on simulations, with a brief discussion of the 122 simulations by Srikanth Sundarrajan. 124 Changes from draft-amit-quick-start-01.txt: 125 * Added a discussion in the related work section about the 126 possibility of optimistically sending a large initial window, 127 without explicit permission of routers. 128 * Added a discussion in the related work section about the 129 tradeoffs of XCP vs. Quick-Start. 130 * Added a section on "The Quick-Start Request: Packets or Bytes?" 132 Changes from draft-amit-quick-start-00.txt: 133 * The addition of a citation to [KHR02]. 134 * The addition of a Related Work section. 135 * Deleted the QS Nonce, in favor of a random initial value for the 136 QS TTL. 138 Table of Contents 140 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 7 141 2. Assumptions and General Principles. . . . . . . . . . . . . . 8 142 2.1. Overview of Quick-Start. . . . . . . . . . . . . . . . . 9 143 3. The Quick-Start Request in IP . . . . . . . . . . . . . . . . 12 144 3.1. The Quick-Start Request Option for IPv4. . . . . . . . . 12 145 3.2. The Quick-Start Request Option for IPv6. . . . . . . . . 14 146 3.3. Processing the Quick-Start Request at 147 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 148 3.4. Deciding the Permitted Rate Request at a 149 Router. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 150 3.5. Quick-Start in IP Tunnels. . . . . . . . . . . . . . . . 17 151 3.6. A Rate-Reduced Nonce?. . . . . . . . . . . . . . . . . . 19 152 4. The Quick-Start Mechanisms in TCP . . . . . . . . . . . . . . 20 153 4.1. When to Use Quick-Start. . . . . . . . . . . . . . . . . 21 154 4.2. The Quick-Start Response Option in the TCP 155 header. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 156 4.3. TCP: Sending the Quick-Start Response. . . . . . . . . . 23 157 4.4. TCP: Receiving and Using the Quick-Start 158 Response Packet . . . . . . . . . . . . . . . . . . . . . . . 24 159 4.5. TCP: Responding to a Loss of a Quick-Start 160 Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 161 4.6. TCP: A Quick-Start Request for a Larger Ini- 162 tial Window . . . . . . . . . . . . . . . . . . . . . . . . . 25 163 4.6.1. Determining the Rate to Request . . . . . . . . . . 25 164 4.6.2. Interactions with Path MTU Discovery. . . . . . . . 26 165 4.6.3. Quick-Start Request Packets that are 166 Discarded by Middleboxes . . . . . . . . . . . . . . . . . 27 167 4.7. TCP: A Quick-Start Request in the Middle of 168 Connection. . . . . . . . . . . . . . . . . . . . . . . . . . 28 169 4.8. An Example Quick-Start Scenario with TCP . . . . . . . . 29 170 5. The Quick-Start Mechanism in other Transport Pro- 171 tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 172 6. Evaluation of Quick-Start . . . . . . . . . . . . . . . . . . 30 173 6.1. Benefits of Quick-Start. . . . . . . . . . . . . . . . . 30 174 6.2. Costs of Quick-Start . . . . . . . . . . . . . . . . . . 31 175 6.3. Protection against Misbehaving Nodes . . . . . . . . . . 33 176 6.3.1. Receivers Lying about Whether the 177 Request was Approved . . . . . . . . . . . . . . . . . . . 33 178 6.3.2. Receivers Lying about the Approved 179 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 180 6.3.3. Collusion between Misbehaving Routers . . . . . . . 35 181 6.3.4. Misbehaving Middleboxes and the IP 182 TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 183 6.4. Quick-Start with QoS-enabled Traffic . . . . . . . . . . 36 184 6.5. Limitations of Quick-Start . . . . . . . . . . . . . . . 36 185 6.6. Attacks on Quick-Start . . . . . . . . . . . . . . . . . 37 186 6.7. Simulations with Quick-Start . . . . . . . . . . . . . . 37 187 7. Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 38 188 7.1. Fast Start-ups without Explicit Information 189 from Routers. . . . . . . . . . . . . . . . . . . . . . . . . 38 190 7.2. Optimistic Sending without Explicit Informa- 191 tion from Routers . . . . . . . . . . . . . . . . . . . . . . 39 192 7.3. Fast Start-ups with other Information from 193 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 194 7.4. Fast Start-ups with more Fine-Grained Feed- 195 back from Routers . . . . . . . . . . . . . . . . . . . . . . 41 196 8. Implementation and Deployment Issues. . . . . . . . . . . . . 41 197 8.1. Implementation Issues for Sending Quick- 198 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 42 199 8.2. Implementation Issues for Processing Quick- 200 Start Requests. . . . . . . . . . . . . . . . . . . . . . . . 42 201 8.3. Possible Deployment Scenarios. . . . . . . . . . . . . . 43 202 8.4. Would QuickStart packets take the slow path 203 in routers? . . . . . . . . . . . . . . . . . . . . . . . . . 44 204 8.5. A Comparison with the Deployment Problems of 205 ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 206 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 207 10. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . 45 208 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 209 A. Design Decisions. . . . . . . . . . . . . . . . . . . . . . . 45 210 A.1. Alternate Mechanisms for the Quick-Start 211 Request: ICMP and RSVP. . . . . . . . . . . . . . . . . . . . 45 212 A.1.1. ICMP. . . . . . . . . . . . . . . . . . . . . . . . 46 213 A.1.2. RSVP. . . . . . . . . . . . . . . . . . . . . . . . 47 214 A.2. Alternate Encoding Functions . . . . . . . . . . . . . . 48 215 A.3. The Quick-Start Request: Packets or Bytes? . . . . . . . 49 216 A.4. Quick-Start Semantics: Total Rate or Addi- 217 tional Rate?. . . . . . . . . . . . . . . . . . . . . . . . . 50 218 A.5. Alternate Responses to the Loss of a Quick- 219 Start Packet. . . . . . . . . . . . . . . . . . . . . . . . . 51 220 A.6. Why Not Include More Functionality?. . . . . . . . . . . 52 221 A.7. The Earlier QuickStart Nonce . . . . . . . . . . . . . . 55 222 B. Quick-Start with DCCP . . . . . . . . . . . . . . . . . . . . 56 223 C. Possible Router Algorithm . . . . . . . . . . . . . . . . . . 58 224 Normative References . . . . . . . . . . . . . . . . . . . . . . 60 225 Informative References . . . . . . . . . . . . . . . . . . . . . 60 226 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 63 227 IP Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 228 TCP Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 229 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 64 230 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 64 231 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 65 233 1. Introduction 235 Each TCP connection begins with a question: "What is the appropriate 236 sending rate for the current network path?" The question is not 237 answered explicitly for TCP, but each TCP connection determines the 238 sending rate by probing the network path and altering the congestion 239 window (cwnd) based on perceived congestion. Each connection starts 240 with a pre-configured initial congestion window (ICW). Currently, 241 TCP allows an initial window of between one and four MSS-sized 242 segments [RFC2581,RFC3390]. The TCP connection then probes the 243 network for available bandwidth using the slow-start procedure 244 [Jac88,RFC2581], doubling cwnd during each congestion-free round- 245 trip time (RTT). 247 The slow-start algorithm can be time-consuming --- especially over 248 networks with large bandwidth or long delays. It may take a number 249 of RTTs in slow-start before the TCP connection begins to fully use 250 the available bandwidth of the network. For instance, it takes 251 log_2(N) - 2 round-trip times to build cwnd up to N segments, 252 assuming an initial congestion window of 4 segments. This time in 253 slow-start is not a problem for large file transfers, where the 254 slow-start stage is only a fraction of the total transfer time. 255 However, in the case of moderate-sized transfers the connection 256 might carry out its entire transfer in the slow-start phase, taking 257 many round-trip times, where one or two RTTs might have been 258 appropriate in the current network conditions. 260 A fair amount of work has already been done to address the issue of 261 choosing the initial congestion window for TCP, with RFC 3390 262 allowing an initial window of up to four segments based on the MSS 263 used by the connection [RFC3390]. Our underlying premise is that 264 explicit feedback from all of the routers along the path would be 265 required, in the current architecture, for best-effort connections 266 to use initial windows significantly larger than those allowed by 267 [RFC3390], in the absence of other information about the path. 269 The Congestion Manager [RFC3124] and TCP control block sharing 270 [RFC2140] both propose sharing congestion information among multiple 271 TCP connections with the same endpoints. With the Congestion 272 Manager, a new TCP connection could start with a high initial cwnd 273 if it was sharing the path and the cwnd with a pre-existing TCP 274 connection to the same destination that had already obtained a high 275 congestion window. RFC 2140 discusses ensemble sharing, where an 276 established connection's congestion window could be `divided up' to 277 be shared with a new connection to the same host. However, neither 278 of these approaches addresses the case of a connection to a new 279 destination, with no existing or recent connection (and therefore 280 congestion control state) to that destination. 282 Quick-Start would not be the first mechanism for explicit 283 communication from routers to transport protocols about sending 284 rates. Explicit Congestion Notification (ECN) gives explicit 285 congestion control feedback from routers to transport protocols, 286 based on the router detecting congestion before buffer overflow 287 [RFC3168]. In contrast, routers would not use Quick-Start to get 288 congestion information, but instead would use Quick-Start as an 289 optional mechanism to give permission to transport protocols to use 290 higher sending rates, based on the ability of all the routers along 291 the path to determine if their respective output links are 292 significantly underutilized. 294 2. Assumptions and General Principles 296 This section describes the assumptions and general principles behind 297 the design of the Quick-Start mechanism. 299 Assumptions: 301 * The data transfer in the two directions of a connection traverses 302 different queues, and possibly even different routers. Thus, any 303 mechanism for determining the allowed sending rate would have to be 304 used independently for each direction. 306 * The path between the two endpoints is relatively stable, such that 307 the path used by the Quick-Start request is generally the same path 308 used by the Quick-Start packets one round-trip time later. [ZPS00] 309 shows this assumption should be generally valid. 311 * Any new mechanism must be incrementally deployable, and might not 312 be supported by all of the routers and/or end-hosts. Thus, any new 313 mechanism must be able to accommodate non-supporting routers or end- 314 hosts without disturbing the current Internet semantics. 316 General Principles: 318 * Our underlying premise is that explicit feedback from all of the 319 routers along the path would be required, in the current 320 architecture, for best-effort connections to use initial windows 321 significantly larger than those allowed by [RFC3390], in the absence 322 of other information about the path. 324 * A router should only approve a request for a higher sending rate 325 if the output link is underutilized. Any other approach will result 326 in either per-flow state at the router, or the possibility of a 327 (possibly transient) queue at the router. 329 * No per-flow state should be required at the router. Note that 330 while per-flow state is not required we also do not preclude a 331 router from storing per-flow state for making Quick-Start decisions. 333 There are also a number of questions regarding the Quick-Start 334 mechanism that are discussed later in this document. 336 Open Questions: 338 * Would the benefits of the Quick-Start mechanism be worth the added 339 complexity? 341 The benefits and drawbacks of Quick-Start are discussed in more 342 detail in Section 6 on "Evaluation of Quick-Start". 344 * One practical consideration is that packets with known and unknown 345 IP options are often dropped in the current Internet [MAF04]. 347 This does not preclude using Quick-Start in Intranets. Further, 348 [MAF04] also shows that over time the blocking of packets 349 negotiating ECN has become less common, and therefore an incremental 350 deployment story for Quick-Start based on IP Options is not out of 351 the question. Appendix A.1 on "Alternate Mechanisms for the Quick- 352 Start Request" discusses the possibility of using RSVP or ICMP 353 instead of IP Options for carrying Quick-Start Requests to routers. 355 * A second practical consideration is that packets could be dropped 356 at non-IP queues along the path. 358 This is discussed in more detail in Section 6.2. * Apart from the 359 merits and shortcomings of the Quick-Start mechanism, is there 360 likely to be a compelling need to add explicit congestion-related 361 feedback from routers over and above the one-bit feedback from ECN? 363 If the answer to the question above is yes, should we be considering 364 ways to incorporate Quick-Start in mechanisms that, while more 365 complex, are also sufficiently more powerful than Quick-Start, or 366 should Quick-Start be considered as orthogonal to such mechanisms? 367 This is discussed further in Appendix A.6 on "Why Not Include More 368 Functionality". 370 2.1. Overview of Quick-Start 372 In this section we give an overview of the use of Quick-Start with 373 TCP, to request a higher congestion window. The description in this 374 section is non-normative; the normative description of Quick-Start 375 with IP and TCP follows in Sections 3 and 4. Quick-Start can be used 376 in the middle of a connection, e.g., after an idle or underutilized 377 period, as well as for the initial sending rate; these uses of 378 Quick-Start are discussed later in the document. 380 Quick-Start requires end-points and routers to work together, with 381 end-points requesting a higher sending rate in the Quick-Start 382 Request (QSR) option in IP, and routers along the path approving, 383 modifying, discarding or ignoring (and therefore disallowing) the 384 Quick-Start Request. The receiver uses reliable, transport-level 385 mechanisms to inform the sender of the status of the Quick-Start 386 Request. In addition, Quick-Start assumes a unicast, congestion- 387 controlled transport protocol; we do not consider the use of Quick- 388 Start for multicast traffic. 390 The Quick-Start Request Option includes a request for a sending rate 391 in bytes per second, and a Quick-Start TTL (QS TTL) to be 392 decremented by every router along the path that understands the 393 option and approves the request. The Quick-Start TTL is initialized 394 by the sender to a random value. The transport receiver returns the 395 rate and information about the TTL to the sender using transport- 396 level mechanisms. In particular, the receiver computes the 397 difference between the Quick-Start TTL and the IP TTL (the TTL in 398 the IP header) of the Quick-Start request packet, and returns this 399 in the Quick-Start response. The sender uses this information to 400 determine if all of the routers along the path decremented the 401 Quick-Start TTL, approving the Quick-Start Request. 403 If the request is approved by all of the routers along the path, 404 then the TCP sender combines this allowed rate with the measurement 405 of the round-trip time, and ends up with an allowed TCP congestion 406 window. This window is sent rate-paced over the next round-trip 407 time, or until an ACK packet is received. 409 Figure 1 shows a successful use of Quick-Start, with both routers 410 along the path approving the Quick-Start Request. In this example, 411 Quick-Start is used by TCP to establish the initial congestion 412 window. 414 Sender Router 1 Router 2 Receiver 415 ------ -------- -------- -------- 416 | 417 | 418 | 419 | Quick-Start Request 420 | in SYN or SYN/ACK --> 421 | 422 | Decrement 423 | QS TTL 424 | to approve 425 | request --> 426 | 427 | Decrement 428 | QS TTL 429 | to approve 430 | request --> 431 | 432 | 433 | 434 | 435 | Return Quick-Start 436 | info to sender in 437 | <-- TCP ACK packet. 438 | 439 | 440 | Quick-Start approved, 441 | translate to cwnd. 442 V Send cwnd paced over one RTT. --> 444 Figure 1: A successful Quick-Start Request. 446 Figure 2 shows an unsuccessful use of Quick-Start, with one of the 447 routers along the path not approving the Quick-Start Request. If 448 the Quick-Start Request is not approved, then the sender uses the 449 default congestion control mechanisms for that transport protocol, 450 including the default initial congestion window, response to idle 451 periods, etc. 453 Sender Router 1 Router 2 Receiver 454 ------ -------- -------- -------- 455 | 456 | 457 | 458 | Quick-Start Request 459 | in SYN or SYN/ACK --> 460 | 461 | Decrement 462 | QS TTL 463 | to approve 464 | request --> 465 | 466 | Forward packet 467 | without modifying 468 | Quick-Start Option. --> 469 | 470 | 471 | 472 | 473 | Return Quick-Start 474 | info to sender in 475 | <-- TCP ACK packet. 476 | 477 | 478 | Quick-Start not approved. 479 V Use default initial cwnd. --> 481 Figure 2: An unsuccessful Quick-Start Request. 483 3. The Quick-Start Request in IP 485 3.1. The Quick-Start Request Option for IPv4 487 The Quick-Start Request for IPv4 is defined as follows: 489 0 1 2 3 490 +--------------+--------------+--------------+--------------+ 491 | Option | Length=4 | QS TTL |Resv. |Rate | 492 | | | | |Request| 493 +--------------+--------------+--------------+--------------+ 495 Figure 3. The Quick-Start Request Option for IPv4. 497 The first byte contains the option field, which includes the one-bit 498 copy flag, the 2-bit class field, and the 5-bit option number (to be 499 assigned by IANA). 501 The second byte contains the length field, indicating an option 502 length of four bytes. 504 The third byte contains the Quick-Start TTL (QS TTL) field. The 505 sender MUST set the QS TTL field to a random value. Routers that 506 approve the Quick-Start Request decrement the QS TTL (mod 256). The 507 QS TTL is used by the sender to detect if all of the routers along 508 the path understood and approved the Quick-Start option. 510 The transport sender MUST calculate and store the TTL Diff, the 511 difference between the IP TTL value and the QS TTL value in the 512 Quick-Start request packet, as follows: 514 TTL Diff = ( IP TTL - QS TTL ) mod 256 (1) 516 The fourth byte includes a four-bit Reserved field, and a four-bit 517 Rate Request field. The sender initializes the Rate Request to the 518 desired sending rate, including an estimate of the transport and IP 519 header overhead. 521 The encoding function for the Rate Request sets the request rate to 522 K*2^N bps, for N the value in the Rate Request field, and for K set 523 to 40,000. For N=0, the rate request would be set to zero, 524 regardless of the encoding function. This is illustrated in Table 1 525 below. For the four-bit Rate Request field, the request range is 526 from 80 Kbps to 1.3 Gbps. Alternate encodings that were considered 527 for the Rate Request are given in Appendix A.2. 529 N Rate Request (in Kbps) 530 --- ------------------- 531 0 0 532 1 80 533 2 160 534 3 320 535 4 640 536 5 1,280 537 6 2,560 538 7 5,120 539 8 10,240 540 9 20,480 541 10 40,960 542 11 81,920 543 12 163,840 544 13 327,680 545 14 655,360 546 15 1,310,720 548 Table 1: Mapping from the Rate Request field to the rate request in Kbps. 550 Routers can approve the Quick-Start Request for a lower rate by 551 decreasing the Rate Request in the Quick-Start Request. 553 We note that unlike a Quick-Start Request sent at the beginning of a 554 connection, when a Quick-Start Request is sent in the middle of a 555 connection, the connection could already have an established 556 congestion window or sending rate. The Rate Request is the 557 requested total rate for the connection, including the current rate 558 of the connection; the Rate Request is *not* a request for an 559 additional sending rate over and above the current sending rate. If 560 the Rate Request is denied, or lowered to a value below the 561 connection's current sending rate, then the sender ignores the 562 request, and reverts to the default congestion control mechanisms of 563 the transport protocol. 565 In IPv4, a change in IP options at routers requires recalculating 566 the IP header checksum. 568 3.2. The Quick-Start Request Option for IPv6 570 The Quick-Start Request Option for IPv6 is placed in the Hop-by-Hop 571 Options extension header that is processed at every network node 572 along the communication path [RFC 2460]. The option format following 573 the generic Hop-by-Hop Options header is similar to the IPv4 format 574 with the exception that the Length field should exclude the common 575 type and length fields in the option format and be set to 2. 577 0 1 2 3 578 +--------------+--------------+--------------+--------------+ 579 | Option | Length=2 | QS TTL |Resv. |Rate | 580 | | | | |Request| 581 +--------------+--------------+--------------+--------------+ 583 Figure 4. The Quick-Start Request Option for IPv6. 585 The transport receiver compares the Quick-Start TTL with the IPv6 586 Hop Limit field in order to calculate the TTL Diff. (The Hop Limit 587 in IPv6 is the equivalent of the TTL in IPv4.) That is, TTL Diff 588 MUST be calculated and stored as follows: 590 TTL Diff = ( IPv6 Hop Limit - QS TTL ) mod 256 (2) 592 Unlike IPv4, modifying or deleting the Quick-Start Request IPv6 593 Option does not require checksum re-calculation, because the IPv6 594 header does not have a checksum field, and modifying the Quick-Start 595 Request in the IPv6 Hop-by-Hop options header does not affect the 596 IPv6 pseudo-header checksum used in upper-layer checksum 597 calculations. 599 Note that [RFC2460] specifies that when a specific flow label has 600 been assigned to packets, the contents of the Hop-by-Hop options, 601 excluding the next header field, must originate with the same 602 contents throughout the IP flow lifetime. This requirement would 603 have to be modified to implement Quick-Start on an IPv6 604 implementation that uses flow labels, because the Quick-Start 605 Request option would be included in only a small fraction of the 606 packets during a flow lifetime. 608 3.3. Processing the Quick-Start Request at Routers 610 Each participating router can either terminate or approve the Quick- 611 Start Request. The router terminates the Quick-Start Request if the 612 router is not underutilized, and therefore has decided not to grant 613 the Quick-Start Request. 615 A router that wishes to terminate the Quick-Start Request SHOULD 616 delete the Quick-Start Request from the IP header. This saves 617 resources as downstream routers will have no option to process. If 618 a Quick-Start-capable router wishes to deny the request but doesn't 619 delete the Quick-Start Request from the IP header, then the router 620 SHOULD zero the QS TTL and the Rate Request fields. This may be 621 more efficient for routers to implement than deleting the Quick- 622 Start option. A router that doesn't understand the Quick-Start 623 option will of course simply forward the packet with the Quick-Start 624 Request unchanged. 626 If the participating router has decided to approve the Quick-Start 627 Request, it does the following: 629 * The router MUST decrements the QS TTL by one. 631 * If the router is only willing to approve an Rate Request less than 632 that in the Quick-Start Request, then the router replaces the Rate 633 Request with a smaller value. The router MUST NOT increase the Rate 634 Request in the Quick-Start Request. 636 * In IPv4, the router MUST update the IP header checksum. 638 A non-participating router forwards the Quick-Start Request 639 unchanged, without decrementing the QS TTL. Of course, the non- 640 participating router still decrements the TTL field in the IP 641 header, as is required for all routers [RFC1812]. As a result, the 642 sender will be able to detect that the Quick-Start Request had not 643 been understood or approved by all of the routers along the path. 645 A router that modifies or deletes the Quick-Start Request in the 646 IPv4 header also MUST update the IPv4 Header checksum. For IPv6, no 647 checksum updates are needed. 649 3.4. Deciding the Permitted Rate Request at a Router 651 In this section we briefly outline how a router might decide whether 652 or not to approve a Quick-Start Request. As an example, the router 653 could ask the following questions: 655 * Has the router's output link been underutilized for some time 656 (e.g., several seconds). 658 * Would the output link remain underutilized if the arrival rate was 659 to increase by the aggregate rate requests that the router has 660 approved over the last fraction of a second? 662 In order to answer this question, the router must have some 663 knowledge of the available bandwidth on the output link and of the 664 Quick-Start bandwidth that could arrive due to recently-approved 665 Quick-Start Requests. In this way, if an underutilized router 666 experiences a flood of Quick-Start requests, the router can begin to 667 deny Quick-Start requests while the output link is still 668 underutilized. 670 A simple way for the router to keep track of the potential bandwidth 671 from recently-approved requests is to maintain two counters, one for 672 the total aggregate Rate Requests that have been approved in the 673 current time interval [T1, T2], for the current time between T1 and 674 T2, and one for the total aggregate Rate Requests approved over a 675 previous time interval [T0, T1]. However, this document doesn't 676 specify router algorithms for approving Quick-Start requests, or 677 make requirements for the appropriate time intervals for remembering 678 the aggregate approved Quick-Start bandwidth. A possible router 679 algorithm is given in Appendix C, and more discussion of these 680 issues is available in [SAF05].) 682 * If the router's output link has been underutilized and the 683 aggregate Quick Start Request Rate options granted is low enough to 684 prevent a near-term bandwidth shortage, then the router could 685 approve the Quick-Start Request. 687 Section 8.2 discusses some of the implementation issues in 688 processing Quick-Start requests at routers. [SAF05] discusses the 689 range of possible Quick-Start algorithms at the router for deciding 690 whether to approve a Quick-Start request. In order to explore the 691 limits of the possible functionality at routers, [SAF05] also 692 discusses Extreme Quick-Start mechanisms at routers, where the 693 router would keep per-flow state concerning approved Quick-Start 694 requests. 696 3.5. Quick-Start in IP Tunnels 698 In this section we consider the effect of IP tunnels on Quick-Start. 699 In the discussion, we use TTL Diff, defined earlier as the 700 difference between the IP TTL and the Quick-Start TTL, mod 256. 701 Recall that the sender considers the Quick-Start request approved if 702 the value of TTL Diff for the packet entering the network is the 703 same as the value of TTL Diff for the packet exiting the network. 705 There are two legitimate ways for handling the Quick-Start Request 706 with IP tunnels: 708 (1) The tunnel ingress node does not support Quick-Start, or does 709 not approve the Quick-Start request. The node could strip the Quick- 710 Start Request option from the IP header before encapsulation. 711 Alternately, the ingress node can decrement the IP TTL before 712 encapsulation, while leaving the Quick-Start TTL unchanged, thereby 713 changing TTL Diff. This is the assumed behavior of current IP 714 tunnels that are not aware of Quick-Start. 716 For a tunnel ingress node that does not support Quick-Start, 717 problems with a Quick-Start Request could still occur if a tunnel 718 discards the outer header at egress and does not decrement the inner 719 IP TTL at the ingress. In this case, if both the inner IP TTL and 720 the Quick-Start TTL are decremented after decapsulation at a Quick- 721 Start-aware egress, or if neither is decremented at the egress, then 722 TTL Diff would be the same after egress as it was before ingress, so 723 that it would wrongly appear that all the routers in the tunnel had 724 approved the Quick-Start request. Fortunately, we are not aware of 725 tunnel technologies that operate this way; to the best of our 726 knowledge, all tunnels decrement the IP TTL either at the ingress 727 before encapsulation, or at the egress router after decapsulation, 728 thus changing TTL Diff. 730 Even the extreme case when the tunnel ingress is at the TCP sender 731 and the tunnel egress is at the TCP receiver, our assumption is that 732 the IP TTL will be decremented either at the tunnel ingress or at 733 the tunnel egress, changing TTL Diff and preventing the end-nodes 734 from wrongly inferring that the Quick-Start Request was approved by 735 all of the routers along the path. If there are tunnels where the 736 IP TTL in not decremented, perhaps for PPP over SSH, then additional 737 attention will have to be paid to the robustness of Quick-Start in 738 these environments. 740 A Quick-Start-aware egress must also make sure that the Quick-Start 741 Request is not approved if for some reason the inner header includes 742 the Quick-Start Request option, the outer header does not, and the 743 Quick-Start TTL and IP TTL have been decremented in a fashion that 744 makes it appear as if the request has been approved. If the Quick- 745 Start Request doesn't appear in the outer header, then the egress 746 node should remove the Quick-Start Request option from the inner 747 header after decapsulation. Alternately, the egress node could 748 decrement the Rate Request in the Quick-Start Request option to 749 zero. 751 (2) The tunnel ingress node may choose to support Quick-Start, and 752 locally approve the Quick-Start Request. In this case the IP TTL 753 and Quick-Start option MUST be copied from the inner IP header to 754 the outer header at the tunnel ingress. Upon decapsulation, the IP 755 TTL and the Quick-Start option in the outer IP header MUST be copied 756 back to the inner header. If the ingress router decrements the IP 757 TTL in the inner header before encapsulation, or in the outer header 758 after encapsulation, then if the ingress router wishes to approve 759 the Quick-Start request, it MUST decrement the Quick-Start TTL at 760 the same time, so as not to change TTL Diff. Similarly, if the 761 egress router wishes to approve the Quick-Start request, then when 762 it decrements the IP TTL in the outer header before decapsulation, 763 or in the inner header after decapsulation, it MUST decrement the 764 Quick-Start TTL at the same time. 766 A tunnel ingress node can support a Quick-Start request without 767 explicitly verifying that the tunnel egress also supports Quick- 768 Start. All that the ingress node has to do is to decrement the IP 769 TTL, but not the Quick-Start TTL, in the inner header after 770 encapsulation. In this case, if the egress node simply discards the 771 outer header at the egress point, TTL Diff will be different after 772 the tunnel egress than it was at the tunnel ingress, and the Quick- 773 Start will not be considered by the end-nodes as having been 774 approved in the network. Thus, the tunnel ingress node on its own 775 can provide protection against egress nodes that might discard the 776 outer header at the egress point. 778 3.6. A Rate-Reduced Nonce? 780 One possibility for the Reserved Field, for further investigation, 781 is to use the four bits for a four-bit Rate-Reduced Nonce. The goal 782 of the Rate-Reduced Nonce would be to give the Quick-Start sender 783 some protection against receivers lying about the value of the 784 received Rate Request. The Rate-Reduced Nonce would be initialized 785 by the sender to a random value. When a router approves the Quick- 786 Start request but reduces the Rate Request field, the router resets 787 the Rate-Reduced Nonce to a new random value. When a Quick-Start- 788 capable router denies the Quick-Start request, the router either 789 deletes the Quick-Start Option, or zeroes the Rate-Reduced Nonce 790 when zeroing the Rate Request and the QS TTL. The receiver reports 791 the value of the Rate-Reduced Nonce back to the sender. 793 The Rate-Reduced Nonce would be of use in cases where the receiver 794 knows the original Rate Request R sent by the sender (e.g., because 795 the sender always uses the same Rate Request), but the Rate Request 796 has been decremented by routers along the path. What prevents the 797 receiver from reporting back to the sender a Rate Request of R, when 798 the received Rate Request was in fact less than R? If the Rate 799 Request was not decremented in the network, then the Rate-Reduced 800 Nonce should have its original value. If the Rate Request *was* 801 decremented in the network, then the probability that the Rate- 802 Reduced Nonce still has its original value is 1/16. Similarly, if 803 the Rate Request was decremented in the network, the chance that the 804 receiver can guess the original value of the Rate-Reduced Nonce is 805 1/16. 807 Thus, if the receiver reports back to the sender the original values 808 for the Rate Request and the Rate-Reduced Nonce, and the correct 809 value for the TTL Diff, then it is likely that the Quick-Start 810 Request was in fact approved at its original value by the routers 811 along the path, in particular by all of the Quick-Start-capable 812 routers. The Rate-Reduced Nonce would make it more difficult for 813 the receiver to report that the Rate Request was received at its 814 original value, when in fact the received Rate Request was less than 815 its original value. 817 We note, however, that the Rate-Reduced Nonce doesn't provide 818 protection against receivers reporting that the Rate Request was 819 decremented by only one step, when it fact it was decremented by 820 many steps in the network. This, if the receiver knows the original 821 Rate Request from the sender, and the received rate request is 822 considerably less than the original request, then the receiver could 823 report a received rate request just one step smaller than the 824 original request, and the Rate-Reduced Nonce wouldn't provide any 825 protection against this. 827 Section 6.3 also considers issues of receiver cheating in more 828 detail. 830 4. The Quick-Start Mechanisms in TCP 832 This section describes how the Quick-Start mechanism would be used 833 in TCP. We first sketch the procedure and then tightly define it in 834 the subsequent subsections. 836 If a TCP sender, say host A, would like to use Quick-Start, the TCP 837 sender puts the requested sending rate in bytes per second, 838 appropriately formatted, in the Quick-Start Request option in the IP 839 header of the TCP packet, called the Quick-Start request packet. 840 (We will be somewhat loose in our use of "packet" vs. "segment" in 841 this section.) When used for initial start-up, the Quick-Start 842 request packet can be either the SYN or SYN/ACK packet, as described 843 above. The requested rate includes an estimate for the transport 844 and IP header overhead. The TCP receiver, say host B, returns the 845 Quick-Start Response option in the TCP header in the responding 846 SYN/ACK packet or ACK packet, called the Quick-Start response 847 packet, informing host A of the results of their request. 849 If the acknowledging packet does not contain a Quick-Start Response, 850 or contains a Quick-Start Response with the wrong value for the TTL 851 Diff, then host A MUST assume that its Quick-Start request failed. 852 In this case, host A uses TCP's default congestion control 853 procedure. For initial start-up, host A uses the default initial 854 congestion window. 856 If the returning packet contains a valid Quick-Start Response, then 857 host A uses the information in the response, along with its 858 measurement of the round-trip time, to determine the Quick-Start 859 congestion window (QS-cwnd). Quick-Start packets are defined as 860 packets sent as the result of a successful Quick-Start request, up 861 to the time when the first Quick-Start packet is acknowledged. In 862 order to use Quick-Start, the TCP host MUST use rate-based pacing to 863 transmit Quick-Start packets at the rate indicated in the Quick- 864 Start Response, at the level of granularity possible by the sending 865 host. We note that the limitations of interrupt timing on computers 866 can limit the ability of the TCP host in rate-pacing the outgoing 867 packets. 869 The two TCP end-hosts can independently decide whether to request 870 Quick-Start. For example, host A could sent a Quick-Start Request 871 in the SYN packet, and host B could also send a Quick-Start Request 872 in the SYN/ACK packet. 874 4.1. When to Use Quick-Start 876 In addition to the use of Quick-Start when a connection is 877 established, there are several additional points in a connection 878 when a transport protocol may want to issue a Rate Request. We 879 first re-iterate the notion that Quick-Start is a coarse-grained 880 mechanism. That is, Quick-Start's Rate Requests are not meant to be 881 used for fine-grained control of the transport's sending rate. 882 Rather, the transport MAY issue a Rate Request when no information 883 about the appropriate sending rate is available, and the default 884 congestion control mechanisms might be significantly underestimating 885 the appropriate sending rate. 887 The following are potential points where Quick-Start may be useful: 889 (1) At connection initiation when the transport has no idea of 890 the capacity of the network, as discussed above. (A transport 891 that uses TCP Control Block sharing, the Congestion Manager, or 892 the like may not need Quick-Start to determine an appropriate 893 rate.) 895 (2) After an idle period when the transport no longer has a 896 validated estimate of the available bandwidth for this flow. 897 (An example could be a persistent-HTTP connection when a new 898 HTTP request is received after an idle period.) 899 (3) After a host has received explicit indications that one of 900 the endpoints has moved its point of network attachment. This 901 can happen due to some underlying mobility mechanism like Mobile 902 IP [RFC3344,RFC3775]. Some transports, such as SCTP [RFC2960], 903 may associate with multiple IP addresses and can switch 904 addresses (and, therefore network paths) in mid-connection. If 905 the transport has concrete knowledge of a changing network path 906 then the current sending rate may not be appropriate and the 907 transport sender may use Quick-Start to probe the network for 908 the appropriate rate at which to send. (Alternatively, 909 traditional slow-start should be used in this case when Quick- 910 Start is not available.) 912 (4) After an application-limited period when the sender has been 913 using only a small amount of its appropriate share of the 914 network capacity, and has no valid estimate for its fair share. 915 In this case, Quick-Start may be an appropriate mechanism to 916 assess the available capacity on the network path. For 917 instance, consider an application that steadily exchanges low- 918 rate control messages and suddenly needs to transmit a large 919 amount of data. 921 Of the above, this document recommends that a TCP sender MAY attempt 922 to use Quick-Start in cases (1) and (2). It is not recommended that 923 a TCP sender use Quick-Start for case (3) at the current time. Case 924 (3) requires external notifications not presently defined for TCP or 925 other transport protocols. Finally, a TCP SHOULD NOT use Quick- 926 Start for case (4) at the current time. Case (4) requires further 927 thought and investigation with regard to how the transport protocol 928 could determine it was in a situation that would warrant 929 transmitting a Quick-Start Rate Request. 931 Section 4.6 discusses some of the issues of using Quick-Start at 932 connection initiation, and Section 4.7 discusses issues that arise 933 when Quick-Start is used to request a larger sending rate after an 934 idle period. 936 4.2. The Quick-Start Response Option in the TCP header 938 TCP's Quick-Start Response option is defined as follows: 940 0 1 2 3 941 +----------+----------+----------+----------+ 942 | Kind | Length=4 | Rate | TTL | 943 | | | Request | Diff | 944 +----------+----------+----------+----------+ 946 Figure 5. The Quick-Start Response option in the TCP header. 948 The first byte of the Quick-Start Response option contains the 949 option kind, identifying the TCP option (to be assigned by IANA). 951 The second byte of the Quick-Start Response option contains the 952 option length in bytes. The length field MUST be set to four bytes. 954 The third byte of the Quick-Start Response option contains the 955 allowed Rate Request, formatted as in the Quick-Start Request 956 option. 958 The fourth byte of the TCP option contains the TTL Diff. The TTL 959 Diff contains the difference between the IP TTL and QS TTL fields in 960 the received Quick-Start request packet, as calculated in equations 961 (1) or (2) (depending on whether IPv4 or IPv6 is used). 963 4.3. TCP: Sending the Quick-Start Response 965 An end host, say host B, that receives an IP packet containing a 966 Quick-Start Request passes the Quick-Start Request, along with the 967 value in the IP TTL field, to the receiving TCP layer. 969 If the TCP host is willing to permit the Quick-Start Request, then a 970 Quick-Start Response option is included in the TCP header of the 971 corresponding acknowledgement packet. The Rate Request in the 972 Quick-Start Response option is set to the received value of the Rate 973 Request in the Quick-Start Request option, or to a lower value if 974 the TCP receiver is only willing to allow a lower Rate Request. The 975 TTL Diff in the Quick-Start Response is set to the difference 976 between the IP TTL value and the QS TTL value as given in equation 977 (1) or (2) (depending on whether IPv4 or IPv6 is used). 979 The Quick-Start Response will not be resent if it is lost in the 980 network. Packet loss is an indication of congestion on the return 981 path, in which case it is better not to approve the Quick-Start 982 Request. 984 4.4. TCP: Receiving and Using the Quick-Start Response Packet 986 A TCP host, say TCP host A, that sent a Quick-Start Request and 987 receives a Quick-Start Response in an acknowledgement first checks 988 that the Quick-Start Response is valid. The Quick-Start Response is 989 valid if it contains the correct value for the TTL Diff, and an 990 equal or lesser value for the Rate Request than that transmitted in 991 the Quick-Start Request. If this check is not successful, then the 992 Quick-Start request failed, and the TCP host MUST use the default 993 TCP congestion window that it would have used without Quick-Start. 995 If the checks of the TTL Diff and the Rate Request are successful, 996 then the TCP host sets its Quick-Start congestion window (in terms 997 of MSS-sized segments), QS-cwnd, as follows: 999 QS-cwnd = (R * T) / (MSS + H) (3) 1001 where R the Rate Request in bytes per second, T the measured round- 1002 trip time in seconds, and H the estimated TCP/IP header size in 1003 bytes (e.g., 40 bytes). 1005 Derivation: the sender is allowed to transmit at R bytes per second 1006 including packet headers, but only R*MSS/(MSS+H) bytes per second, 1007 or equivalently R*T*MSS/(MSS+H) bytes per round-trip time, of 1008 application data. 1010 The TCP host SHOULD set its congestion window cwnd to QS-cwnd only 1011 if QS-cwnd is greater than cwnd; otherwise QS-cwnd is ignored. If 1012 QS-cwnd is used, the TCP host sets a flag that it is in Quick-Start 1013 mode, and while in Quick-Start mode the TCP sender MUST use rate- 1014 based pacing to pace out Quick-Start packets at the specified Rate 1015 Request. Quick-Start mode ends when the TCP host receives an ACK 1016 for one of the Quick-Start packets. 1018 If the congestion window has not been fully used when the first ack 1019 arrives ending the Quick-Start mode, then the congestion window is 1020 decreased to the amount that has actually been used so far. This 1021 addresses the problem of an overly-large congestion window from an 1022 overly-large measurement of the round-trip time. 1024 If the Quick-Start mode ends with all Quick-Start packets being 1025 successfully acknowledged, the TCP sender returns to using the 1026 default congestion control mechanisms. After all the packets are 1027 acknowledged from a Quick-Start request for an initial window, for 1028 example, the TCP sender remains in slow-start, if permitted by 1029 ssthresh, continuing to increase its congestion window rather 1030 aggressively from one round-trip time to the next. To add 1031 robustness, the TCP sender MUST use Limited Slow-Start [RFC3742] 1032 along with Quick-Start. With Limited Slow-Start, the TCP sender 1033 limits the number of packets by which the congestion window is 1034 increased for one window of data during slow-start. 1036 4.5. TCP: Responding to a Loss of a Quick-Start Packet 1038 For TCP, we have defined a ``Quick-Start packet'' as one of the 1039 packets sent in the window immediately following a successful Quick- 1040 Start request. After detecting the loss of a Quick-Start packet, 1041 TCP MUST revert to the default congestion control procedures that 1042 would have been used if the Quick-Start request had not been 1043 approved. For example, if Quick-Start is used for setting the 1044 initial window, and a packet from the initial window is lost, then 1045 the TCP sender MUST then slow-start with the default initial window 1046 that would have been used if Quick-Start had not been used. In 1047 addition to reverting to the default congestion control mechanisms, 1048 the sender must take into account that the Quick-Start congestion 1049 window was too large. Thus, the sender should decrease ssthresh to 1050 at most half the number of Quick-Start packets that were 1051 successfully transmitted. Section A.5 discusses possible 1052 alternatives in responding to the loss of a Quick-Start packet. 1054 We note that ECN [RFC3168] can be used with Quick-Start. As is 1055 always the case with ECN, the sender's congestion control response 1056 to an ECN-marked Quick-Start packet is the same as the response to a 1057 dropped Quick-Start packet, thus reverting to slow start in the case 1058 of Quick-Start packets marked as experiencing congestion. 1060 4.6. TCP: A Quick-Start Request for a Larger Initial Window 1062 Some of the issues of using Quick-Start are related to the specific 1063 scenario in which Quick-Start is used. This section discusses the 1064 following issues that arise when Quick-Start is used by TCP to 1065 request a larger initial window: (1) determining the rate to 1066 request; (2) interactions with Path MTU Discovery; and (3) Quick- 1067 Start request packets that are discarded by middleboxes. 1069 4.6.1. Determining the Rate to Request 1071 As discussed in [SAF05], the data sender does not necessarily have 1072 information about the size of the data transfer at connection 1073 initiation; for example, in request-response protocols such as HTTP, 1074 the server doesn't know the size or name of the requested object 1075 during connection initiation. [SAF05] explores some of the 1076 performance implications of overly-large Quick-Start requests, and 1077 discusses heuristics that end-nodes could use to size their requests 1078 appropriately. For example, the sender might have information about 1079 the bandwidth of the last-mile hop, the size of the local socket 1080 buffer, or of the TCP receive window, and could use this information 1081 in determining the rate to request. Web servers that mostly have 1082 small objects to transfer might decide not to use Quick-Start at 1083 all, since Quick-Start would be of little benefit to them. 1085 In the absence of other information, there could be a configured 1086 value for the Quick-Start Rate Request. Quick-Start will be more 1087 effective if Quick-Start requests are not larger than necessary; 1088 every Quick-Start request that is approved but not used (or not 1089 fully used) takes away from the bandwidth pool available for 1090 granting successive Quick-Start requests. Therefore, it is 1091 recommended that the request for the initial sending rate be 1092 somewhat conservative, in order to improve the chances for more 1093 Quick-Start requests to be approved. 1095 4.6.2. Interactions with Path MTU Discovery 1097 A second issue when Quick-Start is used to request a large initial 1098 window concerns the interactions between the large initial window 1099 and Path MTU Discovery. Some of the issues are discussed in RFC 1100 3390: 1102 "When larger initial windows are implemented along with Path MTU 1103 Discovery [RFC1191], alternatives are to set the "Don't 1104 Fragment" (DF) bit in all segments in the initial window, or to 1105 set the "Don't Fragment" (DF) bit in one of the segments. It is 1106 an open question as to which of these two alternatives is best." 1108 Unfortunately, the sender doesn't necessarily know the Path MTU when 1109 it sends packets in the initial window. The sender should be 1110 conservative in the packet size used. Sending a large number of 1111 overly-large packets with the DF bit set is not desirable, but 1112 sending a large number of packets that are fragmented in the network 1113 can be equally undesirable. 1115 One possibility would be for the sender to send one large packet in 1116 the initial window with the DF bit set, and to send the remaining 1117 packets in the initial window with a smaller MTU of 576 bytes (or 1118 1280 bytes with IPv6). 1120 A second possibility would be for the sender to delay sending the 1121 Quick-Start Request for one round-trip time, sending the Quick-Start 1122 Request with the first window of data while also doing Path MTU 1123 Discovery. 1125 In the future, it might be possible for the TCP SYN packet to do a 1126 probe about the Path MTU. For example, [W03] has proposed an IP 1127 Option that queries routers for their MTU before starting a Path MTU 1128 Discovery process. 1130 4.6.3. Quick-Start Request Packets that are Discarded by Middleboxes 1132 It is always possible for a TCP SYN packet carrying a Quick-Start 1133 request to be dropped in the network due to congestion, or to be 1134 blocked due to interactions with middleboxes. Measurement studies 1135 of interactions between transport protocols and middleboxes [MAF04] 1136 show that for 70% of the web servers investigated, no connection is 1137 established if the TCP SYN packet contains an unknown IP option (and 1138 for 43% of the web servers, no connection is established if the TCP 1139 SYN packet contains an IP TimeStamp Option). In both cases, this is 1140 presumably due to middleboxes along that path. 1142 If the TCP sender doesn't receive a response to the SYN or SYN/ACK 1143 packet containing the Quick-Start Request, then the TCP sender 1144 SHOULD resend the SYN or SYN/ACK packet without the Quick-Start 1145 Request. Similarly, if the TCP sender receives a TCP reset in 1146 response to the SYN or SYN/ACK packet containing the Quick-Start 1147 Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet 1148 without the Quick-Start Request [RFC3360]. 1150 While RFC 1122 and 2988 recommend that the sender should set the 1151 initial RTO to three seconds, many TCP implementations set the 1152 initial RTO to one second. For a TCP SYN packet sent with a Quick- 1153 Start request, we RECOMMEND an RTO of one second, so that the sender 1154 can retransmit the SYN packet reasonably promptly if the original 1155 TCP SYN packet is dropped by a middlebox in the network. 1157 In the case of a retransmission, in addition to resending the SYN or 1158 SYN/ACK packet without the Quick-Start Request, the TCP sender 1159 SHOULD use an RTO of three seconds and a different Initial Sequence 1160 Number. Using this scheme the TCP sender MUST keep track of when 1161 each of the SYN (or SYN/ACKs) was transmitted. In this way, an 1162 acknowledgement for the retransmitted SYN or SYN/ACK packet can be 1163 matched with the SYN or SYN/ACK being acknowledged, and the 1164 transmission time of the SYN (or SYN/ACK) being acknowledged can be 1165 used for an RTT measurement to seed the RTO. If only the 1166 retransmitted SYN or SYN/ACK is acknowledged, the TCP sender can 1167 reasonably assume that the earlier SYN or SYN/ACK with the Quick- 1168 Start option was dropped by the network because of the option and 1169 not because of congestion. In this case, the TCP sender can refrain 1170 from performing TCP's standard congestion control state changes. 1172 We note that if the TCP SYN packet is using the IP Quick-Start 1173 Option for a Quick-Start request, and it is also using bits in the 1174 TCP header to negotiate ECN-capability with the TCP host at the 1175 other end, then the drop of a TCP SYN packet could be due to 1176 congestion, to a middlebox dropping the packet because of the IP 1177 Option, or because of a middlebox dropping the packet because of the 1178 information in the TCP header negotiating ECN. In this case, the 1179 sender could resend the dropped packet without either the Quick- 1180 Start or the ECN requests. Alternately, the sender could resend the 1181 dropped packet with only the ECN request in the TCP header, 1182 resending the TCP SYN packet without either the Quick-Start or the 1183 ECN requests if the second TCP SYN packet is dropped. The second 1184 choice seems reasonable, given that a TCP SYN packet today is more 1185 likely to be blocked due to IP Options than due to an ECN request in 1186 the TCP header [MAF04]. 1188 4.7. TCP: A Quick-Start Request in the Middle of Connection 1190 This section discusses the following issues that arise when Quick- 1191 Start is used by TCP to request a larger window in the middle of 1192 connection, for example after an idle period: (1) determining the 1193 rate to request; and (2) the response if Quick-Start packets are 1194 dropped; 1196 (1) Determining the rate to request: 1197 In the middle of connection, an easy rule of thumb would be for the 1198 TCP sender to determine the largest congestion window that the TCP 1199 connection achieved since the last packet drop, to translate this 1200 congestion window to a sending rate, and use this rate in the Quick- 1201 Start request. If the request is granted, then the sender 1202 essentially restarts with its old congestion window from before it 1203 was reduced, for example during an idle period. 1205 In the case of an idle period, the sender SHOULD NOT use Quick-Start 1206 if the idle period has been less than an RTO, and the congestion 1207 window has not decayed down to less than half of its value at the 1208 start of the idle period. Such a use of Quick-Start requires 1209 further investigation. 1211 (2) Response if Quick-Start packets are dropped: 1212 If Quick-Start packets are dropped in the middle of connection, then 1213 the sender MUST revert to half of the Quick-Start window, or to the 1214 congestion window that the sender would have used if the Quick-Start 1215 request had not been approved, whichever is smaller. 1217 We note that a packet in the middle of a connection carrying a 1218 Quick-Start Request might or might not carry a data payload. For 1219 example, for TCP, the Quick-Start Request could be carried by a data 1220 packet, or by a pure acknowledgement packet. 1222 4.8. An Example Quick-Start Scenario with TCP 1224 The following is an example scenario in the case when both hosts 1225 request Quick-Start for setting their initial windows: 1227 * The TCP SYN packet from Host A contains a Quick-Start Request in 1228 the IP header. 1230 * Routers along the forward path modify the Quick-Start Request as 1231 appropriate. 1233 * Host B receives the Quick-Start Request in the SYN packet, and 1234 calculates the TTL Diff. If Host B approves the Quick-Start 1235 Request, then Host B sends a Quick-Start Response in the TCP header 1236 of the SYN/ACK packet. Host B also sends a Quick-Start Request in 1237 the IP header of the SYN/ACK packet. 1239 * Routers along the reverse path modify the Quick-Start Request as 1240 appropriate. 1242 * Host A receives the Quick-Start Response in the SYN/ACK packet, 1243 and checks the TTL Diff and Rate Request for validity. If they are 1244 valid, then Host A sets its initial congestion window appropriately, 1245 and sets up rate-based pacing to be used with the initial window. 1246 If the Quick-Start Response is not valid, then Host A uses TCP's 1247 default initial window. 1249 Host A also calculates the TTL Diff for the Quick-Start Request in 1250 the incoming SYN/ACK packet, and sends a Quick-Start Response in the 1251 TCP header of the ACK packet. 1253 * Host B receives the Quick-Start Response in an ACK packet, and 1254 checks the TTL Diff and Rate Request for validity. If the Quick- 1255 Start Response is valid, then Host B sets its initial congestion 1256 window appropriately, and sets up rate-based pacing to be used with 1257 its initial window. If the Quick-Start Response is not valid, then 1258 Host B uses TCP's default initial window. 1260 5. The Quick-Start Mechanism in other Transport Protocols 1262 The section earlier specified the use of Quick-Start in TCP. In 1263 this section, we generalize this to give guidelines for the use of 1264 Quick-Start with other transport protocols. We also discuss briefly 1265 how Quick-Start could be specified for other transport protocols. 1267 The general guidelines for Quick-Start in transport protocols are as 1268 follows: 1270 * Quick-Start is only specified for unicast transport protocols with 1271 appropriate congestion control mechanisms. Note: Quick-Start is not 1272 a replacement for standard congestion control techniques, but meant 1273 to augment their operation. 1275 * A transport-level mechanism is needed for the Quick-Start response 1276 from the receiver to the sender. This response contains the Rate 1277 Request and the TTL Diff. 1279 * The sender checks the validity of the Quick-Start response. 1281 * The sender has an estimate of the round-trip time, and translates 1282 the Quick-Start response into an allowed window or allowed sending 1283 rate. The sender starts sending Quick-Start packets, rate-paced out 1284 at the approved sending rate. 1286 * After the sender receives the first acknowledgement packet for a 1287 Quick-Start packet, no more Quick-Start packets are sent. The 1288 sender adjusts its current congestion window or sending rate to be 1289 consistent with the actual amount of data that was transmitted in 1290 that round-trip time. 1292 * When the last Quick-Start packet is acknowledged, the sender 1293 continues using the standard congestion control mechanisms of that 1294 protocol. 1296 * If one of the Quick-Start packets is lost, then the sender reverts 1297 to the standard congestion control method of that protocol that 1298 would have been used if the Quick-Start request had not been 1299 approved. In addition, the sender takes into account the 1300 information that the Quick-Start congestion window was too large 1301 (e.g., by decreasing ssthresh in TCP). 1303 6. Evaluation of Quick-Start 1305 6.1. Benefits of Quick-Start 1307 The main benefit of Quick-Start is the faster start-up for the 1308 transport connection itself. For a small TCP transfer of one to 1309 five packets, Quick-Start is probably of very little benefit; at 1310 best, it might shorten the connection lifetime from three to two 1311 round-trip times (including the round-trip time for connection 1312 establishment). Similarly, for a very large transfer, where the 1313 slow-start phase would have been only a small fraction of the 1314 connection lifetime, Quick-Start would be of limited benefit. 1315 Quick-Start would not significantly shorten the connection lifetime, 1316 but it might eliminate or at least shorten the start-up phase. 1317 However, for moderate-sized connections in a well-provisioned 1318 environment, Quick-Start could possibly allow the entire transfer of 1319 M packets to be completed in one round-trip time (after the initial 1320 round-trip time for the SYN exchange), instead of the log_2(M)-2 1321 round-trip times that it would normally take for the data transfer, 1322 in an uncongested environments (assuming an initial window of four 1323 packets). 1325 6.2. Costs of Quick-Start 1327 This section discusses the costs of Quick-Start for the connection 1328 and for the routers along the path. 1330 The cost of having a Quick-Start packet dropped: 1331 For the sender the biggest risk in using Quick-Start lies in the 1332 possibility of suffering from congestion-related losses of the 1333 Quick-Start packets. This should be an unlikely situation because 1334 routers are expected to approve Quick-Start Requests only when they 1335 are significantly underutilized. However, a transient increase in 1336 cross-traffic in one of the routers, a sudden decrease in available 1337 bandwidth on one of the links, or congestion at a non-IP queue could 1338 result in packet losses even when the Quick-Start Request was 1339 approved by all of the routers along the path. If a Quick-Start 1340 packet is dropped, then the sender reverts to the congestion control 1341 mechanisms it would have used if the Quick-Start request has not 1342 been approved, so the performance cost to the connection of having a 1343 Quick-Start packet dropped is small, compared to the performance 1344 without Quick-Start. (On the other hand, the performance difference 1345 between Quick-Start with a Quick-Start packet dropped and Quick- 1346 Start with no Quick-Start packet dropped can be considerable.) 1348 Added complexity at routers: 1349 The main cost of Quick-Start at routers concerns the costs of added 1350 complexity. The added complexity at the end-points is moderate, and 1351 might easily be outweighed by the benefit of Quick-Start to the end 1352 hosts. The added complexity at the routers is also somewhat 1353 moderate; it involves estimating the unused bandwidth on the output 1354 link over the last several seconds, processing the Quick-Start 1355 request, and keeping a counter of the aggregate Quick-Start rate 1356 approved over the last fraction of a second. However, this added 1357 complexity at routers adds to the development cycle, and could 1358 prevent the addition of other competing functionality to routers. 1359 Thus, careful thought would have to be given to the addition of 1360 Quick-Start to IP. 1362 The slow path in routers: 1363 Another drawback of Quick-Start is that packets containing the 1364 Quick-Start Request message might not take the fast path in routers, 1365 particularly in the beginning of Quick-Start's deployment in the 1366 Internet. This would mean some extra delay for the end hosts, and 1367 extra processing burden for the routers. However, as discussed in 1368 Sections 4.1 and 4.6, not all packets would carry the Quick-Start 1369 Request option. In addition, for the underutilized links where 1370 Quick-Start Requests could actually be approved, or in typical 1371 environments where most of the packets belong to large flows, the 1372 burden of the Quick-Start Option on routers would be considerably 1373 reduced. Nevertheless, it is still conceivable, in the worst case, 1374 that many packets would carry Quick-Start requests; this could slow 1375 down the processing of Quick-Start packets in routers considerably. 1376 As discussed in Section 6.6, routers can easily protect against this 1377 by enforcing a limit on the rate at which Quick-Start requests will 1378 be considered. 1380 Multiple paths: 1381 One limitation of Quick-Start is that it presumes that the data 1382 packets of a connection will follow the same path as the Quick-Start 1383 request packet. If this is not the case, then the connection could 1384 be sending the Quick-Start packets, at the approved rate, along a 1385 path that was already congested, or that became congested as a 1386 result of this connection. This is, however, similar to what would 1387 happen if the connection's path was changed in the middle of the 1388 connection, when the connection had already established the allowed 1389 initial rate. 1391 Non-IP queues: 1392 A problem of any mechanism for feedback from routers at the IP level 1393 is that there can be queues and bottlenecks in the end-to-end path 1394 that are not in IP-level routers. As an example, these include 1395 queues in layer-two Ethernet or ATM networks. One possibility would 1396 be that an IP-level router adjacent to such a non-IP queue or 1397 bottleneck would be configured to reject Quick-Start requests if 1398 that was appropriate. One would hope that in general, IP networks 1399 are configured so that non-IP queues between IP routers do not end 1400 up being the congested bottlenecks. 1402 6.3. Protection against Misbehaving Nodes 1404 In this section we discuss the protection against receivers or 1405 colluding middleboxes lying about the Quick-Start Request. First, 1406 we note that it is not necessarily in the receiver's interest to lie 1407 about the Quick-Start Request. If the sender sends at too-high of 1408 an initial rate, and has a packet dropped, this does not necessarily 1409 improve the performance of the connection, relative to the case when 1410 the Quick-Start Request was not approved. 1412 6.3.1. Receivers Lying about Whether the Request was Approved 1414 One form of misbehavior would be for the receiver to lie to the 1415 sender about whether the Quick-Start Request was approved, by 1416 falsely reporting the TTL Diff. If a router that understands the 1417 Quick-Start Request denies the request by deleting the request or by 1418 zeroing the QS TTL, then the receiver can ``lie" about whether the 1419 request was approved only by successfully guessing the value of the 1420 TTL Diff to report. The chance of the receiver successfully 1421 guessing the correct value for the TTL Diff is 1/256. 1423 However, if the Quick-Start request is denied only by a non-Quick- 1424 Start-capable router, or by a router that is unable to zero the QS 1425 TTL field, the the receiver could lie about whether the Quick-Start 1426 Requests were approved by modifying the QS TTL in successive 1427 requests received from the same host. In particular, if the sender 1428 does not act on a Quick-Start Request, then the receiver could 1429 decrement the QS TTL by one in the next request received from that 1430 host before calculating the TTL Diff, and decrement the QS TTL by 1431 two in the following received request, until the sender acts on one 1432 of the Quick-Start Requests. 1434 Unfortunately, if a router doesn't understand Quick-Start, then it 1435 is not possible for that router to take an active step such as 1436 zeroing a TTL field to deny a request. As a result, the QS TTL is 1437 not a fail-safe mechanism for preventing lying by receivers in the 1438 case of non-Quick-Start-capable routers. 1440 6.3.2. Receivers Lying about the Approved Rate 1442 A second form of misbehavior would be for the receiver to lie to the 1443 sender about the Rate Request for an approved Quick-Start Request, 1444 by increasing the value of the Rate Request field. However, the 1445 receiver generally doesn't know the Rate Request in the original 1446 Quick-Start Request sent by the sender, and a higher Rate Request 1447 reported by the receiver will only be considered valid by the sender 1448 if it is no higher than the Rate Request originally requested by the 1449 sender. This limits the ability of the receiver to cheat. For 1450 example, if the sender sends a Quick-Start Request with an Rate 1451 Request of X, and the receiver reports receiving a Quick-Start 1452 Request with an Rate Request of Y > X, then the sender knows that 1453 either some router along the path malfunctioned (increasing the Rate 1454 Request inappropriately), or the receiver is lying about the Rate 1455 Request in the received packet. 1457 However, if the sender sends a Quick-Start Request with an Rate 1458 Request of Z, the receiver receives the Quick-Start Request with an 1459 approved Rate Request of X, and reports an Rate Request of Y, for X 1460 < Y <= Z, then the receiver succeeds in lying to the sender about 1461 the approved rate. 1463 If senders often use a configured default value for the Rate 1464 Request, then receivers would often be able to guess the original 1465 Rate Request, and this would make it easier for the receiver to lie 1466 about the value of the Rate Request field. Similarly, if the 1467 receiver often communicates with a particular sender, and the sender 1468 always uses the same Rate Request for that receiver, then the 1469 receiver might over time be able to infer the original Rate Request 1470 used by the sender. 1472 There are several possible forms of protection against receivers 1473 lying about the value of the Rate Request. One form of protection 1474 would be the Rate-Reduced Nonce discussed earlier, where the 1475 receiver would have to report the original value of the nonce if the 1476 receiver reported that the original rate request was approved. 1478 A second possible protection would be for a router decreasing a Rate 1479 Request in a Quick-Start Request to report the decrease directly to 1480 the sender. However, this could lead to many reports back to the 1481 sender for a single request, and could also be used in address- 1482 spoofing attacks. 1484 A third limited form of protection would be for senders to use some 1485 degree of randomization in the requested Rate Request, so that it is 1486 difficult for receivers to guess the original value for the Rate 1487 Request. However, this is difficult because there is a fairly 1488 coarse granularity in the set of rate requests available to the 1489 sender, and randomizing the initial request only offers limited 1490 protection in any case. 1492 6.3.3. Collusion between Misbehaving Routers 1494 In addition to protecting against misbehaving receivers, it is 1495 necessary also to protect against misbehaving routers. Consider 1496 collusion between an ingress router and an egress router belonging 1497 to the same Intranet. The ingress router could decrement the Rate 1498 Request at the ingress, with the egress router increasing it again 1499 at the egress. The routers between the ingress and egress that 1500 approved the decremented rate request might not have been willing to 1501 approve the larger, original request. 1503 Another form of collusion would be for the ingress router to inform 1504 the egress router out-of-band of the TTL Diff for the request packet 1505 at the ingress. This would enable the egress router to modify the 1506 QS TTL so that it appeared that all of the routers along the path 1507 had approved the request. There does not appear to be any 1508 protection against a colluding ingress and egress router. Even if 1509 an intermediate router had deleted the Quick-Start Request Option 1510 from the packet, the ingress router could have sent the Quick-Start 1511 Request Option to the egress router out-of-band, with the egress 1512 router inserting the Quick-Start Request Option, with a modified QS 1513 TTL field, back in the packet. 1515 However, unlike ECN, there is somewhat less incentive for 1516 cooperating ingress and egress routers to collude to falsely modify 1517 the Quick-Start Request so that it appears to have been approved by 1518 all of the routers along the path. With ECN, a colluding ingress 1519 router could falsely mark a packet as ECN-capable, with the 1520 colluding egress router returning the ECN field in the IP header to 1521 its original non-ECN-capable codepoint, and congested routers along 1522 the path could have been fooled into not dropping that packet. This 1523 collusion would give an unfair competitive advantage to the traffic 1524 protected by the colluding ingress and egress routers. 1526 In contrast, with Quick-Start, the collusion of the ingress and 1527 egress routers to make it falsely appear that a Quick-Start request 1528 was approved does not necessarily give an advantage to the traffic 1529 covered by that collusion. If some router along the path really 1530 does not have enough available bandwidth to approve the Quick-Start 1531 request, then the Quick-Start packets sent as a result of the 1532 falsely-approved request could be dropped in the network, to the 1533 resulting disadvantage of the connection. Thus, while the ingress 1534 and egress routers could collude to prevent intermediate routers 1535 from denying a Quick-Start request, it would not necessarily be to 1536 the connection's advantage for this to happen. In addition, the 1537 router between the ingress and egress nodes that denied the request 1538 could be monitoring connection performance, actively penalizing 1539 nodes that seem to be using Quick-Start after a Quick-Start request 1540 was denied. 1542 If the congested router was ECN-capable, and the colluding ingress 1543 and egress routers were lying about ECN-capability as well as about 1544 Quick-Start, then the result could be that the Quick-Start request 1545 falsely appears to the sender to have been approved, and the Quick- 1546 Start packets falsely appear to the congested router to be ECN- 1547 capable. In this case, the colluding routers might succeed in 1548 giving a competitive advantage to the traffic protected by their 1549 collusion (if no intermediate router is monitoring to catch such 1550 misbehavior). 1552 6.3.4. Misbehaving Middleboxes and the IP TTL 1554 A separate possibility is that of traffic normalizers [HKP01] or 1555 other middleboxes along that path that re-write IP TTLs, in order to 1556 foil other kinds of attacks in the network. If such a traffic 1557 normalizer re-wrote the IP TTL, but did not adjust the Quick-Start 1558 TTL by the same amount, then the sender's mechanism for determining 1559 if the request was approved by all routers along the path would no 1560 longer be reliable. Re-writing the IP TTL could result in false 1561 positives (with the sender incorrectly believing that the Quick- 1562 Start request was approved) as well as false negatives (with the 1563 sender incorrectly believing that the Quick-Start request was 1564 denied). 1566 6.4. Quick-Start with QoS-enabled Traffic 1568 The discussion in this document has largely been of Quick-Start with 1569 default, best-effort traffic. However, Quick-Start could also be 1570 used by traffic using some form of differentiated services, and 1571 routers could take the traffic class into account when deciding 1572 whether or not to grant the Quick-Start request. We don't address 1573 this context further in this paper, since it is orthogonal to the 1574 specification of Quick-Start. However, we note that routers should 1575 be discouraged from granting Quick-Start requests for higher- 1576 priority traffic when this is likely to result in significant packet 1577 loss for lower-priority traffic. 1579 6.5. Limitations of Quick-Start 1581 The Quick-Start proposal, taken together with HighSpeed TCP [F03], 1582 could go a significant way towards extending the range of 1583 performance for best-effort traffic in the Internet. However, there 1584 are many things that the Quick-Start proposal would not accomplish. 1586 Quick-Start is not a congestion control mechanism, and would not 1587 help in making more precise use of the available bandwidth, that is, 1588 of achieving the goal of high throughput with low delay and low 1589 packet loss rates. Quick-Start would not give routers more control 1590 over the decrease rates of active connections. One of the open 1591 questions addressed later in this document is whether the limited 1592 capabilities of Quick-Start are sufficient to warrant 1593 standardization and deployment, or whether more work is needed first 1594 to explore the space of potential mechanisms. 1596 6.6. Attacks on Quick-Start 1598 As discussed in [SAF05], Quick-Start is vulnerable to two kinds of 1599 Quick-Start attacks: (1) attacks to increase the routers' 1600 processing and state load; and (2) attacks with bogus Quick-Start 1601 requests to temporarily tie up available Quick-Start bandwidth, 1602 preventing routers from approving Quick-Start requests from other 1603 connections. Routers can protect against the first kind of attack 1604 by applying a simple limit on the rate at which Quick-Start requests 1605 will be considered by the router. 1607 The second kind of attack, attacks to tie up the available Quick- 1608 Start bandwidth, is more difficult to defend against. As discussed 1609 in [SAF05]. Quick-Start Requests that are not going to be used, 1610 either because they are from malicious attackers or because they are 1611 denied by routers downstream, can result in `wasting' potential 1612 Quick-Start bandwidth, resulting in routers denying subsequent 1613 Quick-Start Requests that if approved would in fact have been used. 1614 We note that the likelihood of malicious attacks would be minimized 1615 significantly when Quick-Start was deployed in a controlled 1616 environment such as an Intranet, where there was some form of 1617 centralized control over the users in the system. We also note that 1618 this form of attack could potentially make Quick-Start unusable, but 1619 it would not do any further damage; in the worst case, the network 1620 would function as a network without Quick-Start. 1622 [SAF05] considers the potential of Extreme Quick-Start algorithms at 1623 routers, which keep per-flow state for Quick-Start connections, in 1624 protecting the availability of Quick-Start bandwidth in the face of 1625 frequent overly-larqe Quick-Start requests. 1627 6.7. Simulations with Quick-Start 1629 Quick-Start was added to the NS simulator [SH02] by Srikanth 1630 Sundarrajan, and additional functionality was added by Pasi 1631 Sarolahti. The validation test is at `test-all-quickstart' in the 1632 `tcl/test' directory in NS. The initial simulation studies from 1633 [SH02] show a significant performance improvement using Quick-Start 1634 for moderate-sized flows (between 4KB and 128KB) in under-utilized 1635 environments. These studies are of file transfers, with the 1636 improvement measured as the relative increase in the overall 1637 throughput for the file transfer. The study shows that potential 1638 improvement from Quick-Start is proportional to the delay-bandwidth 1639 product of the path. 1641 The Quick-Start simulations in [SAF05] explore the following: the 1642 potential benefit of Quick-Start for the connection; the relative 1643 benefits of different router-based algorithms for approving Quick- 1644 Start requests; and the effectiveness of Quick-Start as a function 1645 of the senders' algorithms for choosing the size of the rate 1646 request. 1648 7. Related Work 1650 Any evaluation of Quick-Start must include a discussion of the 1651 relative benefits of approaches that use no explicit information 1652 from routers, and of approaches that use more fine-grained feedback 1653 from routers as part of a larger congestion control mechanism. We 1654 discuss three classes of proposals (no explicit feedback from 1655 routers; explicit feedback about the initial rate; and more fine- 1656 grained feedback from routers) in the sections below. 1658 7.1. Fast Start-ups without Explicit Information from Routers 1660 One possibility would be for senders to use information from the 1661 packet streams to learn about the available bandwidth, without 1662 explicit information from routers. These techniques would not allow 1663 a start-up as fast as that available from Quick-Start in an 1664 underutilized environment; one has to have sent some packets 1665 already to use the packet stream to learn about available bandwidth. 1666 However, these techniques could allow a start-up considerably faster 1667 than the current slow-start. While it seems clear that approaches 1668 *without* explicit feedback from the routers will be strictly less 1669 powerful that is possible *with* explicit feedback, it is also 1670 possible that approaches that are more aggressive than slow-start 1671 are possible without explicit feedback from routers. 1673 Periodic packet streams: 1674 [JD02] explores the use of periodic packet streams to estimate the 1675 available bandwidth along a path. The idea is that the one-way 1676 delays of a periodic packet stream show an increasing trend when the 1677 stream's rate is higher than the available bandwidth. While [JD02] 1678 states that the proposed mechanism does not cause significant 1679 increases in network utilization, losses, or delays when done by one 1680 flow at a time, the approach could be problematic if conducted 1681 concurrently by a number of flows. [JD02] also gives an overview of 1682 some of the earlier work on inferring the available bandwidth from 1683 packet trains. 1685 Swift-Start: 1686 The Swift Start proposal from [PRAKS02] combines packet-pair and 1687 packet-pacing techniques. An initial congestion window of four 1688 segments is used to estimate the available bandwidth along the path. 1689 This estimate is then used to dramatically increase the congestion 1690 window during the second RTT of data transmission. 1692 While continued research on the limits of the ability of TCP and 1693 other transport protocols to learn of available bandwidth without 1694 explicit feedback from the router seems useful, we note that there 1695 are several fundamental advantages of explicit feedback from 1696 routers. 1698 (1) Explicit feedback is faster than implicit feedback: 1699 One advantage of explicit feedback from the routers is that it 1700 allows the transport sender to reliably learn of available bandwidth 1701 in one round-trip time. 1703 (2) Explicit feedback is more reliable than implicit feedback: 1704 A second advantage of explicit feedback from the routers is that the 1705 available bandwidth along the path does not necessarily map to the 1706 allowed sending rate for an individual flow. As an example, if the 1707 TCP sender sends four packets back-to-back in the initial window, 1708 and the TCP receiver reports that the data packets were received 1709 with roughly the same spacing as they were transmitted, does this 1710 mean that the flow can infer an underutilized path? And how fast 1711 can the flow send in the next round-trip time? Do the results 1712 depend on the level of statistical multiplexing at the congested 1713 link, and on the number of flows attempting a faster start-up at the 1714 same time? 1716 7.2. Optimistic Sending without Explicit Information from Routers 1718 Another possibility that has been suggested [S02] is for the sender 1719 to start with a large initial window without explicit permission 1720 from the routers and without bandwidth estimation techniques, and 1721 for the first packet of the initial window to contain information 1722 such as the size or sending rate of the initial window. The 1723 proposal would be that congested routers would use this information 1724 in the first data packet to drop or delay many or all of the packets 1725 from that initial window. In this way a flow's optimistically-large 1726 initial window would not force the router to drop packets from 1727 competing flows in the network. Such an approach would seem to 1728 require some mechanism for the sender to ensure that the routers 1729 along the path understood the mechanism for marking the first packet 1730 of a large initial window. 1732 Obviously there would be a number of questions to consider about an 1733 approach of optimistic sending. 1735 (1) Incremental deployment: 1736 One question would be the potential complications of incremental 1737 deployment, where some of the routers along the path might not 1738 understand the packet information describing the initial window. 1740 (2) Congestion collapse: 1741 There could also be concerns about congestion collapse if many flows 1742 used large initial windows, many packets were dropped from 1743 optimistic initial windows, and many congested links ended up 1744 carrying packets that are only going to be dropped downstream. 1746 (3) Distributed Denial of Service attacks: 1747 A third key question would be the potential role of optimistic 1748 senders in amplifying the damage done by a Distributed Denial of 1749 Service (DDoS) attack. 1751 (4) Performance hits if a packet is dropped: 1752 A fourth issue would be to quantify the performance hit to the 1753 connection when a packet is dropped from one of the initial windows. 1755 7.3. Fast Start-ups with other Information from Routers 1757 There have been several proposals somewhat similar to Quick-Start, 1758 where the transport protocol collects explicit information from the 1759 routers along the path. 1761 An IP Option about the free buffer size: 1762 In related work, [P00] investigates the use of a slightly different 1763 IP option for TCP connections to discover the available bandwidth 1764 along the path. In that proposal, the IP option would query the 1765 routers along the path about the smallest available free buffer 1766 size. Also, the IP option would have been sent after the initial SYN 1767 exchange, when the TCP sender already had an estimate of the round- 1768 trip time. 1770 The Performance Transparency Protocol: 1771 The Performance Transparency Protocol (PTP) includes a proposal for 1772 a single PTP packet that would collect information from routers 1773 along the path from the sender to the receiver [W00]. For example, 1774 a single PTP packet could be used to determine the bottleneck 1775 bandwidth along a path. 1777 ETEN: 1778 Additional proposals for end nodes to collect explicit information 1779 from routers include Explicit Transport Error Notification (ETEN), 1780 which includes a cumulative mechanism to notify endpoints of 1781 aggregate congestion statistics along the path [KAPS02]. 1783 7.4. Fast Start-ups with more Fine-Grained Feedback from Routers 1785 Proposals for more fine-grained congestion-related feedback from 1786 routers include XCP [KHR02], MaxNet [MaxNet], and AntiECN marking 1787 [K03]. Section A.6 discusses in more detail the relationship 1788 between Quick-Start and proposals for more fine-grained per-packet 1789 feedback from routers. 1791 XCP: 1792 Proposals such as XCP for new congestion control mechanisms based on 1793 more feedback from routers are more powerful than Quick-Start, but 1794 also are more complex to understand and more difficult to deploy. 1795 XCP routers maintain no per-flow state, but provide more fine- 1796 grained feedback to end-nodes than the one-bit congestion feedback 1797 of ECN. The per-packet feedback from XCP can be positive or 1798 negative, and specifies the increase or decrease in the sender's 1799 congestion window when this packet is acknowledged. 1801 AntiECN: 1802 The AntiECN proposal is for a single bit in the packet header that 1803 routers could set to indicate that they are underutilized. For each 1804 TCP ACK arriving at the sender indicating that a packet has been 1805 received with the Anti-ECN bit set, the sender would be able to 1806 increase its congestion window by one packet, as it would during 1807 slow-start. 1809 8. Implementation and Deployment Issues 1811 This section discusses some of the implementation issues with Quick- 1812 Start. This section also discusses some of the key deployment 1813 issues, such as the chicken-and-egg deployment problems of 1814 mechanisms that have to be deployed in both routers and end nodes in 1815 order to work, and the problems posed by the wide deployment of 1816 middleboxes today that block the use of known or unknown IP Options. 1818 8.1. Implementation Issues for Sending Quick-Start Requests 1820 Section 4.6 discusses some of the issues with deciding the initial 1821 sending rate to request. Quick-Start raises additional issues about 1822 the communication between the transport protocol and the 1823 application, and about the use of the past history with Quick-Start 1824 in the end node. 1826 One possibility is that a protocol implementation could provide an 1827 API for applications to indicate when they want to request Quick- 1828 Start, and what rate they would like to request. In the 1829 conventional socket API this could be a socket option that is set 1830 before a connection is established. Some applications, such those 1831 that use TCP for bulk transfers, do not have interest in the 1832 transmission rate, but they might know the amount of data that can 1833 be sent immediately. Based on this, the sender implementation could 1834 decide whether Quick-Start would be useful, and what rate should be 1835 requested. Datagram-based real-time streaming applications, on the 1836 other hand, may have a specific preference on the transmission rate 1837 and they could indicate the required rate explicitly to the 1838 transport protocol to be used in the Quick-Start Request. 1840 We note that when Quick-Start is used, the TCP sender is required to 1841 implement an additional timer for the paced transmission of Quick- 1842 Start packets. 1844 8.2. Implementation Issues for Processing Quick-Start Requests 1846 A router or other network host must be able to determine the 1847 approximate bandwidth of its outbound network interfaces in order to 1848 process incoming Quick-Start rate requests, including those that 1849 originate from the host itself. One possibility would be for hosts 1850 to rely on configuration information to determine link bandwidths; 1851 this has the drawback of not being robust to errors in 1852 configuration. Another possibility would be for network device 1853 drivers to infer the bandwidth for the interface and to communicate 1854 this to the IP layer. 1856 Particular issues will arise for wireless links with variable 1857 bandwidth, where decisions will have to be made about how frequently 1858 the network host gets updates of the changing bandwidth. It seems 1859 appropriate that Quick-Start Requests would be handled particularly 1860 conservatively for links with variable bandwidth, to avoid cases 1861 where Quick-Start Requests are approved, the link bandwidth is 1862 reduced, and the data packets that are send end up being dropped. 1864 8.3. Possible Deployment Scenarios 1866 Because of possible problems discussed above concerning using Quick- 1867 Start over some network paths, the most realistic initial deployment 1868 of Quick-Start would likely to take place in Intranets and other 1869 controlled environments. Quick-Start is most useful on high 1870 bandwidth-delay paths that are significantly underutilized. The 1871 primary initial users of Quick-Start would likely be in 1872 organizations that provide network services to their users and also 1873 have control over a large portion of the network path. 1875 Below are a few examples of networking environments where Quick- 1876 Start would potentially be useful. These are the environments that 1877 might consider an initial deployment of Quick-Start in the routers 1878 and end-nodes, where the incentives for routers to deploy Quick- 1879 Start might be the most clear. 1881 * Centrally-administrated organizational Intranets often have large 1882 network capacity and the networks are underutilized for most of the 1883 time. Such Intranets might also include high-bandwidth and high- 1884 delay paths to remote sites. In such an environment, Quick-Start 1885 would be of benefit to users, and there would be a clear incentive 1886 for the deployment of Quick-Start in routers. For example, Quick- 1887 Start could be quite useful in high-bandwidth networks used for 1888 scientific computing. 1890 * Quick-Start could also be useful in high-delay environments of 1891 Cellular Wide-Area Wireless Networks such as the GPRS [BW97] and 1892 their enhancements and next generations. For example, GPRS EDGE 1893 (Enhanced Data for GSM Evolution) is expected to provide wireless 1894 bandwidth of up to 384 Kbps (roughly 32 1500-byte packets per 1895 second) while the GPRS round-trip times are typically up to one 1896 second excluding any possible queueing delays in the network 1897 [GPAR02]. In addition, these networks sometimes have variable 1898 additional delays due to resource allocation that could be avoided 1899 by keeping the connection path constantly utilized, starting from 1900 initial slow-start. Thus, Quick-Start could be of significant 1901 benefit to users in these environments. 1903 * Geostationary Orbit (GEO) satellite links have one-way propagation 1904 delays on the order of 250 ms while the bandwidth can be measured in 1905 megabits per second [RFC2488]. Because of the considerable 1906 bandwidth-delay product on the link, TCP's slow-start is a major 1907 performance limitation in the beginning of the connection. A large 1908 initial congestion window would be useful to users of such satellite 1909 links. 1911 8.4. Would QuickStart packets take the slow path in routers? 1913 How much delay would the slow path add to the processing time for 1914 this packet? Similarly, if QuickStart packets took the slow path, 1915 how much stress would it add to routers for there to be many more 1916 packets on the slow path, because of the number of packets using 1917 QuickStart? These are both questions to be explored while 1918 experimenting with Quick-Start in the Internet. 1920 8.5. A Comparison with the Deployment Problems of ECN 1922 Given the glacially slow rate of deployment of ECN in the Internet 1923 to date [MAF05], it is disconcerting to note that some of the 1924 deployment problems of Quick-Start are even greater than those of 1925 ECN. First, unlike ECN, which can be of benefit even if it is only 1926 deployed on one of the routers along the end-to-end path, a 1927 connection's use of Quick-Start requires its deployment on all of 1928 the routers along the end-to-end path. Second, unlike ECN, which 1929 uses an allocated field in the IP header, Quick-Start requires the 1930 extra complications of an IP Option. 1932 However, in spite of these issues, there is some hope for the 1933 deployment of Quick-Start, at least in protected corners of the 1934 Internet, because the potential benefits of Quick-Start to the user 1935 are considerably more dramatic than those of ECN. Rather than 1936 simply replacing the occasional dropped packet by an ECN-marked 1937 packet, Quick-Start is capable of dramatically increasing the 1938 throughput of connections in underutilized environments. 1940 9. Security Considerations 1942 Sections 6.3 and 6.6 discuss the security considerations related to 1943 Quick-Start. Section 6.3 discusses the potential abuse of Quick- 1944 Start of receivers lying about whether the request was approved or 1945 about the approved rate; of routers in collusion to misuse Quick- 1946 Start; and of potential problems with traffic normalizers that 1947 rewrite IP TTLs in packet headers. All of these problems could 1948 result in the sender using an Rate Request that was inappropriately 1949 large, or thinking that a request was approved when it was in fact 1950 denied by at least one router along the path. This inappropriate 1951 use of Quick-Start would result in congestion and an unacceptable 1952 level of packet drops along the path, Such congestion could also be 1953 part of a Denial of Service attack. 1955 Section 6.6 discusses a potential attack on the routers' processing 1956 and state load from an attack of Quick-Start Requests. Section 6.6 1957 also discusses a potential attack on the available Quick-Start 1958 bandwidth by sending bogus Quick-Start requests for bandwidth that 1959 will not in fact be used. 1961 Section 4.6.3 discusses the potential problem of packets with Quick- 1962 Start Requests dropped by middleboxes along the path. 1964 10. Conclusions 1966 We are presenting the Quick-Start mechanism as a proposal for a 1967 simple, understandable, and incrementally-deployable mechanism that 1968 would be sufficient to allow connections to start up with large 1969 initial rates, or large initial congestion windows, in 1970 overprovisioned, high-bandwidth environments. We expect there will 1971 be an increasing number of overprovisioned, high-bandwidth 1972 environments where the Quick-Start mechanism, or another mechanism 1973 of similar power, could be of significant benefit to a wide range of 1974 traffic. We are presenting the Quick-Start mechanism as a request 1975 for the community to provide feedback and experimentation on issues 1976 relating to Quick-Start. 1978 11. Acknowledgements 1980 The authors wish to thank Mark Handley for discussions of these 1981 issues. The authors also thank the End-to-End Research Group, the 1982 Transport Services Working Group, and members of IPAM's program on 1983 Large Scale Communication Networks for both positive and negative 1984 feedback on this proposal. We thank Srikanth Sundarrajan for the 1985 initial implementation of Quick-Start in the NS simulator, and for 1986 the initial simulation study. We also thank Mohammed Ashraf, John 1987 Border, Tom Dunigan, John Heidemann, Paul Hyder, Dina Katabi, and 1988 Vern Paxson for feedback. This draft builds upon the concepts 1989 described in [RFC3390], [AHO98], [RFC2415], and [RFC3168]. 1991 This is a modification of a draft originally by Amit Jain for 1992 Initial Window Discovery. 1994 A. Design Decisions 1996 A.1. Alternate Mechanisms for the Quick-Start Request: ICMP and RSVP 1998 This document has proposed using an IP Option for the Quick-Start 1999 Request from the sender to the receiver, and using transport 2000 mechanisms for the Quick-Start Response from the receiver back to 2001 the sender. In this section we discuss alternate mechanisms, and 2002 consider whether ICMP [RFC792, RFC2463] or RSVP [RFC2205] protocols 2003 could be used for delivering the Quick-Start Request. 2005 A.1.1. ICMP 2007 Being a control protocol used between Internet nodes, one could 2008 argue that ICMP is the ideal method for requesting a permission for 2009 faster startup from routers. The ICMP header is above the IP 2010 header. Quick-Start could be accomplished with ICMP as follows: If 2011 the ICMP protocol is used to implement Quick-Start, the equivalent 2012 of the Quick-Start IP option would be carried in the ICMP header of 2013 the ICMP Quick-Start Request. The ICMP Quick-Start Request would 2014 have to pass by the routers on the path to the receiver; for now, we 2015 don't address the mechanisms that would be needed to accomplish this 2016 task. A router that approves the Quick-Start Request would take the 2017 same actions as in the case with the Quick-Start IP Option, and 2018 forward the packet to the next router along the path. A router that 2019 does not approve the Quick-Start Request, even with a decreased 2020 value for the Requested Rate, would delete the ICMP Quick-Start 2021 Request, and send an ICMP Reply to the sender that the request was 2022 not approved. If the ICMP Reply was dropped in the network, and did 2023 not reach the receiver, the sender would still know that the request 2024 was not approved from the absence of feedback from the receiver. If 2025 the ICMP Quick-Start request was dropped in the network due to 2026 congestion, the sender would assume that the request was not 2027 approved. If the ICMP Quick-Start Request reached the receiver, the 2028 receiver would use transport-level mechanisms to send a response to 2029 the sender, exactly as with the IP Option. 2031 One benefit of using ICMP would be that the delivery of the TCP SYN 2032 packet or other initial packet would not be delayed by IP option 2033 processing at routers. A greater advantage is that if middleboxes 2034 were blocking packets with Quick-Start Requests, using the Quick- 2035 Start Request in a separate ICMP packet would mean that the 2036 middlebox behavior would not affect the connection as a whole. (To 2037 get this robustness to middleboxes with TCP using an IP Quick-Start 2038 Option, one would have to have a TCP-level Quick-Start Request 2039 packet that was sent concurrently but separately from the TCP SYN 2040 packet.) 2042 However, there are a number of disadvantages to using ICMP. Some 2043 firewalls and middleboxes may not forward the ICMP Quick-Start 2044 Request packets. (If an ICMP Reply packet from a router to the 2045 sender is dropped in the network, the sender would still know that 2046 the request was not approved, as stated earlier, so this would not 2047 be a problem.) In addition, it would be difficult, if not 2048 impossible, for a router in the middle of an IP tunnel to deliver an 2049 ICMP Reply packet to the actual source, for example when the inner 2050 IP header is encrypted as in IPsec tunnel mode [RFC2401]. Again, 2051 however, the ICMP Reply packet would not be essential to the correct 2052 operation of ICMP Quick-Start. 2054 Unauthenticated out-of-band ICMP messages could enable some types of 2055 attacks by third-party malicious hosts that are not possible when 2056 the control information is carried in-band with the IP packets that 2057 can only be altered by the routers on the connection path. Finally, 2058 as a minor concern, using ICMP would cause a small amount of 2059 additional traffic in the network, which is not the case when using 2060 IP options. 2062 A.1.2. RSVP 2064 With some modifications RSVP [RFC2205] could be used as a bearer 2065 protocol for carrying the Quick-Start Requests. Because routers are 2066 expected to process RSVP packets more extensively than the normal 2067 transport protocol IP packets, delivering a Quick-Start rate request 2068 using an RSVP packet would seem an appealing choice. However, Quick- 2069 Start with RSVP would require a few differences from the 2070 conventional usage of RSVP. Quick-Start would not require periodical 2071 refreshing of soft state, because Quick-Start does not require per- 2072 connection state in routers. Quick-Start Requests would be 2073 transmitted downstream from the sender to receiver in the RSVP Path 2074 messages, which is different from the conventional RSVP model where 2075 the reservations originate from the receiver. Furthermore, the 2076 Quick-Start Response would be sent using the transport-level 2077 mechanisms instead of using the RSVP Resv message. 2079 If RSVP was used for carrying a Quick-Start Request, a new "Quick- 2080 Start Request" class object would be included in the RSVP Path 2081 message that is sent from the sender to receiver. The object would 2082 contain the rate request field in addition to the common length and 2083 type fields. The Send_TTL field in the RSVP common header could be 2084 used as the equivalent of the QS TTL field. The Quick-Start capable 2085 routers along the path would inspect the Quick-Start Request object 2086 in the RSVP Path message, decrement Send_TTL and adjust the rate 2087 request field if needed. If an RSVP router did not understand the 2088 Quick-Start Request object, it would reject the entire RSVP message 2089 and send an RSVP PathErr message back to the sender. When an RSVP 2090 message with the Quick-Start Request object reaches the receiver, 2091 the receiver sends a Quick-Start Reply message in the corresponding 2092 transport protocol header in the same way as described in the 2093 context of IP options earlier. If the RSVP message with the Quick- 2094 Start Request object was dropped along the path, the transport 2095 sender would simply proceed with the normal congestion control 2096 procedures. 2098 Much of the discussion about benefits and drawbacks of using ICMP 2099 for making the Quick-Start Request also applies to the RSVP case. If 2100 the Quick-Start Request was transmitted in a separate packet instead 2101 of as an IP option, the transport protocol packet delivery would not 2102 be delayed due to IP option processing at the routers, and the 2103 initial transport packets would reach their destination more 2104 reliably. The possible disadvantages of using ICMP and RSVP are also 2105 expected to be similar: middleboxes in the network may not be able 2106 to forward the Quick-Start Request messages, and the IP tunnels 2107 might cause problems for processing the Quick-Start Requests. 2109 A.2. Alternate Encoding Functions 2111 In this section we look at alternate encoding functions for the Rate 2112 Request field in the Quick-Start Request. The main requirements for 2113 this function is that it should have a sufficiently wide range for 2114 the requested rate. There is no need for overly-fine-grained 2115 precision in the requested rate. Similarly, while it would be 2116 attractive for the encoding function to be easily computable, it is 2117 also possible for end-nodes and routers to simply store the table 2118 giving the mapping between the value N in the Rate Request field, 2119 and the actual rate request f(N). In this section we consider both 2120 four-bit and eight-bit Rate Request fields. 2122 Linear functions: 2123 The Quick-Start Request contains an 8-bit field for the Rate 2124 Request. One possible proposal would be for this field to be 2125 formatted in bits per second, scaled so that one unit equals 80 2126 Kbps. Thus, for the value N in the Rate Request field, the 2127 requested rate is 80,000*N bps. This gives a request range between 2128 80 Kbps and 20.48 Mbps. For 1500-byte packets, this corresponds to 2129 a request range between 6 and 1706 packets per second. 2131 Powers of two: 2132 If a granularity of factors of two is sufficient for the Rate 2133 Request, then the encoding function with the most range would be for 2134 the requested rate to be K*2^N, for N the value in the Rate Request 2135 field, and for K some constant. For N=0, the rate request would be 2136 set to zero, regardless of the encoding function. For example, for 2137 K=40,000, the request range would be from 80 Kbps to 40*2^256 Kbps. 2138 This clearly would be an unnecessarily large request range. 2140 For a four-bit Rate Request field, the upper limit on the rate 2141 request is 1.3 Gbps. It is possible that an upper limit of 1.3 Gbps 2142 would be fine for the Quick-Start rate request, and that connections 2143 wishing to start up with a higher initial sending rate should be 2144 encouraged to use other mechanisms, such as the explicit reservation 2145 of bandwidth. If an upper limit of 1.3 Gbps is not acceptable, then 2146 five bits could be used for the Rate Request field. 2148 If the granularity of factors of two is too coarse, then the 2149 encoding function could use a base less than two. An alternate form 2150 for the encoding function would be to use a hybrid of linear and 2151 exponential functions. 2153 We note that the Rate Request also has to be constrained by the 2154 abilities of the transport protocol. For example, for TCP with 2155 Window Scaling, the maximum window is at most 2**30 bytes. For a 2156 TCP connection with a long, 1 second round-trip time, this would 2157 give a maximum sending rate of 1.07 Gbps. 2159 A.3. The Quick-Start Request: Packets or Bytes? 2161 One of the design questions is whether the Rate Request field should 2162 be in bytes per second or in packets per second. We will discuss 2163 this separately from the perspective of the transport, and from the 2164 perspective of the router. 2166 For TCP, the results from the Quick-Start Request are translated 2167 into a congestion window in bytes, using the measured round-trip 2168 time and the MSS. This window applies only to the bytes of data 2169 payload, and does not include the bytes in the TCP or IP packet 2170 headers. Other transport protocols would conceivably use the Quick- 2171 Start Request directly in packets per second, or could translate the 2172 Quick-Start Request to a congestion window in packets. 2174 The assumption of this draft is that the router only approves the 2175 Quick-Start Request when the output link is significantly 2176 underutilized. For this, the router could measure the available 2177 bandwidth in bytes per second, or could convert between packets and 2178 bytes by some mechanism. 2180 If the Quick-Start Request was in bytes per second, and applied only 2181 to the data payload, then the router would have to convert from 2182 bytes per second of data payload, to bytes per second of packets on 2183 the wire. If the Rate Request field was in bytes per second and the 2184 sender ended up using very small packets, this could translate to a 2185 significantly larger number in terms of bytes per second on the 2186 wire. Therefore, for a Quick-Start Request in bytes per second, it 2187 makes most sense for this to include the transport and IP headers as 2188 well as the data payload. Of course, this will be at best a rough 2189 approximation on the part of the sender; the transport-level sender 2190 might not know the size of the transport and IP headers in bytes, 2191 and might know nothing at all about the separate headers added in IP 2192 tunnels downstream. This rough estimate seems sufficient, however, 2193 given the overall lack of fine precision in Quick-Start 2194 functionality. 2196 It has been suggested that the router could possibly use information 2197 from the MSS option in the TCP packet header of the SYN packet to 2198 convert the Quick-Start Request from packets per second to bytes per 2199 second, or vice versa. The MSS option is defined as the maximum MSS 2200 that the TCP sender expects to receive, not the maximum MSS that the 2201 TCP sender plans to send [RFC793]. However, it is probably often 2202 the case that this MSS also applies as an upper bound on the MSS 2203 used by the TCP sender in sending. 2205 We note that the sender does not necessarily know the Path MTU when 2206 the Quick-Start Request is sent, or when the initial window of data 2207 is sent. Thus, with IPv4, packets from the initial window could end 2208 up being fragmented in the network if the "Don't Fragment" (DF) bit 2209 is not set [RFC1191]. A Rate Request in bytes per second is 2210 reasonably robust to fragmentation. Clearly a Rate Request in 2211 packets per second is less robust in the presence of fragmentation. 2212 Interactions between larger initial windows and Path MTU Discovery 2213 are discussed in more detail in RFC 3390 [RFC3390]. 2215 For a Quick-Start Request in bytes per second, the transport senders 2216 would have the additional complication of estimating the bandwidth 2217 usage added by the packet headers. 2219 We have chosen an Rate Request field in bytes per second rather than 2220 in packets per second because it seems somewhat more robust, 2221 particularly to routers. 2223 A.4. Quick-Start Semantics: Total Rate or Additional Rate? 2225 For a Quick-Start Request sent in the middle of a connection, there 2226 are two possible semantics for the Rate Request field, as follows: 2228 (1) Total Rate: The requested Rate Request is the requested total 2229 rate for the connection, including the current rate; or 2231 (2) Additional Rate: The requested Rate Request is the requested 2232 increase in the total rate for that connection, over and above the 2233 current sending rate. 2235 When the Quick-Start Request is sent after an idle period, the 2236 current sending rate is zero, and there is no difference between (1) 2237 and (2) above. However, a Quick-Start Request can also be sent in 2238 the middle of a connection that has not been idle, e.g., after a 2239 mobility event, or after an application-limited period when the 2240 sender is suddenly ready to send at a much higher rate. In this 2241 case, there can be a significant difference between (1) and (2) 2242 above. In this section we consider briefly the tradeoffs between 2243 these two options, and explain why we have chosen the `Total Rate' 2244 semantics. 2246 The Total Rate semantics makes it easier for routers to ``allocate'' 2247 the same rate to all connections. This lends itself to fairness, 2248 and improves convergence times between old and new connections. 2249 With the Additional Rate semantics, the router would not necessarily 2250 know the current sending rates of the flows requesting additional 2251 rates, and therefore would not have sufficient information to use 2252 fairness as a metric in granting rate requests. With the Total Rate 2253 semantics, the fairness is automatic; the router is not granting 2254 rate requests for *additional* bandwidth without knowing the current 2255 sending rates of the different flows. 2257 The Additional Rate semantics also lends itself to gaming by the 2258 connection, with senders sending frequent Quick-Start Requests in 2259 the hope of gaining a higher rate. If the router is granting the 2260 same maximum rate for all rate requests, then there is little 2261 benefit to a connection of sending a rate request over and over 2262 again. However, if the router is granting an *additional* rate with 2263 each rate request, over and above the current sending rate, then it 2264 is in a connection's interest to send as many rate requests as 2265 possible, even if very few of them are in fact granted. 2267 For either of these alternatives, there would not be room to report 2268 the current sending rate in the Quick-Start Option using the current 2269 minimal format for the Quick-Start Request. Thus, either the Quick- 2270 Start Option would have to take more than four bytes to include a 2271 report of the current sending rate, or the current sending rate 2272 would not be reported to the routers. 2274 A.5. Alternate Responses to the Loss of a Quick-Start Packet 2276 Section 4.5 discusses TCP's response to the loss of a Quick-Start 2277 packet in the initial window. This section discusses several 2278 alternate responses. 2280 One possible alternative to reverting to the default slow-start 2281 after the loss of a Quick-Start packet from the initial window would 2282 have been to halve the congestion window and continue in congestion 2283 avoidance. However, we note that this would not have been a 2284 desirable response for either the connection or for the network as a 2285 whole. The packet loss in the initial window indicates that Quick- 2286 Start failed in finding an appropriate congestion window, meaning 2287 that the congestion window after halving may easily also be wrong. 2289 A more moderate alternate would be to continue in congestion 2290 avoidance from a window of (W-D)/2, where W is the Quick-Start 2291 congestion window, and D is the number of packets dropped or marked 2292 from that window. However, such an approach would implicitly assume 2293 that the number of Quick-Start packets delivered is a good 2294 indication of the appropriate available bandwidth for that flow, 2295 even though other packets from that window were dropped in the 2296 network. We believe that such an assumption would require more 2297 analysis at this point, particularly in a network with a range of 2298 packet dropping mechanisms at the router, and we cannot recommend it 2299 at this time. 2301 Another drawback of approaches that don't revert back to slow-start 2302 when a Quick-Start packet in the initial window is dropped is that 2303 any such approaches could give the TCP receiver an incentive to lie 2304 about the Quick-Start request. That is, if the sender reverts to 2305 slow-start when a Quick-Start packet is dropped, then it is 2306 generally not to the receiver's advantage to report a larger rate 2307 request than was actually approved if the result is going to be a 2308 Quick-Start packet dropped in the network. However, if the receiver 2309 benefits from a larger Quick-Start window even when the larger 2310 window results in Quick-Start packets dropped in the network, then 2311 the receiver has a greater incentive to lie about the received rate 2312 request, in an effort to get the sender to use a larger initial 2313 sending rate. 2315 A.6. Why Not Include More Functionality? 2317 As Section 6.5 discussed, this proposal for Quick-Start is a rather 2318 coarse-grained mechanism that would allow connections to use higher 2319 sending rates along underutilized paths, but that does not attempt 2320 to provide a next-generation transport protocol, and does not 2321 attempt the goal of providing very high throughput with very low 2322 delay. As Section 7.4 discusses, there are a number of proposals 2323 such as XCP, MaxNet, and AntiECN for more fine-grained per-packet 2324 feedback from routers that the current congestion control 2325 mechanisms, that do attempt these more ambitious goals. 2327 Compared to proposals such as XCP and AntiECN, Quick-Start offers 2328 much less control. Quick-Start does not attempt to provide a new 2329 congestion control mechanism, but simply to get permission from 2330 routers for a higher sending rate at start-up, or after an idle 2331 period. Quick-Start can be thought of as an "anti-congestion- 2332 control" mechanism, that is only of any use when all of the routers 2333 along the path are significantly under-utilized. Thus, Quick-Start 2334 is of no use towards a target of high link utilization, or fairness 2335 in a high-utilization scenario, or controlling queueing delay during 2336 high-utilization, or anything of the like. 2338 At the same time, Quick-Start would allow larger initial windows 2339 than would proposals such as AntiECN, requires less input to routers 2340 than XCP, and would require less frequent feedback from routers than 2341 any new congestion control mechanism. Thus, Quick-Start is 2342 significantly less powerful than proposals for new congestion 2343 control mechanisms such as XCP and AntiECN, but as powerful or more 2344 powerful in terms of the specific issue of allowing larger initial 2345 windows, and (we think) more amenable to incremental deployment in 2346 the current Internet. 2348 We do not discuss proposals such as XCP in detail, but simply note 2349 that there are a number of open questions. One question concerns 2350 whether there is a pressing need for more sophisticated congestion 2351 control mechanisms such as XCP in the Internet. Quick-Start is 2352 inherently a rather crude tool that does not deliver assurances 2353 about maintaining high link utilization and low queueing delay; 2354 Quick-Start is designed for use in environments that are 2355 significantly underutilized, and addresses the single question of 2356 whether a higher sending rate is allowed. New congestion control 2357 mechanisms with more fine-grained feedback from routers could allow 2358 faster startups even in environments with rather high link 2359 utilization. Is this a pressing requirement? Are the other 2360 benefits of more fine-grained congestion control feedback from 2361 routers a pressing requirement? 2363 We would argue that even if more fine-grained per-packet feedback 2364 from routers was implemented, it is reasonable to have a separate 2365 mechanism such as Quick-Start for indicating an allowed initial 2366 sending rate, or an allowed total sending rate after an idle or 2367 underutilized period. 2369 One difference between Quick-Start and current proposals for fine- 2370 grained per-packet feedback such as XCP is that XCP is designed to 2371 give robust performance even in the case where different packets 2372 within a connection routinely follow different paths. XCP achieves 2373 relatively robust performance in the presence of multi-path routing 2374 by using per-packet feedback, where the feedback carried in a single 2375 packet is about the relative increase or decrease in the rate or 2376 window to take effect when that particular packet is acknowledged, 2377 not about the allowed sending rate for the connection as a whole. 2379 In contrast, Quick-Start sends a single Quick-Start request, and the 2380 answer to that request gives the allowed sending rate for an entire 2381 window of data. As a result, Quick-Start could be problematic in an 2382 environment where some fraction of the packets in a window of data 2383 take path A, and the rest of the packets take path B; for example, 2384 the Quick-Start Request could have travelled on path A, while half 2385 of the Quick-Start packets sent in the succeeding round-trip time 2386 are routed on path B. 2388 There are also differences between Quick-Start and some of the 2389 proposals for per-packet feedback in terms of the number of bits of 2390 feedback required from the routers to the end-nodes. Quick-Start 2391 uses four bits of feedback in the rate request field to indicate the 2392 allowed sending rate. XCP allocates a byte for per-packet feedback, 2393 though there has been discussion of variants of XCP with less per- 2394 packet feedback. This would be more like other proposals such as 2395 anti-ECN that use a single bit of feedback from routers to indicate 2396 that the sender can increase as fast as slow-starting, in response 2397 to this particular packet acknowledgement. In general, there is 2398 probably considerable power in fine-grained proposals with only two 2399 bits of feedback, indicating that the sender should decrease, 2400 maintain, or increase the sending rate or window when this packet is 2401 acknowledged. However, the power of Quick-Start would be 2402 considerably limited if it was restricted to only two bits of 2403 feedback; it seems likely that determining the initial sending rate 2404 fundamentally requires more bits of feedback from routers than does 2405 the steady-state, per-packet feedback to increase or decrease the 2406 sending rate. 2408 On a more practical level, one difference between Quick-Start and 2409 proposals for per-packet feedback is that there are fewer open 2410 issues with Quick-Start than there would be with a new congestion 2411 control mechanism. For example, for a mechanism for requesting a 2412 initial sending rate in an underutilized environment, the fairness 2413 issues of a general congestion control mechanism go away, and there 2414 is no need for the end nodes to tell the routers the round-trip time 2415 and congestion window, as is done in XCP; all that is needed is for 2416 the end nodes to report the requested sending rate. 2418 Table 2 provides a summary of the differences between Quick-Start 2419 and proposals for per-packet congestion control feedback. 2421 Proposals for 2422 Quick-Start Per-Packet Feedback 2423 +------------------+----------------------+----------------------+ 2424 Semantics: | Allowed sending rate | Change in rate/window, 2425 | per connection. | per-packet. 2426 +------------------+----------------------+----------------------+ 2427 Relationship to | In addition. | Replacement. 2428 congestion ctrl: | | 2429 +------------------+----------------------+----------------------+ 2430 Frequency: | Start-up, or after | Every packet. 2431 | an idle period. | 2432 +------------------+----------------------+----------------------+ 2433 Limitations: | Only useful on | General congestion 2434 | underutilized paths.| control mechanism. 2435 +------------------+----------------------+----------------------+ 2436 Input to routers: | Rate request. | RTT, cwnd, request (XCP). 2437 | | None (Anti-ECN). 2438 +------------------+----------------------+----------------------+ 2439 Bits of feedback: | Four bits for | A few bits would 2440 | rate request. | suffice? 2441 +------------------+----------------------+----------------------+ 2443 Table 2: Differences between Quick-Start and Proposals for 2444 Fine-Grained Per-Packet Feedback. 2446 A separate question concerns whether mechanisms such as Quick-Start, 2447 in combination with HighSpeed TCP and other changes in progress, 2448 would make a significant contribution towards meeting some of these 2449 needs for new congestion control mechanisms. This could be viewed 2450 as a positive step of meeting some of the current needs with a 2451 simple and reasonably deployable mechanism, or alternately, as a 2452 negative step of unnecessarily delaying more fundamental changes. 2453 Without answering this question, we would note that our own approach 2454 tends to favor the incremental deployment of relatively simple 2455 mechanisms, as long as the simple mechanisms are not short-term 2456 hacks but mechanisms that lead the overall architecture in the 2457 fundamentally correct direction. 2459 A.7. The Earlier QuickStart Nonce 2461 An earlier version of this document included a Request-Approved 2462 QuickStart Nonce (QS Nonce) that was initialized by the sender to a 2463 non-zero, `random' eight-bit number, along with a QS TTL that was 2464 initialized to the same value as the TTL in the IP header. The 2465 Request-Approved QuickStart Nonce would have been returned by the 2466 TCP receiver to the TCP sender in the Quick-Start Response. A 2467 router could deny the Quick-Start request by failing to decrement 2468 the QS TTL field, by zeroing the QS Nonce field, or by deleting the 2469 Quick-Start Request from the packet header. The QS Nonce was 2470 included to provide some protection against broken downstream 2471 routers, or against misbehaving TCP receivers that might be inclined 2472 to lie about whether the Rate Request was approved. This protection 2473 is now provided by the use of a random initial value for the QS TTL 2474 field, and by Quick-Start-capable routers hopefully either deleting 2475 the Quick-Start Option or zeroing the QS TTL field when they deny a 2476 request. 2478 With the old Request-Approved QuickStart Nonce, along with the QS 2479 TTL field set to the same value as the TTL field in the IP header, 2480 the Quick-Start Request mechanism would have been self-terminating; 2481 the Quick-Start Request would terminate at the first participating 2482 router after a non-participating router had been encountered on the 2483 path. This minimizes unnecessary overhead incurred by routers 2484 because of option processing for the Quick-Start Request. In the 2485 current specification, this "self-terminating" property is provided 2486 by Quick-Start-capable routers hopefully either deleting the Quick- 2487 Start Option or zeroing the Rate Request field when they deny a 2488 request. Because the current specification uses a random initial 2489 value for the QS TTL, Quick-Start-capable routers can't tell if the 2490 Quick-Start Request is invalid because of non-Quick-Start-capable 2491 routers upstream. This is the cost of using a single field for the 2492 QS TTL, instead of two fields, one for the QS TTL and another for a 2493 QS-Approved Nonce. 2495 The Quick-Start Nonce has been resurrected in the current proposal 2496 for a Rate-Reduced Nonce given in Section 3.6. This proposal would 2497 provide specific protection against receivers lying about whether 2498 the rate request was decremented by routers along the path. In this 2499 proposal, the Rate-Reduced Nonce would be reset to a new random 2500 value by routers that approve the request but decrement the value of 2501 the Rate Request. Thus, if the original value for the Rate-Reduced 2502 Nonce is reported back by the receiver to the sender, then it is 2503 likely that the Rate Request was not decremented or denied by Quick- 2504 Start-capable routers along the path. 2506 B. Quick-Start with DCCP 2508 DCCP is a new transport protocol for congestion-controlled, 2509 unreliable datagrams, intended for applications such as streaming 2510 media, Internet telephony, and on-line games. In DCCP, the 2511 application has a choice of congestion control mechanisms, with the 2512 currently-specified Congestion Control Identifiers (CCIDs) being 2513 CCID 2 for TCP-like congestion control, and CCID 3 for TFRC, an 2514 equation-based form of congestion control. We refer the reader to 2515 [KHF05] for a more detailed description of DCCP, and of the 2516 congestion control mechanisms. 2518 Because CCID 3 uses a rate-based congestion control mechanism, it 2519 raises some new issues about the use of Quick-Start with transport 2520 protocols. In this document we don't attempt to specify the use of 2521 Quick-Start with DCCP. However, we do discuss some of the issues 2522 that might arise. 2524 In considering the use of Quick-Start with CCID 3 for requesting a 2525 higher initial sending rate, the following questions arise: (1) how 2526 does the sender respond if a Quick-Start packet is dropped; and (2) 2527 when does the sender determine that there has been no feedback from 2528 the receiver, and reduce the sending rate? 2530 (1) How does the sender respond if a Quick-Start packet is dropped: 2531 As in TCP, if an initial Quick-Start packet is dropped, the CCID 3 2532 sender should revert to the congestion control mechanisms it would 2533 have used if the Quick-Start request had not been approved. 2535 (2) When does the sender decide there has been no feedback from the 2536 receiver: 2537 Unlike TCP, CCID 3 does not use acknowledgements for every packet, 2538 or for every other packet. In contrast, the CCID 3 receiver sends 2539 feedback to the sender roughly once per round-trip time. In CCID 3, 2540 the allowed sending rate is halved if no feedback is received from 2541 the receiver in at least four round-trip times (when the sender is 2542 sending at least one packet every two round-trip times). When a 2543 Quick-Start request is used, it would seem prudent to use a smaller 2544 time interval, e.g., to reduce the sending rate if no feedback is 2545 received from the receiver in at least two round-trip times. 2547 The question also arises of how the sending rate should be reduced 2548 after a period of no feedback from the receiver. As with TCP, the 2549 default CCID 3 response of halving the sending rate is not 2550 necessarily sufficient; an alternative is to reduce the sending rate 2551 to the sending rate that would have been used if no Quick-Start 2552 request had been approved. That is, if a CCID 3 sender uses a 2553 Quick-Start request, special rules might be required to handle the 2554 sender's response to a period of no feedback from the receiver 2555 regarding the Quick-Start packets. 2557 Similarly, in considering the use of Quick-Start with CCID 3 for 2558 requesting a higher sending rate after an idle period, the following 2559 questions arise: (1) what rate does the sender request; (2) what is 2560 the response to a loss; and (3) when does the sender determine that 2561 there has been no feedback from the receiver, and the sending rate 2562 must be reduced? 2564 (1) What rate does the sender request: 2565 As in TCP, there is a straightforward answer to the rate request 2566 that the CCID 3 sender should use in requesting a higher sending 2567 rate after an idle period. The sender knows the current loss event 2568 rate, either from its own calculations or from feedback from the 2569 receiver, and can determine the sending rate allowed by that loss 2570 event rate. This is the upper bound on the sending rate that should 2571 be requested by the CCID 3 sender. A Quick-Start request is useful 2572 with CCID 3 when the sender is coming out of an idle or 2573 underutilized period, because in standard operation CCID 3 does not 2574 allow the sender to send more that twice as fast as the receiver has 2575 reported received in the most recent feedback message. 2577 (2) What is the response to loss: 2578 The response to the loss of Quick-Start packets should be to return 2579 to the sending rate that would have been used if Quick-Start had not 2580 been requested. 2582 (3) When does the sender decide there has been no feedback from the 2583 receiver: 2584 As in the case of the initial sending rate, it would seem prudent to 2585 reduce the sending rate if no feedback is received from the receiver 2586 in at least two round-trip times. It seems likely that in this 2587 case, the sending rate should be reduced to the sending rate that 2588 would have been used if no Quick-Start request had been approved. 2590 C. Possible Router Algorithm 2592 This specification does not tightly define the algorithm a router 2593 uses when deciding whether to approve a Quick-Start Rate Request or 2594 whether and how to reduce a Rate Request. A range of algorithms is 2595 likely useful in this space and we consider the algorithm a 2596 particular router uses to be a local policy decision. In addition, 2597 we believe that additional experimentation with router algorithms is 2598 necessary to have a solid understanding of the dynamics various 2599 algorithms impose. However, we provide one particular algorithm in 2600 this appendix as an example and as a framework for thinking about 2601 additional mechanisms. 2603 [SAF05] provides several algorithms routers can use to consider 2604 incoming Rate Requests. The decision process involves two 2605 algorithms. First, the router needs to track the link utilization 2606 over the recent past. Second, this utilization needs to be updated 2607 by the potential new bandwidth from recent Quick-Start approvals, 2608 and then compared with the router's notion of when it is 2609 underutilized enough to approve Quick-Start requests (of some size). 2611 First, we define the "peak utilization" estimation technique (from 2612 [SAF05]). This mechanism records the utilization of the link every 2613 S seconds and stores the most recent N of these measurements. The 2614 utilization is then taken as the highest utilization of the N 2615 samples. This method, therefore, keeps N*S seconds of history. 2616 This algorithm reacts rapidly to increases in the link utilization. 2617 In [SAF05] S is set to 0.15 seconds, and experiments use values for 2618 N ranging from 3 to 20. 2620 Second, we define the "target" algorithm for processing incoming 2621 Quick-Start Rate Requests (also from [SAF05]). The algorithm relies 2622 on knowing the bandwidth of the outgoing link (which in many cases 2623 can be easily configured), the utilization of the outgoing link 2624 (from an estimation technique such as given above) and an estimate 2625 of the potential bandwidth from recent Quick-Start approvals. 2627 Tracking the potential bandwidth from recent Quick-Start approvals 2628 is another case where local policy dictates how it should be done. 2629 The simpliest method, outlined in Section 3.4, is for the router to 2630 keep track of the aggregate Quick-Start rate requests approved in 2631 the most recent two or more time intervals, including the current 2632 time interval, and to use the sum of the aggregate rate requests 2633 over these time intervals as the estimate of the approved Rate 2634 Requests. The experiments in [SAF05] keep track of the aggregate 2635 approved Rate Requests over the most recent two time intervals, for 2636 intervals of 150~msec. 2638 The target algorithm also depends on a threshold (qs_thresh) that is 2639 the fraction of the outgoing link bandwidth that represents the 2640 router's notion of "significantly underutilized". If the 2641 utilization, augmented by the potential bandwidth from recent Quick- 2642 Start approvals, is above this threshold then no Quick-Start Rate 2643 Requests will be approved. If the utilization is less than the 2644 threshold then Rate Requests will be approved. The Rate Requests 2645 will be reduced such that the bandwidth allocated would not drive 2646 the utilization to more than the given threshold. The algorithm is: 2648 util_bw = bandwidth * utilization; 2649 util_bw = util_bw + recent_qs_approvals; 2650 if (util_bw < (qs_thresh * bandwidth)) 2651 { 2652 approved = (qs_thresh * bandwidth) - util_bw; 2653 if (rate_request < approved) 2654 approved = rate_request; 2655 approved = round_down (approved); 2656 recent_qs_approvals += approved; 2658 } 2660 Also note that given that Rate Requests are fairly gross the 2661 approved rate should be rounded down when it does not fall exactly 2662 on one of the rates allowed by the encoding scheme. 2664 Normative References 2666 [RFC793] J. Postel, Transmission Control Protocol, RFC 793, 2667 September 1981. 2669 [RFC1191] Mogul, J. and S. Deering, Path MTU Discovery, RFC 1191, 2670 November 1990. 2672 [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 2673 (IPv6) Specification. RFC 2460, December 1998. 2675 [RFC2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 2676 Control. RFC 2581. April 1999. 2678 [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D. The Addition 2679 of Explicit Congestion Notification (ECN) to IP. RFC 3168, Proposed 2680 Standard, September 2001. 2682 [RFC3390] M. Allman, S. Floyd, and C. Partridge. Increasing TCP's 2683 Initial Window. RFC 3390, October 2002. 2685 [RFC3742] Floyd, S., Limited Slow-Start for TCP with Large 2686 Congestion Windows, RFC 3742, Experimental, March 2004. 2688 Informative References 2690 [RFC792] J. Postel. Internet Control Message Protocol. RFC 792, 2691 September 1981. 2693 [RFC1812] F. Baker (ed.). Requirements for IP Version 4 Routers. RFC 2694 1812, June 1995. 2696 [RFC2140] J. Touch. TCP Control Block Interdependence. RFC 2140. 2697 April 1997. 2699 [RFC2205] R. Braden, et al. Resource ReSerVation Protocol (RSVP) -- 2700 Version 1 Functional Specification. RFC 2205, September 1997. 2702 [RFC2309] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, 2703 D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. 2705 Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, 2706 Recommendations on Queue Management and Congestion Avoidance in the 2707 Internet, RFC 2309, April 1998. 2709 [RFC2401] S. Kent and R. Atkinson. Security Architecture for the 2710 Internet Protocol. RFC 2401, November 1998. 2712 [RFC2415] K. Poduri and K. Nichols. Simulation Studies of Increased 2713 Initial TCP Window Size. RFC 2415. September 1998. 2715 [RFC2416] T. Shepard and C. Partridge. When TCP Starts Up With Four 2716 Packets Into Only Three Buffers. RFC 2416. September 1998. 2718 [RFC2463] A. Conta and S. Deering. Internet Control Message Protocol 2719 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. 2720 RFC 2463, December 1998. 2722 [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over 2723 Satellite Channels using Standard Mechanisms. RFC 2488. January 2724 1999. 2726 [RFC2960] R. Stewart, et. al. Stream Control Transmission Protocol. 2727 RFC 2960, October 2000. 2729 [RFC3124] H. Balakrishnan and S. Seshan. The Congestion Manager. RFC 2730 3124. June 2001. 2732 [RFC3344] C. Perkins (ed.). IP Mobility Support for IPv4. RFC 3344, 2733 August 2002. 2735 [RFC3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. 2736 RFC 3360, August 2002. 2738 [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in 2739 IPv6. RFC 3775, June 2004. 2741 [AHO98] M. Allman, C. Hayes and S. Ostermann. An evaluation of TCP 2742 with Larger Initial Windows. ACM Computer Communication Review, July 2743 1998. 2745 [BW97] G. Brasche and B. Walke. Concepts, Services and Protocols of 2746 the new GSM Phase 2+ General Packet Radio Service. IEEE 2747 Communications Magazine, pages 94--104, August 1997. 2749 [FF99] Floyd, S., and Fall, K., Promoting the Use of End-to-End 2750 Congestion Control in the Internet, IEEE/ACM Transactions on 2751 Networking, August 1999. 2753 [F03] Floyd, S., HighSpeed TCP for Large Congestion Windows, RFC 2754 3649, December 2003. 2756 [GPAR02] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. Multi- 2757 Layer Protocol Tracing in a GPRS Network. In Proceedings of the IEEE 2758 Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada, 2759 September 2002. 2761 [HKP01] M. Handley, C. Kreibich and V. Paxson, Network Intrusion 2762 Detection: Evasion, Traffic Normalization, and End-to-End Protocol 2763 Semantics, Proc. USENIX Security Symposium 2001. 2765 [Jac88] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM 2767 [JD02] Manish Jain, Constantinos Dovrolis, End-to-End Available 2768 Bandwidth: Measurement Methodology, Dynamics, and Relation with TCP 2769 Throughput, SIGCOMM 2002. 2771 [KHR02] Dina Katabi, Mark Handley, and Charles Rohrs, Internet 2772 Congestion Control for Future High Bandwidth-Delay Product 2773 Environments. ACM Sigcomm 2002, August 2002. URL 2774 "http://ana.lcs.mit.edu/dina/XCP/". 2776 [KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion 2777 Control Protocol (DCCP), internet draft draft-ietf-dccp-spec-11.txt, 2778 work in progress, March 2005. 2780 [K03] S. Kunniyur, "AntiECN Marking: A Marking Scheme for High 2781 Bandwidth Delay Connections", Proceedings, IEEE ICC '03, May 2003. 2782 URL "http://www.seas.upenn.edu/~kunniyur/". 2784 [KAPS02] Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. 2785 Sterbenz. Explicit Transport Error Notification (ETEN) for Error- 2786 Prone Wireless and Satellite Networks. Technical Report No. 8333, 2787 BBN Technologies, March 2002. URL 2788 "http://www.icir.org/mallman/papers/". 2790 [MAF04] Alberto Medina, Mark Allman, and Sally Floyd, Measuring 2791 Interactions Between Transport Protocols and Middleboxes, Internet 2792 Measurement Conference 2004, August 2004. URL 2793 "http://www.icir.org/tbit/". 2795 [MAF05] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the 2796 Evolution of Transport Protocols in the Internet. To appear in 2797 Computer Communications Review, April 2004. 2799 [MaxNet] MaxNet Home Page, URL 2800 "http://netlab.caltech.edu/~bartek/maxnet.htm". 2802 [PK98] Venkata N. Padmanabhan and Randy H. Katz, TCP Fast Start: A 2803 Technique For Speeding Up Web Transfers, IEEE GLOBECOM '98, November 2804 1998. 2806 [P00] Joon-Sang Park, Bandwidth Discovery of a TCP Connection, 2807 report to John Jeidemann, 2000, private communication. Citation for 2808 acknowledgement purposes only. 2810 [PRAKS02] Craig Partridge, Dennis Rockwell, Mark Allman, Rajesh 2811 Krishnan, James P.G. Sterbenz. A Swifter Start for TCP. Technical 2812 Report No. 8339, BBN Technologies, March 2002. URL 2813 "http://www.icir.org/mallman/papers/". 2815 [S02] Ion Stoica, private communication, 2002. Citation for 2816 acknowledgement purposes only. 2818 [SAF05] Pasi Sarolahti, Mark Allman, and Sally Floyd. Evaluating 2819 Quick-Start for TCP. Under submission, May 2005. URL 2820 "http://www.icir.org/floyd/quickstart.html". 2822 [SH02] Srikanth Sundarrajan and John Heidemann. Study of TCP Quick 2823 Start with NS-2. Class Project, December 2002. Not publically 2824 available; citation for acknowledgement purposes only. 2826 [W00] Michael Welzl: PTP: Better Feedback for Adaptive Distributed 2827 Multimedia Applications on the Internet, IPCCC 2000 (19th IEEE 2828 International Performance, Computing, And Communications 2829 Conference), Phoenix, Arizona, USA, 20-22 February 2000. URL 2830 "http://informatik.uibk.ac.at/users/c70370/research/publications/". 2832 [W03] Michael Welzl, PMTU-Options: Path MTU Discovery Using Options, 2833 expired internet-draft draft-welzl-pmtud-options-01.txt, work-in- 2834 progress. February 2003. 2836 [ZPS00] Y. Zhang, V. Paxson, and S. Shenker, The Stationarity of 2837 Internet Path Properties: Routing, Loss, and Throughput, ACIRI 2838 Technical Report, May 2000. 2840 IANA Considerations 2842 Quick-Start requires an IP Option and a TCP Option. 2844 IP Option 2846 Quick-Start requires an IP Option Number to be allocated. The IP 2847 Option would have a copied flag of 0, a class field of 00, and the 2848 assigned five-bit option number. The name of the option would be 2849 "QSR - Quick-Start Request", with this document as the reference 2850 document. 2852 TCP Option 2854 Quick-Start also requires that a TCP Option Number be allocated. 2855 The Length would be 4, and the Meaning would be "Quick-Start 2856 Request", with this document as the reference document. 2858 AUTHORS' ADDRESSES 2860 Amit Jain 2861 F5 Networks 2862 Email : a.jain@f5.com 2864 Sally Floyd 2865 Phone: +1 (510) 666-2989 2866 ICIR (ICSI Center for Internet Research) 2867 Email: floyd@icir.org 2868 URL: http://www.icir.org/floyd/ 2870 Mark Allman 2871 ICSI Center for Internet Research 2872 1947 Center Street, Suite 600 2873 Berkeley, CA 94704-1198 2874 Phone: (440) 243-7361 2875 Email: mallman@icir.org 2876 URL: http://www.icir.org/mallman/ 2878 Pasi Sarolahti 2879 Nokia Research Center 2880 P.O. Box 407 2881 FI-00045 NOKIA GROUP 2882 Finland 2883 Phone: +358 50 4876607 2884 Email: pasi.sarolahti@iki.fi 2886 Full Copyright Statement 2888 Copyright (C) The Internet Society 2005. This document is subject 2889 to the rights, licenses and restrictions contained in BCP 78, and 2890 except as set forth therein, the authors retain all their rights. 2892 This document and the information contained herein are provided on 2893 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2894 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2895 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2896 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2897 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2900 Intellectual Property 2902 The IETF takes no position regarding the validity or scope of any 2903 Intellectual Property Rights or other rights that might be claimed 2904 to pertain to the implementation or use of the technology described 2905 in this document or the extent to which any license under such 2906 rights might or might not be available; nor does it represent that 2907 it has made any independent effort to identify any such rights. 2908 Information on the procedures with respect to rights in RFC 2909 documents can be found in BCP 78 and BCP 79. 2911 Copies of IPR disclosures made to the IETF Secretariat and any 2912 assurances of licenses to be made available, or the result of an 2913 attempt made to obtain a general license or permission for the use 2914 of such proprietary rights by implementers or users of this 2915 specification can be obtained from the IETF on-line IPR repository 2916 at http://www.ietf.org/ipr. 2918 The IETF invites any interested party to bring to its attention any 2919 copyrights, patents or patent applications, or other proprietary 2920 rights that may cover technology that may be required to implement 2921 this standard. Please address the information to the IETF at ietf- 2922 ipr@ietf.org.