idnits 2.17.1 draft-floyd-rfc3448bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1324. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 June 2006) is 6522 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3448errata' is mentioned on line 1144, but not defined ** Obsolete undefined reference: RFC 3448 (Obsoleted by RFC 5348) == Unused Reference: 'RFC2119' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: 'RFC3448Err' is defined on line 1241, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. Handley 2 INTERNET-DRAFT University College London 3 draft-floyd-rfc3448bis-00.txt S. Floyd 4 Expires: December 2006 ICIR 5 J. Padhye 6 Microsoft 7 J. Widmer 8 University of Mannheim 9 18 June 2006 11 TCP Friendly Rate Control (TFRC): 12 Protocol Specification 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 2006. 39 Abstract 41 This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a 42 congestion control mechanism for unicast flows operating in a best- 43 effort Internet environment. It is reasonably fair when competing 44 for bandwidth with TCP flows, but has a much lower variation of 45 throughput over time compared with TCP, making it more suitable for 46 applications such as telephony or streaming media where a relatively 47 smooth sending rate is of importance. 49 Table of Contents 51 1. Introduction ...................................................6 52 2. Conventions ....................................................7 53 3. Protocol Mechanism .............................................7 54 3.1. TCP Throughput Equation ...................................8 55 3.2. Packet Contents ...........................................9 56 3.2.1. Data Packets ......................................10 57 3.2.2. Feedback Packets ..................................10 58 4. Data Sender Protocol ..........................................11 59 4.1. Measuring the Segment Size ...............................11 60 4.2. Sender Initialization ....................................12 61 4.3. Sender behavior when a feedback packet is received .......13 62 4.4. Expiration of nofeedback timer ...........................14 63 4.5. Sending a packet after an idle period ....................15 64 4.6. Preventing Oscillations ..................................15 65 4.7. Scheduling of Packet Transmissions .......................16 66 5. Calculation of the Loss Event Rate (p) ........................17 67 5.1. Detection of Lost or Marked Packets ......................17 68 5.2. Translation from Loss History to Loss Events .............18 69 5.3. Inter-loss Event Interval ................................19 70 5.4. Average Loss Interval ....................................19 71 5.5. History Discounting ......................................20 72 6. Data Receiver Protocol ........................................23 73 6.1. Receiver behavior when a data packet is received .........23 74 6.2. Expiration of feedback timer .............................24 75 6.3. Receiver initialization ..................................24 76 6.3.1. Initializing the Loss History after the First Loss 77 Event ....................................................25 78 7. Sender-based Variants .........................................25 79 8. Implementation Issues .........................................26 80 9. Changes from RFC 3448 .........................................27 81 10. Security Considerations ......................................28 82 11. IANA Considerations ..........................................28 83 12. Acknowledgments ..............................................28 84 13. Normative References .........................................29 85 14. Informational References .....................................29 86 15. Authors' Addresses ...........................................30 87 Full Copyright Statement .........................................31 88 Intellectual Property ............................................31 89 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 90 Changes from RFC 3448: 92 * Incorporated changes in the RFC 3448 errata: 94 - "If the sender does not receive a feedback report for 95 four round trip times, it cuts its sending rate in half." 96 ("Two" changed to "four", for consistency with the rest 97 of the document. Reported by Joerg Widmer). 99 - "If the nofeedback timer expires when the sender does not 100 yet have an RTT sample, and has not yet received any 101 feedback from the receiver, or when p == 0,..." 102 (Added "or when p == 0,", reported by Wim Heirman). 104 - In Section 5.5, changed: 105 for (i = 1 to n) { DF_i = 1; } 106 to: 107 for (i = 0 to n) { DF_i = 1; } 108 Reported by Michele R. 110 * Changed RFC 3448 to correspond to the larger initial windows 111 specified in RFC 3390. This includes the following: 113 - Incorporated Section 5.1 from [RFC4342], saying that 114 when reducing the sending rate after an idle period, don't 115 reduce the sending rate below the initial sending rate. 117 - Change for a datalimited sender: 118 When the sender has been datalimited, the sender doesn't 119 let the receive rate limit it to a sending rate less than 120 the initial rate. 122 - Small change to slow-start: 123 Changed so that for the first feedback packet received, 124 or for the first feedback packet received after an idle 125 period, the receive rate is not used to limit the 126 sending rate. This is because the receiver might not yet 127 have seen an entire window of data. 129 * Clarified how the average loss interval is calculated when 130 the receiver has not yet seen eight loss intervals. 132 * Discussed more about estimating the average segment size: 134 - For initializing the loss history after the first loss event, 135 either the receiver knows the sender's value for s, or 136 the receiver uses the throughput equation for X_pps and does 137 not need to know an estimate for s. 139 - Added a discussion about estimating the average segment size 140 s in Section 4.1 on "Measuring the Segment Size". 142 - Changed "packet size" to "segment size". 144 END OF NOTE TO RFC EDITOR. 146 1. Introduction 148 This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a 149 congestion control mechanism designed for unicast flows operating in 150 an Internet environment and competing with TCP traffic [FHPW00]. 151 Instead of specifying a complete protocol, this document simply 152 specifies a congestion control mechanism that could be used in a 153 transport protocol such as DCCP (Datagram Congestion Control 154 Protocol) [RFC4340], in an application incorporating end-to-end 155 congestion control at the application level, or in the context of 156 endpoint congestion management [BRS99]. This document does not 157 discuss packet formats or reliability. Implementation-related 158 issues are discussed only briefly, in Section 8. 160 TFRC is designed to be reasonably fair when competing for bandwidth 161 with TCP flows, where a flow is "reasonably fair" if its sending 162 rate is generally within a factor of two of the sending rate of a 163 TCP flow under the same conditions. However, TFRC has a much lower 164 variation of throughput over time compared with TCP, which makes it 165 more suitable for applications such as telephony or streaming media 166 where a relatively smooth sending rate is of importance. 168 The penalty of having smoother throughput than TCP while competing 169 fairly for bandwidth is that TFRC responds slower than TCP to 170 changes in available bandwidth. Thus TFRC should only be used when 171 the application has a requirement for smooth throughput, in 172 particular, avoiding TCP's halving of the sending rate in response 173 to a single packet drop. For applications that simply need to 174 transfer as much data as possible in as short a time as possible we 175 recommend using TCP, or if reliability is not required, using an 176 Additive-Increase, Multiplicative-Decrease (AIMD) congestion control 177 scheme with similar parameters to those used by TCP. 179 TFRC is designed for applications that use a fixed segment size, and 180 vary their sending rate in packets per second in response to 181 congestion. TFRC can also be used by applications that don't have a 182 fixed segment size, but where the segment size varies according to 183 the needs of the application (e.g., video applications). 185 Some applications (e.g., some audio applications) require a fixed 186 interval of time between packets and vary their segment size instead 187 of their packet rate in response to congestion. The congestion 188 control mechanism in this document is not designed for those 189 applications; TFRC-SP (Small-Packet TFRC) is a variant of TFRC for 190 applications that have a fixed sending rate in packets per second 191 but either use small packets, or vary their packet size in response 192 to congestion. TFRC-SP will be specified in a later document. 194 This document specifies TFRC as a receiver-based mechanism, with the 195 calculation of the congestion control information (i.e., the loss 196 event rate) in the data receiver rather in the data sender. This is 197 well-suited to an application where the sender is a large server 198 handling many concurrent connections, and the receiver has more 199 memory and CPU cycles available for computation. In addition, a 200 receiver-based mechanism is more suitable as a building block for 201 multicast congestion control. However, it is also possible to 202 implement TFRC in sender-based variants, as allowed in DCCP's 203 Congestion Control ID 3 (CCID 3) [RFC4342]. 205 2. Conventions 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119. 211 3. Protocol Mechanism 213 For its congestion control mechanism, TFRC directly uses a 214 throughput equation for the allowed sending rate as a function of 215 the loss event rate and round-trip time. In order to compete fairly 216 with TCP, TFRC uses the TCP throughput equation, which roughly 217 describes TCP's sending rate as a function of the loss event rate, 218 round-trip time, and segment size. We define a loss event as one or 219 more lost or marked packets from a window of data, where a marked 220 packet refers to a congestion indication from Explicit Congestion 221 Notification (ECN) [RFC3168]. 223 Generally speaking, TFRC's congestion control mechanism works as 224 follows: 226 o The receiver measures the loss event rate and feeds this 227 information back to the sender. 229 o The sender also uses these feedback messages to measure the 230 round-trip time (RTT). 232 o The loss event rate and RTT are then fed into TFRC's throughput 233 equation, giving the acceptable transmit rate. 235 o The sender then adjusts its transmit rate to match the 236 calculated rate. 238 The dynamics of TFRC are sensitive to how the measurements are 239 performed and applied. We recommend specific mechanisms below to 240 perform and apply these measurements. Other mechanisms are 241 possible, but it is important to understand how the interactions 242 between mechanisms affect the dynamics of TFRC. 244 3.1. TCP Throughput Equation 246 Any realistic equation giving TCP throughput as a function of loss 247 event rate and RTT should be suitable for use in TFRC. However, we 248 note that the TCP throughput equation used must reflect TCP's 249 retransmit timeout behavior, as this dominates TCP throughput at 250 higher loss rates. We also note that the assumptions implicit in 251 the throughput equation about the loss event rate parameter have to 252 be a reasonable match to how the loss rate or loss event rate is 253 actually measured. While this match is not perfect for the 254 throughput equation and loss rate measurement mechanisms given 255 below, in practice the assumptions turn out to be close enough. 257 The throughput equation we currently recommend for TFRC is a 258 slightly simplified version of the throughput equation for Reno TCP 259 from [PFTK98]. Ideally we'd prefer a throughput equation based on 260 SACK TCP, but no one has yet derived the throughput equation for 261 SACK TCP, and from both simulations and experiments, the differences 262 between the two equations are relatively minor. 264 The throughput equation is: 266 s 267 X = ---------------------------------------------------------- 268 R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) 270 Where: 272 X is the transmit rate in bytes/second. 274 s is the segment size in bytes. 276 R is the round trip time in seconds. 278 p is the loss event rate, between 0 and 1.0, of the number of 279 loss events as a fraction of the number of packets transmitted. 281 t_RTO is the TCP retransmission timeout value in seconds. 283 b is the number of packets acknowledged by a single TCP 284 acknowledgement. 286 We further simplify this by setting t_RTO = 4*R. A more accurate 287 calculation of t_RTO is possible, but experiments with the current 288 setting have resulted in reasonable fairness with existing TCP 289 implementations [W00]. Another possibility would be to set t_RTO = 290 max(4R, one second), to match the recommended minimum of one second 291 on the RTO [RFC2988]. 293 Many current TCP connections use delayed acknowledgements, sending 294 an acknowledgement for every two data packets received, and thus 295 have a sending rate modeled by b = 2. However, TCP is also allowed 296 to send an acknowledgement for every data packet, and this would be 297 modeled by b = 1. Because many TCP implementations do not use 298 delayed acknowledgements, we recommend b = 1. 300 In future, different TCP equations may be substituted for this 301 equation. The requirement is that the throughput equation be a 302 reasonable approximation of the sending rate of TCP for conformant 303 TCP congestion control. 305 The throughput equation can also be expressed as 307 X = X_pps * s , 309 with X_pps, the sending rate in packets per second, given as 311 1 312 X_pps = -------------------------------------------------------- 313 R*sqrt(2*b*p/3) + (t_RTO*(3*sqrt(3*b*p/8)*p*(1+32*p^2))) 315 The parameters s (segment size), p (loss event rate) and R (RTT) 316 need to be measured or calculated by a TFRC implementation. The 317 measurement of s is specified in Section 4.1, measurement of R is 318 specified in Section 4.3, and measurement of p is specified in 319 Section 5. In the rest of this document all data rates are measured 320 in bytes/second. 322 3.2. Packet Contents 324 Before specifying the sender and receiver functionality, we describe 325 the contents of the data packets sent by the sender and feedback 326 packets sent by the receiver. As TFRC will be used along with a 327 transport protocol, we do not specify packet formats, as these 328 depend on the details of the transport protocol used. 330 3.2.1. Data Packets 332 Each data packet sent by the data sender contains the following 333 information: 335 o A sequence number. This number is incremented by one for each 336 data packet transmitted. The field must be sufficiently large 337 that it does not wrap causing two different packets with the 338 same sequence number to be in the receiver's recent packet 339 history at the same time. 341 o A timestamp indicating when the packet is sent. We denote by 342 ts_i the timestamp of the packet with sequence number i. The 343 resolution of the timestamp should typically be measured in 344 milliseconds. 345 This timestamp is used by the receiver to determine which losses 346 belong to the same loss event. The timestamp is also echoed by 347 the receiver to enable the sender to estimate the round-trip 348 time, for senders that do not save timestamps of transmitted 349 data packets. 350 We note that as an alternative to a timestamp incremented in 351 milliseconds, a "timestamp" that increments every quarter of a 352 round-trip time would be sufficient for determining when losses 353 belong to the same loss event, in the context of a protocol 354 where this is understood by both sender and receiver, and where 355 the sender saves the timestamps of transmitted data packets. 357 o The sender's current estimate of the round trip time. The 358 estimate reported in packet i is denoted by R_i. The round-trip 359 time estimate is used by the receiver, along with the timestamp, 360 to determine when multiple losses belong to the same loss event. 361 If the sender sends a coarse-grained "timestamp" that increments 362 every quarter of a round-trip time, as discussed above, then the 363 sender does not need to send its current estimate of the round 364 trip time. 366 3.2.2. Feedback Packets 368 Each feedback packet sent by the data receiver contains the 369 following information: 371 o The timestamp of the last data packet received. We denote this 372 by t_recvdata. If the last packet received at the receiver has 373 sequence number i, then t_recvdata = ts_i. 374 This timestamp is used by the sender to estimate the round-trip 375 time, and is only needed if the sender does not save timestamps 376 of transmitted data packets. 378 o The amount of time elapsed between the receipt of the last data 379 packet at the receiver, and the generation of this feedback 380 report. We denote this by t_delay. 382 o The rate at which the receiver estimates that data was received 383 since the last feedback report was sent. We denote this by 384 X_recv. 386 o The receiver's current estimate of the loss event rate, p. 388 4. Data Sender Protocol 390 The data sender sends a stream of data packets to the data receiver 391 at a controlled rate. When a feedback packet is received from the 392 data receiver, the data sender changes its sending rate, based on 393 the information contained in the feedback report. If the sender does 394 not receive a feedback report for four round trip times, it cuts its 395 sending rate in half. This is achieved by means of a timer called 396 the nofeedback timer. 398 We specify the sender-side protocol in the following steps: 400 o Measurement of the mean segment size being sent. 402 o The sender behavior when a feedback packet is received. 404 o The sender behavior when the nofeedback timer expires. 406 o Oscillation prevention (optional) 408 o Scheduling of transmission on non-realtime operating systems. 410 4.1. Measuring the Segment Size 412 The parameter s (segment size) is normally known to an application. 413 This may not be so in two cases: 415 o (1) The segment size naturally varies depending on the data. In 416 this case, although the segment size varies, that variation is 417 not coupled to the transmit rate. The TFRC sender can either 418 compute the average segment size or use the maximum segment size 419 for the segment size s. 421 o (2) The application needs to change the segment size rather than 422 the number of segments per second to perform congestion control. 423 This would normally be the case with packet audio applications 424 where a fixed interval of time needs to be represented by each 425 packet. Such applications need to have a completely different 426 way of measuring parameters. 428 For the first class of applications where the segment size varies 429 depending on the data, the sender MAY estimate the segment size s as 430 the average segment size over the last four loss intervals. The 431 sender MAY also estimate the average segment size over longer time 432 intervals, if so desired. The TFRC sender uses the segment size s 433 in the throughput equation, in the setting of the maximum receive 434 rate and the minimum sending rate, and in the setting of the 435 nofeedback timer. 437 The TFRC receiver may use the average segment size s in initializing 438 the loss history after the first loss event, but Section 6.3.1 also 439 gives an alternate procedure that does not use the average segment 440 size s. 442 The second class of applications are discussed separately in a 443 separate document on TFRC-SP. For the remainder of this section we 444 assume the sender can estimate the segment size, and that congestion 445 control is performed by adjusting the number of packets sent per 446 second. 448 4.2. Sender Initialization 450 The initial values for X and tld are undefined until they are set as 451 described below. If the sender is ready to send data when it does 452 not yet have a round trip sample, the value of X is set to 1 453 packet/second, the nofeedback timer is set to expire after 2 454 seconds, and the tld, the Time Last Doubled during slow-start, is 455 set to -1. Upon receiving a round trip time measurement (e.g., 456 after the first feedback packet), tld is set to the current time, 457 and the transmit rate X is set to W_init/R, for W_init below from 458 [RFC3390]: 460 W_init = min(4*MSS, max(2*MSS, 4380)), 462 for MSS the Maximum Segment Size. For responding to the initial 463 feedback packet, this replaces step (4) of Section 4.3 below. 465 If the sender does have a round trip sample when it is ready to 466 first send data (e.g., from the SYN exchange or from a previous 467 connection [RFC2140]), the initial transmit rate X is set to 468 W_init/R, and tld is set to the current time. 470 4.3. Sender behavior when a feedback packet is received 472 The sender knows its current sending rate, X, and maintains an 473 estimate of the current round trip time, R, and an estimate of the 474 timeout interval, t_RTO. 476 When a feedback packet is received by the sender at time t_now, the 477 following actions should be performed: 479 1) Calculate a new round trip sample. 480 R_sample = (t_now - t_recvdata) - t_delay. 482 2) Update the round trip time estimate: 484 If no feedback has been received before 485 R = R_sample; 486 Else 487 R = q*R + (1-q)*R_sample; 489 TFRC is not sensitive to the precise value for the filter 490 constant q, but we recommend a default value of 0.9. 492 3) Update the timeout interval: 494 t_RTO = 4*R. 496 4) Update the sending rate as follows: 498 If (sender has been idle or data-limited) 499 min_rate = max(2*X_recv, W_init/R); 500 Else 501 min_rate = 2*X_recv; 502 If (p > 0) 503 Calculate X_calc using the TCP throughput equation. 504 X = max(min(X_calc, min_rate), s/t_mbi); 505 Else if (not the first feedback packet, and 506 not the first feedback packet after a nofeedback timer) 507 If (t_now - tld >= R) 508 X = max(min(2*X, min_rate), s/R); 509 tld = t_now; 511 The condition ``if (sender has been idle or data-limited)'' prevents 512 an idle or data-limited sender from having to reduce the sending 513 rate to less than the initial sending rate as a result of 514 limitations from a small receive rate. The condition ``if (not the 515 first feedback packet, and not the first feedback packet after a 516 nofeedback timer)'' prevents a sender from reducing the sending rate 517 in response to a feedback packet that reports the receipt of only a 518 few packets after start-up or after an idle period. 520 Note that if p == 0, then the sender is in slow-start phase, where 521 it approximately doubles the sending rate each round-trip time until 522 a loss occurs. The s/R term gives a minimum sending rate during 523 slow-start of one packet per RTT. The parameter t_mbi is 64 524 seconds, and represents the maximum inter-packet backoff interval in 525 the persistent absence of feedback. Thus, when p > 0 the sender 526 sends at least one packet every 64 seconds. 528 5) Reset the nofeedback timer to expire after max(4*R, 2*s/X) 529 seconds. 531 4.4. Expiration of nofeedback timer 533 If the nofeedback timer expires, the sender should perform the 534 following actions: 536 1) Cut the sending rate in half. If the sender has received 537 feedback from the receiver, this is done by modifying the 538 sender's cached copy of X_recv (the receive rate). Because the 539 sending rate is limited to at most twice X_recv, modifying 540 X_recv limits the current sending rate, but allows the sender to 541 slow-start, doubling its sending rate each RTT, if feedback 542 messages resume reporting no losses. 544 If (X_calc > 2*X_recv) 545 X_recv = max(X_recv/2, s/(2*t_mbi)); 546 Else 547 X_recv = X_calc/4; 549 The term s/(2*t_mbi) limits the backoff to one packet every 64 550 seconds in the case of persistent absence of feedback. 552 2) The value of X must then be recalculated as described under 553 point (4) above. 555 If the nofeedback timer expires when the sender does not yet 556 have an RTT sample and has not yet received any feedback from 557 the receiver, or when p == 0, then step (1) can be skipped, and 558 the sending rate cut in half directly: 560 X = max(X/2, s/t_mbi) 562 3) Restart the nofeedback timer to expire after max(4*R, 2*s/X) 563 seconds. 565 Note that when the sender stops sending, the receiver will stop 566 sending feedback. This will cause the nofeedback timer to start to 567 expire and decrease X_recv. If the sender subsequently starts to 568 send again, X_recv will limit the transmit rate, and a normal 569 slowstart phase will occur until the transmit rate reaches X_calc. 571 4.5. Sending a packet after an idle period 573 If the sender has been idle (unable to send because there is no data 574 from the application), the allowed sending rate could have been 575 reduced due to the nofeedback timer, as specified in the section 576 above. Because the sender is always restricted to sending at most 577 twice the receive rate reported by the receiver, the sender will be 578 limited to at most doubling its sending rate each round-trip time, 579 until the sending rate reaches the allowed sending rate calculated 580 by the throughput equation. 582 4.6. Preventing Oscillations 584 To prevent oscillatory behavior in environments with a low degree of 585 statistical multiplexing it is useful to modify sender's transmit 586 rate to provide congestion avoidance behavior by reducing the 587 transmit rate as the queuing delay (and hence RTT) increases. To do 588 this the sender maintains an estimate of the long-term RTT and 589 modifies its sending rate depending on how the most recent sample of 590 the RTT differs from this value. The long-term sample is R_sqmean, 591 and is set as follows: 593 If no feedback has been received before 594 R_sqmean = sqrt(R_sample); 595 Else 596 R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample); 598 Thus R_sqmean gives the exponentially weighted moving average of the 599 square root of the RTT samples. The constant q2 should be set 600 similarly to q, and we recommend a value of 0.9 as the default. 602 The sender obtains the base transmit rate, X, from the throughput 603 function. It then calculates a modified instantaneous transmit rate 604 X_inst, as follows: 606 X_inst = X * R_sqmean / sqrt(R_sample); 608 When sqrt(R_sample) is greater than R_sqmean then the queue is 609 typically increasing and so the transmit rate needs to be decreased 610 for stable operation. 612 Note: This modification is not always strictly required, especially 613 if the degree of statistical multiplexing in the network is high. 614 However, we recommend that it is done because it does make TFRC 615 behave better in environments with a low level of statistical 616 multiplexing. If it is not done, we recommend using a very low 617 value of q, such that q is close to or exactly zero. 619 4.7. Scheduling of Packet Transmissions 621 As TFRC is rate-based, and as operating systems typically cannot 622 schedule events precisely, it is necessary to be opportunistic about 623 sending data packets so that the correct average rate is maintained 624 despite the course-grain or irregular scheduling of the operating 625 system. Thus a typical sending loop will calculate the correct 626 inter-packet interval, t_ipi, as follows: 628 t_ipi = s/X_inst; 630 When a sender first starts sending at time t_0, it calculates t_ipi, 631 and calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. 632 When the application becomes idle, it checks the current time, 633 t_now, and then requests re-scheduling after (t_ipi - (t_now - t_0)) 634 seconds. When the application is re-scheduled, it checks the 635 current time, t_now, again. If (t_now > t_1 - delta) then packet 1 636 is sent. 638 Now a new t_ipi may be calculated, and used to calculate a nominal 639 send time t_2 for packet 2: t2 = t_1 + t_ipi. The process then 640 repeats, with each successive packet's send time being calculated 641 from the nominal send time of the previous packet. 643 In some cases, when the nominal send time, t_i, of the next packet 644 is calculated, it may already be the case that t_now > t_i - delta. 645 In such a case the packet should be sent immediately. Thus if the 646 operating system has coarse timer granularity and the transmit rate 647 is high, then TFRC may send short bursts of several packets 648 separated by intervals of the OS timer granularity. 650 The parameter delta is to allow a degree of flexibility in the send 651 time of a packet. If the operating system has a scheduling timer 652 granularity of t_gran seconds, then delta would typically be set to: 654 delta = min(t_ipi/2, t_gran/2); 656 t_gran is 10ms on many Unix systems. If t_gran is not known, a 657 value of 10ms can be safely assumed. 659 5. Calculation of the Loss Event Rate (p) 661 Obtaining an accurate and stable measurement of the loss event rate 662 is of primary importance for TFRC. Loss rate measurement is 663 performed at the receiver, based on the detection of lost or marked 664 packets from the sequence numbers of arriving packets. We describe 665 this process before describing the rest of the receiver protocol. 667 5.1. Detection of Lost or Marked Packets 669 TFRC assumes that all packets contain a sequence number that is 670 incremented by one for each packet that is sent. For the purposes 671 of this specification, we require that if a lost packet is 672 retransmitted, the retransmission is given a new sequence number 673 that is the latest in the transmission sequence, and not the same 674 sequence number as the packet that was lost. If a transport 675 protocol has the requirement that it must retransmit with the 676 original sequence number, then the transport protocol designer must 677 figure out how to distinguish delayed from retransmitted packets and 678 how to detect lost retransmissions. 680 The receiver maintains a data structure that keeps track of which 681 packets have arrived and which are missing. For the purposes of 682 specification, we assume that the data structure consists of a list 683 of packets that have arrived along with the receiver timestamp when 684 each packet was received. In practice this data structure will 685 normally be stored in a more compact representation, but this is 686 implementation-specific. 688 The loss of a packet is detected by the arrival of at least NDUPACK 689 packets with a higher sequence number than the lost packet, for 690 NDUPACK set to 3. The requirement for NDUPACK subsequent packets is 691 the same as with TCP, and is to make TFRC more robust in the 692 presence of reordering. In contrast to TCP, if a packet arrives 693 late (after NDUPACK subsequent packets arrived) in TFRC, the late 694 packet can fill the hole in TFRC's reception record, and the 695 receiver can recalculate the loss event rate. Future versions of 696 TFRC might make the requirement for NDUPACK subsequent packets 697 adaptive based on experienced packet reordering, but we do not 698 specify such a mechanism here. 700 For an ECN-capable connection, a marked packet is detected as a 701 congestion event as soon as it arrives, without having to wait for 702 the arrival of subsequent packets. 704 5.2. Translation from Loss History to Loss Events 706 TFRC requires that the loss fraction be robust to several 707 consecutive packets lost where those packets are part of the same 708 loss event. This is similar to TCP, which (typically) only performs 709 one halving of the congestion window during any single RTT. Thus 710 the receiver needs to map the packet loss history into a loss event 711 record, where a loss event is one or more packets lost in an RTT. 712 To perform this mapping, the receiver needs to know the RTT to use, 713 and this is supplied periodically by the sender, typically as 714 control information piggy-backed onto a data packet. TFRC is not 715 sensitive to how the RTT measurement sent to the receiver is made, 716 but we recommend using the sender's calculated RTT, R, (see Section 717 4.3) for this purpose. 719 To determine whether a lost or marked packet should start a new loss 720 event, or be counted as part of an existing loss event, we need to 721 compare the sequence numbers and timestamps of the packets that 722 arrived at the receiver. For a marked packet S_new, its reception 723 time T_new can be noted directly. For a lost packet, we can 724 interpolate to infer the nominal "arrival time". Assume: 726 S_loss is the sequence number of a lost packet. 728 S_before is the sequence number of the last packet to arrive 729 with sequence number before S_loss. 731 S_after is the sequence number of the first packet to arrive 732 with sequence number after S_loss. 734 T_before is the reception time of S_before. 736 T_after is the reception time of S_after. 738 Note that T_before can either be before or after T_after due to 739 reordering. 741 For a lost packet S_loss, we can interpolate its nominal "arrival 742 time" at the receiver from the arrival times of S_before and 743 S_after. Thus: 745 T_loss = T_before + ( (T_after - T_before) 746 * (S_loss - S_before)/(S_after - S_before) ); 748 Note that if the sequence space wrapped between S_before and 749 S_after, then the sequence numbers must be modified to take this 750 into account before performing this calculation. If the largest 751 possible sequence number is S_max, and S_before > S_after, then 752 modifying each sequence number S by S' = (S + (S_max + 1)/2) mod 753 (S_max + 1) would normally be sufficient. 755 If the lost packet S_old was determined to have started the previous 756 loss event, and we have just determined that S_new has been lost, 757 then we interpolate the nominal arrival times of S_old and S_new, 758 called T_old and T_new respectively. 760 If T_old + R >= T_new, then S_new is part of the existing loss 761 event. Otherwise S_new is the first packet in a new loss event. 763 5.3. Inter-loss Event Interval 765 If a loss interval, A, is determined to have started with packet 766 sequence number S_A and the next loss interval, B, started with 767 packet sequence number S_B, then the number of packets in loss 768 interval A is given by (S_B - S_A). 770 5.4. Average Loss Interval 772 To calculate the loss event rate p, we first calculate the average 773 loss interval. This is done using a filter that weights the n most 774 recent loss event intervals in such a way that the measured loss 775 event rate changes smoothly. 777 Weights w_0 to w_(n-1) are calculated as: 779 If (i < n/2) 780 w_i = 1; 781 Else 782 w_i = 1 - (i - (n/2 - 1))/(n/2 + 1); 784 Thus if n=8, the values of w_0 to w_7 are: 786 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2 788 The value n for the number of loss intervals used in calculating the 789 loss event rate determines TFRC's speed in responding to changes in 790 the level of congestion. As currently specified, TFRC should not be 791 used for values of n significantly greater than 8, for traffic that 792 might compete in the global Internet with TCP. At the very least, 793 safe operation with values of n greater than 8 would require a 794 slight change to TFRC's mechanisms to include a more severe response 795 to two or more round-trip times with heavy packet loss. 797 When calculating the average loss interval we need to decide whether 798 to include the interval since the most recent packet loss event. We 799 only do this if it is sufficiently large to increase the average 800 loss interval. 802 Let the most recent loss intervals be I_0 to I_k, where I_0 is the 803 interval since the most recent loss event. If there have been at 804 least n loss intervals, then k is set to n; otherwise k is the 805 maximum number of loss intervals seen so far. We calculate the 806 average loss interval I_mean is: 808 I_tot0 = 0; 809 I_tot1 = 0; 810 W_tot = 0; 811 for (i = 0 to k-1) { 812 I_tot0 = I_tot0 + (I_i * w_i); 813 W_tot = W_tot + w_i; 814 } 815 for (i = 1 to k) { 816 I_tot1 = I_tot1 + (I_i * w_(i-1)); 817 } 818 I_tot = max(I_tot0, I_tot1); 819 I_mean = I_tot/W_tot; 821 The loss event rate, p is simply: 823 p = 1 / I_mean; 825 5.5. History Discounting 827 As described in Section 5.4, the most recent loss interval is only 828 assigned 1/(0.75*n) of the total weight in calculating the average 829 loss interval, regardless of the size of the most recent loss 830 interval. This section describes an optional history discounting 831 mechanism, discussed further in [FHPW00a] and [W00], that allows the 832 TFRC receiver to adjust the weights, concentrating more of the 833 relative weight on the most recent loss interval, when the most 834 recent loss interval is more than twice as large as the computed 835 average loss interval. 837 To carry out history discounting, we associate a discount factor 838 DF_i with each loss interval L_i, for i > 0, where each discount 839 factor is a floating point number. The discount array maintains the 840 cumulative history of discounting for each loss interval. At the 841 beginning, the values of DF_i in the discount array are initialized 842 to 1: 844 for (i = 0 to n) { 845 DF_i = 1; 846 } 848 History discounting also uses a general discount factor DF, also a 849 floating point number, that is also initialized to 1. First we show 850 how the discount factors are used in calculating the average loss 851 interval, and then we describe later in this section how the 852 discount factors are modified over time. 854 As described in Section 5.4 the average loss interval is calculated 855 using the n previous loss intervals I_1, ..., I_n, and the interval 856 I_0 that represents the number of packets received since the last 857 loss event. The computation of the average loss interval using the 858 discount factors is a simple modification of the procedure in 859 Section 5.4, as follows: 861 I_tot0 = I_0 * w_0 862 I_tot1 = 0; 863 W_tot0 = w_0 864 W_tot1 = 0; 865 for (i = 1 to n-1) { 866 I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF); 867 W_tot0 = W_tot0 + w_i * DF_i * DF; 868 } 869 for (i = 1 to n) { 870 I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i); 871 W_tot1 = W_tot1 + w_(i-1) * DF_i; 872 } 873 p = min(W_tot0/I_tot0, W_tot1/I_tot1); 875 The general discounting factor, DF is updated on every packet 876 arrival as follows. First, the receiver computes the weighted 877 average I_mean of the loss intervals I_1, ..., I_n: 879 I_tot = 0; 880 W_tot = 0; 881 for (i = 1 to n) { 882 W_tot = W_tot + w_(i-1) * DF_i; 883 I_tot = I_tot + (I_i * w_(i-1) * DF_i); 884 } 885 I_mean = I_tot / W_tot; 887 This weighted average I_mean is compared to I_0, the number of 888 packets received since the last loss event. If I_0 is greater than 889 twice I_mean, then the new loss interval is considerably larger than 890 the old ones, and the general discount factor DF is updated to 891 decrease the relative weight on the older intervals, as follows: 893 if (I_0 > 2 * I_mean) { 894 DF = 2 * I_mean/I_0; 895 if (DF < THRESHOLD) 896 DF = THRESHOLD; 897 } else 898 DF = 1; 900 A nonzero value for THRESHOLD ensures that older loss intervals from 901 an earlier time of high congestion are not discounted entirely. We 902 recommend a THRESHOLD of 0.5. Note that with each new packet 903 arrival, I_0 will increase further, and the discount factor DF will 904 be updated. 906 When a new loss event occurs, the current interval shifts from I_0 907 to I_1, loss interval I_i shifts to interval I_(i+1), and the loss 908 interval I_n is forgotten. The previous discount factor DF has to 909 be incorporated into the discount array. Because DF_i carries the 910 discount factor associated with loss interval I_i, the DF_i array 911 has to be shifted as well. This is done as follows: 913 for (i = 1 to n) { 914 DF_i = DF * DF_i; 915 } 916 for (i = n-1 to 0 step -1) { 917 DF_(i+1) = DF_i; 918 } 919 I_0 = 1; 920 DF_0 = 1; 921 DF = 1; 923 This completes the description of the optional history discounting 924 mechanism. We emphasize that this is an optional mechanism whose 925 sole purpose is to allow TFRC to response somewhat more quickly to 926 the sudden absence of congestion, as represented by a long current 927 loss interval. 929 6. Data Receiver Protocol 931 The receiver periodically sends feedback messages to the sender. 932 Feedback packets should normally be sent at least once per RTT, 933 unless the sender is sending at a rate of less than one packet per 934 RTT, in which case a feedback packet should be send for every data 935 packet received. A feedback packet should also be sent whenever a 936 new loss event is detected without waiting for the end of an RTT, 937 and whenever an out-of-order data packet is received that removes a 938 loss event from the history. 940 If the sender is transmitting at a high rate (many packets per RTT) 941 there may be some advantages to sending periodic feedback messages 942 more than once per RTT as this allows faster response to changing 943 RTT measurements, and more resilience to feedback packet loss. 944 However, there is little gain from sending a large number of 945 feedback messages per RTT. 947 6.1. Receiver behavior when a data packet is received 949 When a data packet is received, the receiver performs the following 950 steps: 952 1) Add the packet to the packet history. 954 2) Let the previous value of p be p_prev. Calculate the new value 955 of p as described in Section 5. 957 3) If p > p_prev, cause the feedback timer to expire, and perform 958 the actions described in Section 6.2 960 If p <= p_prev no action need be performed. 962 However an optimization might check to see if the arrival of the 963 packet caused a hole in the packet history to be filled and 964 consequently two loss intervals were merged into one. If this 965 is the case, the receiver might also send feedback immediately. 966 The effects of such an optimization are normally expected to be 967 small. 969 6.2. Expiration of feedback timer 971 When the feedback timer at the receiver expires, the action to be 972 taken depends on whether data packets have been received since the 973 last feedback was sent. 975 Let the maximum sequence number of a packet at the receiver so far 976 be S_m, and the value of the RTT measurement included in packet S_m 977 be R_m. If data packets have been received since the previous 978 feedback was sent, the receiver performs the following steps: 980 1) Calculate the average loss event rate using the algorithm 981 described above. 983 2) Calculate the measured receive rate, X_recv, based on the 984 packets received within the previous R_m seconds. 986 3) Prepare and send a feedback packet containing the information 987 described in Section 3.2.2 989 4) Restart the feedback timer to expire after R_m seconds. 991 If no data packets have been received since the last feedback was 992 sent, no feedback packet is sent, and the feedback timer is 993 restarted to expire after R_m seconds. 995 6.3. Receiver initialization 997 The receiver is initialized by the first packet that arrives at the 998 receiver. Let the sequence number of this packet be i. 1000 When the first packet is received: 1002 o Set p=0 1004 o Set X_recv = 0. 1006 o Prepare and send a feedback packet. 1008 o Set the feedback timer to expire after R_i seconds. 1010 6.3.1. Initializing the Loss History after the First Loss Event 1012 The number of packets until the first loss can not be used to 1013 compute the sending rate directly, as the sending rate changes 1014 rapidly during this time. TFRC assumes that the correct data rate 1015 after the first loss is half of the sending rate when the loss 1016 occurred. TFRC approximates this target rate by X_recv, the receive 1017 rate over the most recent round-trip time. After the first loss, 1018 instead of initializing the first loss interval to the number of 1019 packets sent until the first loss, the TFRC receiver calculates the 1020 loss interval that would be required to produce the data rate 1021 X_recv, and uses this synthetic loss interval to seed the loss 1022 history mechanism. 1024 TFRC does this by finding some value p for which the throughput 1025 equation in Section 3.1 gives a sending rate within 5% of X_recv, 1026 given the round-trip time R, and the first loss interval is then set 1027 to 1/p. If the receiver knows the segment size s used by the 1028 sender, then the receiver can use the throughput equation for X; 1029 otherwise, the receiver can meaure the receive rate in packets per 1030 second instead of bytes per second for this purpose, and use the 1031 throughput equation for X_pps. (The 5% tolerance is introduced 1032 simply because the throughput equation is difficult to invert, and 1033 we want to reduce the costs of calculating p numerically.) 1035 7. Sender-based Variants 1037 It would be possible to implement a sender-based variant of TFRC, 1038 where the receiver uses reliable delivery to send information about 1039 packet losses to the sender, and the sender computes the packet loss 1040 rate and the acceptable transmit rate. However, we do not specify 1041 the details of a sender-based variant in this document. 1043 The main advantages of a sender-based variant of TFRC would be that 1044 the sender would not have to trust the receiver's calculation of the 1045 packet loss rate. However, with the requirement of reliable 1046 delivery of loss information from the receiver to the sender, a 1047 sender-based TFRC would have much tighter constraints on the 1048 transport protocol in which it is embedded. 1050 In contrast, the receiver-based variant of TFRC specified in this 1051 document is robust to the loss of feedback packets, and therefore 1052 does not require the reliable delivery of feedback packets. It is 1053 also better suited for applications such as streaming media from web 1054 servers, where it is typically desirable to offload work from the 1055 server to the client as much as possible. 1057 The sender-based and receiver-based variants also have different 1058 properties in terms of upgrades. For example, for changes in the 1059 procedure for calculating the packet loss rate, the sender would 1060 have to be upgraded in the sender-based variant, and the receiver 1061 would have to be upgraded in the receiver-based variant. 1063 8. Implementation Issues 1065 This document has specified the TFRC congestion control mechanism, 1066 for use by applications and transport protocols. This section 1067 mentions briefly some of the few implementation issues. 1069 For t_RTO = 4*R and b = 1, the throughput equation in Section 3.1 1070 can be expressed as follows: 1072 s 1073 X = -------- 1074 R * f(p) 1076 for 1078 f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)). 1080 A table lookup could be used for the function f(p). 1082 Many of the multiplications (e.g., q and 1-q for the round-trip time 1083 average, a factor of 4 for the timeout interval) are or could be by 1084 powers of two, and therefore could be implemented as simple shift 1085 operations. 1087 We note that the optional sender mechanism for preventing 1088 oscillations described in Section 4.6 uses a square-root 1089 computation. 1091 The calculation of the average loss interval in Section 5.4 involves 1092 multiplications by the weights w_0 to w_(n-1), which for n=8 are: 1094 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2. 1096 With a minor loss of smoothness, it would be possible to use weights 1097 that were powers of two or sums of powers of two, e.g., 1099 1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25. 1101 The optional history discounting mechanism described in Section 5.5 1102 is used in the calculation of the average loss rate. The history 1103 discounting mechanism is invoked only when there has been an 1104 unusually long interval with no packet losses. For a more efficient 1105 operation, the discount factor DF_i could be restricted to be a 1106 power of two. 1108 9. Changes from RFC 3448 1110 The changes from RFC 3448 are as follows: 1112 o Changes to the initial sending rate: In RFC 3448, the initial 1113 sending rate was two packets per round trip time. In this 1114 document, the initial sending rate can be as high as four 1115 packets per round trip time, following RFC 3390. 1117 Following Section 5.1 from [RFC4342], this document also 1118 specifies that when the sending rate is reduced after an idle 1119 period, it is not reduced below the initial sending rate. In 1120 addition, when the sender has been data-limited and the sender 1121 is reducing the allowed transmit rate to twice the receive 1122 rate,, the sender doesn't reduce the allowed transmit rate to 1123 less than the initial sending rate. 1125 A larger initial sending rate is of little use if the receiver 1126 sends a feedback packet after the first packet is received, and 1127 the sender in response reduces the allowed sending rate to at 1128 most twice the receive rate. In the current document, the 1129 sender does not reduce the allowed sending rate to at most twice 1130 the receive rate in response to the first feedback packet. 1132 o RFC 3448 had contradictory text about whether the sender halved 1133 its sending rate after *two* round-trip times without receiving 1134 a feedback report, or after *four* round-trip times. This 1135 document clarifies that the sender halves its sending rate after 1136 four round-trip times without receiving a feedback report 1137 [RFC3448errata]. 1139 o Section 4.4 was clarified to specify that on the expiration of 1140 the nofeedback timer, if p = 0, step (2) applies instead of step 1141 (1) [RFC3448errata]. 1143 o A line in Section 5.5 was changed from ``for (i = 1 to n) { DF_i 1144 = 1; }'' to ``for (i = 0 to n) { DF_i = 1; }'' [RFC3448errata]. 1146 o Section 5.4 was modified to clarify the receiver's calculation 1147 of the average loss interval when the receiver has not yet seen 1148 eight loss intervals. 1150 o Section 4.1 was modified to give a specific algorithm that could 1151 be used for estimating the average segment size. 1153 10. Security Considerations 1155 TFRC is not a transport protocol in its own right, but a congestion 1156 control mechanism that is intended to be used in conjunction with a 1157 transport protocol. Therefore security primarily needs to be 1158 considered in the context of a specific transport protocol and its 1159 authentication mechanisms. 1161 Congestion control mechanisms can potentially be exploited to create 1162 denial of service. This may occur through spoofed feedback. Thus 1163 any transport protocol that uses TFRC should take care to ensure 1164 that feedback is only accepted from the receiver of the data. The 1165 precise mechanism to achieve this will however depend on the 1166 transport protocol itself. 1168 In addition, congestion control mechanisms may potentially be 1169 manipulated by a greedy receiver that wishes to receive more than 1170 its fair share of network bandwidth. A receiver might do this by 1171 claiming to have received packets that in fact were lost due to 1172 congestion. Possible defenses against such a receiver would 1173 normally include some form of nonce that the receiver must feed back 1174 to the sender to prove receipt. However, the details of such a 1175 nonce would depend on the transport protocol, and in particular on 1176 whether the transport protocol is reliable or unreliable. 1178 We expect that protocols incorporating ECN with TFRC will also want 1179 to incorporate feedback from the receiver to the sender using the 1180 ECN nonce [RFC3540]. The ECN nonce is a modification to ECN that 1181 protects the sender from the accidental or malicious concealment of 1182 marked packets. Again, the details of such a nonce would depend on 1183 the transport protocol, and are not addressed in this document. 1185 11. IANA Considerations 1187 There are no IANA actions required for this document. 1189 12. Acknowledgments 1191 We would like to acknowledge feedback and discussions on equation- 1192 based congestion control with a wide range of people, including 1193 members of the Reliable Multicast Research Group, the Reliable 1194 Multicast Transport Working Group, and the End-to-End Research 1195 Group. We would like to thank Wim Heirman, Ken Lofgren, Mike Luby, 1196 Michele R., Vladica Stanisic, Randall Stewart, Eduardo Urzaiz, 1197 Shushan Wen, and Wendy Lee (lhh@zsu.edu.cn) for feedback on earlier 1198 versions of this document, and to thank Mark Allman for his 1199 extensive feedback from using the document to produce a working 1200 implementation. 1202 13. Normative References 1204 14. Informational References 1206 [BRS99] Balakrishnan, H., Rahul, H., and Seshan, S., "An 1207 Integrated Congestion Management Architecture for 1208 Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA, 1209 September 1999. 1211 [FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, 1212 "Equation-Based Congestion Control for Unicast 1213 Applications", August 2000, Proc SIGCOMM 2000. 1215 [FHPW00a] S. Floyd, M. Handley, J. Padhye, and J. Widmer, 1216 "Equation-Based Congestion Control for Unicast 1217 Applications: the Extended Version", ICSI tech 1218 report TR-00-03, March 2000. 1220 [PFTK98] Padhye, J. and Firoiu, V. and Towsley, D. and 1221 Kurose, J., "Modeling TCP Throughput: A Simple Model 1222 and its Empirical Validation", Proc ACM SIGCOMM 1223 1998. 1225 [RFC2119] S. Bradner, Key Words For Use in RFCs to Indicate 1226 Requirement Levels, RFC 2119. 1228 [RFC2140] J. Touch, "TCP Control Block Interdependence", RFC 1229 2140, April 1997. 1231 [RFC2988] V. Paxson and M. Allman, "Computing TCP's 1232 Retransmission Timer", RFC 2988, November 2000. 1234 [RFC3168] K. Ramakrishnan and S. Floyd, "The Addition of 1235 Explicit Congestion Notification (ECN) to IP", RFC 1236 3168, September 2001. 1238 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing 1239 TCP's Initial Window", RFC 3390, October 2002. 1241 [RFC3448Err] RFC 3448 Errata, URL 1242 ``http://www.icir.org/tfrc/rfc3448.errata''. 1244 [RFC3540] Wetherall, D., Ely, D., and Spring, N., "Robust ECN 1245 Signaling with Nonces", RFC 3540, Experimental, June 1246 2003 1248 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1249 Congestion Control Protocol (DCCP)", RFC 4340, March 1250 2006. 1252 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1253 Datagram Congestion Control Protocol (DCCP) 1254 Congestion Control ID 3: TCP-Friendly Rate Control 1255 (TFRC)", RFC 4342, March 2006. 1257 [W00] Widmer, J., "Equation-Based Congestion Control", 1258 Diploma Thesis, University of Mannheim, February 1259 2000. URL "http://www.icir.org/tfrc/". 1261 15. Authors' Addresses 1262 Mark Handley, 1263 Department of Computer Science 1264 University College London 1265 Gower Street 1266 London WC1E 6BT 1267 UK 1268 EMail: M.Handley@cs.ucl.ac.uk 1270 Sally Floyd 1271 ICIR/ICSI 1272 1947 Center St, Suite 600 1273 Berkeley, CA 94708 1274 floyd@icir.org 1276 Jitendra Padhye 1277 Microsoft Research 1278 padhye@microsoft.com 1280 Joerg Widmer 1281 Lehrstuhl Praktische Informatik IV 1282 Universitat Mannheim 1283 L 15, 16 - Room 415 1284 D-68131 Mannheim 1285 Germany 1286 widmer@informatik.uni-mannheim.de 1288 Full Copyright Statement 1290 Copyright (C) The Internet Society 2006. This document is subject 1291 to the rights, licenses and restrictions contained in BCP 78, and 1292 except as set forth therein, the authors retain all their rights. 1294 This document and the information contained herein are provided on 1295 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1296 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1297 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1298 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1299 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1302 Intellectual Property 1304 The IETF takes no position regarding the validity or scope of any 1305 Intellectual Property Rights or other rights that might be claimed 1306 to pertain to the implementation or use of the technology described 1307 in this document or the extent to which any license under such 1308 rights might or might not be available; nor does it represent that 1309 it has made any independent effort to identify any such rights. 1310 Information on the procedures with respect to rights in RFC 1311 documents can be found in BCP 78 and BCP 79. 1313 Copies of IPR disclosures made to the IETF Secretariat and any 1314 assurances of licenses to be made available, or the result of an 1315 attempt made to obtain a general license or permission for the use 1316 of such proprietary rights by implementers or users of this 1317 specification can be obtained from the IETF on-line IPR repository 1318 at http://www.ietf.org/ipr. 1320 The IETF invites any interested party to bring to its attention any 1321 copyrights, patents or patent applications, or other proprietary 1322 rights that may cover technology that may be required to implement 1323 this standard. Please address the information to the IETF at ietf- 1324 ipr@ietf.org.