idnits 2.17.1 draft-fairhurst-tsvwg-dccp-qs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 881. 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 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 (June 1, 2008) is 5806 days in the past. Is this intentional? -- 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 (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DCCP Working Group Gorry Fairhurst 3 Internet-Draft Arjuna Sathiaseelan 4 Intended status: Experimental University of Aberdeen 5 Expires: November 31, 2008 7 Intended status: Experimental June 1, 2008 9 Quick-Start for Datagram Congestion Control Protocol (DCCP) 10 draft-fairhurst-tsvwg-dccp-qs-03.txt 12 Status of this Draft 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 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, 2008. 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 and 45 CCID-3. Quick-Start enables a DCCP sender to cooperate with any 46 Quick-Start routers along the end-to-end path to determine an 47 allowed sending rate at the start and, at times, in the middle of a 48 DCCP connection (e.g., after an idle or application-limited period). 49 The present specification is provided for use in controlled 50 environments, and not as a mechanism that would be intended or 51 appropriate for ubiquitous deployment in the global Internet. 53 Table of Contents 55 1. Introduction 56 2. Quick-Start for DCCP 57 2.1 Sending a Quick-Start Request for a DCCP flow 58 2.2 The Quick-Start Interval 59 2.3 Receiving a Quick-Start Request for a DCCP flow 60 2.3.1 The Quick-Start Response Option 61 2.4 Receiving a Quick-Start Response 62 2.5 Procedure when no response to a Quick-Start Request 63 2.6 Procedure when a Quick-Start Packet is dropped 64 2.7 Interactions with Mobility and Signalled Path Changes 65 2.8 Interactions with Path MTU Discovery 66 2.9 Interactions with Middle boxes 67 3. Mechanisms for Specific CCIDs 68 3.1 Quick-Start for CCID-2 69 3.1.1 The Quick-Start Request for CCID-2 70 3.1.2 Sending a Quick-Start Response with CCID-2 71 3.1.3 Using the Quick-Start Response with CCID-2 72 3.1.4 Reported Loss during Quick-Start Mod 73 3.1.5 CCID-2 Feedback Traffic on the Reverse Path 74 3.2 Quick-Start for CCID-3 75 3.2.1 The Quick-Start Request for CCID-3 76 3.2.2 Sending a Quick-Start Response with CCID-3 77 3.2.3 Using the Quick-Start Response with CCID-3 78 3.2.4 The Quick-Start Validation Phase 79 3.2.5 Reported Loss during Quick-Start Mode or Validation Phase 80 3.2.6 An Example Quick-Start Scenario with CCID-3 81 3.2.7 CCID-3 Feedback Traffic on the Reverse Path 82 3.3 Quick-Start for CCID-4 83 3.3.1 The Quick-Start Request for CCID-4 84 3.3.2 Sending a Quick-Start Response with CCID-4 85 3.3.3 Using the Quick-Start Response with CCID-4 86 3.3.4 CCID-4 Feedback Traffic on the Reverse Path 87 4. Discussion of Issues 88 4.1 Over-run and Quick-Start Validation 89 4.2 Experimental Status 90 5. IANA Considerations 91 6. Acknowledgments 92 7. Security Considerations 93 8. References 94 8.1 Normative References 95 8.2 Informative References 96 9. Authors' Addresses 97 10. IPR Notices 98 10.1 Intellectual Property Statement 99 10.2 Disclaimer of Validity 100 11. Copyright Statement 101 1. Introduction 103 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 104 transport protocol for congestion-controlled, unreliable datagrams, 105 intended for applications such as streaming media, Internet 106 telephony, and on-line games. 108 In DCCP, an application has a choice of congestion control 109 mechanisms, each specified by a Congestion Control Identifier (CCID) 110 [RFC4340]. There are general procedures applicable to all DCCP CCIDs 111 that are described in Section 2, and details that relate to how 112 individual CCIDs should operate, which are described in Section 3. 113 This separation of CCID-specific and DCCP general functions is in 114 the spirit of the modular approach adopted by DCCP. 116 Quick-Start [RFC4782] is an Experimental mechanism for transport 117 protocols specified for use in controlled environments. The current 118 specification of this mechanism is not intended or appropriate for 119 ubiquitous deployment in the global Internet. 121 Quick-Start is designed for use between end hosts within the same 122 network or on Internet paths that include IP routers. It works in 123 cooperation with any routers, allowing a sender to determine an 124 allowed sending rate at the start and at times in the middle of a 125 data transfer (e.g., after an idle or application-limited period). 127 This document assumes that the reader is familiar with RFC4782 128 [RFC4782], which specifies the use of Quick-Start with IP and with 129 TCP. Section 7 of RFC4782 also provides guidelines for the use of 130 Quick-Start with other transport protocols, including DCCP. This 131 document answers some of the issues that were raised by RFC4782 and 132 provides a definition of how Quick-Start must be used with DCCP. 134 In using Quick-Start, the sending DCCP end host indicates the 135 desired sending rate in bytes per second, using a Quick-Start option 136 in the IP header of a DCCP packet. Each Quick-Start capable router 137 along the path could, in turn, either approve the requested rate, 138 reduce the requested rate, or indicate that the Quick-Start Request 139 is not approved. 141 If the Quick-Start Request is approved by all the routers along the 142 path, then the DCCP receiver returns an appropriate Quick-Start 143 Response. On receipt of this, the sending end host can send at up to 144 the approved rate for one round-trip time. Subsequent transmissions 145 will be governed by the default CCID congestion control mechanisms 146 for the connection. If the Quick-Start Request is not approved, then 147 the sender must use the default congestion control mechanisms. 149 2. Quick-Start for DCCP 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 Unless otherwise specified, DCCP end hosts follow the procedures 156 specified in Section 4 of [RFC4782], following the use specified for 157 Quick-Start with TCP. 159 2.1 Sending a Quick-Start Request for a DCCP flow 161 A DCCP sender MAY use a Quick-Start Request during the start of a 162 connection, when the sender would prefer to have a larger initial 163 rate than allowed by standard mechanisms (e.g. [RFC-to-be-3448.bis] 164 or [RFC3390]). 166 A Quick-Start Request MAY be also used once a DCCP flow is connected 167 (in the middle of a DCCP flow). In standard operation, DCCP CCIDs 168 can constrain the sending rate (or window) to less than that desired 169 (e.g. when an application increases the rate at which it wishes to 170 send). A DCCP sender that has data to send after an idle period or 171 application-limited period (i.e. where the sender transmits at less 172 than the allowed sending rate) can send a Quick-Start Request using 173 the procedures defined in Section 3. 175 Quick-Start Requests will be more effective if the Quick-Start Rate 176 is not larger than necessary. Each requested Quick-Start Rate that 177 has been approved, but was not fully utilized, takes away from the 178 bandwidth pool maintained by Quick-Start routers that would be 179 otherwise available for granting successive requests [RFC4782]. 181 In contrast to most TCP applications, many DCCP applications have 182 the notion of a natural media rate that they wish to achieve. For 183 example, during the initial connection, a host may request a Quick- 184 Start rate equal to the media rate of the application. 186 When sending a Quick-Start Request, the DCCP sender SHOULD send the 187 Quick-Start Request using a packet that requires an acknowledgement, 188 such as a DCCP-Request, DCCP-Response, or DCCP-Data. 190 2.2 The Quick-Start Interval 192 Excessive use of the Quick-Start mechanism is undesirable. This 193 document therefore introduces the concept of the Quick-Start 194 Interval. End hosts therefore MUST NOT make a subsequent Quick-Start 195 Request within a period specified as the Quick-Start Interval. 197 When a connection is established, the Quick-Start Interval is 198 initialized to a value of 6 seconds, and the previous Quick-Start 199 Interval is set to 0 seconds. This value is chosen to be 200 sufficiently large to prevent excessive router processing over 201 typical Internet paths. 203 Whenever a Quick-Start Request is sent, the Quick-Start Interval is 204 then recalculated as: 206 Quick-Start Interval = max(6 seconds, QSPrev_Interval*2, 4*RTT) 208 where the QSPrev_Interval is the value of the previous Quick-Start 209 Interval. 211 Each unsuccessful Quick-Start Request, therefore results in the 212 Quick-Start Interval being doubled (resulting in an exponential 213 back-off). The maximum time the sender can back-off is 64 seconds, 214 after which a sender ceases using Quick-Start and MUST NOT send any 215 further Quick-Start Requests for the remainder of the DCCP 216 connection. 218 Whenever a Quick-Start Request is approved, the previous Quick-Start 219 Interval and QSPrev_Interval are reset to their initial value. 221 2.3 Receiving a Quick-Start Request for a DCCP flow 223 The procedure for processing a received Quick-Start Request is 224 normatively defined in [RFC4782], and summarised in this paragraph. 225 An end host that receives an IP packet containing a Quick-Start 226 Request passes the Quick-Start Request, along with the value in the 227 IP TTL field, to the receiving DCCP layer. If the receiving host is 228 willing to permit the Quick-Start Request, it SHOULD respond 229 immediately by sending a packet that carries the Quick-Start 230 Response option in the DCCP header of the corresponding feedback 231 packet (e.g. using a DCCP-Ack packet or in a DCCP-DataAck packet). 233 The Rate Request in the Quick-Start Response option is set to the 234 received value of the Rate Request in the Quick-Start option or to a 235 lower value if the DCCP receiver is only willing to allow a lower 236 Rate Request. Where information is available (e.g. knowledge of the 237 local layer 2 interface speed), a QS receiver SHOULD verify that the 238 received rate does not exceed its expected receive link capacity. 239 The TTL Diff in the Quick-Start Response is set to the difference 240 between the IP TTL value and the Quick-Start TTL value. The Quick- 241 Start Nonce in the Response is set to the received value of the 242 Quick-Start Nonce in the Quick-Start option. 244 If an end host receives an IP packet with a Quick-Start Request with 245 a request rate of zero, then this host SHOULD NOT send a Quick-Start 246 Response [RFC4782]. 248 The Quick-Start Response MUST NOT be resent if it is lost in the 249 network [RFC4782]. Packet loss could be an indication of congestion 250 on the return path, in which case it is better not to approve the 251 Quick-Start Request. 253 2.3.1 The Quick-Start Response Option 254 The Quick-Start Response message must be carried by the transport 255 protocol using Quick-Start. This section defines a DCCP Header 256 option used to carry the Quick-Start response. This header option is 257 REQUIRED for end hosts to utilise the Quick-Start mechanism with 258 DCCP flows. The format resembles that defined for TCP [RFC4782]. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type=xQSOx | Length=8 | Resv. | Rate | TTL Diff | 264 | | | |Request| | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Quick-Start Nonce | R | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1. The Quick-Start Response option. 271 ### IANA ACTION, PLEASE REPLACE xQSOx with the assigned value in the 272 figure above.### 274 ### IANA ACTION, PLEASE ALSO REPLACE xQSOx with the assigned value 275 in the paragraph below.### 277 The first byte of the Quick-Start Response option contains the 278 option kind, identifying the DCCP option (xQSOx). 280 The second byte of the Quick-Start Response option contains the 281 option length in bytes. The length field MUST be set to 8 bytes. 283 The third byte of the Quick-Start Response option contains a four- 284 bit Reserved field, and the four-bit allowed Rate Request, formatted 285 as in the IP Quick-Start Rate Request option [RFC4782]. 287 The fourth byte of the DCCP Quick-Start Response option contains the 288 TTL Diff. The TTL Diff contains the difference between the IP TTL 289 and Quick-Start TTL fields in the received Quick-Start Request 290 packet, as calculated in [RFC4782]. 292 Bytes 5-8 of the DCCP option contain the 30-bit Quick-Start Nonce 293 and a two-bit Reserved field. 295 2.4 Receiving a Quick-Start Response 297 Reception of a Quick-Start Response packet results in the sender 298 entering the Quick-Start Mode. The procedure following reception of 299 a Quick-Start Response packet is CCID-specific and described in 300 Section 3. 302 2.5 Procedure when no response to a Quick-Start Request 304 As in TCP, if a Quick-Start Request is dropped (i.e., the Request or 305 Response is not delivered by the network) the DCCP sender MUST 306 revert to the congestion control mechanisms it would have used if 307 the Quick-Start Request had not been approved. The connection is not 308 permitted to send a subsequent Quick-Start Request before expiry of 309 the current Quick-Start Interval (section 2.1). 311 2.6 Procedure when a Quick-Start Packet is dropped 313 While the sender is in the Quick-Start Mode, all sent packets are 314 known as Quick-Start Packets [RFC4782]. Loss of a Quick-Start 315 Packet is an indication of potential network congestion. The 316 behaviour of a DCCP sender following the loss of a Quick-Start 317 Packet is specific to a particular CCID (see section 3). 319 2.7 Interactions with Mobility and Signalled Path Changes 321 The use of Quick-Start may assist hosts in determining when it is 322 appropriate to increase their rate following an explicitly signalled 323 change of the network path. Senders must ensure this does not 324 generate an excessive rate of Quick-Start Requests by using the 325 method below. 327 A sender that has explicit information that the network path has 328 changed (e.g. a mobile IP binding update [RFC3344], [RFC3775]) MAY 329 reset the Quick-Start Interval and QSPrev_Interval to their initial 330 values (specified in section 2.1). 332 The sender MAY also send a Quick-Start Request to determine a new 333 safe transmission rate, but must observe the following rules: 335 . It MUST NOT send a Quick-Start Request within a period less 336 than the initial Quick-Start Interval (i.e., 6 seconds) since 337 it previously sent a Quick-Start Request. That is, it must wait 338 for at least a period of 6 seconds after the previous request, 339 before sending a new Quick-Start Request. 341 . If it has not sent a Quick-Start Request within the previous 6 342 seconds, it SHOULD defer sending a Quick-Start Request for a 343 randomly chosen period between 0 and 6 seconds. The random 344 period should be statistically independent between different 345 hosts and between different connections on the same host. This 346 delay is to mitigate the effect on router load of synchronised 347 responses by multiple connections in response to a path change 348 that effects multiple connections. 350 2.8 Interactions with Path MTU Discovery 352 DCCP implementations are encouraged to support Path MTU Discovery 353 (PMTUD) when applications are able to use a DCCP packet size that 354 exceeds the default Path MTU [RFC4340], [RFC4821]. Quick-Start 355 Requests SHOULD NOT be sent with packets that are used as a PMTUD 356 Probe Packet, since these packets could be lost in the network 357 increasing the probability of loss. It may therefore be preferable 358 to separately negotiate the PMTU and the use of Quick-Start. 360 The DCCP protocol is datagram-based and therefore the size of the 361 segments that are sent is a function of application behaviour as 362 well as being constrained by the largest supported Path MTU. 364 2.9 Interactions with Middle boxes 366 A Quick-Start Request is carried in an IP packet option [RFC4782]. 367 Interactions with network devices (middleboxes) that inspect or 368 modify IP options could therefore led to discard, ICMP error, or 369 DCCP-Reset when attempting to forward packets carrying a Quick-Start 370 Request. 372 If a DCCP sender sends a DCCP-Request that also carries a Quick- 373 Start Request, and does not receive a DCCP-Response to the packet, 374 the DCCP sender SHOULD resend the DCCP-Request packet without 375 including a Quick-Start Request. 377 Similarly, if a DCCP sender receives a DCCP-Reset in response to a 378 DCCP-Request packet that also carries a Quick-Start Request, then 379 the DCCP sender SHOULD resend DCCP-Request packet without the 380 Quick-Start Request. 382 The DCCP sender then ceases to use the Quick-Start Mechanism for the 383 remainder of the connection. 385 A DCCP sender that uses a Quick-Start Request within an established 386 connection, and does not receive a response will treat this as non- 387 approval of the request. Successive unsuccessful attempts will 388 result in an exponential increase in the Quick-Start Interval 389 (section 2.1). If this grows to a value exceeding 64 seconds the 390 DCCP sender ceases to use the Quick-Start Mechanism for the 391 remainder of the connection. 393 3. Mechanisms for Specific CCIDs 395 This section specifies the use of Quick-Start with DCCP CCID-2, 396 CCID-3, and CCID-4. 398 3.1 Quick-Start for CCID-2 400 This section describes the Quick-Start mechanism to be used with 401 DCCP CCID-2 [RFC4341]. CCID-2 uses a TCP-like congestion control 402 mechanism. 404 3.1.1 The Quick-Start Request for CCID-2 406 A Quick-Start Request MAY be sent to allow the sender to determine 407 if it is safe to use a larger initial cwnd. This permits a faster 408 start-up of a new DCCP CCID-2 flow. 410 A Quick-Start Request MAY also be sent for an established connection 411 to request a higher sending rate after an idle period or 412 application-limited period (described in section 2.1). This allows a 413 receiver to use a larger cwnd than allowed with standard operation. 415 A Quick-Start Request SHOULD NOT be sent within a period less than 416 the Quick-Start Interval following a previous Quick-Start Request 417 (section 2.2), unless it is sent as a result of a network path 418 change (section 2.7). A Quick-Start Request that follows a loss or 419 congestion event MUST NOT request a Quick-Start rate that exceeds 420 the largest congestion window achieved by the CCID-2 connection 421 since the last packet drop (translated to a sending rate). 423 3.1.2 Sending a Quick-Start Response with CCID-2 425 A receiver processing a Quick-Start Request uses the method 426 described in Section 2.2. On receipt of a Quick-Start Request, the 427 receiver MUST send a Quick-Start Response (even if a receiver is 428 constrained by the ACK Ratio). 430 3.1.3 Using the Quick-Start Response with CCID-2 432 On receipt of a valid Quick-Start Response option, the sender MUST 433 send a Quick-Start Approved option [RFC4782] as an IP option using 434 the first Quick-Start Packet or send this as an option using a DCCP 435 control packet if there are no DCCP-Data packets pending 436 transmission. 438 If the approved Quick-Start rate is less than current sending rate, 439 the sender does not enter the Quick-Start Mode, and continues using 440 the procedure defined in CCID-2. 442 If the approved Quick-Start rate at the sender exceeds the current 443 sending rate, the sender enters the Quick-Start Mode and continues 444 in the Quick-Start Mode for a maximum period of 1 RTT. While in the 445 Quick-Start Mode, all DCCP packets that it sends are known as Quick- 446 Start Packets. 448 The sender sets its Quick-Start cwnd (QS_cwnd) as follows: 450 QS_cwnd = (R * T) / (s + H) (1) 452 where R is the Rate Request in bytes per second, s is the packet 453 size, and H is the estimated DCCP/IP header size in bytes (e.g., 32 454 bytes for DCCP layered directly over IPv4). 456 A CCID-2 sender MAY then increase its cwnd to the QS_cwnd. The cwnd 457 should not be reduced (i.e., a QS_cwnd lower than cwnd should be 458 ignored, since the CCID-2 congestion control method already permits 459 this rate). CCID-2 is not a rate-paced protocol. Therefore, if the 460 QS_cwnd is used, the sending host MUST implement a suitable method 461 to pace the rate at which the Quick-Start Packets are sent until it 462 receives an ACK for a packet sent during the Quick-Start Mode 463 [RFC4782]. The sending host SHOULD also record the previous cwnd and 464 note that the new cwnd has been determined by Quick-Start, rather by 465 other means (e.g. by setting a flag to indicate that it is in Quick- 466 Start Mode). 468 When the sender receives the first ACK to a packet sent in the 469 Quick-Start Mode, the sender MUST reduce the cwnd to the actual 470 flight size (the current amount of unacknowledged data sent) 471 [RFC4782]. 473 3.1.4 Reported Loss during Quick-Start Mode 475 A sender in the Quick-Start Mode or Validation Phase that detects 476 congestion (e.g. receives a feedback packet that reports new packet 477 loss or a packet with a congestion marking), MUST immediately leave 478 the Quick-Start Mode or Validation Phase and enter the congestion 479 avoidance phase [RFC4341]. 481 3.1.5 CCID-2 Feedback Traffic on the Reverse Path 483 A CCID-2 receiver sends feedback for groups of received packets 484 [RFC4341]. Approval of a higher transmission rate using Quick-Start 485 will increase control traffic on the reverse path. A return path 486 that becomes congested could have a transient negative impact on 487 other traffic flows sharing the return link. The lower rate of 488 feedback will then limit the achievable rate in the forward 489 direction. 491 3.2 Quick-Start for CCID-3 493 This section describes the Quick-Start mechanism to be used with 494 DCCP CCID-3 [RFC4342]. The rate-based congestion control mechanism 495 used by CCID-3, leads to specific issues that are addressed by 496 Quick-Start in this section, and include the introduction of a 497 Quick-Start Validation Phase. 499 3.2.1 The Quick-Start Request for CCID-3 501 A Quick-Start Request MAY be sent to allow the sender to determine 502 if it is safe to use a larger initial sending rate. This permits a 503 faster start-up of a new DCCP flow. 505 A Quick-Start Request MAY also be sent to request a higher sending 506 rate after an idle period (in which the nofeedback timer expires 507 [RFC-to-be-3448bis]) or an application-limited period (described in 508 section 2.1). This allows a receiver to increase the sending rate 509 faster than allowed with standard operation (i.e. faster than twice 510 the rate reported by a CCID-3 receiver in the most recent feedback 511 message). 513 The requested rate specified in a Quick-Start Request must consider 514 the current loss event rate (if any), either from calculation at the 515 sender or from feedback received from the receiver. CCID-3 requires 516 that a sender must not send more than the upper bound dictated by 517 the loss event rate. This rate offers a safe response in the 518 presence of expected congestion. 520 3.2.2 Sending a Quick-Start Response with CCID-3 522 When processing a received Quick-Start Request, the receiver uses 523 the method described in Section 2.3. In addition, if a CCID-3 524 receiver uses the window counter to send periodic feedback messages, 525 then the receiver sets its local variable last_counter to the value 526 of the window counter reported by the segment containing the Quick- 527 Start Request. The next feedback message would then be sent when the 528 window_counter is greater or equal to last_counter + 4. If the CCID- 529 3 receiver uses a feedback timer to send period feedback messages, 530 then the DCCP receiver MUST reset the CCID-3 feedback timer, causing 531 the feedback to be sent as soon as possible. This helps to align the 532 timing of feedback to the start and end of the period in which 533 Quick-Start Packets are sent, and will normally result in feedback 534 at a time that is approximately the end of the period when Quick- 535 Start Packets are received. 537 A Quick-Start Request SHOULD NOT be sent within a period less than 538 the Quick-Start Interval following a previous Quick-Start Request 539 (section 2.2), unless it is sent as a result of a network path 540 change (section 2.7). 542 3.2.3 Using the Quick-Start Response with CCID-3 544 On receipt of a valid Quick-Start Response option, the sender enters 545 the Quick-Start Mode. The sender MUST send a Quick-Start Approved 546 option [RFC4782] as an IP option using the first Quick-Start Packet 547 or send this as an option using a DCCP control packet if there are 548 no DCCP-Data packets pending transmission. 550 If the approved Quick-Start rate is less than current sending rate, 551 the sender does not enter the Quick-Start Mode, and continues using 552 the procedure defined in CCID-3. While in the Quick-Start Mode, all 553 DCCP packets that it sends are known as Quick-Start Packets. 555 If the approved Quick-Start rate exceeds the current sending rate, 556 the sender enters the Quick-Start Mode and continues in the Quick- 557 Start Mode for a maximum period of 1 RTT. The sender sets its Quick- 558 Start sending rate (QS_sendrate) as follows: 560 QS_sendrate = R * s/(s + H) (2) 561 where R the Rate Request in bytes per second, s is the packet size, 562 and H the estimated DCCP/IP header size in bytes (e.g., 32 bytes). 563 A CCID-3 host MAY then increase its sending rate (sendrate) to the 564 QS_sendrate. The rate should not be reduced. 566 CCID-3 is a rate-paced protocol. Therefore, if the QS_sendrate is 567 used, the sending host MUST pace the rate at which the Quick-Start 568 Packets are sent over the next RTT. The sending host SHOULD also 569 record the previous congestion-controlled rate and note that the new 570 rate has been determined by Quick-Start rather by other means (e.g. 571 by setting a flag to indicate that it is in Quick-Start Mode). 573 The sender exits the Quick-Start Mode after either: 575 * Receipt of a feedback packet acknowledging one or more Quick-Start 576 Packets, 577 * A period of 1 RTT after receipt of a Quick-Start Response, 578 or 579 * Detection of a loss or congestion event (see Section 3.2.5). 581 3.2.4 The Quick-Start Validation Phase 583 After transmitting a set of Quick-Start Packets (and providing that 584 no loss or ECN marking is reported), the sender enters the Quick- 585 Start Validation Phase. This phase persists for a period during 586 which the sender seeks to affirm that the capacity used by the 587 Quick-Start Packets did not introduce congestion. (This phase is 588 introduced, because unlike TCP (and CCID-2), CCID-3 does not receive 589 frequent feedback that would indicate the congestion state of the 590 forward path). While in the Quick-Start Validation Phase, the sender 591 is tentatively permitted to continue sending at the QS_sendrate. On 592 conclusion of the Validation Phase, the sender expects to receive 593 assurance that it may safely use the current rate. 595 A sender that receives feedback that reports a loss or congestion 596 event MUST follow the procedures described in Section 3.2.5. 598 The sender SHOULD exit the Quick-Start Validation Phase on receipt 599 of feedback that acknowledges all packets sent in the Quick-Start 600 Mode (i.e. all Quick-Start Packets). It MUST exit this phase on 601 expiry of the Quick-Start validation time. The Quick-Start 602 Validation Phase is limited to the Quick-Start Validation Time (a 603 maximum of 1.5 RTTs). 605 A sender that completes the Quick-Start Validation phase with no 606 reported packet loss or congestion, stops using the QS_sendrate and 607 MUST recalculate a suitable sending rate using the standard 608 congestion control mechanisms [RFC4342]. For example, if the DCCP 609 sender was in slow-start prior to the Quick-Start Request, and no 610 packets were lost or marked since that time, then the sender 611 continues in slow-start after exiting Quick-Start Mode until the 612 sender sees a packet loss, or congestion is reported. 614 If no feedback is received within the Quick-Start Validation Phase, 615 the sender MUST return to the minimum of the original rate (at the 616 start of the Quick-Start Mode) and one half of the QS_sendrate. 618 3.2.5 Reported Loss during Quick-Start Mode or Validation Phase 619 A sender in the Quick-Start Mode or Validation Phase that detects 620 congestion (e.g. receives a feedback packet that reports new packet 621 loss or a packet with a congestion marking) MUST immediately leave 622 the Quick-Start Mode or Validation Phase and enter the congestion 623 avoidance phase [RFC4342]. This implies re-calculating the send 624 rate, X, as required by RFC4342: 626 X = max(min(X_calc, min(2*X_recv, 2* QS_recv-rate)), s/t_mbi); 628 where X_recv is the previously cached receiver rate and QS recv-rate 629 is the receiver rate reported by the feedback due to the arrival of 630 Quick-Start Packets. 632 The current specification of TFRC [RFC-to-be-3448bis], which 633 obsoletes RFC 3448, uses a set of X_recv values and uses the maximum 634 of the set during data-limited intervals. This calculates the send 635 rate, X as: 637 X = max(min(X_calc, min(recv_limit, 2* QS_recv-rate)), 638 s/t_mbi); 640 where recv_limit could be max(X_recv_set) or 2*max(X_recv_set) 641 dependent on whether there was a new loss event during a data- 642 limited interval, or no loss event during a data-limited interval 643 respectively. When the sender is not data-limited, recv_limit is set 644 to 2*max(X_recv_set). 646 When RFC4342 adopts [RFC-to-be-3448bis], the send rate, X would also 647 be calculated using the above formula from [RFC-to-be-3448bis]. 649 3.2.6 An Example Quick-Start Scenario with CCID-3 651 DCCP Sender DCCP Receiver 653 Quick-Start +----------------------------------------------+ 654 Request/Response | Quick-Start Request --> | 655 | <-- Quick-Start Response | 656 | Quick-Start Approve --> | 657 +----------------------------------------------+ 658 +----------------------------------------------+ 659 Quick-Start | Quick-Start Packets --> | 660 Mode | | 661 | <-- Feedback from Receiver| 662 +----------------------------------------------+ 663 +---------------------------------------------- 664 Quick-Start | Packets --> | 665 Validation Phase | | 666 | <-- Feedback from Receiver| 667 +----------------------------------------------+ 668 CCID-3 | Packets --> | 669 Congestion | | 670 Control | <-- Feedback from Receiver | 671 | | 672 Figure 2. The Quick-Start Mode and Validation Phase. 674 Figure 2 shows an example use of Quick-Start with CCID-3. 676 3.2.7 CCID-3 Feedback Traffic on the Reverse Path 678 A CCID-3 receiver sends feedback at least once each RTT [RFC4342]. 679 Use of Quick-Start is therefore not expected to significantly 680 increase control traffic on the reverse path. 682 3.3 Quick-Start for CCID-4 684 This section describes the Quick-Start mechanism to be used with 685 DCCP CCID-4 [ID.CCID4]. CCID-4 is similar to CCID-3 except that a 686 sender using CCID-4 is limited to a maximum of 100 packets/second. 687 The Quick-Start procedure defined below therefore resembles that for 688 CCID-3. 690 3.3.1 The Quick-Start Request for CCID-4 692 The procedure for sending a Quick-Start Request using CCID-4 is the 693 same as for CCID-3, defined in section 3.2.1. In addition, the 694 requested rate MUST be less than or equal to the equivalent of a 695 sending rate of 100 packet per second [ID.CCID4]. 697 3.3.2 Sending a Quick-Start Response with CCID-4 699 This procedure is the same as for CCID-3, defined in section 3.2.2. 701 3.3.3 Using the Quick-Start Response with CCID-4 703 This procedure is the same as for CCID-3, defined in sections 3.2.3, 704 3.2.4, and 3.2.5, except that the congestion control procedures 705 defined in [ID.CCID4] and used in place of those defined in 706 [RFC4342] 708 3.3.4 CCID-4 Feedback Traffic on the Reverse Path 710 A CCID-4 receiver sends feedback at least once each RTT (defined in 711 [RFC4342]). Use of Quick-Start is therefore not expected to 712 significantly increase control traffic on the reverse path. 714 4. Discussion of Issues 716 The considerations for using Quick-Start with DCCP are not 717 significantly different to those for Quick-Start with TCP. 719 4.1 Over-run and Quick-Start Validation 721 CCID-3 raises an issue in that a sender using Quick-Start may 722 continue to use the rate specified by a Quick-Start Response for a 723 period that exceeds one path round trip time (i.e., that which TCP 724 would have used). This over-run is a result of the less frequent 725 feedback interval used by TFRC (i.e., CCID-3 and CCID-4 provide 726 feedback once per RTT, rather than once for a few packets). In the 727 method specified by this document, the Quick-Start Validation Time 728 bounds this over-run to be not more than an additional 1.5 RTTs. 730 The currently selected method is chosen as a compromise that 731 reflects the need to terminate quickly following the loss of a 732 feedback packet, and the need to allow sufficient time for end host 733 and router processing as well as the different perceptions of the 734 path RTT held at the sender and receiver. Any reported loss or 735 congestion results in immediate action without waiting for 736 completion of the Quick-Start Validation period. 738 4.2 Experimental Status 740 There are many cases in which Quick-Start Requests would not be 741 approved [RFC4782]. These include communication over paths 742 containing routers, IP tunnels, MPLS paths, and the like, that do 743 not support Quick-Start. These cases also include paths with 744 routers or middleboxes that drop packets containing IP options. 745 Quick-Start Requests could be difficult to approve over paths that 746 include multi-access layer-two networks. 748 Transient effects could arise when the transport protocol packets 749 associated with a connection are multiplexed over multiple parallel 750 (sometimes known as alternative) link or network-layer paths, and 751 Quick-Start is used, since it will be effective on only one of the 752 paths, but could lead to increased traffic on all paths. 754 A CCID-2 sender using Quick-Start can increase the control traffic 755 on the reverse path, which could have a transient negative impact on 756 other traffic flows sharing the return link (section 3.1.5). The 757 lower rate of feedback will then limit the achievable rate in the 758 forward direction. 760 [RFC4782] also describes environments where the Quick-Start 761 mechanism could fail with false positives, with the sender 762 incorrectly assuming that the Quick-Start Request had been approved 763 by all of the routers along the path. As a result of these 764 concerns, and as a result of the difficulties and seeming absence of 765 motivation for routers, such as core routers, to deploy Quick-Start, 766 Quick-Start has been proposed as a mechanism that could be of use in 767 controlled environments, and not as a mechanism that would be 768 intended or appropriate for ubiquitous deployment in the global 769 Internet. 771 Further experimentation would be required to confirm the deployment 772 of Quick-Start and to investigate performance issues that may arise, 773 prior to any recommendation for use over the general Internet. 775 5. IANA Considerations 776 This document requires IANA involvement for the assignment of a DCCP 777 Option Type from the DCCP Option Types Registry. This Option is 778 applicable to all CCIDs and is known as the "Quick-Start Response" 779 Option and is defined in Section 2.2.1. It specifies a length value 780 in the format used for options numbered 32-128. 782 6. Acknowledgments 784 The author gratefully acknowledges the previous work by Sally Floyd 785 to identify issues that impact Quick-Start for DCCP, and her 786 comments to improve this document. We also acknowledge comments and 787 corrections from Pasi Sarolahti, Mark Allman and others in the IETF 788 DCCP WG. 790 7. Security Considerations 792 Security issues are discussed in [RFC4782]. Middlebox deployment 793 issues are also highlighted in section 2.7. No new security issues 794 are raised within this document. 796 8. References 798 8.1 Normative References 800 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, 1997. 803 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 804 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 806 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 807 Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion 808 Control", RFC 4341, March 2006. 810 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 811 Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: 812 TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. 814 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 815 Start for TCP and IP", RFC 4782, January 2007. 817 [ID.CCID4] Floyd, S., Kohler, E., "Profile for Datagram Congestion 818 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control 819 for Small Packets (TFRC-SP)", IETF Work In Progress, 2007. 821 [RFC-to-be-3448bis] Floyd, S., Padhye, J., Widmer, J., "TCP Friendly 822 Rate Control (TFRC): Protocol Specification", IETF Work In Progress, 823 2008. 825 8.2 Informative References 827 [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 828 3344, August 2002. 830 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 831 in IPv6", RFC 3775, June 2004. 833 [RFC3390] Allman, M., Floyd, S., Partridge, C., "Increasing TCP's 834 Initial Window", RFRC 3390, October 2002. 836 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 837 Discovery", RFC 4821, March 2007. 839 9. Authors' Addresses 841 Godred Fairhurst 842 School of Engineering 843 University of Aberdeen 844 Aberdeen, AB24 3UE 845 UK 846 Email: gorry@erg.abdn.ac.uk 847 Web: http://www.erg.abdn.ac.uk/users/gorry 849 Arjuna Sathiaseelan 850 School of Engineering 851 University of Aberdeen 852 Aberdeen, AB24 3UE 853 UK 854 Email: arjuna@erg.abdn.ac.uk 855 Web: http://www.erg.abdn.ac.uk/users/arjuna 857 10. IPR Notices 859 10.1 Intellectual Property Statement 861 The IETF takes no position regarding the validity or scope of any 862 Intellectual Property Rights or other rights that might be claimed 863 to pertain to the implementation or use of the technology described 864 in this document or the extent to which any license under such 865 rights might or might not be available; nor does it represent that 866 it has made any independent effort to identify any such rights. 867 Information on the procedures with respect to rights in RFC 868 documents can be found in BCP 78 and BCP 79. 870 Copies of IPR disclosures made to the IETF Secretariat and any 871 assurances of licenses to be made available, or the result of an 872 attempt made to obtain a general license or permission for the use 873 of such proprietary rights by implementers or users of this 874 specification can be obtained from the IETF on-line IPR repository 875 at http://www.ietf.org/ipr. 877 The IETF invites any interested party to bring to its attention any 878 copyrights, patents or patent applications, or other proprietary 879 rights that may cover technology that may be required to implement 880 this standard. Please address the information to the IETF at ietf- 881 ipr@ietf.org. 883 10.2 Disclaimer of Validity 885 This document and the information contained herein are provided on 886 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 887 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 888 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 889 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 890 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 891 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 892 FOR A PARTICULAR PURPOSE. 894 11. Copyright Statement 896 Copyright (C) The IETF Trust (2008). 898 This document is subject to the rights, licenses and restrictions 899 contained in BCP 78, and except as set forth therein, the authors 900 retain all their rights. 902 Acknowledgment 904 Funding for the RFC Editor function is currently provided by the 905 Internet Society. 907 ------------------------------------------------------------------- 909 [RFC EDITOR NOTE: 910 This section must be deleted prior to publication] 912 DOCUMENT HISTORY 914 Individual Draft 00 915 This is the first presentation of this document. 917 Individual Draft 01 918 This includes fixes for NiTs (thanks Pasi) 919 It also includes a note on initial rates in 2.1 920 All mention of packet loss now qualified with loss/congestion. 921 It adds supports for CCID-2. 922 It also defines the Quick-Start Interval as a way of controlling the 923 rate at which hosts may issue Quick-Start requests. 925 Individual Draft 02 - Draft intended for more general review 926 Resolution of many minor outstanding editorial issues. 927 Includes feedback on a longer Quick-Start period from Mark Allman. 928 Includes new section on the interaction with middleboxes. 929 CCID-2 and CCID-3 text now use the same style. 930 Added description for CCID-4, based on CCID-3. 931 Added clarification of PMTUD interaction. 932 Reorganised to create a section on the QS Interval 933 Rewritten sections on what to do after loss/congestion 934 Clarified path change triggers (e.g. from mobility binding updates) 935 There are no currently known remaining issues to be addressed. 937 Individual Draft 03 938 This includes fixes for NiTs, especially to shorten some parts of 939 text. 940 It includes some additional clarification based on the progress of 941 RFC3448.bis. 942 Replaced reference to Faster Restart. 943 Change to paragraph on mobility usage. 945 [END of RFC EDITOR NOTE]