idnits 2.17.1 draft-ietf-dccp-tfrc-faster-restart-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1003. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (14 July 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 899 -- Looks like a reference, but probably isn't: '3' on line 899 ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-05) exists of draft-ietf-dccp-ccid4-02 -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2861 (Obsoleted by RFC 7661) -- Duplicate reference: RFC4342, mentioned in 'RFC4342Errat', was also mentioned in 'RFC4342'. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Kohler 3 INTERNET-DRAFT UCLA 4 Intended status: Experimental S. Floyd 5 Expires: January 2009 ICIR 6 A. Sathiaseelan 7 University of Aberdeen 8 14 July 2008 10 Faster Restart for TCP Friendly Rate Control (TFRC) 11 draft-ietf-dccp-tfrc-faster-restart-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 2009. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 TCP-Friendly Rate Control (TFRC) is a congestion control mechanism 45 for unicast flows operating in a best-effort Internet environment. 46 This document introduces Faster Restart, an optional mechanism for 47 safely improving the behavior of interactive flows that use TFRC. 48 Faster Restart is proposed for use with TFRC and with TFRC-SP, the 49 Small Packet variant of TFRC. We present Faster Restart in general 50 terms as a congestion control mechanism, and further discuss Faster 51 Restart for Datagram Congestion Control Protocol (DCCP) Congestion 52 Control IDs 3 and 4. 54 Table of Contents 56 1. Introduction ....................................................6 57 2. Conventions ....................................................10 58 3. Faster Restart: Changes to TFRC ................................11 59 3.1. Feedback Packets ..........................................11 60 3.2. Nofeedback Timer ..........................................15 61 4. Faster Restart Discussion ......................................15 62 4.1. Worst-Case Scenarios ......................................16 63 4.2. Incentives for applications to send unnecessary packets 64 during idle or data-limited periods ............................16 65 4.3. Interoperability Issues ...................................17 66 4.3.1. Interoperability Issues with CCID-3 and the RFC 67 4342 Errata ...............................................17 68 4.4. Faster Restart for TFRC-SP ................................18 69 5. Simulations of Faster Restart ..................................18 70 6. Implementation Issues ..........................................19 71 7. Security Considerations ........................................19 72 8. IANA Considerations ............................................19 73 9. Thanks .........................................................19 74 Normative References ..............................................19 75 Informative References ............................................20 76 A. Appendix: Simulations ..........................................21 77 Authors' Addresses ................................................23 78 Full Copyright Statement ..........................................24 79 Intellectual Property .............................................24 80 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 82 Changes from draft-ietf-dccp-tfrc-faster-restart-05.txt: 84 * Updated application-limited behavior for Revised TFRC 85 in Table 1, to reflect changes to rfc3448bis. 87 * Updated description of code in rfc3448bis to reflect 88 changes in that document. 90 Changes from draft-ietf-dccp-tfrc-faster-restart-04.txt: 92 * Changed "RTO" to "NFT". 93 Changed the targeted idle period to the configurable DelayTime. 94 Feedback from Gerrit Renker. 96 * Removed Section 4.1 on the receive rate, after it is made 97 into an Errata for RFC 4342. Feedback from Gerrit Renker. 99 * General editing from Gorry Fairhurst and Arjuna, and additional 100 reporting on simulations. 102 * Added a section on Interoperability Issues. 104 * Specified CCID 3 and 4 impact in the introduction. 106 Changes from draft-ietf-dccp-tfrc-faster-restart-03.txt: 108 * Deleted ping packets, and the section about the implementation 109 of ping packets in DCCP. 111 * In Section 3.2, calls to 112 "Update X_active_recv and X_fast_max;" and 113 "Interpolate X_fast_max;" 114 had been reversed accidentally. Put them back in the right order. 116 * Changed Intended Status back to Experimental (where it started 117 out). 119 * General editing is response to feedback from Gorry. 121 * Added simulation tests to the list in the section on simulations: 122 (1) simulations 123 with a worst-case scenario of high congestion, all flows using 124 TFRC, all flows having various idle times, all flows using Faster 125 Restart, and variable arrival rates for the TFRC flows (to create 126 variable levels of congestion). And compare this to the same 127 scenario with no flows using Faster Restart. (2) scenarios with 128 transient changes from routing changes and from variable traffic. 129 The goal is to explore worse-case scenarios showing off the worst 130 aspects of Faster Restart. 132 * Targeted an idle period of at most six minutes, not thirty 133 minutes. Feedback from Gorry and Ian McDonald. 135 * Added a section of whether Faster Restart encourages flows to 136 pad their sending rate during idle periods. 138 * Didn't implement suggestion from Lachlan Andrew to decay from 139 quadrupling to doubling the sending rate gradually. The last 140 more-than-doubling of the sending rate is probably not a 141 quadrupling in any case, since the allowed sending rate is 142 not increased due to quadrupling to more than X_fast_max. 144 Changes from draft-ietf-dccp-tfrc-faster-restart-02.txt: 146 * Deleted proposed response to dealing with X_recv for idle or 147 data-limited periods; RFC3448bis now deals with this instead. 149 * Deleted the Receive Rate Length option. Also 150 removed all text about using the inflation factor to 151 reduce X_recv_in based on the sender's idle time. 153 * Moved TFRC changes and DCCP-specific changes to separate sections. 155 * Revised draft to refer to RFC3448bis instead of to RFC3448. 156 This included modifying sections on "Feedback Packets" and 157 "Nofeedback Timer". 159 * Said that CCID 3 could calculate the receive rate only 160 for one RTT, rather than for longer, after an idle period. 161 (When used with RFC3448bis, it shouldn't affect performance 162 one way or another). 164 Changes from draft-ietf-dccp-tfrc-faster-restart-01.txt: 166 * Added a sentence to Abstract about DCCP. 168 * Added some text to the Introduction, 170 * Added sections on "Minimum Sending Rate", "Send Receive 171 Rate Length Feature", "Nofeedback Timer", and "Simulations 172 of Faster Restart". 174 * Added an Appendix on "Simulations". 176 Changes from draft-ietf-dccp-tfrc-faster-restart-00.txt: 178 * Added mechanisms for dealing with a more general problem with 179 idle periods. This includes a section of "Receive Rate 180 Adjustment". 182 END OF NOTE TO RFC EDITOR. 184 1. Introduction 186 This document defines congestion control mechanisms that improve the 187 performance of occasionally idle flows using TCP-Friendly Rate 188 Control (TFRC) [RFC3448] [RFC3448bis]. A data-limited or idle flow 189 uses less than its allowed sending rate for application-specific 190 reasons, such as lack of data to send. The responses of Standard 191 TFRC [RFC3448], and Revised TFRC [RFC3448bis] to long idle or data- 192 limited periods are summarized in Table 1 below, and the responses of 193 Standard TCP [RFC2581] and TCP with Congestion Window Validation 194 [RFC2861] are described in Appendix C of [RFC3448bis]. All of these 195 mechanisms allow a flow to recover from a long idle period by ramping 196 up to the allowed sending rate or window. This document specifies 197 mechanisms that allow TFRC to start at a higher sending rate after an 198 idle period, and to ramp up faster to the old sending rate after an 199 idle period. 201 As this draft is being written, Standard TFRC is specified in 202 [RFC3448], and TFRC is in the process of being revised, as Revised 203 TFRC, in [RFC3448bis]. When [RFC3448bis] is approved as a Proposed 204 Standard document, this draft will be revised, with the phrase 205 "Standard TFRC" replaced by "Old TFRC", and other language changes as 206 appropriate. 208 For Standard TFRC as specified in [RFC3448], a TFRC flow may not send 209 more than twice X_recv, the rate at which data was received at the 210 receiver over the previous RTT. Thus in Standard TFRC the previous 211 receive rate limits the sending rate of applications with highly 212 variable sending rates, forcing the applications to ramp up, by 213 doubling their sending rate each round-trip time, from the earlier 214 data-limited rate to the sending rate allowed by the throughput 215 equation. TFRC's nofeedback timer halves the allowed sending rate 216 after each nofeedback timer interval (at least four round-trip times) 217 in which no feedback is received. One result is that applications 218 must slow-start after being idle for any significant length of time, 219 in the absence of mechanisms such as Quick-Start [RFC4782] and Quick- 220 Start for DCCP [GA08]. 222 For Revised TFRC as specified in [RFC3448bis], the previous receive 223 rate is not used to limit the sending rate during data-limited 224 periods. Thus, unlike [RFC3448], in [RFC3448bis] applications with 225 highly variable sending rates are not limited by the previous receive 226 rates. However, [RFC3448bis] is like [RFC3448] in that the 227 nofeedback timer is used to halve the allowed sending rate after each 228 nofeedback timer interval in which no feedback is received. With 229 [RFC3448] the allowed sending rate is not reduced below two packets 230 per RTT during idle periods, and with [RFC3448bis] the allowed 231 sending rate is not reduced below the allowed initial sending rate 232 during idle periods. 234 This behavior is safe, though conservative, for best-effort traffic 235 in the network. A silent application stops receiving feedback about 236 the condition of the current network path, and thus should not be 237 able to send at an arbitrary rate. A data-limited application stops 238 receiving feedback about whether current network conditions would 239 support higher rates. However, this behavior also affects the 240 perceived performance of interactive applications such as voice. 241 Connections for interactive telephony and conference applications, 242 for example, will usually have one party active at a time, with 243 seamless switching between active parties. TFRC's reduction of the 244 allowed sending rate, and slow-starting back to a higher sending 245 rate, after every switch between parties could seriously degrade 246 perceived performance. Some of the strategies suggested for coping 247 with this problem, such as sending padding data during application 248 idle periods, might have worse effects on the network than simply 249 switching onto the desired rate with no slow-start. 251 There is some justification for somewhat accelerating the slow start 252 process after idle periods, as opposed to at the beginning of a 253 connection. A flow that fairly achieves a sending rate of X has 254 proved, at least, that some path between the endpoints can support 255 that rate. The path might change, due to endpoint reset or routing 256 adjustments; or many new connections might start up, significantly 257 reducing the application's fair rate. However, it seems reasonable 258 to allow an application to possibly contribute to limited transient 259 congestion in times of change, in return for improving application 260 responsiveness. 262 This document suggests a relatively simple approach to this problem. 263 Standard TFRC [RFC3448] specifies that the allowed sending rate is 264 never reduced below two packets per RTT as the result of a nofeedback 265 timer after an idle period. Following [RFC3390], CCID-3 [RFC4342] 266 and Revised TFRC [RFC3448bis] specify that the allowed sending rate 267 is never reduced below the TCP initial sending rate of two or four 268 packets per RTT, depending on packet size, as the result of a 269 nofeedback timer after an idle period. Faster Restart doubles this 270 allowed sending rate after idle periods. Thus, the sending rate 271 after an idle period is not reduced below a rate Y between four and 272 eight packets per RTT, depending on the packet size. The rate Y is 273 restricted to at most 8760 bytes per RTT (which is twice TCP's 274 maximum allowed initial window size). 276 In addition, because flows already have some (possibly old) 277 information about the path, Faster Restart allows flows to quadruple 278 their sending rate in every congestion-free RTT, instead of doubling, 279 upwards towards the previously achieved rate. When the TFRC sender 280 detects congestion, the sender leaves Faster Restart and changes into 281 congestion avoidance. These changes are summarized in the table 282 below. In this document, "NFT" refers to the NoFeedback Timer 283 interval for TFRC; this is roughly equivalent to the Retransmit 284 TimeOut (RTO) interval for TCP. 286 ------------------------------------------------------------------ 287 - Standard TFRC - 288 ------------------------------------------------------------------ 289 Idle period: 290 Halve allowed sending rate each NFT, not below two packets per RTT. 291 After sending again, double the sending rate each RTT. 292 Application-limited period: 293 Send at most twice X_recv. 294 As a result, at most double the sending rate each RTT. 295 ------------------------------------------------------------------ 297 ------------------------------------------------------------------ 298 - Revised TFRC - 299 ------------------------------------------------------------------ 300 Idle period: 301 Halve allowed sending rate each NFT, not below initial sending rate. 302 After sending again, double the sending rate each RTT. 303 Application-limited period: 304 If no loss, send at most twice max (X_recv_set), including old values 305 of X_recv going back to just before the data-limited interval was 306 entered. 307 If loss, reduce saved values of X_recv. 308 ------------------------------------------------------------------ 310 ------------------------------------------------------------------ 311 - Revised TFRC with Faster Restart - 312 ------------------------------------------------------------------ 313 Idle period: 314 Halve allowed sending rate each NFT, not below twice initial rate. 315 (Specified in Section 3.2.) 316 After sending again, quadruple the sending rate towards old rate. 317 (Specified in Section 3.1.) 318 Application-limited period: 319 Sending rate not limited by X_recv. 320 ------------------------------------------------------------------ 322 Table 1: Behavior of TFRC, with and without Faster Restart. 324 The congestion control mechanisms defined here are intended to apply 325 to any implementations of TFRC, including that in DCCP's CCID 3 and 326 CCID 4 [RFC4342], [CCID4]. These mechanisms change only CCID 3 and 4 327 sender behavior and do not change DCCP packets in externally visible 328 ways (except in that the sending rate will be higher after an idle 329 period). This reduces interoperability concerns. Any DCCP CCID 3 330 or 4 sender MAY therefore use Faster Restart algorithms at its 331 discretion, without negotiation with the corresponding receiver. 333 While we also believe that TCP could safely use a similar Faster 334 Restart mechanism, we do not specify it here. Our assumption is that 335 flows that are sensitive to restrictions to the sending rate after 336 idle periods are more likely to use TFRC than to use TCP or TCP-like 337 congestion control. 339 2. Conventions 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 343 document are to be interpreted as described in [RFC2119]. 345 The Faster Restart mechanism refers to several existing TFRC state 346 variables, including the following: 348 R: The RTT estimate. 350 X: The current allowed sending rate in bytes per second. 352 p: The recent loss event rate. 354 X_recv: 355 The rate at which the receiver estimates that data was received 356 since the last feedback report was sent. 358 s: The packet size in bytes. 360 Faster Restart uses the following variable from [RFC3448bis]: 362 recv_limit: 363 The limit on the sending rate that is computed from the receive 364 rate. 366 Faster Restart also introduces new state variables to TFRC, as 367 follows: 369 X_active_recv: 370 The receiver's estimated receive rate reported during a recent 371 active sending period. An active sending period is a period in 372 which the sender has not experienced a loss event. X_active_recv 373 is initialized to 0 until there has been an active sending period, 374 and X_active_recv is reduced after a loss event. 376 T_active_recv: 377 The time at which X_active_recv was measured. T_active_recv is 378 initialized to the start time of the connection. 380 recover_rate: 381 The minimum restart rate allowed by Faster Restart after an idle 382 period. Note that Faster Restart flows can drop below this rate 383 as the result of experienced congestion (e.g. actual loss 384 feedback). Recover_rate is defined as follows: 386 recover_rate = min(8*s, max(4*s, 8760 bytes))/R. 388 Faster Restart also uses the following, which could be implemented as 389 a temporary variable: 391 X_fast_max: 392 The rate at which the sender should stop quadrupling its sending 393 rate, and return to at most doubling its sending rate. 395 Other variables have values as described in [RFC3448] and 396 [RFC3448bis]. 398 3. Faster Restart: Changes to TFRC 400 3.1. Feedback Packets 402 The Faster Restart algorithm replaces the lines in step (4) of 403 Section 4.3, "Sender Behavior When a Feedback Packet is Received", of 404 [RFC3448bis] that specify the limitation on the sending rate 405 calculated from the reported receive rates. [RFC3448bis] allows the 406 sender to slow-start back up to the previous sending rate after an 407 idle period, doubling its sending rate after each round-trip time. 409 This document specifies a mechanism so that during recovery from an 410 idle period, the TFRC sender can quadruple its sending rate each 411 (congestion-free) round-trip time, until it reaches its old sending 412 rate before the idle or data-limited period. This modification uses 413 three new variables: X_active_recv specifies the maximum receive rate 414 achieved before the idle period, T_active_recv specifies the time of 415 the last update of X_active_recv, and X_fast_max specifies the 416 adjusted rate at which the sender should stop quadrupling its sending 417 rate and continue to its default behavior of doubling its sending 418 rate. 420 The procedure "Update X_active_recv and X_fast_max" below increases 421 the two variables in response to increases in the reported receive 422 rate and reduces them after a report of a lost packet or an 423 indication of congestion (e.g. an ECN-marked packet). 425 Update X_active_recv and X_fast_max: 426 If (the feedback packet does not indicate a loss or mark, 427 and X_recv >= X_fast_max) 428 X_active_recv = X_fast_max = X_recv, 429 T_active_recv = current time. 430 Else if (the feedback packet DOES indicate a loss or mark, 431 and X_recv < X_fast_max) 432 X_active_recv = X_fast_max = X_recv/2, 433 T_active_recv = current time. 435 The parameter X_active_recv gives an upper bound on the rate 436 achievable through Faster Restart, and is only modified by the 437 "Update X_active_rate and X_fast_max" procedure. This modification 438 is based on the contents of the feedback packet and the value of 439 X_fast_max. X_active_recv is updated as the connection achieves 440 higher congestion-free transmit rates. X_active_recv is reduced on 441 congestion feedback, to prevent an inappropriate Faster Restart until 442 a new stable active rate is achieved. Specifically, when congestion 443 feedback is received at a low sending rate, the sender reduces 444 X_active_recv to X_recv/2, allowing a limited Faster Restart up to a 445 likely-safe rate. 447 For some transport protocols using TFRC, the feedback packets might 448 report the loss event rate, but not explicitly report lost or marked 449 packets. For such protocols, the sender in the "Update X_active_rate 450 and X_fast_max" procedure can infer that a feedback packet indicates 451 a loss or mark by looking at the reported loss event rate. If the 452 current or previous feedback packet reported an increase in the loss 453 event rate, then the current feedback packet is assumed to indicate a 454 loss or mark. (If the previous feedback packet reported an increase 455 in the loss event rate, then a loss event began in the interval 456 covered by that feedback packet. However, the loss event can cover 457 up to a round-trip time of data, so the second half of the loss 458 event, including additional lost or marked packets, could be covered 459 by the second feedback packet.) 461 The "Interpolate X_fast_max" procedure determines X_fast_max, the 462 adjusted rate at which Faster Restart should stop. The procedure 463 sets X_fast_max to something between zero and X_active_recv, 464 depending on the time since X_active_recv was last updated. The 465 procedure allows full Faster Restart up to the old sending rate 466 X_active_recv after a short idle period, but requires more 467 conservative behavior after a longer idle period. Thus, if at most 468 DecayTime has elapsed since the last update of X_active_recv, for a 469 default DecayTime of two minutes, then X_fast_max is set to 470 X_active_recv. If 3*DecayTime or more has elapsed, X_fast_max is set 471 to zero. Linear interpolation is used between these extremes. 473 The default DecayTime of two minutes is chosen to strike a balance 474 between the needs of applications, and the time intervals over which 475 connections might reasonably quadruple back up to their old sending 476 rates after idle periods. In terms of the needs of applications, 477 models of voice traffic generally use average idle times between 0.5 478 and two seconds [JS00] (Section 3). However, in terms of changes in 479 path characteristics, Faster Restart does not assume that the 480 previous sending rate is valid after an idle period; Faster Restart 481 simply assumes that a connection may *quadruple* rather than *double* 482 its sending rate up to the previous rate. Therefore, while an overly 483 long DecayTime is not likely to lead to congestion collapse, it could 484 result in unnecessary packet drops, and therefore in reduced 485 performance for the application itself. Path congestion levels can 486 change over time scales of round-trip times, which are generally 487 between 10 and several hundred milliseconds; more dramatic changes in 488 path characteristics (e.g., routing changes, changes in link 489 bandwidth) happen less frequently. For now, the DecayTime may be a 490 configurable parameter. Future work may shed more light on optimum 491 values for DecayTime. 493 Interpolate X_fast_max: 494 // If achieved X_active_recv <= 1 minute ago, 495 // set X_fast_max to X_active_recv; 496 // If achieved X_active_recv >= 3 minutes ago, 497 // set X_fast_max to zero; 498 // If in between, interpolate. 499 delta_T = now - T_active_recv; 500 F = (6 min - min(max(delta_T, 2 min), 6 min)) / (2 min); 501 X_fast_max = F * X_active_recv; 503 The pseudocode above uses the temporary variables delta_T and F. 505 Faster Restart replaces the following lines from step (4) of Section 506 4.3 of [RFC3448bis]: 508 If (the entire interval covered by the feedback packet 509 was a data-limited interval) { 510 If (the feedback packet reports a new loss event or an 511 increase in the loss event rate p) { 512 Halve entries in X_recv_set; 513 X_recv = 0.85 * X_recv; 514 Maximize X_recv_set(); 515 recv_limit = max (X_recv_set); 516 } Else { 517 Maximize X_recv_set(); 518 recv_limit = 2 * max (X_recv_set); 519 } 520 } Else { // typical behavior 521 Update X_recv_set(); 522 recv_limit = 2 * max (X_recv_set); 523 } 525 with the following: 527 Interpolate X_fast_max; 528 Update X_active_recv and X_fast_max; 529 If (the entire interval covered by the feedback packet 530 was a data-limited interval) { 531 If (the feedback packet reports a new loss event or an 532 increase in the loss event rate p) { 533 Halve entries in X_recv_set; 534 X_recv = 0.85 * X_recv; 535 Maximize X_recv_set(); 536 recv_limit = max (X_recv_set); 537 } Else { 538 Maximize X_recv_set(); 539 recv_limit = 2 * max (X_recv_set); 540 If (recv_limit < X_fast_max) 541 recv_limit = min (2*recv_limit, X_fast_max); 542 } 543 } Else { // typical behavior 544 Update X_recv_set(); 545 recv_limit = 2 * max (X_recv_set); 546 If (recv_limit < X_fast_max) 547 recv_limit = min (2*recv_limit, X_fast_max); 548 } 550 In summary, when a feedback packet is received, as specified in 551 [RFC3448bis], then the sender updates the round-trip time estimate 552 and the NFT (NoFeedback Timer), and updates X_recv_set, the set of 553 recent X_recv values, and then executes the procedure above. 554 X_fast_max always represents the interpolated value from highest 555 X_recv reported since the last loss event. However, because 556 X_recv_set contains only X_recv values from the most recent two 557 round-trip times, the calculated recv_limit could be less than 558 X_fast_max. In this case, recv_limit is doubled, up to at most 559 X_fast_max. Faster Restart's doubling of recv_limit allows the TFRC 560 sender to quadruple its sending rate each round-trip time after an 561 idle period. 563 3.2. Nofeedback Timer 565 Section 4.4 of [RFC3448bis] specifies when the allowed sending rate 566 is halved after the nofeedback timer expires. In particular, 567 [RFC3448bis] specifies that if the sender has been idle since the 568 nofeedback timer was set, then the allowed sending rate is not 569 reduced below recover_rate, which in [RFC3448bis] is set to the 570 initial_rate of W_init/R, for: 572 W_init = min(4*s, max(2*s, 4380)), 574 for segment size s. In contrast, this document sets recover_rate to 575 twice the initial_rate, as follows: 577 recover_rate = 2*W_init/R; 579 4. Faster Restart Discussion 581 Standard TCP has historically dealt with idleness and data-limited 582 flows either by keeping cwnd entirely open ("immediate start") or by 583 entering slow-start, as recommended in RFC 2581 in response to an 584 idle period. The first option is too liberal, the second too 585 conservative. Clearly a short idle or data-limited period is not a 586 new connection: the sending rate maintained before the idle or data- 587 limited period shows that previously, the connection could fairly 588 sustain some rate without adversely impacting other flows. However, 589 longer idle periods are more problematic. Idle periods of many 590 minutes would seem to require slow-start. 592 RFC 2861 [RFC2861] gives a moderate mechanism for TCP, where the 593 congestion window is halved for every retransmit timeout interval 594 that the sender has remained idle, down to the initial window, and 595 the window is re-opened in slow-start when the idle period is over. 596 TFRC in [RFC3448bis] roughly follows [RFC2861] for the response to an 597 idle period. Unlike [RFC2861], however, [RFC3448bis] follows 598 Standard TCP in its responses to a data-limited period, and does not 599 reduce the allowed sending rate in response to data-limited periods. 601 4.1. Worst-Case Scenarios 603 Faster Restart should be acceptable for TFRC if its worst-case 604 scenarios are acceptable. Realistic worst-case scenarios might 605 include the following scenarios: 607 o Path changes: The path changes and the old rate is not acceptable 608 on the new path. RTTs are shorter on the new path too, so Faster 609 Restart takes bandwidth from other connections for multiple RTTs, 610 not just one. (This can happen with TCP or with TFRC without 611 Faster Restart, but Faster Restart could make this behavior more 612 severe.) 614 o Synchronized flows: Several connections enter Faster Restart 615 simultaneously. If the path is congested, the extra load 616 resulting from Faster Restart could be twice as bad as the extra 617 load if the connections had simply slow-started from their allowed 618 initial sending rate. 620 o Many forms of burstiness: Variable-rate connections using Faster 621 Restart share the congested link with short TCP or DCCP 622 connections starting and stopping, with initial windows of three 623 or four packets. The aggregate traffic could also include TCP 624 connections with short quiescent periods (e.g., web browsing 625 sessions using HTTP 1.1), or bursty higher-priority traffic. As a 626 result of the bursty traffic, the aggregate arrival rate varies 627 from one RTT to the next. The transient congestion will be 628 particularly severe if the congested link is an access link 629 instead of a backbone link; the level of statistical multiplexing 630 on an access link may not be sufficiently high to "smooth out" the 631 burstiness. 633 o Wireless links: The network allocates capacity based on traffic 634 conditions, as in some current wireless technologies, such as 635 Bandwidth on Demand (BoD) links [RFC3819] where capacity is 636 variable and dependent on several parameters other than network 637 congestion. In this case, the old sending rate might not be 638 acceptable after a change in capacity for the wireless link during 639 an idle period. 641 Further analysis is required to analyze the effects of these 642 scenarios. 644 4.2. Incentives for applications to send unnecessary packets during 645 idle or data-limited periods 647 How does Faster Restart affect an application's incentive to pad its 648 sending rate by sending unnecessary packets during idle or data- 649 limited periods? We would like to limit an application's incentive 650 to pad its sending rate during idle or data-limited periods; if all 651 applications were to pad their sending rates, it could reduce the 652 available bandwidth, and degrade the performance for all flows on the 653 congested link. 655 With Standard TFRC as specified in [RFC3448], a data-limited TFRC 656 flow may not send more than twice X_recv, the rate at which data was 657 received at the receiver over the previous RTT. Thus, with Standard 658 TFRC, one could argue that a variable-rate application over an 659 uncongested path does have some incentive to pad its sending rate. 661 With Revised TFRC as specified in [RFC3448bis], the allowed sending 662 rate after an idle period is larger than the allowed sending rate 663 with Standard TFRC. Further, with Revised TFRC the receive rate 664 reported in feedback packets is not used to limit the sending rate 665 during data-limited periods. Thus, with Revised TFRC an application 666 has less incentive to pad its sending rate than with Standard TFRC. 667 However, with Revised TFRC an application could have some incentive 668 to pad its sending rate just enough to maintain the status of "data- 669 limited" instead of "idle", by sending at least one packet every four 670 round-trip times. 672 By allowing TFRC to revert to its old sending rate more quickly after 673 an idle period, Faster Restart could reduce an application's 674 incentive to pad its sending rate. 676 4.3. Interoperability Issues 678 Faster Restart is a sender-side only modification to TFRC, and is 679 intended to work with any TFRC receiver using the same transport 680 protocol. The current standard for TFRC is RFC 3448. After 681 [RFC3448bis] is standardized, the authors of this document will 682 verify that Faster Restart works with either an RFC3448 or an 683 RFC3448bis receiver. 685 4.3.1. Interoperability Issues with CCID-3 and the RFC 4342 Errata 687 For the particular case of TFRC as used in CCID-3 or CCID-4 in DCCP, 688 there are currently two variants of CCID-3 receivers. For TFRC as 689 specified in [RFC3448], the receiver reports the receive rate 690 measured over the most recent round-trip time. In contrast, for 691 CCID-3 as specified in [RFC4342], the receiver reports the receive 692 rate measured over the interval since the last feedback packet was 693 received. These two methods can differ for feedback packets sent 694 after a loss event or after an idle period. To correct this, the RFC 695 4342 Errata [RFC4342Errat] now specifies that the receiver reports 696 the receive rate measured over the most recent round-trip time, as in 697 RFC 3448. 699 Because Faster Restart is being specified only for a sender using 700 [RFC3448bis], and not for a sender using [RFC3448], Faster Restart in 701 CCID-3 should interoperate with a CCID-3 receiver as specified in 702 [RFC4342], with a CCID-3 receiver as specified in [RFC4342] and 703 updated by the RFC 4342 Errata, or with a CCID-3 receiver as 704 specified in [RFC4342] updated by both the RFC 4342 Errata and by 705 [RFC3448bis]. In particular, with Faster Restart in CCID-3 (or 706 CCID-4) with RFC3448bis, the sender's sending rate is not limited by 707 the first feedback packet received after an idle period, so Faster 708 Restart should perform well even with a CCID-3 (or CCID-4) receiver 709 following RFC 4342 and not updated by the RFC 4342 Errata. 711 4.4. Faster Restart for TFRC-SP 713 We note that Faster Restart with TFRC-SP [RFC4828] is considerably 714 more restrained than Faster Restart with TFRC. In TFRC-SP, the 715 sender is restricted to sending at most one packet every Min 716 Interval. 718 5. Simulations of Faster Restart 720 Some test case scenarios based on simulation analysis are described 721 in Appendix A. These simulations follow the guidelines set in 722 [RFC4828]. These are: 724 1. Fairness to standard TCP and TFRC: The simulation tests examine 725 whether flows that use Faster Restart allow TCP and TFRC flows can 726 achieve their share of the path capacity. 728 2. Fairness within Faster Restart: The simulation tests examine how 729 multiple competing Faster Restart flows share the available 730 capacity among them. 732 3. Response to transient events: The simulation tests examine how a 733 Faster Restart flow reacts to a sudden congestion event. 735 4. Behavior in a range of environments: Tests assess a range of 736 bandwidths, RTTs, and varying idle periods. 738 A set of initial simulation results will be described in [S08]. We 739 note some of the important results here. 741 o Faster Restart does improve the performance of a flow after an 742 idle period by faster restarting when compared to TFRC. The 743 results indicate that the worst case packet delay distribution is 744 small for Faster Restart than for TFRC. 746 o The effect of Faster Restart restarting after an idle period seems 747 to have an effect on other competing flows only when the Faster 748 Restart flow has a high sending rate before it enters the idle 749 period. 751 o When the Faster Restart flows experience losses and hence reduce 752 their rates to a lower rate prior to entering an idle period, the 753 effect of faster restarting is similar to that of slow-start. 755 A later version of this draft will provide more discussion on these 756 results in the appendix and implications will be noted here. 758 6. Implementation Issues 760 TBA 762 7. Security Considerations 764 TRFC security considerations are discussed in [RFC3448]. DCCP 765 security considerations are discussed in [RFC4340]. Faster Restart 766 adds no additional security considerations. 768 8. IANA Considerations 770 There are no IANA considerations. 772 9. Thanks 774 We thank the DCCP Working Group for feedback and discussions; we 775 particularly thank Gorry Fairhurst. We thank Vlad Balan and Gerrit 776 Renker for pointing out problems with the mechanisms discussed in 777 previous versions of the draft. 779 Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, March 1997. 784 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, 785 "TCP Friendly Rate Control (TFRC): Protocol 786 Specification", RFC 3448, Proposed Standard, January 787 2003. 789 [RFC3448bis] Handley, M., Floyd, S., Padhye, J., and J. Widmer, 790 "TCP Friendly Rate Control (TFRC): Protocol 791 Specification", internet draft draft-ietf-dccp- 792 rfc3448bis-06.txt, work-in-progress, April 2008. 794 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 795 Congestion Control Protocol (DCCP)", RFC 4340, March 796 2006. 798 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 799 Datagram Congestion Control Protocol (DCCP) Congestion 800 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 801 4342, March 2006. 803 Informative References 805 [CCID4] Floyd, S., and E. Kohler, "Profile for Datagram 806 Congestion Control Protocol (DCCP) Congestion ID 4: 807 TCP-Friendly Rate Control for Small Packets (TFRC- 808 SP)", Internet-Draft draft-ietf-dccp-ccid4-02.txt, 809 work in progress, February 2008. 811 [GA08] "Quick-Start for the Datagram Congestion Control 812 Protocol (DCCP)", Internet-Draft draft-fairhurst- 813 tsvwg-dccp-qs-03.txt, work in progress, June 2008. 815 [JS00] W. Jiang and H. Schulzrinne, Analysis of On-Off 816 Patterns in VoIP and Their Effect on Voice Traffic 817 Aggregation, Proceedings of the Ninth Conference on 818 Computer Communications and Networks (ICCCN), October 819 2000. 821 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP 822 Congestion Control", RFC 2581, April 1999. 824 [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion 825 Window Validation", RFC 2861, June 2000. 827 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing 828 TCP's Initial Window", RFC 3390, October 2002. 830 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, 831 D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, 832 J., and L. Wood, "Advice for Internet Subnetwork 833 Designers", RFC 3819, July 2004. 835 [RFC4342Errat] RFC Errata for RFC 4342, URL "http://www.rfc- 836 editor.org/errata.php". 838 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, 839 "Quick-Start for TCP and IP", RFC 4782, June 2006. 841 [RFC4828] Floyd, S., and E. Kohler, "TCP Friendly Rate Control 842 (TFRC): the Small-Packet (SP) Variant", RFC 4828, 843 April 2007. 845 [S08] Sathiaseelan, A., Faster Restart - Analysis, URL 846 www.erg.abdn.ac.uk/users/arjuna/faster-restart.pdf, to 847 appear. 849 A. Appendix: Simulations 851 This appendix describes a set of initial test case scenarios for 852 simulation analysis of Faster Restart. The simulation results use 853 the ns-2 simulator. 855 Several types of flows are considered: 857 o Bulk TCP Flows. 859 o Interactive (short) TCP Flows. 861 o TFRC Flows with and without Faster Restart. 863 o TFRC-SP Flows with and without Faster Restart. 865 The implications on other flows (e.g. using UDP) may be extrapolated 866 from this. 868 For these simulations, we consider two application rates. 870 o Small media flows: These have a similar rate to voice over IP 871 with a media bit rate of 64 Kbps (using segments of 160 bytes and 872 a nominal transmit rate of 8 KBps). 874 o Large media flows: These have a similar rate to medium quality 875 video over IP with a media bit rate of 512 Kbps (using segments of 876 size 1000 bytes and a nominal transmit rate of 64 KBps). 878 The simulations will model the effect of an idle period in which the 879 application does not attempt to send any data for a period of time, 880 then resumes transmission. Various idle times are considered. 882 The simulation scenarios include the following. These are intended 883 to be illustrative, rather than exact models of the application 884 behavior. 886 o Performance of a long-lived (bulk) TCP flow (e.g. FTP) with TFRC 887 flows (with and without Faster Restart): The test scenario would 888 involve a single large FTP flow with varying number of large media 889 flows. Each large media flow becomes idle for one second and then 890 restarts. The FTP flow starts during the idle period. The 891 throughput performance of the single FTP flow would be plotted for 892 varying number of large media flows. Does the single FTP flow get 893 at least 1/n share of the bandwidth, where TFRC flows decrease the 894 bandwidth received by the TCP flow? 896 o Performance of small TCP flows (HTTP) with TFRC flows with and 897 without Faster Restart: The test scenario would involve a single 898 large media flow which runs for ten seconds, is idle in the time 899 interval [2, 3], and then restarts. At three seconds, a number of 900 HTTP flows are started. The min, max and median of the 901 request/response time of these HTTP flows would be plotted. Do 902 the request/response times of these HTTP flows differ? If so, by 903 how much? 905 o High-congestion test: In a worst-case scenario with high 906 congestion, all flows use TFRC, with a range of arrival times and 907 idle times. The simulations are run both with and without Faster 908 Restart. How does the use of Faster Restart affect the aggregate 909 packet drop rate? 911 o Transient changes: The first worst-case scenario with transient 912 changes includes a routing change, where the new path has less 913 bandwidth than the old path. The second scenario with transient 914 changes includes transient congestion from a sudden increase in 915 traffic. This increase in traffic could be from long-lived TCP 916 traffic, or from higher-priority traffic, or from many new TFRC 917 sessions. The transient congestion could be particularly severe 918 if the congested link is an access link instead of a backbone 919 link. The third scenario with transient changes could include a 920 wireless link with variable bandwidth, as discussed earlier in 921 Section 4. A fourth scenario would involve a mobility event that 922 results in an increase in the round-trip time. In all cases, the 923 simulations are run both with and without Faster Restart. How 924 does the use of Faster Restart affect the aggregate packet drop 925 rate? 927 o An ideal scenario showing the benefits of Faster Restart: A 928 scenario with an uncongested network, just a few TFRC flows, 929 comparing the per-packet delay distribution with and without 930 Faster Restart. Without Faster Restart, there should be a few 931 packets in each flow with very large delay times, from waiting at 932 the sender until they can be sent. 934 o A scenario showing the benefits (to the flow, not to competing 935 traffic) of padding during idle periods: Are there any scenarios 936 where Faster Restart *increases* a flow's incentives to pad its 937 sending rate during idle or under-utilized periods? 939 Authors' Addresses 941 Eddie Kohler 942 4531C Boelter Hall 943 UCLA Computer Science Department 944 Los Angeles, CA 90095 945 USA 947 Email: kohler@cs.ucla.edu 949 Sally Floyd 950 ICSI Center for Internet Research 951 1947 Center Street, Suite 600 952 Berkeley, CA 94704 953 USA 955 Email: floyd@icir.org 957 Arjuna Sathiaseelan 958 Electronics Research Group 959 University of Aberdeen 960 Aberdeen 961 UK 963 Email: arjuna@erg.abdn.ac.uk 965 Full Copyright Statement 967 Copyright (C) The IETF Trust (2007). 969 This document is subject to the rights, licenses and restrictions 970 contained in BCP 78, and except as set forth therein, the authors 971 retain all their rights. 973 This document and the information contained herein are provided on an 974 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 975 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 976 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 977 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 978 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 979 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 981 Intellectual Property 983 The IETF takes no position regarding the validity or scope of any 984 Intellectual Property Rights or other rights that might be claimed to 985 pertain to the implementation or use of the technology described in 986 this document or the extent to which any license under such rights 987 might or might not be available; nor does it represent that it has 988 made any independent effort to identify any such rights. Information 989 on the procedures with respect to rights in RFC documents can be 990 found in BCP 78 and BCP 79. 992 Copies of IPR disclosures made to the IETF Secretariat and any 993 assurances of licenses to be made available, or the result of an 994 attempt made to obtain a general license or permission for the use of 995 such proprietary rights by implementers or users of this 996 specification can be obtained from the IETF on-line IPR repository at 997 http://www.ietf.org/ipr. 999 The IETF invites any interested party to bring to its attention any 1000 copyrights, patents or patent applications, or other proprietary 1001 rights that may cover technology that may be required to implement 1002 this standard. Please address the information to the IETF at ietf- 1003 ipr@ietf.org.