idnits 2.17.1 draft-ietf-dccp-quickstart-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DCCP Working Group G. Fairhurst 2 Internet-Draft A. Sathiaseelan 3 Intended status: Experimental University of Aberdeen 4 Expires: November 31, 2009 6 Intended status: Experimental 03 June, 2009 8 Quick-Start for Datagram Congestion Control Protocol (DCCP) 9 draft-ietf-dccp-quickstart-05.txt 11 Status of this Draft 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 31, 2009. 34 Abstract 36 This document specifies the use of the Quick-Start mechanism by the 37 Datagram Congestion Control Protocol (DCCP). DCCP is a transport 38 protocol that allows the transmission of congestion-controlled, 39 unreliable datagrams. DCCP is intended for applications such as 40 streaming media, Internet telephony, and on-line games. In DCCP, an 41 application has a choice of congestion control mechanisms, each 42 specified by a Congestion Control Identifier (CCID). This document 43 specifies general procedures applicable to all DCCP CCIDs and 44 specific procedures for the use of Quick-Start with DCCP CCID 2, 45 CCID 3 and CCID 4. Quick-Start enables a DCCP sender to cooperate 46 with Quick-Start routers along the end-to-end path to determine an 47 allowed sending rate at the start of a connection and, at times, in 48 the middle of a DCCP connection (e.g., after an idle or application- 49 limited period). The present specification is provided for use in 50 controlled environments, and not as a mechanism that would be 51 intended or appropriate for ubiquitous deployment in the global 52 Internet. 54 Table of Contents 56 1. Introduction 57 1.1 Terminology 59 2. Quick-Start for DCCP 60 2.1 Sending a Quick-Start Request for a DCCP flow 61 2.1.1 The Quick-Start Interval 62 2.2 Receiving a Quick-Start Request for a DCCP flow 63 2.2.1 The Quick-Start Response Option 64 2.3 Receiving a Quick-Start Response 65 2.3.1 The Quick-Start Mode 66 2.3.2 The Quick-Start Validation Phase 67 2.4 Procedure when no response to a Quick-Start Request 68 2.5 Procedure when a Quick-Start Packet is dropped 69 2.6 Interactions with Mobility and Signalled Path Changes 70 2.7 Interactions with Path MTU Discovery 71 2.8 Interactions with Middle boxes 72 3. Mechanisms for Specific CCIDs 73 3.1 Quick-Start for CCID 2 74 3.1.1 The Quick-Start Request for CCID 2 75 3.1.2 Sending a Quick-Start Response with CCID 2 76 3.1.3 Using the Quick-Start Response with CCID 2 77 3.1.4 Quick-Start Validation Phase for CCID 2 78 3.1.5 Reported loss or congestion while using Quick-Start 79 3.1.6 CCID 2 Feedback Traffic on the Reverse Path 80 3.2 Quick-Start for CCID 3 81 3.2.1 The Quick-Start Request for CCID 3 82 3.2.2 Sending a Quick-Start Response with CCID 3 83 3.2.3 Using the Quick-Start Response with CCID 3 84 3.2.4 Quick-Start Validation Phase for CCID 3 85 3.2.5 Reported loss during Quick-Start Mode or Validation Phase 86 3.2.6 CCID 3 Feedback Traffic on the Reverse Path 87 3.3 Quick-Start for CCID 4 88 3.3.1 The Quick-Start Request for CCID 4 89 3.3.2 Sending a Quick-Start Response with CCID 4 90 3.3.3 Using the Quick-Start Response with CCID 4 91 3.3.4 Reported loss or congestion while using Quick-Start 92 3.3.5 CCID 4 Feedback Traffic on the Reverse Path 93 4. Discussion of Issues 94 4.1 Over-run and the Quick-Start Validation Phase 95 4.2 Experimental Status 96 5. IANA Considerations 97 6. Acknowledgments 98 7. Security Considerations 99 8. References 100 8.1 Normative References 101 8.2 Informative References 102 9. Authors' Addresses 103 10. IPR Notices 104 10.1 Intellectual Property Statement 105 10.2 Disclaimer of Validity 106 11. Copyright Statement 107 1. Introduction 109 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 110 transport protocol for congestion-controlled, unreliable datagrams, 111 intended for applications such as streaming media, Internet 112 telephony, and on-line games. 114 In DCCP, an application has a choice of congestion control 115 mechanisms, each specified by a Congestion Control Identifier (CCID) 116 [RFC4340]. There are general procedures applicable to all DCCP CCIDs 117 that are described in Section 2, and details that relate to how 118 individual CCIDs should operate, which are described in Section 3. 119 This separation of CCID-specific and DCCP general functions is in 120 the spirit of the modular approach adopted by DCCP. 122 Quick-Start [RFC4782] is an Experimental mechanism for transport 123 protocols specified for use in controlled environments. The current 124 specification of this mechanism is not intended or appropriate for 125 ubiquitous deployment in the global Internet. 127 Quick-Start is designed for use between end hosts within the same 128 network or on Internet paths that include IP routers. It works in 129 cooperation with routers, allowing a sender to determine an allowed 130 sending rate at the start and at times in the middle of a data 131 transfer (e.g., after an idle or application-limited period). 133 This document assumes the reader is familiar with RFC4782 [RFC4782], 134 which specifies the use of Quick-Start with IP and with TCP. Section 135 7 of RFC4782 also provides guidelines for the use of Quick-Start 136 with other transport protocols, including DCCP. This document 137 provides answers to some of the issues that were raised by RFC4782 138 and provides a definition of how Quick-Start must be used with DCCP. 140 In using Quick-Start, the sending DCCP end host indicates the 141 desired sending rate in bytes per second, using a Quick-Start option 142 in the IP header of a DCCP packet. Each Quick-Start capable router 143 along the path could, in turn, either approve the requested rate, 144 reduce the requested rate, or indicate that the Quick-Start Request 145 is not approved. 147 If the Quick-Start Request is approved (possibly with a reduced 148 rate) by all the routers along the path, then the DCCP receiver 149 returns an appropriate Quick-Start Response. On receipt of this, the 150 sending end host can send at up to the approved rate for a period 151 determined by the method specified for each DCCP CCID, and not 152 exceeding three round-trip times. Subsequent transmissions will be 153 governed by the default CCID congestion control mechanisms for the 154 connection. If the Quick-Start Request is not approved, then the 155 sender must use the default congestion control mechanisms. 157 DCCP receivers are not required to acknowledge individual packets 158 (or pairs of segments) as in TCP. CCID 2 [RFC4341] allows much less 159 frequent feedback. Rate-based protocols (e.g. TFRC [RFC5348], CCID 3 161 [RFC4342]) have a different feedback mechanism than that of TCP. 162 With rate-based protocols, feedback may be sent less frequently 163 (e.g. once per RTT). In such cases, a sender using Quick-Start needs 164 to implement a different mechanism to determine whether the Quick- 165 Start sending rate has been sustained by the network. This 166 introduces a new mechanism called the Quick-Start Validation Phase 167 (Section 2.5). 169 In addition, this document defines two more general enhancements 170 that refine the use of Quick-Start after a flow has started 171 (expected to be more common in applications using DCCP). These are 172 the Quick-Start Interval (Section 2.2), and the reaction to mobility 173 triggers (Section 2.7). 175 1.1 Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 2. Quick-Start for DCCP 183 Unless otherwise specified, DCCP end hosts follow the procedures 184 specified in Section 4 of [RFC4782], following the use specified for 185 Quick-Start with TCP. 187 2.1 Sending a Quick-Start Request for a DCCP flow 189 A DCCP sender MAY use a Quick-Start Request during the start of a 190 connection, when the sender would prefer to have a larger initial 191 rate than allowed by standard mechanisms (e.g. [RFC5348] or 192 [RFC3390]). 194 A Quick-Start Request MAY also be used once a DCCP flow is connected 195 (i.e., in the middle of a DCCP flow). In standard operation, DCCP 196 CCIDs can constrain the sending rate (or window) to less than that 197 desired (e.g. when an application increases the rate at which it 198 wishes to send). A DCCP sender that has data to send after an idle 199 period or application-limited period (i.e. where the sender has 200 transmitted at less than the allowed sending rate) can send a Quick- 201 Start Request using the procedures defined in Section 3. 203 Quick-Start Requests will be more effective if the Quick-Start Rate 204 is not larger than necessary. Each requested Quick-Start Rate that 205 has been approved, but was not fully utilized, takes away from the 206 bandwidth pool maintained by Quick-Start routers that would be 207 otherwise available for granting successive requests [RFC4782]. 209 In contrast to most TCP applications, many DCCP applications have 210 the notion of a natural media rate that they wish to achieve. For 211 example, during the initial connection, a host may request a Quick- 212 Start Rate equal to the media rate of the application, appropriately 213 increased to account for the size of packet headers. (Note that 214 Quick-Start only provides a course-grain indication of the 215 desired rate that is expected to be sent in the next RTT.) 217 When sending a Quick-Start Request, the DCCP sender SHOULD send the 218 Quick-Start Request using a packet that requires an acknowledgement, 219 such as a DCCP-Request, DCCP-Response, or DCCP-Data. 221 2.1.1 The Quick-Start Interval 223 Excessive use of the Quick-Start mechanism is undesirable. This 224 document defines an enhancement to RFC4782 to update the use of 225 Quick-Start after a DCCP flow has started, by introducing the 226 concept of the Quick-Start Interval. The Quick-Start Interval 227 specifies a period of time during which a Quick-Start Request SHOULD 228 NOT be sent. The Quick-Start Interval is measured from the time of 229 transmission of the previous Quick-Start Request (section 2.1). The 230 Quick-Start Interval MAY be overridden as a result of a network path 231 change (section 2.6). 233 When a connection is established, the Quick-Start Interval is 234 initialized to the Initial_QSI. The Initial_QSI MUST be at least 6 235 Seconds (larger values are permitted). This value was chosen so that 236 it is sufficiently large to prevent excessive router processing over 237 typical Internet paths. Quick-Start routers that track per-flow 238 state MAY penalise senders by suspending Quick-Start processing of 239 flows that make Quick-Start Requests for the same flow with an 240 interval less than 6 seconds. 242 When the first Quick-Start Request is sent, the Quick-Start Interval 243 is set to: 245 Quick-Start Interval = Initial_QSI; 247 After sending each subsequent Quick-Start Request, the Quick-Start 248 Interval is then recalculated as: 250 Quick-Start Interval = max(Quick-Start Interval *2, 4*RTT); 252 Each unsuccessful Quick-Start Request therefore results in the 253 Quick-Start Interval being doubled (resulting in an exponential 254 back-off). The maximum time the sender can back-off is 64 seconds. 255 When the back-off calculation results in a larger value, the sender 256 MUST NOT send any further Quick-Start Requests for the remainder of 257 the DCCP connection (i.e. the sender ceases to use Quick-Start). 259 Whenever a Quick-Start Request is approved (at any rate), the Quick- 260 Start Interval is reset to the Initial_QSI. 262 2.2 Receiving a Quick-Start Request for a DCCP flow 264 The procedure for processing a received Quick-Start Request is 265 normatively defined in [RFC4782] and summarised in this paragraph. 266 An end host that receives an IP packet containing a Quick-Start 267 Request passes the Quick-Start Request, along with the value in the 268 IP TTL field, to the receiving DCCP layer. If the receiving host is 269 willing to permit the Quick-Start Request, it SHOULD respond 270 immediately by sending a packet that carries the Quick-Start 271 Response option in the DCCP header of the corresponding feedback 272 packet (e.g. using a DCCP-Ack packet or in a DCCP-DataAck packet). 274 The Rate Request field in the Quick-Start Response option is set to 275 the received value of the Rate Request in the Quick-Start option or 276 to a lower value if the DCCP receiver is only willing to allow a 277 lower Rate Request. Where information is available (e.g. knowledge 278 of the local layer 2 interface speed), a Quick-Start receiver SHOULD 279 verify that the received rate does not exceed its expected receive 280 link capacity. The TTL Diff field in the Quick-Start Response is set 281 to the difference between the received IP TTL value (Hop Limit field 282 in IPv6) and the Quick-Start TTL value. The Quick-Start Nonce in 283 the Response is set to the received value of the Quick-Start Nonce 284 in the Quick-Start option (or IPv6 Header Extension). 286 The Quick-Start Response MUST NOT be resent if it is lost in the 287 network [RFC4782]. Packet loss could be an indication of congestion 288 on the return path, in which case it is better not to approve the 289 Quick-Start Request. 291 If an end host receives an IP packet with a Quick-Start Request with 292 a requested rate of zero, then this host SHOULD NOT send a Quick- 293 Start Response [RFC4782]. 295 2.2.1 The Quick-Start Response Option 297 The Quick-Start Response message must be carried by the transport 298 protocol using Quick-Start. This section defines a DCCP Header 299 option used to carry the Quick-Start Response. This header option is 300 REQUIRED for end hosts to utilise the Quick-Start mechanism with 301 DCCP flows. The format resembles that defined for TCP [RFC4782]. 303 0 1 2 3 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type=xQSOx | Length=8 | Resv. | Rate | TTL Diff | 307 | | | |Request| | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Quick-Start Nonce | R | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Figure 1. The Quick-Start Response option. 314 ### IANA ACTION, PLEASE REPLACE xQSOx with the assigned value in the 315 figure above.### 317 ### IANA ACTION, PLEASE ALSO REPLACE xQSOx with the assigned value 318 in the paragraph below.### 320 The first byte of the Quick-Start Response option contains the 321 option kind, identifying the DCCP option (xQSOx). 323 The second byte of the Quick-Start Response option contains the 324 option length in bytes. The length field MUST be set to 8 bytes. 326 The third byte of the Quick-Start Response option contains a four- 327 bit Reserved field, and the four-bit allowed Rate Request, formatted 328 as in the IP Quick-Start Rate Request option [RFC4782]. 330 The fourth byte of the DCCP Quick-Start Response option contains the 331 TTL Diff. The TTL Diff contains the difference between the IP TTL 332 and Quick-Start TTL fields in the received Quick-Start Request 333 packet, as calculated in [RFC4782]. 335 Bytes 5-8 of the DCCP option contain the 30-bit Quick-Start Nonce 336 and a two-bit Reserved field [RFC4782]. 338 2.3 Receiving a Quick-Start Response 340 On reception of a Quick-Start Response packet, the sender MUST 341 report the approved rate, by sending a Quick-Start Report of 342 Approved Rate [RFC4782]. This report includes the Rate Report field 343 set to the Approved Rate, and the QS Nonce set to the QS Nonce value 344 sent in the Quick-Start Request. 346 The Quick-Start Report of Approved Rate is sent as an IPv4 option or 347 IPv6 header extension using the first Quick-Start Packet or sent as 348 an option using a DCCP control packet if there are no DCCP-Data 349 packets pending transmission. 351 The Quick-Start Interval is also reset (as described in section 352 2.1.1). 354 Reception of a Quick-Start Response packet that approves a rate 355 higher than the current rate results in the sender entering the 356 Quick-Start Mode. 358 2.3.1 The Quick-Start Mode 360 While a sender is in the Quick-Start Mode, all sent packets are 361 known as Quick-Start Packets [RFC4782]. The Quick-Start Packets MUST 362 be sent at a rate not greater than the rate specified in the Quick- 363 Start Response. The Quick-Start Mode continues for a period up to 364 one RTT (shorter, if a feedback message arrives acknowledging the 365 receipt of one or more Quick-Start Packets). 367 The procedure following exit of the Quick-Start Mode is specified in 368 the following paragraphs. Note that this behaviour is CCID-specific 369 and the details for each current CCID are described in Section 3. 371 2.3.2 The Quick-Start Validation Phase 373 After transmitting a set of Quick-Start Packets in the Quick-Start 374 Mode (and providing that no loss or congestion is reported), the 375 sender enters the Quick-Start Validation Phase. This phase persists 376 for a period during which the sender seeks to affirm that the 377 capacity used by the Quick-Start Packets did not introduce 378 congestion. This phase is introduced, because unlike TCP, DCCP 379 senders do not necessarily receive frequent feedback that would 380 indicate the congestion state of the forward path. 382 While in the Quick-Start Validation Phase, the sender is tentatively 383 permitted to continue sending using the Quick-Start rate. This phase 384 normally concludes when the sender receives feedback that includes 385 an acknowledgment that all Quick-Start Packets were received. 387 However, the duration of the Quick-Start Validation Phase MUST NOT 388 exceed the Quick-Start Validation Time (a maximum of 2 RTTs). 389 Implementations may set a timer (initialised to the Quick-Start 390 Validation Time) to detect the end of this phase. There may be scope 391 for optimisation of timer resources in an implementation, since the 392 Quick-Start Validation period temporarily enforces more strict 393 monitoring of acknowledgements than normally used in a CCID (e.g. an 394 implementation may consider using a common timer resource for Quick- 395 Start Validation and a nofeedback timer)._ 397 An example sequence of packet exchanges showing Quick-Start with 398 DCCP is shown in Figure 2. 400 DCCP Sender DCCP Receiver 401 Quick-Start +----------------------------------------------+ 402 Request/Response | Quick-Start Request --> | 403 | <-- Quick-Start Response | 404 | Quick-Start Approve --> | 405 +----------------------------------------------+ 406 +----------------------------------------------+ 407 Quick-Start | Quick-Start Packets --> | 408 Mode | Quick-Start Packets --> | 409 | <-- Feedback A from Receiver| 410 | (acknowledging first QS Packet)| 411 +----------------------------------------------+ 412 +---------------------------------------------- 413 Quick-Start | Packets --> | 414 Validation Phase | <-- Feedback B from Receiver| 415 | (acknowledging all QS Packets)| 416 +---------------------------------------------- 417 +----------------------------------------------+ 418 DCCP | Packets --> | 419 Congestion | <-- Feedback C from Receiver| 420 Control | | 422 Figure 2. The Quick-Start Mode and Validation Phase. 424 On conclusion of the Validation Phase (Feedback B in the above 425 figure), the sender expects to receive assurance that it may safely 426 use the current rate. A sender that completes the Quick-Start 427 Validation Phase with no reported packet loss or congestion stops 428 using the Quick-Start rate and continues to adjust its rate using 429 the standard congestion control mechanisms. For example, if the 430 DCCP sender was in slow-start prior to the Quick-Start Request, and 431 no packets were lost or ECN marked since that time, then the sender 432 continues in slow-start after exiting Quick-Start Mode until the 433 sender sees a packet loss, or congestion is reported. 435 2.4 Procedure when no response to a Quick-Start Request 437 As in TCP, if a Quick-Start Request is dropped (i.e., the Request or 438 Response is not delivered by the network) the DCCP sender MUST 439 revert to the congestion control mechanisms it would have used if 440 the Quick-Start Request had not been approved. The connection is not 441 permitted to send a subsequent Quick-Start Request before expiry of 442 the current Quick-Start Interval (section 2.1.1). 444 2.5 Procedure when a packet is dropped while using Quick-Start 446 A lost or ECN-marked packet is an indication of potential network 447 congestion. The behaviour of a DCCP sender following a lost or ECN- 448 marked Quick-Start Packet or a lost feedback packet is specific to a 449 particular CCID (see section 3). 451 2.6 Interactions with Mobility and Signalled Path Changes 453 The use of Quick-Start may assist end hosts in determining when it 454 is appropriate to increase their rate following an explicitly 455 signalled change of the network path. 457 When an end host receives a signal from an upstream link/network 458 notifying it of a path change, the change could simultaneously 459 impact more than one flow, and may affect flows between multiple 460 endpoints. Senders should avoid responding immediately, since this 461 could result in unwanted synchronisation of signalling messages, and 462 control loops (e.g. a synchronised attempt to probe for a larger 463 congestion window), which may negatively impact the performance of 464 the network and transport sessions. In Quick-Start, this could 465 increase the rate of Quick-Start Requests, possibly incurring 466 additional router load, and may result in some requests not being 467 granted. A sender must ensure this does not generate an excessive 468 rate of Quick-Start Requests by using the method below: 470 A sender that has explicit information that the network path has 471 changed (e.g. a mobile IP binding update [RFC3344], [RFC3775]) 472 SHOULD reset the Quick-Start Interval to its initial value 473 (specified in section 2.1). 475 The sender MAY also send a Quick-Start Request to determine a new 476 safe transmission rate, but must observe the following rules: 478 . It MUST NOT send a Quick-Start Request within a period less 479 than the initial Quick-Start Interval (Initial_QSI) since it 480 previously sent a Quick-Start Request. That is, it must wait 481 for at least a period of Initial_QSI after the previous 482 request, before sending a new Quick-Start Request. 484 . If it has not sent a Quick-Start Request within the previous 485 Initial_QSI period, it SHOULD defer sending a Quick-Start 486 Request for a randomly chosen period between 0 and the 487 Initial_QSI value in seconds. The random period should be 488 statistically independent between different hosts and between 489 different connections on the same host. This delay is to 490 mitigate the effect on router load of synchronised responses by 491 multiple connections in response to a path change that affects 492 multiple connections. 494 Hosts do not generally have sufficient information to choose an 495 appropriate randomisation interval. This value was selected to 496 ensure randomisation of requests over the Quick-Start Interval. In 497 networks where a large number of senders may potentially be impacted 498 by the same signal, a larger value may be desirable (or methods may 499 be used to control this effect in the path change signalling). 501 2.7 Interactions with Path MTU Discovery 503 DCCP implementations are encouraged to support Path MTU Discovery 504 (PMTUD) when applications are able to use a DCCP packet size that 505 exceeds the default Path MTU [RFC4340], [RFC4821]. Quick-Start 506 Requests SHOULD NOT be sent with packets that are used as a PMTUD 507 Probe Packet, since these packets could be lost in the network 508 increasing the probability of loss of the request. It may therefore 509 be preferable to separately negotiate the PMTU and the use of Quick- 510 Start. 512 The DCCP protocol is datagram-based and therefore the size of the 513 segments that are sent is a function of application behaviour as 514 well as being constrained by the largest supported Path MTU. 516 2.8 Interactions with Middle boxes 518 A Quick-Start Request is carried in an IPv4 packet option or IPv6 519 extension header [RFC4782]. Interactions with network devices 520 (middle boxes) that inspect or modify IP options could therefore 521 lead to discard, ICMP error, or DCCP-Reset when attempting to 522 forward packets carrying a Quick-Start Request. 524 If a DCCP sender sends a DCCP-Request that also carries a Quick- 525 Start Request, and does not receive a DCCP-Response to the packet, 526 the DCCP sender SHOULD resend the DCCP-Request packet without 527 including a Quick-Start Request. 529 Similarly, if a DCCP sender receives a DCCP-Reset in response to a 530 DCCP-Request packet that also carries a Quick-Start Request, then 531 the DCCP sender SHOULD resend DCCP-Request packet without the 532 Quick-Start Request. The DCCP sender then ceases to use the Quick- 533 Start Mechanism for the remainder of the connection. 535 A DCCP sender that uses a Quick-Start Request within an established 536 connection and does not receive a response will treat this as non- 537 approval of the request. Successive unsuccessful attempts will 538 result in an exponential increase in the Quick-Start Interval 539 (section 2.2). If this grows to a value exceeding 64 seconds the 540 DCCP sender ceases to use the Quick-Start Mechanism for the 541 remainder of the connection. 543 3. Mechanisms for Specific CCIDs 545 The following sections specify the use of Quick-Start with DCCP CCID 546 2, CCID 3, and for DCCP with TFRC-SP (as proposed for CCID 4). 548 3.1 Quick-Start for CCID 2 550 This section describes the Quick-Start mechanism to be used with 551 DCCP CCID 2 [RFC4341]. CCID 2 uses a TCP-like congestion control 552 mechanism. 554 3.1.1 The Quick-Start Request for CCID 2 556 A Quick-Start Request MAY be sent to allow the sender to determine 557 if it is safe to use a larger initial cwnd. This permits a faster 558 start-up of a new CCID 2 flow. 560 A Quick-Start Request MAY also be sent for an established connection 561 to request a higher sending rate after an idle period or 562 application-limited period (described in section 2.1). This allows a 563 receiver to use a larger cwnd than allowed with standard operation. 565 A Quick-Start Request that follows a reported loss or congestion 566 event MUST NOT request a Quick-Start rate that exceeds the largest 567 congestion window achieved by the CCID 2 connection since the last 568 packet drop (translated to a sending rate). 570 3.1.2 Sending a Quick-Start Response with CCID 2 572 A receiver processing a Quick-Start Request uses the method 573 described in Section 2.3. On receipt of a Quick-Start Request, the 574 receiver MUST send a Quick-Start Response (even if a receiver is 575 constrained by the ACK Ratio). 577 3.1.3 Using the Quick-Start Response with CCID 2 579 On receipt of a valid Quick-Start Response option, the sender MUST 580 send a Quick-Start Approved option [RFC4782] (see Section 2.3). 582 If the approved Quick-Start rate is less than current sending rate, 583 the sender does not enter the Quick-Start Mode, and continues using 584 the procedure defined in CCID 2. 586 If the approved Quick-Start rate at the sender exceeds the current 587 sending rate, the sender enters the Quick-Start Mode and continues 588 in the Quick-Start Mode for a maximum period of 1 RTT. 590 The sender sets its Quick-Start cwnd (QS_cwnd) as follows: 592 QS_cwnd = (R * T) / (s + H) (1) 593 where R is the Rate Request in bytes per second, T is the measured 594 round-trip path delay (RTT), s is the packet size, and H is the 595 estimated DCCP/IP header size in bytes (e.g., 32 bytes for DCCP 596 layered directly over IPv4, but larger when using IPsec or IPv6). 598 A CCID 2 sender MAY then increase its cwnd to the QS_cwnd. The cwnd 599 should not be reduced (i.e., a QS_cwnd lower than cwnd should be 600 ignored, since the CCID 2 congestion control method already permits 601 this rate). CCID 2 is not a rate-paced protocol. Therefore, if the 602 QS_cwnd is used, the sending host MUST implement a suitable method 603 to pace the rate at which the Quick-Start Packets are sent until it 604 receives a DCCP-ACK for a packet sent during the Quick-Start Mode 605 [RFC4782]. The sending host SHOULD also record the previous cwnd and 606 note that the new cwnd has been determined by Quick-Start, rather by 607 other means (e.g. by setting a flag to indicate that it is in Quick- 608 Start Mode). 610 When the sender receives the first DCCP-ACK to a packet sent in the 611 Quick-Start Mode, it leaves the Quick-Start Mode and enters the 612 Validation Phase. 614 3.1.4 Quick-Start Validation Phase for CCID 2 616 A CCID 2 sender MAY continue to send at the paced Quick-Start Rate 617 while in the Validation Phase. It leaves the Validation Phase on 618 receipt of an ACK that acknowledges the last Quick-Start Packet, or 619 if the validation phase persists for a period that exceeds the 620 Quick-Start Validation Time of 1 RTT. It MUST then reduce the cwnd 621 to the actual flight size (the current amount of unacknowledged data 622 sent) [RFC4782], and uses the congestion control methods specified 623 for CCID 2. 625 3.1.5 Reported loss or congestion while using Quick-Start 627 A sender in the Quick-Start Mode (or Validation Phase) that detects 628 congestion (e.g. receives a feedback packet that reports new packet 629 loss or a packet with a congestion marking), MUST immediately leave 630 the Quick-Start Mode (or Validation Phase). It then resets the cwnd 631 to half the recorded previous cwnd and enters the congestion 632 avoidance phase described in [RFC4341]. 634 In the absence of any feedback at the end of the Validation period, 635 the sender resets the cwnd to half the recorded previous cwnd and 636 enters the congestion avoidance phase. 638 3.1.6 CCID 2 Feedback Traffic on the Reverse Path 640 A CCID 2 receiver sends feedback for groups of received packets 641 [RFC4341]. Approval of a higher transmission rate using Quick-Start 642 will increase control traffic on the reverse path. A return path 643 that becomes congested could have a transient negative impact on 644 other traffic flows sharing the return link. The lower rate of 645 feedback will then limit the achievable rate in the forward 646 direction. 648 3.2 Quick-Start for CCID 3 650 This section describes the Quick-Start mechanism to be used with 651 DCCP CCID 3 [RFC4342]. The rate-based congestion control mechanism 652 used by CCID 3 leads to specific issues that are addressed by Quick- 653 Start in this section. 655 3.2.1 The Quick-Start Request for CCID 3 657 A Quick-Start Request MAY be sent to allow the sender to determine 658 if it is safe to use a larger initial sending rate. This permits a 659 faster start-up of a new CCID 3 flow. 661 A Quick-Start Request MAY also be sent to request a higher sending 662 rate after an idle period (in which the nofeedback timer expires 663 [RFC5348]) or an application-limited period (described in section 664 2.1). This allows a receiver to increase the sending rate faster 665 than allowed with standard operation (i.e. faster than twice the 666 rate reported by a CCID 3 receiver in the most recent feedback 667 message). 669 The requested rate specified in a Quick-Start Request MUST NOT 670 exceed the TFRC-controlled sending rate [RFC4342] when this is 671 bounded by the current loss event rate (if any), either from 672 calculation at the sender or from feedback received from the 673 receiver. CCID 3 considers this rate is a safe response in the 674 presence of expected congestion. 676 3.2.2 Sending a Quick-Start Response with CCID 3 678 When processing a received Quick-Start Request, the receiver uses 679 the method described in Section 2.3. In addition, if a CCID 3 680 receiver uses the window counter to send periodic feedback messages, 681 then the receiver sets its local variable last_counter to the value 682 of the window counter reported by the segment containing the Quick- 683 Start Request. The next feedback message would then be sent when the 684 window_counter is greater or equal to last_counter + 4. If the CCID 685 3 receiver uses a feedback timer to send period feedback messages, 686 then the DCCP receiver MUST reset the CCID 3 feedback timer, causing 687 the feedback to be sent as soon as possible. This helps to align the 688 timing of feedback to the start and end of the period in which 689 Quick-Start Packets are sent, and will normally result in feedback 690 at a time that is approximately the end of the period when Quick- 691 Start Packets are received. 693 3.2.3 Using the Quick-Start Response with CCID 3 695 On receipt of a valid Quick-Start Response option, the sender MUST 696 send a Quick-Start Approved option [RFC4782] (see Section 2.3). 698 If the approved Quick-Start rate is greater than the current sending 699 rate, the sender enters the Quick-Start Mode, otherwise it does not 700 enter the Quick-Start Mode and continues using the procedure defined 701 in CCID 3. 703 If loss or congestion is reported after sending the Quick-Start 704 Request, the sender also does not enter the Quick-Start Mode and 705 continues using the procedure defined in CCID 3. 707 If the approved Quick-Start rate exceeds the current sending rate, 708 the sender enters the Quick-Start Mode and continues in the Quick- 709 Start Mode for a maximum period of 1 RTT. The sender sets its Quick- 710 Start sending rate (QS_sendrate) as follows: 712 QS_sendrate = R * s/(s + H); (2) 714 where R the Rate Request in bytes per second, s is the packet size 715 [RFC4342], and H the estimated DCCP/IP header size in bytes (e.g., 716 32 bytes for IPv4). A CCID 3 host MAY then increase its sending rate 717 to the QS_sendrate. The rate should not be reduced. 719 CCID 3 is a rate-paced protocol. Therefore, if the QS_sendrate is 720 used, the sending host MUST pace the rate at which the Quick-Start 721 Packets are sent over the next RTT. The sending host SHOULD also 722 record the previous congestion-controlled rate and note that the new 723 rate has been determined by Quick-Start rather by other means (e.g. 724 by setting a flag to indicate that it is in the Quick-Start Mode). 726 The sender exits the Quick-Start Mode after either: 728 * Receipt of a feedback packet acknowledging one or more Quick-Start 729 Packets, 730 * A period of 1 RTT after receipt of a Quick-Start Response, 731 or 732 * Detection of a loss or congestion event (see Section 3.2.5). 734 3.2.4 Quick-Start Validation Phase for CCID 3 736 After transmitting a set of Quick-Start Packets in the Quick Start 737 Mode (and providing that no loss or congestion marking is reported), 738 the sender enters the Quick-Start Validation Phase. A sender that 739 receives feedback that reports a loss or congestion event MUST 740 follow the procedures described in Section 3.2.5. 742 The sender MUST exit the Quick-Start Validation Phase on receipt of 743 feedback that acknowledges all packets sent in the Quick-Start Mode 744 (i.e. all Quick-Start Packets) or if the Validation Phase persists 745 for a period that exceeds the Quick-Start Validation Time of two 746 RTTs. 748 A sender that completes the Quick-Start Validation Phase with no 749 reported packet loss or congestion stops using the QS_sendrate and 750 MUST recalculate a suitable sending rate using the standard 751 congestion control mechanisms [RFC4342]. 753 If no feedback is received within the Quick-Start Validation Phase, 754 the sender MUST return to the minimum of the recorded original rate 755 (at the start of the Quick-Start Mode) and one half of the 756 QS_sendrate. The nofeedback timer is also reset. 758 3.2.5 Reported loss or congestion during the Quick-Start Mode or 759 Validation Phase 761 A sender in the Quick-Start Mode or Validation Phase that detects 762 congestion (e.g. receives a feedback packet that reports new packet 763 loss or a packet with a congestion marking) MUST immediately leave 764 the Quick-Start Mode or Validation Phase and enter the congestion 765 avoidance phase [RFC4342]. This implies re-calculating the sending 766 rate, X, as required by RFC4342: 768 X = max(min(X_calc, 2*X_recv), s/t_mbi); 770 where X_calc is the transmit rate calculated by the throughput 771 equation, X_recv is the reported receiver rate, s is the packet size 772 and t_mbi is the maximum backoff interval of 64 seconds. 774 The current specification of TFRC [RFC5348], which obsoletes RFC 775 3448, uses a set of X_recv values and uses the maximum of the set 776 during data-limited intervals. This calculates the sending rate, X 777 as: 779 X = max(min(X_calc, recv_limit),s/t_mbi); 781 where recv_limit could be max(X_recv_set) or 2*max(X_recv_set) 782 depending on whether there was a new loss event during a data- 783 limited interval, or no loss event during a data-limited interval 784 respectively. When the sender is not data-limited, the recv_limit is 785 set to 2*max(X_recv_set). 787 A sender using RFC4342 updated by [RFC5348], calculates the sending 788 rate, X, using the above formula normatively defined in [RFC5348]. 790 3.2.6 CCID 3 Feedback Traffic on the Reverse Path 792 A CCID 3 receiver sends feedback at least once each RTT [RFC4342]. 793 Use of Quick-Start is therefore not expected to significantly 794 increase control traffic on the reverse path. 796 3.3 Quick-Start for CCID 4 798 This section describes the Quick-Start mechanism to be used when 799 DCCP uses TFRC-SP [RFC4828] in place of TFRC [RFC5348], as specified 800 in CCID 4 [ID.CCID4]. CCID 4 is similar to CCID 3 except that a 801 sender using CCID 4 is limited to a maximum of 100 packets/second. 803 The Quick-Start procedure defined below therefore resembles that for 804 CCID 3. 806 3.3.1 The Quick-Start Request for CCID 4 808 The procedure for sending a Quick-Start Request using CCID 4 is the 809 same as for CCID 3, defined in section 3.2.1. In addition, the 810 requested rate MUST be less than or equal to the equivalent of a 811 sending rate of 100 packets per second [RFC4828 CCID 4 [RFC4828] 812 specifies that the allowed sending rate derived from the TCP 813 throughput equation is reduced by a factor that accounts for packet 814 header size. 816 3.3.2 Sending a Quick-Start Response with CCID 4 818 This procedure is the same as for CCID 3, defined in section 3.2.2. 820 3.3.3 Using the Quick-Start Response with CCID 4 822 This procedure is the same as for CCID 3, defined in sections 3.2.3, 823 3.2.4, and 3.2.5, except that the congestion control procedures is 824 updated to use TFRC-SP [RFC4828]. 826 A CCID 4 sender does not need to account for headers a second time 827 when translating the approved Quick-Start rate into an allowed 828 sending rate (as described in section 5 of [ID.CCID4]. 830 3.3.4 Reported loss or congestion while using Quick-Start 832 This procedure is the same as for CCID 3, defined in 3.2.5, except 833 that the congestion control procedures is updated to use TFRC-SP 834 [RFC4828]. 836 3.3.5 CCID 4 Feedback Traffic on the Reverse Path 838 A CCID 4 receiver sends feedback at least once each RTT. Use of 839 Quick-Start is therefore not expected to significantly increase 840 control traffic on the reverse path. 842 4. Discussion of Issues 844 The considerations for using Quick-Start with DCCP are not 845 significantly different to those for Quick-Start with TCP. The 846 document does not modify the router behaviour specified for Quick- 847 Start. 849 4.1 Over-run and the Quick-Start Validation Phase 851 The less frequent feedback of DCCP raises an issue in that a sender 852 using Quick-Start may continue to use the rate specified by a Quick- 853 Start Response for a period that exceeds one path round trip time 854 (i.e., that which TCP would have used). This over-run is a result of 855 the less frequent feedback interval used by DCCP (i.e., CCID 2 may 856 delay feedback by at most one half cwnd and CCID 3 and CCID 4 857 provide feedback at least once per RTT). In the method specified by 858 this document, the Quick-Start Validation Phase bounds this over-run 859 to be not more than an additional 2 RTTs. 861 The currently selected method is chosen as a compromise that 862 reflects the need to terminate quickly following the loss of a 863 feedback packet, and the need to allow sufficient time for end host 864 and router processing, as well as the different perceptions of the 865 path RTT held at the sender and receiver. Any reported loss or 866 congestion results in immediate action without waiting for 867 completion of the Quick-Start Validation period. 869 4.2 Experimental Status 871 There are many cases in which Quick-Start Requests would not be 872 approved [RFC4782]. These include communication over paths 873 containing routers, IP tunnels, MPLS paths, and the like, that do 874 not support Quick-Start. These cases also include paths with 875 routers or middleboxes that drop packets containing IP options (or 876 IPv6 extensions). Quick-Start Requests could be difficult to 877 approve over paths that include multi-access layer-two networks. 879 Transient effects could arise when the transport protocol packets 880 associated with a connection are multiplexed over multiple parallel 881 (sometimes known as alternative) links or network-layer paths, and 882 Quick-Start is used, since it will be effective on only one of the 883 paths, but could lead to increased traffic on all paths. 885 A CCID 2 sender using Quick-Start can increase the control traffic 886 on the reverse path, which could have a transient negative impact on 887 other traffic flows sharing the return link (section 3.1.5). The 888 lower rate of feedback will then limit the achievable rate in the 889 forward direction. 891 [RFC4782] also describes environments where the Quick-Start 892 mechanism could fail with false positives, with the sender 893 incorrectly assuming that the Quick-Start Request had been approved 894 by all of the routers along the path. As a result of these 895 concerns, and as a result of the difficulties and the seeming 896 absence of motivation for routers, such as core routers, to deploy 897 Quick-Start, Quick-Start has been proposed as a mechanism that could 898 be of use in controlled environments, and not as a mechanism that 899 would be intended or appropriate for ubiquitous deployment in the 900 global Internet. 902 Further experimentation would be required to confirm the deployment 903 of Quick-Start and to investigate performance issues that may arise, 904 prior to any recommendation for use over the general Internet. 906 5. IANA Considerations 908 This document requires IANA involvement for the assignment of a DCCP 909 Option Type from the DCCP Option Types Registry. This Option is 910 applicable to all CCIDs and is known as the "Quick-Start Response" 911 Option and is defined in Section 2.2.1. It specifies a length value 912 in the format used for options numbered 32-128. 914 6. Acknowledgments 916 The author gratefully acknowledges the previous work by Sally Floyd 917 to identify issues that impact Quick-Start for DCCP, and her 918 comments to improve this document. We also acknowledge comments and 919 corrections from Pasi Sarolahti, Vincent Roca, Mark Allman, Michael 920 Scharf, Sally Floyd, and others in the IETF DCCP WG. 922 7. Security Considerations 924 Security issues are discussed in [RFC4782]. Middlebox deployment 925 issues are also highlighted in section 2.9. No new security issues 926 are raised within this document. 928 8. References 930 8.1 Normative References 932 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, 1997. 935 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 936 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 938 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 939 Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion 940 Control", RFC 4341, March 2006. 942 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 943 Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: 944 TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. 946 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 947 Start for TCP and IP", RFC 4782, January 2007. 949 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 950 (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007. 952 [RFC5348] Floyd, S., Padhye, J., Widmer, J., "TCP Friendly Rate 953 Control (TFRC): Protocol Specification", RFC 5348, September 2008. 955 8.2 Informative References 957 [ID.CCID4] Floyd, S., Kohler, E., "Profile for Datagram Congestion 958 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control 959 for Small Packets (TFRC-SP)", IETF Work In Progress, 2007. 961 [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 962 3344, August 2002. 964 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 965 in IPv6", RFC 3775, June 2004. 967 [RFC3390] Allman, M., Floyd, S., Partridge, C., "Increasing TCP's 968 Initial Window", RFC 3390, October 2002. 970 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 971 Discovery", RFC 4821, March 2007. 973 9. Authors' Addresses 975 Godred Fairhurst 976 School of Engineering 977 University of Aberdeen 978 Aberdeen, AB24 3UE 979 Scotland, UK 980 Email: gorry@erg.abdn.ac.uk 981 URI: http://www.erg.abdn.ac.uk/users/gorry 983 Arjuna Sathiaseelan 984 School of Engineering 985 University of Aberdeen 986 Aberdeen, AB24 3UE 987 Scotland, UK 988 Email: arjuna@erg.abdn.ac.uk 989 URI: http://www.erg.abdn.ac.uk/users/arjuna 991 10. Copyright Notice 993 Copyright (c) 2009 IETF Trust and the persons identified as the 994 document authors. All rights reserved. 996 This document is subject to BCP 78 and the IETF Trust's Legal 997 Provisions Relating to IETF Documents in effect on the date of 998 publication of this document (http://trustee.ietf.org/license-info). 999 Please review these documents carefully, as they describe your 1000 rights and restrictions with respect to this document. 1002 This document may contain material from IETF Documents or IETF 1003 Contributions published or made publicly available before November 1004 10, 2008. The person(s) controlling the copyright in some of this 1005 material may not have granted the IETF Trust the right to allow 1006 modifications of such material outside the IETF Standards Process. 1007 Without obtaining an adequate license from the person(s) controlling 1008 the copyright in such materials, this document may not be modified 1009 outside the IETF Standards Process, and derivative works of it may 1010 not be created outside the IETF Standards Process, except to format 1011 it for publication as an RFC or to translate it into languages other 1012 than English. 1014 ------------------------------------------------------------------- 1016 [RFC EDITOR NOTE: 1017 This section must be deleted prior to publication] 1019 DOCUMENT HISTORY 1021 Individual Draft 00 1022 This is the first presentation of this document. 1024 Individual Draft 01 1025 This includes fixes for NiTs (thanks Pasi) 1026 It also includes a note on initial rates in 2.1 1027 All mention of packet loss now qualified with loss/congestion. 1028 It adds supports for CCID 2. 1029 It also defines the Quick-Start Interval as a way of controlling the 1030 rate at which hosts may issue Quick-Start requests. 1032 Individual Draft 02 - Draft intended for more general review 1033 Resolution of many minor outstanding editorial issues. 1034 Includes feedback on a longer Quick-Start period from Mark Allman. 1035 Includes new section on the interaction with middleboxes. 1036 CCID 2 and CCID 3 text now use the same style. 1037 Added description for CCID 4, based on CCID 3. 1038 Added clarification of PMTUD interaction. 1039 Reorganised to create a section on the QS Interval 1040 Rewritten sections on what to do after loss/congestion 1041 Clarified path change triggers (e.g. from mobility binding updates) 1042 There are no currently known remaining issues to be addressed. 1044 Individual Draft 03 1045 This includes fixes for NiTs, especially to shorten some parts of 1046 text. 1047 It includes some additional clarification based on the progress of 1048 RFC3448.bis. 1049 Replaced reference to Faster Restart. 1050 Change to paragraph on mobility usage. 1052 Working Group Draft 00 1053 Title change only. 1055 Working Group Draft 01 : Following WG feedback 1056 Issued following feedback on Quick-Start issues and various comments 1057 from Michael Scharf. CCID 2 feedback expected in 1.5 RTTs (allowing 1058 for less frequent ACKs). TFRC-SP is now cited in CCID 4 discussion. 1059 Included more on the rationale of the validation phase and the 1060 mobility trigger randomisation interval of 6 seconds. 1062 Note: This I-D must be Last-Called in both TSV and DCCP. 1064 Working Group Draft 02 1065 Clarified text on QS Interval. 1067 Harmonised the Quick-Start mode across all CCIDs. 1068 Introduced the concept of the Quick_Start Validation Phase for CCID 1069 2, as a counter to using a less frequent acknowledgment policy. This 1070 behavior is now similar to that of CCID 3 in this regard. 1071 A new subsection was added in Section 2 to describe the validation 1072 for all CCIDs. 1074 Working Group Draft 03 1075 This revision renumbered some sections to improve organisation. 1076 Revised ID following feedback from Vincent Roca. 1077 Revised ID following feedback from Sally Floyd. 1079 Working Group Draft 04 - based on Pasi's comments during WGLC 1081 The constant 6 seconds was replaced by the text constant 1082 Initital_QSI. 1084 QSPrev_Interval has been removed - to avoid the ambiguity concerning 1085 when to reset the value. 1087 The max(Initital_QSI..) term has been removed, since the value can 1088 never anyway be less than Initital_QSI, and the text now reflects 1089 this. 1091 The CCID 3 equations have been simplified, by removing a smaller 1092 term from a MIN(,) expression - again this value can not change the 1093 calculation. 1095 The QS Approve method was mentioned in section 2 for completeness. 1097 Working Group Draft 04 - based on Pasi's comments aftre WGLC 1099 Fixed section number ref in IANA section. 1101 Note: This I-D must be Last-Called in both TSV and DCCP. 1103 [END of RFC EDITOR NOTE]