idnits 2.17.1 draft-ietf-dccp-rfc3448bis-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2931. 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4342, updated by this document, for RFC5378 checks: 2002-10-24) -- 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 (12 April 2008) is 5830 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) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-05) exists of draft-ietf-dccp-ccid4-02 == Outdated reference: A later version (-06) exists of draft-ietf-dccp-tfrc-faster-restart-05 -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) == Outdated reference: A later version (-07) exists of draft-ietf-tcpm-rfc2581bis-03 -- Obsolete informational reference (is this intentional?): RFC 2861 (Obsoleted by RFC 7661) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) -- Duplicate reference: RFC3448, mentioned in 'RFC3448Err', was also mentioned in 'RFC3448'. -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Floyd 3 INTERNET-DRAFT ICIR 4 Intended status: Proposed Standard M. Handley 5 Expires: October 2008 University College London 6 Obsoletes: 3448 (if approved) J. Padhye 7 Updates: 4342 (if approved) Microsoft 8 J. Widmer 9 DoCoMo 10 12 April 2008 12 TCP Friendly Rate Control (TFRC): Protocol Specification 13 draft-ietf-dccp-rfc3448bis-06.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a 47 congestion control mechanism for unicast flows operating in a best- 48 effort Internet environment. It is reasonably fair when competing 49 for bandwidth with TCP flows, but has a much lower variation of 50 throughput over time compared with TCP, making it more suitable for 51 applications such as streaming media where a relatively smooth 52 sending rate is of importance. 54 This document obsoletes RFC 3448 and updates RFC 4342. 56 Table of Contents 58 1. Introduction ..................................................12 59 2. Conventions ...................................................13 60 3. Protocol Mechanism ............................................13 61 3.1. TCP Throughput Equation ..................................14 62 3.2. Packet Contents ..........................................16 63 3.2.1. Data Packets ......................................16 64 3.2.2. Feedback Packets ..................................17 65 4. Data Sender Protocol ..........................................17 66 4.1. Measuring the Segment Size ...............................18 67 4.2. Sender Initialization ....................................19 68 4.3. Sender Behavior When a Feedback Packet is Received .......19 69 4.4. Expiration of Nofeedback Timer ...........................24 70 4.5. Reducing Oscillations ....................................26 71 4.6. Scheduling of Packet Transmissions .......................27 72 5. Calculation of the Loss Event Rate (p) ........................28 73 5.1. Detection of Lost or Marked Packets ......................28 74 5.2. Translation from Loss History to Loss Events .............29 75 5.3. Inter-loss Event Interval ................................31 76 5.4. Average Loss Interval ....................................31 77 5.5. History Discounting ......................................32 78 6. Data Receiver Protocol ........................................34 79 6.1. Receiver Behavior When a Data Packet is Received .........35 80 6.2. Expiration of Feedback Timer .............................36 81 6.3. Receiver Initialization ..................................37 82 6.3.1. Initializing the Loss History after the First Loss 83 Event ....................................................37 84 7. Sender-based Variants .........................................39 85 8. Implementation Issues .........................................39 86 8.1. Computing the Throughput Equation ........................39 87 8.2. Sender Behavior When a Feedback Packet is Received .......40 88 8.2.1. Determining If an Interval Was a Data-limited 89 Interval .................................................40 90 8.2.2. Maintaining X_recv_set ............................42 91 8.3. Sending Packets Before their Nominal Send Time ...........42 92 8.4. Calculation of the Average Loss Interval .................44 93 8.5. The Optional History Discounting Mechanism ...............44 94 9. Changes from RFC 3448 .........................................44 95 9.1. Overview of Changes ......................................44 96 9.2. Changes in each Section ..................................45 97 10. Security Considerations ......................................47 98 11. IANA Considerations ..........................................48 99 12. Acknowledgments ..............................................48 100 A. Terminology ...................................................48 101 B. The Initial Value of the Nofeedback Timer .....................51 102 C. Response to Idle or Data-limited Periods ......................51 103 C.1. Long Idle or Data-limited Periods ........................53 104 C.2. Short Idle or Data-limited Periods .......................56 105 C.3. Moderate Idle or Data-limited Periods ....................56 106 C.4. Losses During Data-Limited Periods .......................57 107 C.5. Other Patterns ...........................................61 108 C.6. Evaluating TFRC's Response to Idle Periods ...............61 109 Normative References .............................................62 110 Informational References .........................................62 111 Authors' Addresses ...............................................64 112 Full Copyright Statement .........................................64 113 Intellectual Property ............................................65 114 NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. 116 Changes from draft-ietf-dccp-rfc3448bis-05.txt: 118 * Editing in response to AD review from Lars Eggert. 119 Using normative language (MAY/SHOULD/REQUIRE/OPTIONAL/etc.), 120 fixing a few nits. 122 * Added to Maximize X_recv_set that the initial value Infinity 123 is deleted. This only matters if the sender is data-limited 124 for a number of round-trip times starting with its initial 125 start-up. 127 * Added that if this document is approved, CCID-3 and CCID-4 128 SHOULD use this document instead of RFC 3448. 130 * Editing in response to feedback from Gerrit. 132 * Clarified definition of X_Bps. Feedback from Tom Phelan. 134 * Clarified that "segment size" means user data only. 135 Feedback from Tom Phelan. 137 * A small change to the Update_limits procedure in Section 4.4. 138 Feedback from Tom Phelan. 140 * Editing in response to feedback from Gorry. This includes the 141 use of normative language. 143 Changes from draft-ietf-dccp-rfc3448bis-04.txt: 145 * Added a mechanism for decaying the value in X_recv_set 146 following a loss event in a data-limited interval, and 147 restricting recv_limit to "max (X_recv_set)" for the next 148 RTT. Also added a discussion to Appendix C of the 149 response to a loss during a data-limited period. 150 Following feedback from Gorry and Arjuna. 152 * Removed a restriction in step 4) of Section 4.3 about 153 checking if the sender was not data-limited, when the sender 154 has been in initial slow-start. It is no longer needed. 155 Feedback from Arjuna. 157 * Added pseudocode to Section 8.2.1 on "Determining If an 158 Interval Was a Data-limited Interval", fixing a bug in the 159 procedure. Feedback from Arjuna. 161 Changes from draft-ietf-dccp-rfc3448bis-03.txt: 163 * Added text that the choice of b=1 is consistent with RFC3465bis. 164 Feedback from Gorry. 166 * Typos and such reported by Arjuna. 168 * Updated terminology section, fixed typos and such. 169 Feedback from Vladimir Moltchanov. 171 * Added a section to the Appendix about how one would 172 add CWV-style behavior to TFRC for data-limited periods, 173 if one wanted to. Feedback from Gorry. 175 * Added an implementation section about X_recv_set. 177 Changes from draft-ietf-dccp-rfc3448bis-02.txt: 179 * In a data-limited period, instead of setting the receive rate to 180 Infinity, set it to the maximum of (X_recv, values in X_recv_set). 181 Step (4) of Section 4.3. 183 * Added a fix so that when data-limited and p = 0, the sender 184 does not double the allowed sending rate after each feedback 185 packet. Step (4) of Section 4.3. Problem reported by Arjuna. 187 * Added a line to the pseudocode for reducing the sending rate 188 during idle periods during initial slow-start. This fixes 189 a problem when the sender is in initial slow-start, has 190 an allowed sending rate less than twice the initial sending rate, 191 and has been idle since the nofeedback timer was set. 192 Step (1) of Section 4.4. Problem reported by Arjuna. 194 * Added one line to the pseudocode in Section 4.4 on "Expiration of 195 Nofeedback Timer" so that when the nofeedback timer expires and 196 the sender does not have an RTT sample and has not yet received 197 feedback from the receiver, we also look at whether the sender has 198 been idle during the entire nofeedback interval. 200 * General editing from feedback from Colin Perkins. 202 * General editing from feedback from Gerrit Renker. 203 This includes the following: 204 - Added a subsection to Section 8 on implementation issues about 205 "Sender Behavior When a Feedback Packet is Received". 206 - Moved Section 4.6.1 on "Sending Packets Before their Nominal 207 Send Time" to Section 8 on "Implementation Issues". 209 * Added a subsection on "Evaluating TFRC's Response to Idle Periods" 210 to the Appendix, encouraging future work on TFRC's responses to 211 idle and data-limited periods. 213 Changes from draft-ietf-dccp-rfc3448bis-01.txt: 215 * Specified that the sender is not limited by the receive rate 216 if the sender has been data-limited for an entire feedback 217 interval. 219 * Added variables "initial_rate" and "recover_rate, for the 220 initial transmit rate and the rate for resuming after an idle 221 period, for easier specification of Faster Restart (in a separate 222 document). Also added the variable "recv_limit" to specify 223 the limit on the sending rate that is computed from the receive 224 rate, and the variable "timer_limit" to specify the 225 limit on the sending rate from the expiration of the nofeedback 226 timer. 227 Explained why recover_rate is not used as lower bound 228 for nofeedback timer expirations after a data-limited period. 230 * Added Appendix C on "Response to Idle or Data-limited Periods". 232 * Revised the section on "Scheduling of Packet Transmissions" 233 to make clear what is specification, and what is 234 implementation. From Gerrit Renker. Also stated that the 235 accumulation of sending credits should be limited 236 to a round-trip time's worth of packets. 238 * For measuring the receive rate, added that after a loss event, 239 the receive rate SHOULD be measured over the most recent RTT, 240 but for simplicity of implementation, MAY be measured over 241 a slightly longer time interval. 243 * Clarified that RTT measurements do not necessarily come from 244 feedback packets; they could also come from other places, 245 e.g., from the SYN exchange. 247 * Specified that the sender may maintain unused sent credits 248 up to one RTT. This gives behavior similar to TCP. 249 Also specified that the sender should not sent packets more 250 that rtt/2 seconds before their nominal send time. 252 * Reinserted the last paragraph of Section 4.4 from RFC 3448. 253 It must have been deleted accidentally. 255 * Feedback from Arjuna Sathiaseelan: 256 - Changing W_init to be in terms of segment size s, not MSS. 258 * Changed THRESHOLD, the lower bound on the history 259 discounting parameter DF, from 0.5 to 0.25, for more 260 history discounting when the current interval is long. 262 * Relying on the sender not to use X_recv from data-limited 263 periods. This gives behavior similar to TCP, when 264 ACK-clocking is not in effect in data-limited periods. 265 The largest X_recv over the most recent two round-trip 266 times is used to limit the sending rate. This is 267 maintained using X_recv_set. Taken together, these avoid 268 problems with the first feedback packet after an idle 269 period, and this avoids problems with limitations 270 from X_recv during data-limited periods. 272 * Clarified that when the receiver receives a data packet, 273 and didn't send a feedback packet when the feedback timer 274 last expired (because no data packets were received), 275 then the receiver sends a feedback packet immediately. 277 * Clarified that the feedback packet reports the rate over 278 the last RTT, not necessarily the rate since the 279 last feedback packet was sent (if no feedback packet was 280 sent when the feedback timer last expired). 282 * Corrected earlier code designed to prevent the receive 283 rate from limiting the sending rate when the first feedback 284 packet received, or for the first feedback packet received 285 after an idle period. 287 * Clarified that we have p=0 only until the first loss event. 288 After the first loss event, p>0, and it is not possible to go 289 back to p=0. In response to old email. 291 * Clarified in Section 6.1 that the loss event rate does not 292 have to be recalculated with the arrival of each new data 293 packet. 295 * Clarified the section on Reducing Oscillations. Feedback from 296 Gerrit Renker. 298 Changes from draft-ietf-dccp-rfc3448bis-00.txt: 300 * When initializing the loss history after the first 301 data packet sent is lost or ECN-marked, TFRC uses 302 a minimum receive rate of 0.5 packets per second. 304 * For initializing the estimated packet drop rate 305 for the first loss interval when coming out of slow-start, 306 it is ok to use the maximum receive rate so far, not just 307 the receive rate in the last round-trip time. 308 Feedback from Ladan Gharai. 310 * General feedback from Gorry Fairhurst: 311 - Added a reference for RFC4828. 312 - Clarified that R_m is sender's estimate of RTT, as reported 313 in Section 3.2.1. 314 - Added a definition of terms. 315 - Added a discussion of why the initial value of the nofeedback 316 timer is two seconds, instead of three seconds for the 317 recommended initial value for TCP's retransmit timer. 319 * General feedback from Arjuna Sathiaseelan: 320 - Added more details about sending multiple feedback 321 packets per RTT. 322 - Added change to Section 4.3 to use the first feedback 323 packet, or the first feedback packet after a 324 nofeedback timer during slow-start, *if min_rate > X*. 326 * General feedback from Gerrit Renker: 327 - Changed "delta" to "t_delta". 328 - Changed X_calc to X_Bps, clarified X. 329 - Clarified send times in "Scheduling of Packet Transmissions". 330 - Changed so that tld can be initialized to either 0 or -1. 331 - Fixed Section 5.5 to say that the most recent lost 332 interval has weight 1/(0.75*n) *when there have been 333 at least eight loss intervals*. 334 - Clarified introduction about fixed-size and variable-size 335 packets. 337 * Added more about sender-based variants. 338 Feedback from Guillaume Jourjon. 340 * Corrected that the loss interval I_0 includes all transmitted 341 packets, including lost and marked packets (as defined in Section 342 5.3 in the general definition.) Email from Eddie Kohler and 343 Gerrit Renker. 345 * Not done: I didn't add a minimum value for the nofeedback 346 timer. (Why would a nofeedback timer need to be bigger 347 than max(4*R, 2*s/X)? Email discussing pros and cons from 348 Arjuna. 350 Changes from draft-floyd-rfc3448bis-00.txt: 352 * Name change to draft-ietf-dccp-rfc3448bis-00.txt. 354 * Specified the receiver's initialization of the feedback timer 355 when the first data packet does not have an estimate of the 356 RTT. From feedback from Dado Colussi. 358 * Added the procedure for sending receiver 359 feedback packets when a coarse-grained 360 timestamp is used. From RFC 4243. 362 Changes from RFC 3448: 364 * Incorporated changes in the RFC 3448 errata: 366 - "If the sender does not receive a feedback report for 367 four round trip times, it cuts its sending rate in half." 368 ("Two" changed to "four", for consistency with the rest 369 of the document. Reported by Joerg Widmer). 371 - "If the nofeedback timer expires when the sender does not 372 yet have an RTT sample, and has not yet received any 373 feedback from the receiver, or when p == 0,..." 374 (Added "or when p == 0,", reported by Wim Heirman). 376 - In Section 5.5, changed: 377 for (i = 1 to n) { DF_i = 1; } 378 to: 379 for (i = 0 to n) { DF_i = 1; } 380 Reported by Michele R. 382 * Changed RFC 3448 to correspond to the larger initial windows 383 specified in RFC 3390. This includes the following: 385 - Incorporated Section 5.1 from [RFC4342], saying that 386 when reducing the sending rate after an idle period, do not 387 reduce the sending rate below the initial sending rate. 389 - Change for a data-limited sender: 390 When the sender has been data-limited, the sender does not 391 let the receive rate limit it to a sending rate less than 392 the initial rate. 394 - Small change to slow-start: 395 Changed so that for the first feedback packet received, 396 or for the first feedback packet received after an idle 397 period, the receive rate is not used to limit the 398 sending rate. This is because the receiver might not yet 399 have seen an entire window of data. 401 * Clarified how the average loss interval is calculated when 402 the receiver has not yet seen eight loss intervals. 404 * Discussed more about estimating the average segment size: 406 - For initializing the loss history after the first loss event, 407 either the receiver knows the sender's value for s, or 408 the receiver uses the throughput equation for X_pps and does 409 not need to know an estimate for s. 411 - Added a discussion about estimating the average segment size 412 s in Section 4.1 on "Measuring the Segment Size". 414 - Changed "packet size" to "segment size". 416 END OF NOTE TO RFC EDITOR. 418 1. Introduction 420 This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a 421 congestion control mechanism designed for unicast flows operating in 422 an Internet environment and competing with TCP traffic [FHPW00]. 423 Instead of specifying a complete protocol, this document simply 424 specifies a congestion control mechanism that could be used in a 425 transport protocol such as DCCP (Datagram Congestion Control 426 Protocol) [RFC4340], in an application incorporating end-to-end 427 congestion control at the application level, or in the context of 428 endpoint congestion management [BRS99]. This document does not 429 discuss packet formats or reliability. Implementation-related 430 issues are discussed only briefly, in Section 8. 432 TFRC is designed to be reasonably fair when competing for bandwidth 433 with TCP flows, where we call a flow "reasonably fair" if its 434 sending rate is generally within a factor of two of the sending rate 435 of a TCP flow under the same conditions. However, TFRC has a much 436 lower variation of throughput over time compared with TCP, which 437 makes it more suitable for applications such as telephony or 438 streaming media where a relatively smooth sending rate is of 439 importance. 441 The penalty of having smoother throughput than TCP while competing 442 fairly for bandwidth is that TFRC responds slower than TCP to 443 changes in available bandwidth. Thus, TFRC should only be used when 444 the application has a requirement for smooth throughput, in 445 particular, avoiding TCP's halving of the sending rate in response 446 to a single packet drop. For applications that simply need to 447 transfer as much data as possible in as short a time as possible we 448 recommend using TCP, or if reliability is not required, using an 449 Additive-Increase, Multiplicative-Decrease (AIMD) congestion control 450 scheme with similar parameters to those used by TCP. 452 TFRC is designed for best performance with applications that use a 453 fixed segment size, and vary their sending rate in packets per 454 second in response to congestion. TFRC can also be used, perhaps 455 with less optimal performance, with applications that do not have a 456 fixed segment size, but where the segment size varies according to 457 the needs of the application (e.g., video applications). 459 Some applications (e.g., some audio applications) require a fixed 460 interval of time between packets and vary their segment size instead 461 of their packet rate in response to congestion. The congestion 462 control mechanism in this document is not designed for those 463 applications; TFRC-SP (Small-Packet TFRC) is a variant of TFRC for 464 applications that have a fixed sending rate in packets per second 465 but either use small packets, or vary their packet size in response 466 to congestion. TFRC-SP is specified in a separate document 467 [RFC4828]. 469 This document specifies TFRC as a receiver-based mechanism, with the 470 calculation of the congestion control information (i.e., the loss 471 event rate) in the data receiver rather in the data sender. This is 472 well-suited to an application where the sender is a large server 473 handling many concurrent connections, and the receiver has more 474 memory and CPU cycles available for computation. In addition, a 475 receiver-based mechanism is more suitable as a building block for 476 multicast congestion control. However, it is also possible to 477 implement TFRC in sender-based variants, as allowed in DCCP's 478 Congestion Control ID 3 (CCID 3) [RFC4342]. 480 This document obsoletes RFC 3448. In the transport protocol DCCP 481 (Datagram Congestion Control Protocol) [RFC4340], the Congestion 482 Control ID Profiles CCID-3 [RFC4342] and CCID-4 [CCID-4] both 483 specify the use of TFRC from RFC 3448. If this document is 484 approved, then CCID-3 and CCID-4 implementations SHOULD use this 485 document instead of RFC 3448 for the specification of TFRC. 487 The normative specification of TFRC is in Sections 3-6. Section 7 488 discusses sender-based variants, Section 8 discusses implementation 489 issues, and Section 9 gives a non-normative overview of differences 490 with RFC 3448. 492 2. Conventions 494 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 495 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 496 document are to be interpreted as described in [RFC2119]. 498 Appendix A gives a list of technical terms used in this document. 500 3. Protocol Mechanism 502 For its congestion control mechanism, TFRC directly uses a 503 throughput equation for the allowed sending rate as a function of 504 the loss event rate and round-trip time. In order to compete fairly 505 with TCP, TFRC uses the TCP throughput equation, which roughly 506 describes TCP's sending rate as a function of the loss event rate, 507 round-trip time, and segment size. We define a loss event as one or 508 more lost or marked packets from a window of data, where a marked 509 packet refers to a congestion indication from Explicit Congestion 510 Notification (ECN) [RFC3168]. 512 Generally speaking, TFRC's congestion control mechanism works as 513 follows: 515 o The receiver measures the loss event rate and feeds this 516 information back to the sender. 518 o The sender also uses these feedback messages to measure the 519 round-trip time (RTT). 521 o The loss event rate and RTT are then fed into TFRC's throughput 522 equation, and the resulting sending rate is limited to at most 523 twice the receive rate to give the allowed transmit rate X. 525 o The sender then adjusts its transmit rate to match the allowed 526 transmit rate X. 528 The dynamics of TFRC are sensitive to how the measurements are 529 performed and applied. We recommend specific mechanisms below to 530 perform and apply these measurements. Other mechanisms are 531 possible, but it is important to understand how the interactions 532 between mechanisms affect the dynamics of TFRC. 534 3.1. TCP Throughput Equation 536 Any realistic equation giving TCP throughput as a function of loss 537 event rate and RTT should be suitable for use in TFRC. However, we 538 note that the TCP throughput equation used must reflect TCP's 539 retransmit timeout behavior, as this dominates TCP throughput at 540 higher loss rates. We also note that the assumptions implicit in 541 the throughput equation about the loss event rate parameter have to 542 be a reasonable match to how the loss rate or loss event rate is 543 actually measured. While this match is not perfect for the 544 throughput equation and loss rate measurement mechanisms given 545 below, in practice the assumptions turn out to be close enough. 547 The throughput equation currently REQUIRED for TFRC is a slightly 548 simplified version of the throughput equation for Reno TCP from 549 [PFTK98]. Ideally we would prefer a throughput equation based on 550 SACK TCP, but no one has yet derived the throughput equation for 551 SACK TCP, and simulations and experiments suggest that the 552 differences between the two equations would be relatively minor 553 [FF99] (Appendix B). 555 The throughput equation for X_Bps, TCP's average sending rate in 556 bytes per second, is: 558 s 559 X_Bps = ---------------------------------------------------------- 560 R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8)*p*(1+32*p^2))) 562 Where: 564 X_Bps is TCP's average transmit rate in bytes per second. 565 (X_Bps is the same as X_calc in RFC 3448.) 567 s is the segment size in bytes (excluding IP and transport 568 protocol headers). 570 R is the round trip time in seconds. 572 p is the loss event rate, between 0 and 1.0, of the number of 573 loss events as a fraction of the number of packets transmitted. 575 t_RTO is the TCP retransmission timeout value in seconds. 577 b is the maximum number of packets acknowledged by a single TCP 578 acknowledgement. 580 Setting the TCP retransmission timeout value t_RTO: 581 Implementations SHOULD set t_RTO = 4*R. Implementations MAY choose 582 to implement a more accurate calculation of t_RTO. Implementatins 583 MAY also set t_RTO to max(4*R, one second), to match the recommended 584 minimum of one second on the RTO [RFC2988]. 586 Setting the parameter b for delayed acknowledgements: 587 Some current TCP connections use delayed acknowledgements, sending 588 an acknowledgement for every two data packets received. However, 589 TCP is also allowed to send an acknowledgement for every data 590 packet. For the revised TCP congestion control mechanisms, 591 [RFC2581bis] currently specifies that the delayed acknowledgement 592 algorithm should be used with TCP. However, [RFC2581bis] recommends 593 increasing the congestion window during congestion avoidance by one 594 segment per RTT even in the face of delayed acknowledgements, 595 consistent with a TCP throughput equation with b = 1. On an 596 experimental basis, [RFC2581bis] allows for increases of the 597 congestion window during slow-start that are also consistent with a 598 TCP throughput equation with b = 1. Thus, the use of b = 1 is 599 consistent with [RFC2581bis]. The use of b = 1 is RECOMMENDED. 601 With t_RTO=4*R and b=1, the throughput equation for X_Bps, the TCP 602 sending rate in bytes per second, can be simplified as: 604 s 605 X_Bps = ----------------------------------------------- 606 R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2)) 608 In the future, updates to this document could specify different TCP 609 equations to be substituted for this equation. The requirement is 610 that the throughput equation be a reasonable approximation of the 611 sending rate of TCP for conformant TCP congestion control. 613 The throughput equation can also be expressed in terms of X_pps, the 614 sending rate in packets per second, with 616 X_pps = X_Bps / s . 618 The parameters s (segment size), p (loss event rate) and R (RTT) 619 need to be measured or calculated by a TFRC implementation. The 620 measurement of s is specified in Section 4.1, measurement of R is 621 specified in Section 4.3, and measurement of p is specified in 622 Section 5. In the rest of this document data rates are measured in 623 bytes per second unless otherwise specified. 625 3.2. Packet Contents 627 Before specifying the sender and receiver functionality, we describe 628 the contents of the data packets sent by the sender and feedback 629 packets sent by the receiver. As TFRC will be used along with a 630 transport protocol, we do not specify packet formats, as these 631 depend on the details of the transport protocol used. 633 3.2.1. Data Packets 635 Each data packet sent by the data sender contains the following 636 information: 638 o A sequence number. This number MUST be incremented by one for 639 each data packet transmitted. The field must be sufficiently 640 large that it does not wrap causing two different packets with 641 the same sequence number to be in the receiver's recent packet 642 history at the same time. 644 o A timestamp indicating when the packet is sent. We denote by 645 ts_i the timestamp of the packet with sequence number i. The 646 resolution of the timestamp SHOULD typically be measured in 647 milliseconds. 649 This timestamp is used by the receiver to determine which losses 650 belong to the same loss event. The timestamp is also echoed by 651 the receiver to enable the sender to estimate the round-trip 652 time, for senders that do not save timestamps of transmitted 653 data packets. 655 We note that as an alternative to a timestamp incremented in 656 milliseconds, a "timestamp" that increments every quarter of a 657 round-trip time MAY be used for determining when losses belong 658 to the same loss event, in the context of a protocol where this 659 is understood by both sender and receiver, and where the sender 660 saves the timestamps of transmitted data packets. 662 o The sender's current estimate of the round trip time. The 663 estimate reported in packet i is denoted by R_i. The round-trip 664 time estimate is used by the receiver, along with the timestamp, 665 to determine when multiple losses belong to the same loss event. 666 The round-trip time estimate is also used by the receiver to 667 determine the interval to use for calculating the receive rate, 668 and to determine when to send feedback packets. 670 If the sender sends a coarse-grained "timestamp" that increments 671 every quarter of a round-trip time, as discussed above, then the 672 sender is not required to send its current estimate of the round 673 trip time. 675 3.2.2. Feedback Packets 677 Each feedback packet sent by the data receiver contains the 678 following information: 680 o The timestamp of the last data packet received. We denote this 681 by t_recvdata. If the last packet received at the receiver has 682 sequence number i, then t_recvdata = ts_i. 683 This timestamp is used by the sender to estimate the round-trip 684 time, and is only needed if the sender does not save timestamps 685 of transmitted data packets. 687 o The amount of time elapsed between the receipt of the last data 688 packet at the receiver, and the generation of this feedback 689 report. We denote this by t_delay. 691 o The rate at which the receiver estimates that data was received 692 in the previous round-trip time. We denote this by X_recv. 694 o The receiver's current estimate of the loss event rate p. 696 4. Data Sender Protocol 698 The data sender sends a stream of data packets to the data receiver 699 at a controlled rate. When a feedback packet is received from the 700 data receiver, the data sender changes its sending rate, based on 701 the information contained in the feedback report. If the sender does 702 not receive a feedback report for four round trip times, then the 703 sender cuts its sending rate in half. This is achieved by means of 704 a timer called the nofeedback timer. 706 We specify the sender-side protocol in the following steps: 708 o Measurement of the mean segment size being sent. 710 o Sender initialization. 712 o The sender behavior when a feedback packet is received. 714 o The sender behavior when the nofeedback timer expires. 716 o Oscillation prevention (optional) 718 o Scheduling of packet transmission and allowed burstiness. 720 4.1. Measuring the Segment Size 722 The TFRC sender uses the segment size s in the throughput equation, 723 in the setting of the maximum receive rate and the minimum and 724 initial sending rates, and in the setting of the nofeedback timer. 725 The TFRC receiver MAY use the average segment size s in initializing 726 the loss history after the first loss event. As specified in 727 Section 6.3.1, if the TFRC receiver does not know the segment size s 728 used by the sender, the TFRC receiver MAY instead use the arrival 729 rate in packets per second in initializing the loss history. 731 The segment size is normally known to an application. This may not 732 be so in two cases: 734 1) The segment size naturally varies depending on the data. In 735 this case, although the segment size varies, that variation is 736 not coupled to the transmit rate. The TFRC sender can either 737 compute the average segment size or use the maximum segment size 738 for the segment size s. 740 2) The application needs to change the segment size rather than the 741 number of segments per second to perform congestion control. 742 This would normally be the case with packet audio applications 743 where a fixed interval of time needs to be represented by each 744 packet. Such applications need to have a completely different 745 way of measuring parameters. 747 For the first class of applications where the segment size varies 748 depending on the data, the sender SHOULD estimate the segment size s 749 as the average segment size over the last four loss intervals. The 750 sender MAY estimate the average segment size over longer time 751 intervals, if so desired. 753 The second class of applications are discussed separately in a 754 separate document on TFRC-SP [RFC4828]. For the remainder of this 755 section we assume the sender can estimate the segment size, and that 756 congestion control is performed by adjusting the number of packets 757 sent per second. 759 4.2. Sender Initialization 761 The initial values for X (the allowed sending rate in bytes per 762 second) and tld (the Time Last Doubled during slow-start, in 763 seconds) are undefined until they are set as described below. If 764 the sender is ready to send data when it does not yet have a round 765 trip sample, the value of X is set to s bytes per second, for 766 segment size s, the nofeedback timer is set to expire after two 767 seconds, and tld is set to 0 (or to -1, either one is okay). Upon 768 receiving the first round trip time measurement (e.g., after the 769 first feedback packet or the SYN exchange from connection set-up, or 770 from a previous connection [RFC2140]), tld is set to the current 771 time, and the allowed transmit rate X is set to the initial_rate, 772 specified as W_init/R, for W_init based on [RFC3390]: 774 W_init = min(4*MSS, max(2*MSS, 4380)). 776 In computing W_init, instead of using MSS, the TFRC sender SHOULD 777 use the maximum segment size to be used for the initial round-trip 778 time of data, if that is known by the TFRC sender when X is 779 initialized. 781 For responding to the initial feedback packet, this replaces step 782 (4) of Section 4.3 below. 784 Appendix B explains why the initial value of TFRC's nofeedback timer 785 is set to two seconds, instead of the recommended initial value of 786 three seconds for TCP's retransmit timer from [RFC2988]. 788 4.3. Sender Behavior When a Feedback Packet is Received 790 The sender knows its current allowed sending rate X, and maintains 791 an estimate of the current round trip time R. The sender also 792 maintains X_recv_set as a small set of recent X_recv values 793 (typically only two values). 795 Initialization: X_recv_set is first initialized to contain a single 796 item, with value Infinity. (As a implementation-specific issue, 797 X_recv_set MAY be initialized to a large number instead of to 798 Infinity, e.g., to the largest integer that is easily 799 representable). 801 When a feedback packet is received by the sender at time t_now, the 802 current time in seconds, the following actions MUST be performed. 804 1) Calculate a new round trip sample: 806 R_sample = (t_now - t_recvdata) - t_delay. 808 As described in Section 3.2.2, t_delay gives the elapsed time at 809 the receiver. 811 2) Update the round trip time estimate: 813 If no feedback has been received before { 814 R = R_sample; 815 } Else { 816 R = q*R + (1-q)*R_sample; 817 } 819 TFRC is not sensitive to the precise value for the filter 820 constant q, but a default value of 0.9 is RECOMMENDED. 822 3) Update the timeout interval: 824 RTO = max(4*R, 2*s/X) 826 4) Update the allowed sending rate as follows. This procedure uses 827 the variables t_mbi and recv_limit: 829 t_mbi: the maximum backoff interval of 64 seconds. 830 recv_limit: the limit on the sending rate computed from 831 X_recv_set. 833 This procedure also uses the procedures Maximize X_recv_set() 834 and Update X_recv_set(), which are defined below. 836 The procedure for updating the allowed sending rate: 838 If (the entire interval covered by the feedback packet 839 was a data-limited interval) { 840 If (the feedback packet reports a new loss event or an 841 increase in the loss event rate p) { 842 Halve entries in X_recv_set; 843 X_recv = 0.85 * X_recv; 844 Maximize X_recv_set(); 845 recv_limit = max (X_recv_set); 846 } Else { 847 Maximize X_recv_set(); 848 recv_limit = 2 * max (X_recv_set); 849 } 850 } Else { // typical behavior 851 Update X_recv_set(); 852 recv_limit = 2 * max (X_recv_set); 853 } 854 If (p > 0) { // congestion avoidance phase 855 Calculate X_Bps using the TCP throughput equation. 856 X = max(min(X_Bps, recv_limit), s/t_mbi); 857 } Else if (t_now - tld >= R) } 858 // initial slow-start 859 X = max(min(2*X, recv_limit), initial_rate); 860 tld = t_now; 861 } 863 5) If oscillation reduction is used, calculate the instantaneous 864 transmit rate X_inst, following Section 4.5. 866 6) Reset the nofeedback timer to expire after RTO seconds. 868 The procedure for maximizing X_recv_set keeps a single value, the 869 largest value from X_recv_set and the new X_recv. 871 Maximize X_recv_set(): 872 Add X_recv to X_recv_set; 873 Delete initial value Infinity from X_recv_set, 874 if it is still a member. 875 Set the timestamp of the largest item to the current time; 876 Delete all other items. 878 The procedure for updating X_recv_set keeps a set of X_recv values 879 with timestamps from the most recent two round-trip times. 881 Update X_recv_set(): 882 Add X_recv to X_recv_set; 883 Delete from X_recv_set values older than 884 two round-trip times. 886 Definition of a data-limited interval: 887 We define a sender as data-limited any time it is not sending as 888 much as it is allowed to send. We define an interval as a 'data- 889 limited interval' if the sender was data-limited over the *entire* 890 interval; Section 8.2.1 discusses implementation issues for a sender 891 in determining if an interval was a data-limited interval. The term 892 `data-limited interval' is used in the first "if" condition in step 893 (4), which prevents a sender from having to reduce its sending rate 894 as a result of a feedback packet reporting the receive rate from a 895 data-limited period. 897 As an example, consider a sender that is sending at its full allowed 898 rate, except that it is sending packets in pairs, rather than 899 sending each packet as soon as it can. Such a sender is considered 900 data-limited part of the time, because it is not always sending 901 packets as soon as it can. However, consider an interval that 902 covers this sender's transmission of at least two data packets; 903 such an interval does not meet the definition of a data-limited 904 interval, because the sender was not data-limited *over the entire 905 interval*. 907 X_recv_set and the first feedback packet: 908 Because X_recv_set is initialized with a single item, with value 909 Infinity, recv_limit is set to Infinity for the first two round-trip 910 times of the connection. As a result, the sending rate is not 911 limited by the receive rate during that period. This avoids the 912 problem of the sending rate being limited by the value of X_recv 913 from the first feedback packet, which reports only one segment 914 received in the last round-trip time, 916 The interval covered by a feedback packet: 917 How does the sender determine the period covered by a feedback 918 packet? This is discussed in more detail in Section 8.2. In 919 general, the receiver will be sending a feedback packet once per 920 round-trip time, so typically the sender will be able to determine 921 exactly the period covered by the current feedback packet from the 922 previous feedback packet. However, in cases when the previous 923 feedback packet was lost, or when the receiver sends a feedback 924 packet early because it detected a lost or ECN-marked packet, the 925 sender will have to estimate the interval covered by the feedback 926 packet. As specified in Section 6.2, each feedback packet sent by 927 the receiver covers a round-trip time, for the round-trip time 928 estimate R_m maintained by the receiver R_m seconds before the 929 feedback packet was sent. 931 The response to a loss during a data-limited interval: 932 In TFRC, after the initial slow-start, the sender always updates the 933 calculated transmit rate X_Bps after a feedback packet is received, 934 and the allowed sending rate X is always limited by X_Bps. However, 935 during a data-limited interval, when the actual sending rate is 936 usually below X_Bps, the sending rate is still limited by 937 recv_limit, derived from X_recv_set. If the sender is data-limited, 938 possibly with a varying sending rate from one round-trip time to the 939 next, and is experiencing losses, then we decrease the entry in 940 X_recv_set in order to reduce the allowed sending rate. 942 The sender can detect a loss event during a data-limited period 943 either from explicit feedback from the receiver, or from a reported 944 increase in the loss event rate. When the sender receives a 945 feedback packet reporting such a loss event in a data-limited 946 interval, the sender limits the allowed increases in the sending 947 rate during the data-limited interval. 949 The initial slow-start phase: 950 Note that when p=0, the sender has not yet learned of any loss 951 events, and the sender is in the initial slow-start phase. In this 952 initial slow-start phase, the sender can approximately double the 953 sending rate each round-trip time until a loss occurs. The 954 initial_rate term in step (4) gives a minimum allowed sending rate 955 during slow-start of the initial allowed sending rate. 957 We note that if the sender is data-limited during slow-start, or if 958 the connection is limited by the path bandwidth, then the sender is 959 not necessarily able to double its sending rate each round-trip 960 time; the sender's sending rate is limited to at most twice the past 961 receive rate, or at most initial_rate, whichever is larger. This is 962 similar to TCP's behavior, where the sending rate is limited by the 963 rate of incoming acknowledgement packets as well as by the 964 congestion window. Thus in TCP's Slow-Start, for the most 965 aggressive case of the TCP receiver acknowledging every data packet, 966 the TCP sender's sending rate is limited to at most twice the rate 967 of these incoming acknowledgment packets. 969 The minimum allowed sending rate: 970 The term s/t_mbi ensures that when p > 0, the sender is allowed to 971 send at least one packet every 64 seconds. 973 4.4. Expiration of Nofeedback Timer 975 This section specifies the sender's response to a nofeedback timer. 976 The nofeedback timer could expire because of an idle period, or 977 because of data or feedback packets dropped in the network. 979 This section uses the variable recover_rate. If the TFRC sender has 980 been idle ever since the nofeedback timer was set, the allowed 981 sending rate is not reduced below the recover_rate. For this 982 document, the recover_rate is set to the initial_rate. Future 983 updates to this specification may explore other possible values for 984 the recover_rate. 986 If the nofeedback timer expires, the sender MUST perform the 987 following actions: 989 1) Cut the allowed sending rate in half. 991 If the nofeedback timer expires when the sender has had at least 992 one RTT measurement, the allowed sending rate is reduced by 993 modifying X_recv_set as described in the pseudocode below 994 (including item (2)). In the general case, the sending rate is 995 limited to at most twice X_recv. Modifying X_recv_set limits 996 the sending rate, but still allows the sender to slow-start, 997 doubling its sending rate each RTT, if feedback messages resume 998 reporting no losses. 1000 If the sender has been idle since this nofeedback timer was set 1001 and X_recv is less than the recover_rate, then the allowed 1002 sending rate is not halved, and X_recv_set is not changed. This 1003 ensures that the allowed sending rate is not reduced to less 1004 than half the recover_rate as a result of an idle period. 1006 In the general case, the allowed sending rate is halved in 1007 response to the expiration of the nofeedback timer. The 1008 details, in the pseudocode below, depend on whether the sender 1009 is in slow-start, is in congestion avoidance limited by X_recv, 1010 or is in congestion avoidance limited by the throughput 1011 equation. 1013 X_recv = max (X_recv_set); 1014 If (sender does not have an RTT sample, 1015 has not received any feedback from receiver, 1016 and has not been idle ever since the nofeedback timer 1017 was set) { 1018 // We do not have X_Bps or recover_rate yet. 1019 // Halve the allowed sending rate. 1020 X = max(X/2, s/t_mbi); 1021 } Else if (((p>0 && X_recv < recover_rate) or 1022 (p==0 && X < 2 * recover_rate)), and 1023 sender has been idle ever 1024 since nofeedback timer was set) { 1025 // Don't halve the allowed sending rate. 1026 Do nothing; 1027 } Else if (p==0) { 1028 // We do not have X_Bps yet. 1029 // Halve the allowed sending rate. 1030 X = max(X/2, s/t_mbi); 1031 } Else if (X_Bps > 2*X_recv)) { 1032 // 2*X_recv was already limiting the sending rate. 1033 // Halve the allowed sending rate. 1034 Update_Limits(X_recv;) 1035 } Else { 1036 // The sending rate was limited by X_Bps, not by X_recv. 1037 // Halve the allowed sending rate. 1038 Update_Limits(X_Bps/2); 1039 } 1041 The term s/t_mbi limits the backoff to one packet every 64 1042 seconds. 1044 The procedure Update_Limits() uses the variable timer_limit for 1045 the limit on the sending rate computed from the expiration of 1046 the nofeedback timer, as follows: 1048 Update_Limits(timer_limit): 1049 If (timer_limit < s/t_mbi) 1050 timer_limit = s/t_mbi; 1051 Replace X_recv_set contents with the single item 1052 timer_limit/2; 1053 Recalculate X as in steps (4) and (5) of Section 4.3; 1055 2) Restart the nofeedback timer to expire after max(4*R, 2*s/X) 1056 seconds. 1058 If the sender has been data-limited but not idle since the 1059 nofeedback timer was set, it is possible that the nofeedback timer 1060 expired because data or feedback packets were dropped in the 1061 network. In this case, the nofeedback timer is the backup mechanism 1062 for the sender to detect these losses, similar to the retransmit 1063 timer in TCP. 1065 Note that when the sender stops sending data for a period of time, 1066 the receiver will stop sending feedback. When the sender's 1067 nofeedback timer expires, the sender could use the procedure above 1068 to limit the sending rate. If the sender subsequently starts to 1069 send again, X_recv_set will be used to limit the transmit rate, and 1070 slow-start behavior will occur until the transmit rate reaches 1071 X_Bps. 1073 The TFRC sender's reduction of the allowed sending rate after the 1074 nofeedback timer expires is similar to TCP's reduction of the 1075 congestion window cwnd after each RTO seconds of an idle period, for 1076 TCP with Congestion Window Validation [RFC2861]. 1078 4.5. Reducing Oscillations 1080 To reduce oscillations in queueing delay and sending rate in 1081 environments with a low degree of statistical multiplexing at the 1082 congested link, it is RECOMMENDED that the sender reduce the 1083 transmit rate as the queuing delay (and hence RTT) increases. To do 1084 this the sender maintains R_sqmean, a long-term estimate of the 1085 square root of the RTT, and modifies its sending rate depending on 1086 how the square root of R_sample, the most recent sample of the RTT, 1087 differs from the long-term estimate. The long-term estimate 1088 R_sqmean is set as follows: 1090 If no feedback has been received before { 1091 R_sqmean = sqrt(R_sample); 1092 } Else { 1093 R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample); 1094 } 1096 Thus R_sqmean gives the exponentially weighted moving average of the 1097 square root of the RTT samples. The constant q2 should be set 1098 similarly to q, the constant used in the round trip time estimate R. 1099 A value of 0.9 as the default for q2 is RECOMMENDED. 1101 When sqrt(R_sample) is greater than R_sqmean then the current round- 1102 trip time is greater than the long-term average, implying that 1103 queueing delay is probably increasing. In this case, the transmit 1104 rate is decreased to minimize oscillations in queueing delay. 1106 The sender obtains the base allowed transmit rate, X, as described 1107 in step (4) of Section 4.3 above. It then calculates a modified 1108 instantaneous transmit rate X_inst, as follows: 1110 X_inst = X * R_sqmean / sqrt(R_sample); 1111 If (p > 0) { // congestion avoidance phase 1112 X_inst = max(X_inst, s/t_mbi) 1113 } Else if (t_now - tld >= R) { // initial slow-start 1114 X_inst = max(X_inst, s/R) 1115 } 1117 Because we are using square roots, there is generally only a 1118 moderate difference between the instantaneous transmit rate X_inst 1119 and the allowed transmit rate X. For example, in a somewhat extreme 1120 case when the current RTT sample R_sample is twice as large as the 1121 long-term average, then sqrt(R_sample) will be roughly 1.44 times 1122 R_sqmean, and the allowed transmit rate will be reduced by a factor 1123 of roughly 0.7. 1125 We note that this modification for reducing oscillatory behavior is 1126 not always needed, especially if the degree of statistical 1127 multiplexing in the network is high. We also note that the measured 1128 round-trip time is not necessarily strongly correlated with the data 1129 packet queueing delay. However, this modification SHOULD be 1130 implemented because it makes TFRC behave better in some environments 1131 with a low level of statistical multiplexing. The performance of 1132 this modification is illustrated in Section 3.1.3 of [FHPW00]. If 1133 it is not implemented, implementations SHOULD use a very low value 1134 of the weight q for the average round-trip time. 1136 4.6. Scheduling of Packet Transmissions 1138 As TFRC is rate-based, and as operating systems typically cannot 1139 schedule events precisely, it is necessary to be opportunistic about 1140 sending data packets so that the correct average rate is maintained 1141 despite the coarse-grain or irregular scheduling of the operating 1142 system. To help maintain the correct average sending rate, the TFRC 1143 sender MAY send some packets before their nominal send time. 1145 In addition, the scheduling of packet transmissions controls the 1146 allowed burstiness of senders after an idle or data-limited period. 1147 The TFRC sender MAY accumulate sending 'credits' for past unused 1148 send times; this allows the TFRC sender to send a burst of data 1149 after an idle or data-limited period. To compare with TCP, TCP may 1150 send up to a round-trip time's worth of packets in a single burst, 1151 but never more. As examples, packet bursts can be sent by TCP when 1152 an ACK arrives acknowledging a window of data, or when a data- 1153 limited sender suddenly has a window of data to send after a delay 1154 of nearly a round-trip time. 1156 To limit burstiness, a TFRC implementation MUST prevent bursts of 1157 arbitrary size. This limit MUST be less than or equal to one round- 1158 trip time's worth of packets. A TFRC implementation MAY limit 1159 bursts to less than a round-trip time's worth of packets. 1161 As an implementation-specific example, a sending loop could 1162 calculate the correct inter-packet interval, t_ipi, as follows: 1164 t_ipi = s/X_inst; 1166 Let t_now be the current time and i be a natural number, i = 0, 1, 1167 ..., with t_i the nominal send time for the i-th packet. Then the 1168 nominal send time t_(i+1) would derive recursively as 1170 t_0 = t_now, 1171 t_(i+1) = t_i + t_ipi. 1173 For TFRC senders allowed to accumulate sending credits for unused 1174 send time over the last T seconds, the sender would be allowed to 1175 use unused nominal send times t_j for t_j < now - T, for T set to 1176 the round-trip time. 1178 5. Calculation of the Loss Event Rate (p) 1180 Obtaining an accurate and stable measurement of the loss event rate 1181 is of primary importance for TFRC. Loss rate measurement is 1182 performed at the receiver, based on the detection of lost or marked 1183 packets from the sequence numbers of arriving packets. We describe 1184 this process before describing the rest of the receiver protocol. 1185 If the receiver has not yet detected a lost or marked packet, then 1186 the receiver does not calculate the loss event rate, but reports a 1187 loss event rate of zero. 1189 5.1. Detection of Lost or Marked Packets 1191 TFRC assumes that all packets contain a sequence number that is 1192 incremented by one for each packet that is sent. For the purposes 1193 of this specification, it is REQUIRED that if a lost packet is 1194 retransmitted, the retransmission is given a new sequence number 1195 that is the latest in the transmission sequence, and not the same 1196 sequence number as the packet that was lost. If a transport 1197 protocol has the requirement that it must retransmit with the 1198 original sequence number, then the transport protocol designer must 1199 figure out how to distinguish delayed from retransmitted packets and 1200 how to detect lost retransmissions. 1202 The receiver maintains a data structure that keeps track of which 1203 packets have arrived and which are missing. For the purposes of 1204 specification, we assume that the data structure consists of a list 1205 of packets that have arrived along with the receiver timestamp when 1206 each packet was received. In practice this data structure will 1207 normally be stored in a more compact representation, but this is 1208 implementation-specific. 1210 The loss of a packet is detected by the arrival of at least NDUPACK 1211 packets with a higher sequence number than the lost packet, for 1212 NDUPACK set to 3. The requirement for NDUPACK subsequent packets is 1213 the same as with TCP, and is to make TFRC more robust in the 1214 presence of reordering. In contrast to TCP, if a packet arrives 1215 late (after NDUPACK subsequent packets arrived) in TFRC, the late 1216 packet can fill the hole in TFRC's reception record, and the 1217 receiver can recalculate the loss event rate. Future versions of 1218 TFRC might make the requirement for NDUPACK subsequent packets 1219 adaptive based on experienced packet reordering, but such a 1220 mechanism is not part of the current specification. 1222 For an ECN-capable connection, a marked packet is detected as a 1223 congestion event as soon as it arrives, without having to wait for 1224 the arrival of subsequent packets. 1226 5.2. Translation from Loss History to Loss Events 1228 TFRC requires that the loss fraction be robust to several 1229 consecutive packets lost or marked in the same loss event. This is 1230 similar to TCP, which (typically) only performs one halving of the 1231 congestion window during any single RTT. Thus the receiver needs to 1232 map the packet loss history into a loss event record, where a loss 1233 event is one or more packets lost or marked in an RTT. To perform 1234 this mapping, the receiver needs to know the RTT to use, and this is 1235 supplied periodically by the sender, typically as control 1236 information piggy-backed onto a data packet. TFRC is not sensitive 1237 to how the RTT measurement sent to the receiver is made, but it is 1238 RECOMMENDED to use the sender's calculated RTT, R, (see Section 4.3) 1239 for this purpose. 1241 To determine whether a lost or marked packet should start a new loss 1242 event, or be counted as part of an existing loss event, we need to 1243 compare the sequence numbers and timestamps of the packets that 1244 arrived at the receiver. For a marked packet S_new, its reception 1245 time T_new can be noted directly. For a lost packet, we can 1246 interpolate to infer the nominal "arrival time". Assume: 1248 S_loss is the sequence number of a lost packet. 1250 S_before is the sequence number of the last packet to arrive, 1251 before any packet arrivals with a sequence number above S_loss, 1252 with a sequence number below S_loss. 1254 S_after is the sequence number of the first packet to arrive 1255 after S_before with a sequence number above S_loss. 1257 S_max is the largest sequence number. 1259 Therefore, S_before < S_loss < S_after <= S_max. 1261 T_loss is the nominal estimated arrival time for the lost 1262 packet. 1264 T_before is the reception time of S_before. 1266 T_after is the reception time of S_after. 1268 Note that due to reordering, T_before could be either before or 1269 after T_after. 1271 For a lost packet S_loss, we can interpolate its nominal "arrival 1272 time" at the receiver from the arrival times of S_before and 1273 S_after. Thus: 1275 T_loss = T_before + ( (T_after - T_before) 1276 * (S_loss - S_before)/(S_after - S_before) ); 1278 To address sequence number wrapping, let S_MAX be the maximum 1279 sequence number using by the particular implementation. In this 1280 case, we can interpolate the arrival time T_loss as follows: 1282 T_loss = T_before + (T_after - T_before) 1283 * Dist(S_loss, S_before)/Dist(S_after, S_before) 1285 where 1287 Dist(S_A, S_B) = (S_A + S_MAX - S_B) % S_MAX 1289 If the lost packet S_old was determined to have started the previous 1290 loss event, and we have just determined that S_new has been lost, 1291 then we interpolate the nominal arrival times of S_old and S_new, 1292 called T_old and T_new respectively. 1294 If T_old + R >= T_new, then S_new is part of the existing loss 1295 event. Otherwise S_new is the first packet in a new loss event. 1297 5.3. Inter-loss Event Interval 1299 If a loss interval, A, is determined to have started with packet 1300 sequence number S_A and the next loss interval, B, started with 1301 packet sequence number S_B, then the number of packets in loss 1302 interval A is given by (S_B - S_A). Thus, loss interval A contains 1303 all of the packets transmitted by the sender starting with the first 1304 packet transmitted in loss interval A, and ending with but not 1305 including the first packet transmitted in loss interval B. 1307 5.4. Average Loss Interval 1309 To calculate the loss event rate p, we first calculate the average 1310 loss interval. This is done using a filter that weights the n most 1311 recent loss event intervals in such a way that the measured loss 1312 event rate changes smoothly. If the receiver has not yet seen a 1313 lost or marked packet, then the receiver does not calculate the 1314 average loss interval. 1316 Weights w_0 to w_(n-1) are calculated as: 1318 If (i < n/2) { 1319 w_i = 1; 1320 } Else { 1321 w_i = 2 * (n-i)/(n+2); 1322 } 1324 Thus if n=8, the values of w_0 to w_7 are: 1326 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2 1328 The value n for the number of loss intervals used in calculating the 1329 loss event rate determines TFRC's speed in responding to changes in 1330 the level of congestion. It is RECOMMENDED to set the value n to 8. 1331 TFRC SHOULD NOT use values of n greater than 8, for traffic that 1332 might compete in the global Internet with TCP. At the very least, 1333 safe operation with values of n greater than 8 would require a 1334 slight change to TFRC's mechanisms, to include a more severe 1335 response to two or more round-trip times with heavy packet loss. 1337 When calculating the average loss interval we need to decide whether 1338 to include the current loss interval, defined as the loss interval 1339 containing the most recent loss event. We only include the current 1340 loss interval if it is sufficiently large to increase the average 1341 loss interval. 1343 Let the most recent loss intervals be I_0 to I_k, where I_0 is the 1344 current loss interval. If there have been at least n loss 1345 intervals, then k is set to n; otherwise k is the maximum number of 1346 loss intervals seen so far. We calculate the average loss interval 1347 I_mean as follows: 1349 I_tot0 = 0; 1350 I_tot1 = 0; 1351 W_tot = 0; 1352 for (i = 0 to k-1) { 1353 I_tot0 = I_tot0 + (I_i * w_i); 1354 W_tot = W_tot + w_i; 1355 } 1356 for (i = 1 to k) { 1357 I_tot1 = I_tot1 + (I_i * w_(i-1)); 1358 } 1359 I_tot = max(I_tot0, I_tot1); 1360 I_mean = I_tot/W_tot; 1362 The loss event rate, p is simply: 1364 p = 1 / I_mean; 1366 5.5. History Discounting 1368 As described in Section 5.4, when there have been at least n loss 1369 intervals, the most recent loss interval is only assigned 1/(0.75*n) 1370 of the total weight in calculating the average loss interval, 1371 regardless of the size of the most recent loss interval. This 1372 section describes an OPTIONAL history discounting mechanism, 1373 discussed further in [FHPW00a] and [W00], that allows the TFRC 1374 receiver to adjust the weights, concentrating more of the relative 1375 weight on the most recent loss interval, when the most recent loss 1376 interval is more than twice as large as the computed average loss 1377 interval. 1379 To carry out history discounting, we associate a discount factor 1380 DF_i with each loss interval L_i, for i > 0, where each discount 1381 factor is a floating point number. The discount array maintains the 1382 cumulative history of discounting for each loss interval. At the 1383 beginning, the values of DF_i in the discount array are initialized 1384 to 1: 1386 for (i = 0 to n) { 1387 DF_i = 1; 1388 } 1390 History discounting also uses a general discount factor DF, also a 1391 floating point number, that is also initialized to 1. First we show 1392 how the discount factors are used in calculating the average loss 1393 interval, and then we describe later in this section how the 1394 discount factors are modified over time. 1396 As described in Section 5.4 the average loss interval is calculated 1397 using the n previous loss intervals I_1, ..., I_n and the current 1398 loss interval I_0. The computation of the average loss interval 1399 using the discount factors is a simple modification of the procedure 1400 in Section 5.4, as follows: 1402 I_tot0 = I_0 * w_0; 1403 I_tot1 = 0; 1404 W_tot0 = w_0; 1405 W_tot1 = 0; 1406 for (i = 1 to n-1) { 1407 I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF); 1408 W_tot0 = W_tot0 + w_i * DF_i * DF; 1409 } 1410 for (i = 1 to n) { 1411 I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i); 1412 W_tot1 = W_tot1 + w_(i-1) * DF_i; 1413 } 1414 p = min(W_tot0/I_tot0, W_tot1/I_tot1); 1416 The general discounting factor DF is updated on every packet arrival 1417 as follows. First, the receiver computes the weighted average I_mean 1418 of the loss intervals I_1, ..., I_n: 1420 I_tot = 0; 1421 W_tot = 0; 1422 for (i = 1 to n) { 1423 W_tot = W_tot + w_(i-1) * DF_i; 1424 I_tot = I_tot + (I_i * w_(i-1) * DF_i); 1425 } 1426 I_mean = I_tot / W_tot; 1428 This weighted average I_mean is compared to I_0, the size of current 1429 loss interval. If I_0 is greater than twice I_mean, then the new 1430 loss interval is considerably larger than the old ones, and the 1431 general discount factor DF is updated to decrease the relative 1432 weight on the older intervals, as follows: 1434 if (I_0 > 2 * I_mean) { 1435 DF = 2 * I_mean/I_0; 1436 if (DF < THRESHOLD) { 1437 DF = THRESHOLD; 1438 } 1439 } else { 1440 DF = 1; 1441 } 1443 A nonzero value for THRESHOLD ensures that older loss intervals from 1444 an earlier time of high congestion are not discounted entirely. We 1445 recommend a THRESHOLD of 0.25. Note that with each new packet 1446 arrival, I_0 will increase further, and the discount factor DF will 1447 be updated. 1449 When a new loss event occurs, the current interval shifts from I_0 1450 to I_1, loss interval I_i shifts to interval I_(i+1), and the loss 1451 interval I_n is forgotten. The previous discount factor DF has to 1452 be incorporated into the discount array. Because DF_i carries the 1453 discount factor associated with loss interval I_i, the DF_i array 1454 has to be shifted as well. This is done as follows: 1456 for (i = 1 to n) { 1457 DF_i = DF * DF_i; 1458 } 1459 for (i = n-1 to 0 step -1) { 1460 DF_(i+1) = DF_i; 1461 } 1462 I_0 = 1; 1463 DF_0 = 1; 1464 DF = 1; 1466 This completes the description of the optional history discounting 1467 mechanism. We emphasize that this is an OPTIONAL mechanism whose 1468 sole purpose is to allow TFRC to respond somewhat more quickly to 1469 the sudden absence of congestion, as represented by a long current 1470 loss interval. 1472 6. Data Receiver Protocol 1474 The receiver periodically sends feedback messages to the sender. 1475 Feedback packets SHOULD normally be sent at least once per RTT, 1476 unless the sender is sending at a rate of less than one packet per 1477 RTT, in which case a feedback packet SHOULD be send for every data 1478 packet received. A feedback packet SHOULD also be sent whenever a 1479 new loss event is detected without waiting for the end of an RTT, 1480 and whenever an out-of-order data packet is received that removes a 1481 loss event from the history. 1483 If the sender is transmitting at a high rate (many packets per RTT) 1484 there may be some advantages to sending periodic feedback messages 1485 more than once per RTT as this allows faster response to changing 1486 RTT measurements, and more resilience to feedback packet loss. 1488 If the receiver was sending k feedback packets per RTT, for k>1, 1489 step (4) of Section 6.2 would be modified to set the feedback timer 1490 to expire after R_m/k seconds. However, each feedback packet would 1491 still report the receiver rate over the last RTT, not over a 1492 fraction of an RTT. In this document we do not specify the 1493 modifications that might be required for a receiver sending more 1494 than one feedback packet per RTT. We note that there is little gain 1495 from sending a large number of feedback messages per RTT. 1497 6.1. Receiver Behavior When a Data Packet is Received 1499 When a data packet is received, the receiver performs the following 1500 steps: 1502 1) Add the packet to the packet history. 1504 2) Check if done: If the new packet results in the detection of a 1505 new loss event, or if no feedback packet was sent when the 1506 feedback timer last expired, go to step 3). Otherwise, no 1507 action need be performed (unless the optimization in the next 1508 paragraph is used), so exit the procedure. 1510 An OPTIONAL optimization might check to see if the arrival of 1511 the packet caused a hole in the packet history to be filled and 1512 consequently two loss intervals were merged into one. If this 1513 is the case, the receiver might also send feedback immediately. 1514 The effects of such an optimization are normally expected to be 1515 small. 1517 3) Calculate p: Let the previous value of p be p_prev. Calculate 1518 the new value of p as described in Section 5. 1520 4) Expire feedback timer: If p > p_prev, cause the feedback timer 1521 to expire, and perform the actions described in Section 6.2 1523 If p <= p_prev and no feedback packet was sent when the feedback 1524 timer last expired, cause the feedback timer to expire, and 1525 perform the actions described in Section 6.2. If p <= p_prev 1526 and a feedback packet was sent when the feedback timer last 1527 expired, no action need be performed. 1529 6.2. Expiration of Feedback Timer 1531 When the feedback timer at the receiver expires, the action to be 1532 taken depends on whether data packets have been received since the 1533 last feedback was sent. 1535 For the m-th expiration of the feedback timer, let the maximum 1536 sequence number of a packet at the receiver so far be S_m, and the 1537 value of the RTT measurement included in packet S_m be R_m. As 1538 described in Section 3.2.1, R_m is the sender's most recent estimate 1539 of the round trip time, as reported in data packets. If data 1540 packets have been received since the previous feedback was sent, the 1541 receiver performs the following steps: 1543 1) Calculate the average loss event rate using the algorithm 1544 described in Section 5. 1546 2) Calculate the measured receive rate, X_recv, based on the 1547 packets received within the previous R_(m-1) seconds. This is 1548 performed whether the feedback timer expired at its normal time, 1549 or expired early due to a new lost or marked packet (i.e., step 1550 (3) in Section 6.1). 1552 In the typical case, when the receiver is sending only one 1553 feedback packet per round-trip time and the feedback timer did 1554 not expire early due to a new lost packet, then the time 1555 interval since the feedback timer last expired would be R_(m-1) 1556 seconds. 1558 We note that when the feedback timer expires early due to a new 1559 lost or marked packet, the time interval since the feedback 1560 timer last expired is likely to be smaller than R_(m-1) seconds. 1562 For ease of implementation, if the time interval since the 1563 feedback timer last expired is not R_(m-1) seconds, the receive 1564 rate MAY be calculated over a longer time interval, the time 1565 interval going back to the most recent feedback timer expiration 1566 that was at least R_(m-1) seconds ago. 1568 3) Prepare and send a feedback packet containing the information 1569 described in Section 3.2.2. 1571 4) Restart the feedback timer to expire after R_m seconds. 1573 Note that rule 2) above gives a minimum value for the measured 1574 receive rate X_recv of one packet per round-trip time. If the 1575 sender is limited to a sending rate of less than one packet per 1576 round-trip time, this will be due to the loss event rate, not from a 1577 limit imposed by the measured receive rate at the receiver. 1579 If no data packets have been received since the last feedback was 1580 sent, then no feedback packet is sent, and the feedback timer is 1581 restarted to expire after R_m seconds. 1583 6.3. Receiver Initialization 1585 The receiver is initialized by the first data packet that arrives at 1586 the receiver. Let the sequence number of this packet be i. 1588 When the first packet is received: 1590 o Set p=0. 1592 o Set X_recv = 0. 1594 o Prepare and send a feedback packet. 1596 o Set the feedback timer to expire after R_i seconds. 1598 If the first data packet does not contain an estimate R_i of the 1599 round-trip time, then the receiver sends a feedback packet for every 1600 arriving data packet, until a data packet arrives containing an 1601 estimate of the round-trip time. 1603 If the sender is using a coarse-grained timestamp that increments 1604 every quarter of a round-trip time, then a feedback timer is not 1605 needed, and the following procedure from RFC 4342 is used to 1606 determine when to send feedback messages. 1608 o Whenever the receiver sends a feedback message, the receiver 1609 sets a local variable last_counter to the greatest received 1610 value of the window counter since the last feedback message was 1611 sent, if any data packets have been received since the last 1612 feedback message was sent. 1614 o If the receiver receives a data packet with a window counter 1615 value greater than or equal to last_counter + 4, then the 1616 receiver sends a new feedback packet. ("Greater" and "greatest" 1617 are measured in circular window counter space.) 1619 6.3.1. Initializing the Loss History after the First Loss Event 1621 This section describes the procedure that MUST be used for 1622 initializing the loss history after the first loss event. 1624 The number of packets until the first loss can not be used to 1625 compute the allowed sending rate directly, as the sending rate 1626 changes rapidly during this time. TFRC assumes that the correct 1627 data rate after the first loss is half of the maximum sending rate 1628 before the loss occurred. TFRC approximates this target rate 1629 X_target by the maximum value in X_recv_set. (For slow-start, for a 1630 particular round-trip time, the sender's sending rate is generally 1631 twice the receiver's receive rate for data sent over the previous 1632 round-trip time.) 1634 After the first loss, instead of initializing the first loss 1635 interval to the number of packets sent until the first loss, the 1636 TFRC receiver calculates the loss interval that would be required to 1637 produce the data rate X_target, and uses this synthetic loss 1638 interval to seed the loss history mechanism. 1640 TFRC does this by finding some value p for which the throughput 1641 equation in Section 3.1 gives a sending rate within 5% of X_target, 1642 given the round-trip time R, and the first loss interval is then set 1643 to 1/p. If the receiver knows the segment size s used by the 1644 sender, then the receiver MAY use the throughput equation for X; 1645 otherwise, the receiver MAY measure the receive rate in packets per 1646 second instead of bytes per second for this purpose, and use the 1647 throughput equation for X_pps. (The 5% tolerance is introduced 1648 simply because the throughput equation is difficult to invert, and 1649 we want to reduce the costs of calculating p numerically.) 1651 Special care is needed for initializing the first loss interval when 1652 the first data packet is lost or marked. When the first data packet 1653 is lost in TCP, the TCP sender retransmits the packet after the 1654 retransmit timer expires. If TCP's first data packet is ECN-marked, 1655 the TCP sender resets the retransmit timer, and sends a new data 1656 packet only when the retransmit timer expires [RFC3168] (Section 1657 6.1.2). For TFRC, if the first data packet is lost or ECN-marked, 1658 then the first loss interval consists of the null interval with no 1659 data packets. In this case, the loss interval length for this 1660 (null) loss interval SHOULD be set to give a similar sending rate to 1661 that of TCP, as specified in the paragraph below. 1663 When the first TFRC loss interval is null, meaning that the first 1664 data packet is lost or ECN-marked, in order to follow the behavior 1665 of TCP, TFRC wants the allowed sending rate to be 1 packet every two 1666 round-trip times, or equivalently, 0.5 packets per RTT. Thus, the 1667 TFRC receiver calculates the loss interval that would be required to 1668 produce the target rate X_target of 0.5/R packets per second, for 1669 the round-trip time R, and uses this synthetic loss interval for the 1670 first loss interval. The TFRC receiver uses 0.5/R packets per 1671 second as the minimum value for X_target when initializing the first 1672 loss interval. 1674 7. Sender-based Variants 1676 In a sender-based variant of TFRC, the receiver uses reliable 1677 delivery to send information about packet losses to the sender, and 1678 the sender computes the packet loss rate and the acceptable transmit 1679 rate. 1681 The main advantage of a sender-based variant of TFRC is that the 1682 sender does not have to trust the receiver's calculation of the 1683 packet loss rate. However, with the requirement of reliable 1684 delivery of loss information from the receiver to the sender, a 1685 sender-based TFRC would have much tighter constraints on the 1686 transport protocol in which it is embedded. 1688 In contrast, the receiver-based variant of TFRC specified in this 1689 document is robust to the loss of feedback packets, and therefore 1690 does not require the reliable delivery of feedback packets. It is 1691 also better suited for applications where it is desirable to offload 1692 work from the server to the client as much as possible. 1694 RFC 4340 and RFC 4342 together specify DCCP's CCID 3, which can be 1695 used as a sender-based variant of TFRC. In CCID 3, each feedback 1696 packet from the receiver contains a Loss Intervals option, reporting 1697 the lengths of the most recent loss intervals. Feedback packets may 1698 also include the Ack Vector option, allowing the sender to determine 1699 exactly which packets were dropped or marked and to check the 1700 information reported in the Loss Intervals options. The Ack Vector 1701 option can also include ECN Nonce Echoes, allowing the sender to 1702 verify the receiver's report of having received an unmarked data 1703 packet. The Ack Vector option allows the sender to see for itself 1704 which data packets were lost or ECN-marked, to determine loss 1705 intervals, and to calculate the loss event rate. Section 9 of 1706 RFC 4342 discusses issues in the sender verifying information 1707 reported by the receiver. 1709 8. Implementation Issues 1711 This document has specified the TFRC congestion control mechanism, 1712 for use by applications and transport protocols. This section 1713 mentions briefly some of the implementation issues. 1715 8.1. Computing the Throughput Equation 1717 For t_RTO = 4*R and b = 1, the throughput equation in Section 3.1 1718 can be expressed as follows: 1720 s 1721 X_Bps = -------- 1722 R * f(p) 1724 for 1726 f(p) = sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)). 1728 A table lookup could be used for the function f(p). 1730 Many of the multiplications (e.g., q and 1-q for the round-trip time 1731 average, a factor of 4 for the timeout interval) are or could be by 1732 powers of two, and therefore could be implemented as simple shift 1733 operations. 1735 8.2. Sender Behavior When a Feedback Packet is Received 1737 This section discusses implementation issues for sender behavior 1738 when a feedback packet is received, from Section 4.3. 1740 8.2.1. Determining If an Interval Was a Data-limited Interval 1742 When a feedback packet is received, the sender has to determine if 1743 the entire interval covered by that feedback packet was a data- 1744 limited period. This section discusses one possible implementation 1745 for the sender to determine if the interval covered by a feedback 1746 packet was a data-limited period. 1748 If the feedback packets all report the timestamp of the last data 1749 packet received, then let t_new be the timestamp reported by this 1750 feedback packet. Because all feedback packets cover an interval of 1751 at least a round-trip time, it is sufficient for the sender to 1752 determine if there was any time in the period (t_old, t_new] when 1753 the sender was not data-limited, for R the sender's estimate of the 1754 round-trip time, and for t_old set to t_new - R. (This procedure 1755 estimates the interval covered by the feedback packet, rather than 1756 computing it exactly. This seems fine to us.) 1758 The pseudocode for determining if the sender was data-limited over 1759 the entire interval covered in a feedback packet is given below. 1760 The variables NotLimited1 and NotLimited2 both represent times when 1761 the sender was *not* data-limited. 1763 Initialization: 1764 NotLimited1 = NotLimited2 = t_new = t_next = 0; 1765 t_now = current time; 1767 After sending a segment: 1768 If (sender has sent all it is allowed to send) { 1769 // Sender is not data-limited at this instant. 1770 If NotLimited1 <= t_new 1771 // Goal: NotLimited1 > t_new. 1772 NotLimited1 = t_now; 1773 Else if (NotLimited2 <= t_next) 1774 // Goal: NotLimited2 > t_next. 1775 NotLimited2 = t_now; 1776 } 1778 When a feedback packet is received, is this interval data-limited: 1779 t_new = timestamp reported in feedback packet. 1780 t_old = t_new - R. // local variable 1781 t_next = t_now; 1782 If ((t_old < NotLimited1 <= t_new) or 1783 (t_old < NotLimited2 <= t_new)) 1784 This was not a data-limited interval; 1785 Else 1786 This was a data-limited interval. 1787 If (NotLimited1 <= t_new && NotLimited2 > t_new) 1788 NotLimited1 = NotLimited2; 1790 Transmission times refer to transmission of a segment or segments to 1791 the layer below. 1793 Between feedback packets, (t_old, t_new] gives the transmission time 1794 interval estimated to be covered by the most recent feedback packet, 1795 and t_next gives a time at least a round-trip time greater than 1796 t_new. The next feedback packet can be expected to cover roughly 1797 the interval (t_new, t_next] (unless the receiver sends the feedback 1798 packet early because it is reporting a new loss event). The goal is 1799 for NotLimited1 to save a not-data-limited time in (t_new, t_next], 1800 if there was one, and for NotLimited2 to save a not-data-limited 1801 time after t_next. 1803 When a feedback packet was received, if either NotLimited1 or 1804 NotLimited2 is in the time interval covered by the feedback packet, 1805 that the interval is not a data-limited interval; the sender was not 1806 data-limited at least once during that time interval. If neither 1807 NotLimited1 nor NotLimited2 is in the time interval covered by a 1808 feedback packet, then the sender is assumed to have been data- 1809 limited over that time interval. 1811 We note that this procedure is a heuristic, and in some cases the 1812 sender might not determine correctly if the sender was data-limited 1813 over the entire interval covered by the feedback packet. This 1814 heuristic does not address the possible complications of reordering. 1816 That seems acceptable to us. In order to improve its accuracy in 1817 identifying if the entire interval covered by a feedback packet was 1818 a data-limited interval, the sender could save more NotLimited 1819 times. 1821 In some implementations of TFRC, the sender sends coarse-grained 1822 timestamps that increment every quarter of a round-trip time, and 1823 the feedback packet reports the greatest valid sequence number 1824 received so far instead of reporting the timestamp of the last 1825 packet received. In this case, the sender can maintain per-packet 1826 state to determine t_new (the time that the acknowledged packet was 1827 sent), or the sender can estimate t_new from its estimate of the 1828 round-trip time and the elapsed time t_delay reported by the 1829 feedback packet. 1831 8.2.2. Maintaining X_recv_set 1833 To reduce the complexity of maintaining X_recv_set, it is sufficient 1834 to limit X_recv_set to at most N=3 elements. In this case, the 1835 procedure Update X_recv_set() would be modified as follows: 1837 Update X_recv_set(): 1838 Add X_recv to X_recv_set; 1839 Delete from X_recv_set values older than 1840 two round-trip times. 1841 Keep only the most recent N values. 1843 Maintaining at most *two* elements in X_recv_set would be sufficient 1844 for the sender to save an old value of X_recv from before a data- 1845 limited period, and to allow the sender not to be limited by the 1846 first feedback packet after an idle period (reporting a receive rate 1847 of one packet per round-trip time). However, it is *possible* that 1848 maintaining at most two elements in X_recv_set would not give quite 1849 as good performance as maintaining at most three elements. 1850 Maintaining three elements in X_recv_set would allow X_recv_set to 1851 contain X_recv values from two successive feedback packets, plus a 1852 more recent X_recv value from a loss event. 1854 8.3. Sending Packets Before their Nominal Send Time 1856 This section discusses one possible scheduling mechanism for a 1857 sender in an operating system with a coarse-grained timing 1858 granularity (from Section 4.6). 1860 Let t_gran be the scheduling timer granularity of the operating 1861 system. Let t_ipi be the inter-packet interval, as specified in 1862 Section 4.6. If the operating system has a coarse timer granularity 1863 or otherwise cannot support short t_ipi intervals, then either the 1864 TFRC sender will be restricted to a sending rate of at most 1 packet 1865 every t_gran seconds, or the TFRC sender must be allowed to send 1866 short bursts of packets. In addition to allowing the sender to 1867 accumulate sending credits for past unused send times, it can be 1868 useful to allow the sender to send a packet before its scheduled 1869 send time, as described in the section below. 1871 A parameter t_delta may be used to allow a packet to be sent before 1872 its nominal send time. Consider an application that becomes idle 1873 and requests re-scheduling for time t_i = t_(i-1) + t_ipi, for 1874 t_(i-1) the send time for the previous packet. When the application 1875 is re-scheduled, it checks the current time, t_now. If (t_now > t_i 1876 - t_delta) then packet i is sent. When the nominal send time, t_i, 1877 of the next packet is calculated, it may already be the case that 1878 t_now > t_i - t_delta. In such a case the packet would be sent 1879 immediately. 1881 In order to send at most one packet before its nominal send time, 1882 and never to send a packet more than a round-trip time before its 1883 nominal send time the parameter t_delta would be set as follows: 1885 t_delta = min(t_ipi, t_gran, rtt)/2; 1887 (The scheduling granularity t_gran is 10 ms on some older Unix 1888 systems.) 1890 As an example, consider a TFRC flow with an allowed sending rate X 1891 of 10 packets per round-trip time (PPR), a round-trip time of 100 1892 ms, a system with a scheduling granularity t_gran of 10 ms, and the 1893 ability to accumulate unused sending credits for a round-trip time. 1894 In this case, t_ipi is 1 ms. The TFRC sender would be allowed to 1895 send packets 0.5 ms before their nominal sending time, and would be 1896 allowed to save unused sending credits for 100 ms. The scheduling 1897 granularity of 10 ms would not significantly affect the performance 1898 of the connection. 1900 As a different example, consider a TFRC flow with a scheduling 1901 granularity greater than the round-trip time, for example, with a 1902 round-trip time of 0.1 ms and a system with a scheduling granularity 1903 of 1 ms, and with the ability to accumulate unused sending credits 1904 for a round-trip time. The TFRC sender would be allowed to save 1905 unused sending credits for 0.1 ms. If the scheduling granularity 1906 *did not* affect the sender's response to an incoming feedback 1907 packet, then the TFRC sender would be able to send an RTT of data 1908 (as determined by the allowed sending rate) each RTT, in response to 1909 incoming feedback packets. In this case, the coarse scheduling 1910 granularity would not significantly reduce the sending rate, but the 1911 sending rate would be bursty, with a round-trip time of data sent in 1912 response to each feedback packet. 1914 However, performance would be different in this case if the 1915 operating system scheduling granularity affected the sender's 1916 response to feedback packets as well as the general scheduling of 1917 the sender, In this case the sender's performance would be severely 1918 limited by the scheduling granularity being greater than the round- 1919 trip time, with the sender able to send an RTT of data, at the 1920 allowed sending rate, at most once every 1 ms. This restriction of 1921 the sending rate is an unavoidable consequence of allowing 1922 burstiness of at most a round-trip time of data. 1924 8.4. Calculation of the Average Loss Interval 1926 The calculation of the average loss interval in Section 5.4 involves 1927 multiplications by the weights w_0 to w_(n-1), which for n=8 are: 1929 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2. 1931 With a minor loss of smoothness, it would be possible to use weights 1932 that were powers of two or sums of powers of two, e.g., 1934 1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25. 1936 8.5. The Optional History Discounting Mechanism 1938 The optional history discounting mechanism described in Section 5.5 1939 is used in the calculation of the average loss rate. The history 1940 discounting mechanism is invoked only when there has been an 1941 unusually long interval with no packet losses. For a more efficient 1942 operation, the discount factor DF_i could be restricted to be a 1943 power of two. 1945 9. Changes from RFC 3448 1947 9.1. Overview of Changes 1949 This section summarizes the changes from RFC 3448. At a high level, 1950 the main change is to add mechanisms to address the case of a data- 1951 limited sender. This document also explicitly allows the TFRC 1952 sender to accumulate up to a round-trip time of unused send credits, 1953 and as a result to send a burst of packets if data arrives from the 1954 application in a burst after a data-limited period. This issue was 1955 not explicitly addressed in RFC 3448. 1957 This document changes RFC 3448 to incorporate TCP's higher initial 1958 sending rates from RFC 3390. This document also changes RFC 3448 to 1959 allow RFC 4243's use of a coarse-grained timestamp on data packets 1960 instead of a more fine-grained timestamp. 1962 Other changes address corner cases involving slow-start, the 1963 response when the first data packet is dropped, and the like. This 1964 document also incorporates the items in the RFC 3448 Errata. 1966 This section is non-normative; the normative text is in the cited 1967 sections. 1969 9.2. Changes in each Section 1971 Section 4.1, estimating the average segment size: Section 4.1 was 1972 modified to give a specific algorithm that could be used for 1973 estimating the average segment size. 1975 Section 4.2, update to the initial sending rate: In RFC 3448, the 1976 initial sending rate was two packets per round trip time. In this 1977 document, the initial sending rate can be as high as four packets 1978 per round trip time, following RFC 3390. The initial sending rate 1979 was changed to be in terms of the segment size s, not in terms of 1980 the MSS. 1982 Section 4.2 now says that tld, the Time Last Doubled during slow- 1983 start, can be initialized to either 0 or to -1. Section 4.2 was 1984 also clarified to say that RTT measurements do not only come from 1985 feedback packets; they could also come from other places, such as 1986 the SYN exchange. 1988 Section 4.3, response to feedback packets: Section 4.3 was modified 1989 to change the way that the receive rate is used in limiting the 1990 sender's allowed sending rate, by using the set of receive rate 1991 values of the last two round-trip times, and initializing the set of 1992 receive rate values by a large value. 1994 The larger initial sending rate in Section 4.2 is of little use if 1995 the receiver sends a feedback packet after the first packet is 1996 received, and the sender in response reduces the allowed sending 1997 rate to at most two packets per RTT, which would be twice the 1998 receive rate. Because of the change in the sender's processing of 1999 the receive rate, the sender now does not reduce the allowed sending 2000 rate to twice the reported receive rate in response to the first 2001 feedback packet. 2003 During a data-limited period, the sender saves the receive rate 2004 reported from just before the data-limited period, if it is larger 2005 than the receive rate during the data-limited period. The sender 2006 also reduces the saved values in X_recv_set in response to a loss 2007 during a data-limited period. Appendix C discusses this response 2008 further. 2010 Section 4.4, response to an idle period: Following Section 5.1 from 2011 [RFC4342], this document specifies that when the sending rate is 2012 reduced after an idle period that covers the period since the 2013 nofeedback timer was set, the allowed sending rate is not reduced 2014 below the initial sending rate. (In Section 4.4, the variable 2015 recover_rate is set to the initial sending rate.) 2017 Section 4.4, correction from [RFC3448Err]. RFC 3448 had 2018 contradictory text about whether the sender halved its sending rate 2019 after *two* round-trip times without receiving a feedback report, or 2020 after *four* round-trip times. This document clarifies that the 2021 sender halves its sending rate after four round-trip times without 2022 receiving a feedback report [RFC3448Err]. 2024 Section 4.4, clarification for Slow-Start: Section 4.4 was clarified 2025 to specify that on the expiration of the nofeedback timer, if p = 0, 2026 X_Bps can not be used, because the sender does not yet have a value 2027 for X_Bps. Section 4.4 was also clarified to check the case when 2028 the sender does not yet have an RTT sample, but has sent a packet 2029 since the nofeedback timer was set. 2031 Section 4.6: credits for unused send time: 2033 Section 4.6 has been clarified to say that the TFRC sender gets to 2034 accumulate up to an RTT of credits for unused send time. Section 2035 4.6 was also rewritten to clarify what is specification and what is 2036 implementation. 2038 Section 5.4, clarification: Section 5.4 was modified to clarify the 2039 receiver's calculation of the average loss interval when the 2040 receiver has not yet seen n loss intervals. 2042 Section 5.5, correction: Section 5.5 was corrected to say that the 2043 loss interval I_0 includes all transmitted packets, including lost 2044 and marked packets (as defined in Section 5.3 in the general 2045 definition of loss intervals.) 2047 Section 5.5, correction from [RFC3448Err]: A line in Section 5.5 was 2048 changed from 2050 for (i = 1 to n) { DF_i = 1; } 2052 to 2054 for (i = 0 to n) { DF_i = 1; } 2056 [RFC3448Err]. 2058 Section 5.5, history discounting: THRESHOLD, the lower bound on the 2059 history discounting parameter DF, has been changed from 0.5 to 0.25, 2060 to allow more history discounting when the current interval is long. 2062 Section 6, multiple feedback packets: Section 6 now contains more 2063 discussion of procedures if the receiver sends multiple feedback 2064 packets each round-trip time. 2066 Section 6.3, initialization of the feedback timer: Section 6.3 now 2067 specifies the receiver's initialization of the feedback timer if the 2068 first data packet received does not have an estimate of the round- 2069 trip time. 2071 Section 6.3, a coarse-grained timestamp: Section 6.3 was modified to 2072 incorporate, as an option, a coarse-grained timestamp from the 2073 sender that increments every quarter of a round-trip time, instead 2074 of a more fine-grained timestamp. This follows RFC 4243. 2076 Section 6.3.1, after the first loss event: Section 6.3.1 now says 2077 that for initializing the loss history after the first loss event, 2078 the receiver uses the maximum receive rate in X_recv_set, instead of 2079 the receive rate in the last round-trip time. 2081 Section 6.3.1, if the first data packet is dropped: Section 6.3.1 2082 now contains a specification for initializing the loss history if 2083 the first data packet sent is lost or ECN-marked. 2085 Section 7, sender-based variants: Section 7's discussion of sender- 2086 based variants has been expanded, with reference to RFC 4342. 2088 10. Security Considerations 2090 TFRC is not a transport protocol in its own right, but a congestion 2091 control mechanism that is intended to be used in conjunction with a 2092 transport protocol. Therefore security primarily needs to be 2093 considered in the context of a specific transport protocol and its 2094 authentication mechanisms. 2096 Congestion control mechanisms can potentially be exploited to create 2097 denial of service. This may occur through spoofed feedback. Thus 2098 any transport protocol that uses TFRC should take care to ensure 2099 that feedback is only accepted from the receiver of the data. The 2100 precise mechanism to achieve this will however depend on the 2101 transport protocol itself. 2103 In addition, congestion control mechanisms may potentially be 2104 manipulated by a greedy receiver that wishes to receive more than 2105 its fair share of network bandwidth. A receiver might do this by 2106 claiming to have received packets that in fact were lost due to 2107 congestion. Possible defenses against such a receiver would 2108 normally include some form of nonce that the receiver must feed back 2109 to the sender to prove receipt. However, the details of such a 2110 nonce would depend on the transport protocol, and in particular on 2111 whether the transport protocol is reliable or unreliable. 2113 We expect that protocols incorporating ECN with TFRC will also want 2114 to incorporate feedback from the receiver to the sender using the 2115 ECN nonce [RFC3540]. The ECN nonce is a modification to ECN that 2116 protects the sender from the accidental or malicious concealment of 2117 marked packets. Again, the details of such a nonce would depend on 2118 the transport protocol, and are not addressed in this document. 2120 11. IANA Considerations 2122 There are no IANA actions required for this document. 2124 12. Acknowledgments 2126 We would like to acknowledge feedback and discussions on equation- 2127 based congestion control with a wide range of people, including 2128 members of the Reliable Multicast Research Group, the Reliable 2129 Multicast Transport Working Group, and the End-to-End Research 2130 Group. We would like to thank Dado Colussi, Gorry Fairhurst, Ladan 2131 Gharai, Wim Heirman, Eddie Kohler, Ken Lofgren, Mike Luby, Ian 2132 McDonald, Vladimir Moltchanov, Colin Perkins, Michele R., Gerrit 2133 Renker, Arjuna Sathiaseelan, Vladica Stanisic, Randall Stewart, 2134 Eduardo Urzaiz, Shushan Wen, and Wendy Lee (lhh@zsu.edu.cn) for 2135 feedback on earlier versions of this document, and to thank Mark 2136 Allman for his extensive feedback from using [RFC3448] to produce a 2137 working implementation. 2139 A. Terminology 2141 This document uses the following terms. Timer variables (e.g., 2142 t_now, tld) are assumed to be in seconds, with a timer resolution of 2143 at least a millisecond. 2145 data-limited interval: 2146 An interval where the sender is data-limited (not sending as 2147 much as it is allowed to send) over the entire interval (Section 2148 4.3). 2150 DF: Discount factor for a loss interval (Section 5.5). 2152 initial_rate: 2153 Allowed initial sending rate. 2155 last_counter: 2156 Greatest received value of the window counter (Section 6.3). 2158 min_rate: 2159 Minimum transmit rate (Section 4.3). 2161 n: Number of loss intervals. 2163 NDUPACK: 2164 Number of dupacks for inferring loss (constant) (Section 5.1). 2166 nofeedback timer: 2167 Sender-side timer (Section 4). 2169 p: Estimated Loss Event Rate. 2171 p_prev: 2172 Previous value of p (Section 6.1). 2174 q: Filter constant for RTT (constant) (Section 4.3). 2176 q2: Filter constant for long-term RTT (constant) (Section 4.6). 2178 R: Estimated path round-trip time. 2180 R_m: 2181 A specific estimate of the path round-trip time (Sections 4.3, 2182 6). 2184 R_sample: 2185 Measured path RTT (Section 4.3). 2187 R_sqmean: 2188 Long-term estimate of the square root of the RTT (Section 4.6). 2190 recover_rate: 2191 Allowed rate for resuming after an idle period (Section 4.4). 2193 recv_limit; 2194 Limit on sending rate computed from X_recv_set (Section 4.3). 2196 s: Nominal packet size in bytes. 2198 S: Sequence number. 2200 t_delay: 2201 Reported time delay between receipt of the last packet at the 2202 receiver and the generation of the feedback packet (Section 2203 3.2.2). 2205 t_delta: 2206 Parameter for flexibility in send time (Section 8.3). 2208 t_gran: 2209 Scheduling timer granularity of the operating system (constant) 2210 (Section 8.3). 2212 t_ipi: 2213 Inter-packet interval for sending packets (Section 4.6). 2215 t_mbi: 2216 Maximum RTO value of TCP (constant) (Section 4.3). 2218 t_recvdata: 2219 Timestamp of the last data packet received (Section 3.2.2). 2221 timer_limit: 2222 Limit on the sending rate from the expiration of the nofeedback 2223 timer (Section 4.4). 2225 tld: 2226 Time Last Doubled (Section 4.2). 2228 t_now: 2229 Current time (Section 4.3). 2231 t_RTO: 2232 Estimated RTO of TCP (Section 4.3). 2234 X: Allowed transmit rate, as limited by the receive rate. 2236 X_Bps: 2237 Calculated sending rate in bytes per second (Section 3.1). 2239 X_pps: 2240 Calculated sending rate in packets per second (Section 3.1). 2242 X_inst: 2243 Instantaneous allowed transmit rate (Section 4.6). 2245 X_recv: 2246 Estimated receive rate at the receiver (Section 3.2.2). 2248 X_recv_set: 2249 A small set of recent X_recv values (Section 4.3). 2251 X_target: 2252 The target sending rate after the first loss event (Section 2253 6.3.1). 2255 W_init: 2256 TCP initial window (constant) (Section 4.2). 2258 B. The Initial Value of the Nofeedback Timer 2260 Why is the initial value of TFRC's nofeedback timer set to two 2261 seconds, instead of the recommended initial value of three seconds 2262 for TCP's retransmit timer, from [RFC2988]? There is not any 2263 particular reason why TFRC's nofeedback timer should have the same 2264 initial value as TCP's retransmit timer. TCP's retransmit timer is 2265 used not only to reduce the sending rate in response to congestion, 2266 but also to retransmit a packet that is assumed to have been dropped 2267 in the network. In contrast, TFRC's nofeedback timer is only used 2268 to reduce the allowed sending rate, not to trigger the sending of a 2269 new packet. As a result, there is no danger to the network for the 2270 initial value of TFRC's nofeedback timer to be smaller than the 2271 recommended initial value for TCP's retransmit timer. 2273 Further, when the nofeedback timer has not yet expired, TFRC has a 2274 more slowly-responding congestion control mechanism than TCP, and 2275 TFRC's use of the receive rate for limiting the sending rate is 2276 somewhat less precise than TCP's use of windows and ack-clocking, so 2277 the nofeedback timer is a particularly important safety mechanism 2278 for TFRC. For all of these reasons, it is perfectly reasonable for 2279 TFRC's nofeedback timer to have a smaller initial value than that of 2280 TCP's retransmit timer. 2282 C. Response to Idle or Data-limited Periods 2284 Future work could explore alternate responses to using the receive 2285 rate during a data-limited period, and to responding to a loss event 2286 during a data-limited period. 2288 In particular, an Experimental RFC [RFC2861] specifies Congestion 2289 Window Validation (CWV) for TCP. For this discussion, we use the 2290 term "Standard TCP" to refer to the TCP congestion control 2291 mechanisms in [RFC2581] and [RFC2581bis]. [RFC2861] specifies a 2292 different response to idle or data-limited periods than those of 2293 Standard TCP. With CWV, the TCP sender halves the congestion window 2294 after each RTO during an idle period, down to the initial window. 2295 Similarly, with CWV the TCP sender halves the congestion window 2296 half-way down to the flight size after each RTO during a data- 2297 limited period. 2299 This document already specifies a TFRC response to idle periods that 2300 is similar to that of TCP with Congestion Window Validation. 2301 However, this document does not specify a TFRC response to data- 2302 limited periods similar to that of CWV. Adding such a mechanism to 2303 TFRC would require a one-line change to step (4) of Section 4.3. In 2304 particular, the sender's response to a feedback packet could be 2305 changed from: 2307 If (the entire interval covered by the feedback packet 2308 was a data-limited interval) { 2309 If (the feedback packet reports a new loss event or an 2310 increase in the loss event rate p) { 2311 Halve entries in X_recv_set; 2312 X_recv = 0.85 * X_recv; 2313 Maximize X_recv_set(); 2314 recv_limit = max (X_recv_set); 2315 } Else { 2316 Maximize X_recv_set(); 2317 recv_limit = 2 * max (X_recv_set); 2318 } 2319 } 2321 to: 2323 If (the entire interval covered by the feedback packet 2324 was a data-limited interval) { 2325 Multiply old entries in X_recv_set by 0.85; 2326 If (the feedback packet reports a new loss event or an 2327 increase in the loss event rate p) { 2328 Multiply new value X_recv by 0.85. 2329 } 2330 Maximize X_recv_set(); 2331 recv_limit = 2 * max (X_recv_set); 2332 } 2334 In particular, if the receive rate from before a data-limited period 2335 is saved in X_recv_set, then the change in step (4) above would 2336 multiply that receive rate by 0.85 each time that a feedback packet 2337 is received and the above code is executed. As a result, after four 2338 successive round-trip times of data-limited intervals, the receive 2339 rate from before the data-limited period would be reduced by 0.85^4 2340 = 0.52. Thus, this one-line change to step (4) of Section 4.3 would 2341 result in the allowed sending rate being halved for each four 2342 roundtrip times in which the sender was data-limited. Because of 2343 the nature of X_recv_set, this mechanism would never reduce the 2344 allowed sending rate below twice the most recent receive rate. 2346 We note that in the suggested code above, with CWV-style behavior in 2347 response to data-limited intervals, we keep 2349 recv_limit = 2 * max (X_recv_set); 2351 instead of using 2353 recv_limit = max (X_recv_set); 2355 following loss events in data-limited intervals. This relaxed 2356 response to a loss event is allowed because the CWV-style behavior 2357 itself limits rapid fluctuations in the sending rate during data- 2358 limited periods. 2360 C.1. Long Idle or Data-limited Periods 2362 Table 1 summarizes the response of Standard TCP [RFC2581], TCP with 2363 Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and 2364 Revised TFRC (this document) in response to long idle or data- 2365 limited periods. For the purposes of this section, we define a long 2366 period as a period of at least an RTO. 2368 Protocol Long idle periods Long data-limited periods 2369 -------------- -------------------- ---------------------- 2370 Standard TCP: Window -> initial. No change in window. 2371 (Window not increased in 2372 data-limited periods.) 2374 TCP with CWV: Halve window Reduce window half way 2375 (not below initial cwnd). to used window. 2377 Standard TFRC: Halve rate Rate limited to 2378 (not below 2 pkts/rtt). twice receive rate. 2379 One RTT after sending pkt, 2380 rate is limited by X_recv. 2382 Revised TFRC: Halve rate Rate limited to twice 2383 (not below initial rate). max (current X_recv, 2384 receive rate before 2385 data-limited period). 2387 Table 1: Response to long idle or data-limited periods. 2389 Standard TCP after long idle periods: For Standard TCP, [RFC2581] 2390 specifies that TCP SHOULD set the congestion window to no more than 2391 the initial window after an idle period of at least an RTO. (To be 2392 precise, RFC 2581 specifies that the TCP sender should set cwnd to 2393 the initial window if the sender has not sent data in an interval 2394 exceeding the retransmission timeout.) 2396 Standard TCP after long data-limited periods: Standard TCP [RFC2581] 2397 does not reduce TCP's congestion window after a data-limited period, 2398 when the congestion window is not fully used. Standard TCP in 2399 [RFC2581] uses the FlightSize, the amount of outstanding data in the 2400 network, only in setting the slow-start threshold after a retransmit 2401 timeout. Standard TCP is not limited by TCP's ack-clocking 2402 mechanism during a data-limited period. 2404 Standard TCP's lax response to a data-limited period is quite 2405 different from its stringent response to an idle period. 2407 TCP with Congestion Window Validation (CWV) after long idle periods: 2408 As an experimental alternative, [RFC2861] specifies a more moderate 2409 response to an idle period than that of Standard TCP, where during 2410 an idle period the TCP sender halves cwnd after each RTO, down to 2411 the initial cwnd. 2413 TCP with Congestion Window Validation after long data-limited 2414 periods: As an experimental alternative, [RFC2861] specifies a more 2415 stringent response to a data-limited period than that of Standard 2416 TCP, where after each RTO seconds of a data-limited period, the 2417 congestion window is reduced half way down to the window that is 2418 actually used. 2420 The response of TCP with CWV to an idle period is similar to its 2421 response to a data-limited period. TCP with CWV is less restrictive 2422 than Standard TCP in response to an idle period, and more 2423 restrictive than Standard TCP in response to a data-limited period. 2425 Standard TFRC after long idle periods: For Standard TFRC, [RFC3448] 2426 specifies that the allowed sending rate is halved after each RTO 2427 seconds of an idle period. The allowed sending rate is not reduced 2428 below two packets per RTT after idle periods. After an idle period, 2429 the first feedback packet received reports a receive rate of one 2430 packet per round-trip time, and this receive rate is used to limit 2431 the sending rate. Standard TFRC effectively slow-starts up from 2432 this allowed sending rate. 2434 Standard TFRC after long data-limited periods: [RFC3448] does not 2435 distinguish between data-limited and non-data-limited periods. As a 2436 consequence, the allowed sending rate is limited to at most twice 2437 the receive rate during and after a data-limited period. This is a 2438 very restrictive response, more restrictive than that of either 2439 Standard TCP or of TCP with CWV. 2441 Revised TFRC after long idle periods: For Revised TFRC, this 2442 document specifies that the allowed sending rate is halved after 2443 each RTO seconds of an idle period. The allowed sending rate is not 2444 reduced below the initial sending rate as the result of an idle 2445 period. The first feedback packet received after the idle period 2446 reports a receive rate of one packet per round-trip time. However, 2447 the Revised TFRC sender does not use this receive rate for limiting 2448 the sending rate. Thus, Revised TFRC differs from Standard TFRC in 2449 the lower limit used in the reduction of the sending rate, and in 2450 the better response to the first feedback packet received after the 2451 idle period. 2453 Revised TFRC after long data-limited periods: For Revised TFRC, this 2454 document distinguishes between data-limited and non-data-limited 2455 periods. As specified in Section 4.3, during a data-limited period 2456 Revised TFRC remembers the receive rate before the data-limited 2457 period began, and does not reduce the allowed sending rate below 2458 twice that receive rate. This is somewhat similar to the response 2459 of Standard TCP, and is quite different from the very restrictive 2460 response of Standard TFRC to a data-limited period. However, the 2461 response of Revised TFRC is not as conservative as the response of 2462 TCP with Congestion Window Validation, where the congestion window 2463 is gradually reduced down to the window actually used during a data- 2464 limited period. 2466 We note that for Standard TCP, the congestion window is generally 2467 not increased during a data-limited period (when the current 2468 congestion window is not being fully used). We note that there is 2469 no mechanism comparable to this in Revised TFRC. 2471 Recovery after idle or data-limited periods: When TCP reduces the 2472 congestion window after an idle or data-utilized period, TCP can set 2473 the slow-start threshold ssthresh to allow the TCP sender to slow- 2474 start back up towards its old sending rate when the idle or data- 2475 limited period is over. However in TFRC, even when the TFRC 2476 sender's sending rate is restricted by twice the previous receive 2477 rate, this results in the sender being able to double the sending 2478 rate from one round-trip time to the next, if permitted by the 2479 throughput equation. Thus, TFRC does not need a mechanism such as 2480 TCP's setting of ssthresh to allow a slow-start after an idle or 2481 data-limited period. 2483 For future work, one avenue to explore would be the addition of 2484 Congestion Window Validation mechanisms for TFRC's response to data- 2485 limited periods. Currently, following Standard TCP, during data- 2486 limited periods Revised TFRC does not limit its allowed sending rate 2487 as a function of the receive rate. 2489 C.2. Short Idle or Data-limited Periods 2491 Table 2 summarizes the response of Standard TCP [RFC2581], TCP with 2492 Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and 2493 Revised TFRC (this document) in response to short idle or data- 2494 limited periods. For the purposes of this section, we define a 2495 short period as a period of less than an RTT. 2497 Protocol Short idle periods Short data-limited periods 2498 -------------- -------------------- ---------------------- 2499 Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd. 2501 TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd. 2503 Standard TFRC: ? ? 2505 Revised TFRC: Send a burst Send a burst 2506 (up to an RTT of (up to an RTT of 2507 unused send credits). unused send credits). 2509 Table 2: Response to short idle or data-limited periods. 2511 Table 2 shows that Revised TFRC has a similar response to that of 2512 Standard TCP and of TCP with CWV to a short idle or data-limited 2513 period. For a short idle or data-limited period, TCP is limited 2514 only by the size of the unused congestion window, and Revised TFRC 2515 is limited only by the number of unused send credits (up to an RTT's 2516 worth). For Standard TFRC, [RFC3448] did not explicitly specify the 2517 behavior with respect to unused send credits. 2519 C.3. Moderate Idle or Data-limited Periods 2521 Table 3 summarizes the response of Standard TCP [RFC2581], TCP with 2522 Congestion Window Validation [RFC2861], Standard TFRC [RFC3448], and 2523 Revised TFRC (this document) in response to moderate idle or data- 2524 limited periods. For the purposes of this section, we define a 2525 moderate period as a period greater than an RTT, but less than an 2526 RTO. 2528 Protocol Moderate idle periods Moderate data-limited periods 2529 ------------- --------------------- ------------------------- 2530 Standard TCP: Send a burst up to cwnd. Send a burst up to cwnd. 2532 TCP with CWV: Send a burst up to cwnd. Send a burst up to cwnd. 2534 Standard TFRC: ? Limited by X_recv. 2536 Revised TFRC: Send a burst Send a burst 2537 (up to an RTT of (up to an RTT of 2538 unused send credits). unused send credits). 2540 Table 3: Response to moderate idle or data-limited periods. 2542 Table 3 shows that Revised TFRC has a similar response to that of 2543 Standard TCP and of TCP with CWV to a moderate idle or data-limited 2544 period. For a moderate idle or data-limited period, TCP is limited 2545 only by the size of the unused congestion window. For a moderate 2546 idle period, Revised TFRC is limited only by the number of unused 2547 send credits (up to an RTT's worth). For a moderate data-limited 2548 period, Standard TFRC would be limited by X_recv from the most 2549 recent feedback packet. In contrast, Revised TFRC is not limited by 2550 the receive rate from data-limited periods that cover an entire 2551 feedback period of a round-trip time. For Standard TFRC, [RFC3448] 2552 did not explicitly specify the behavior with respect to unused send 2553 credits. 2555 C.4. Losses During Data-Limited Periods 2557 This section discusses the response to a loss during a data-limited 2558 period. 2560 Protocol Response to a loss during a data-limited period 2561 ------------- ----------------------------------------------- 2562 Standard TCP: Set ssthresh, cwnd to FlightSize/2. 2564 TCP with CWV: Same as Standard TCP. 2566 Standard TFRC: Calculate X_Bps, send at most 2*X_recv. 2568 Revised TFRC: Calculate X_Bps, send at most recv_limit. 2569 In addition, modify X_recv_set. 2571 Table 4: Response to a loss during a data-limited period. 2573 In TCP [RFC2581], the response to a loss during a data-limited 2574 period is the same as the response to a loss at any other time in 2575 TCP. This response is to set the congestion window to half of the 2576 FlightSize, where the FlightSize is the actual amount of 2577 unacknowledged data. Thus, after a loss during a data-limited 2578 period, the TCP sender must halve its allowed sending rate, as it 2579 normally does in response to a loss. 2581 In Standard TFRC, the response to a loss during a data-limited 2582 period is also the same as the response to a loss at any other time 2583 in Standard TFRC. The sending rate is limited by X_Bps, from the 2584 throughput equation, and the sending rate is also limited by twice 2585 X_recv, the most recent receive rate. As a result, after a loss in 2586 a data-limited period, the sender can at most double its sending 2587 rate to twice X_recv, even if the throughput equation X_Bps would 2588 allow a sending rate much higher than that. 2590 In Revised TFRC, there have been changes to the use of the receive 2591 rate X_recv during data-limited intervals; the sender is limited to 2592 sending at most recv_limit, where the sender can remember the 2593 receive rate X_recv from just before the data-limited period. This 2594 allows the sender to more than double its sending rate during data- 2595 limited periods, up to the receive rate from before the data-limited 2596 period (if allowed by the throughput equation as given in X_Bps). 2597 This is similar to Standard TCP's practice of not reducing the 2598 window during data-limited periods (in the absence of loss). 2600 As with Standard TFRC, during a data-limited period the Revised TFRC 2601 sender is sending less than is allowed by the throughput equation 2602 X_Bps. After the loss event, the sender still might not want to be 2603 sending as much as allowed by the recalculated value of X_Bps that 2604 takes into account the new loss event. Revised TFRC adds an 2605 additional mechanism to gradually limit the sender's sending rate 2606 after losses during data-limited periods. Unlike TCP's response of 2607 setting cwnd to half the FlightSize, this additional mechanism in 2608 Revised TFRC uses TFRC's practice of using slowly-responding changes 2609 for both increases and decreases in the allowed sending rate. 2611 This is done in Revised TFRC (in step (4) of Section 4.3) by 2612 decreasing the entry in X_recv_set after a loss in a data-limited 2613 interval, and by allowing the sender to send at most max 2614 (X_recv_set), instead of at most twice max (X_recv_set), in the 2615 immediate round-trip time following the reported loss. Thus, the 2616 `price' for allowing the sender to send more than twice the most 2617 immediately reported value of X_recv during a data-limited interval 2618 is the introduction of an additional mechanism to reduce this 2619 allowed sending rate following losses in data-limited periods. 2621 In TFRC's response to a loss in a data-limited interval, we have 2622 considered the following examples. 2624 Example 1, Losses *after* a Data-Limited Period: This example shows 2625 that losses after a data-limited period has ended are addressed by 2626 the throughput equation X_Bps. 2628 ------------------------------------------------------------------- 2629 Stage 1: Not data-limited. 2630 Sending 100 packets per round-trip time (PPR). 2631 Stage 2: Data-limited, sending 10 PPR. 2632 Stage 3: Not data-limited. 2633 Sending 100 PPR again, as allowed by X_Bps. 2634 A packet loss in the first RTT of Stage 3. 2635 X_Bps is updated, 2636 Response of Revised TFRC: a slight reduction in the allowed sending 2637 rate, depending on the number of packets since the last loss event. 2638 ------------------------------------------------------------------- 2640 Table 5: Example 1, Losses after a Data-Limited Period. 2642 For example 1, when there is a packet loss in the first RTT of 2643 Stage 3, this will be reflected in a modified value of X_Bps, and 2644 future loss events would result in future reductions of the 2645 throughput equation X_Bps. In particular, following TFRC's standard 2646 use of the throughput equation [FHPW00] (Section A.2), the allowed 2647 TFRC sending rate would be halved after something like five 2648 successive round-trip times with loss. 2650 Example 2, a Mildly Data-Limited Sender: This example considers 2651 losses in a data-limited period when, during the data-limited 2652 period, the sender is sending *almost* as much as it is allowed to 2653 send. 2655 ------------------------------------------------------------------- 2656 Stage 1: Not data-limited. Sending 100 PPR. 2657 Stage 2: Data-limited, sending 99 PPR. 2658 A packet loss in Stage 2. 2659 Response of Revised TFRC: a slight reduction in the allowed sending 2660 rate, down to 85 PPR or less, depending on the number of packets 2661 since the last loss event. 2662 ------------------------------------------------------------------- 2664 Table 6: Example 2, a Mildly Data-Limited Sender. 2666 Consider a Revised TFRC connection where the sender has been sending 2667 a hundred PPR, and then enters a data-limited period of sending only 2668 99 PPR, because of data limitations from the application. (That is, 2669 at every instance of time during the data-limited period, the sender 2670 could have sent one more packet). If there are losses in the data- 2671 limited period, the allowed sending rate is reduced to min(X_Bps, 2672 recv_limit), where both the throughput equation X_Bps and the limit 2673 recv_limit force a slight reduction in the allowed sending rate. 2675 Example 3, a Single Packet Loss during a Data-Limited Period. This 2676 example considers the loss of a single packet during a data-limited 2677 period, after the sender has not sent a packet for two RTTs. 2679 ------------------------------------------------------------------- 2680 Stage 1: Not data-limited. Sending 100 PPR. 2681 Stage 2: Data-limited, sending 10 PPR. 2682 Stage 3: Data-limited, sending no data for two RTTs. 2683 Stage 4: Data-limited, sending one packet, which is ECN-marked. 2684 Response of Revised TFRC: a reduction in the allowed sending 2685 rate, down to 50 PPR or less. For each loss event during 2686 the data-limited period, the `remembered' X_recv from before 2687 the data-limited period is effectively halved. 2688 ------------------------------------------------------------------- 2690 Table 7: Example 3, a Single Packet Loss. 2692 Consider a Revised TFRC connection where the sender has been sending 2693 a hundred PPR, and then enters a data-limited period of sending only 2694 ten PPR, and then does not send any packets for two RTTs, and then 2695 sends a single packet, which is ECN-marked. In this case, with 2696 Revised TFRC, for each loss event during the data-limited period, 2697 the sender halves its `remembered' X_recv from before the data- 2698 limited period 2700 Example 4, Losses after Increasing the Sending Rate during a Data- 2701 Limited Period. This example considers losses when the sender 2702 significantly increases its sending rate during a data-limited 2703 period. 2705 ------------------------------------------------------------------- 2706 Stage 1: Not data-limited. Sending 100 PPR. 2707 Stage 2: Data-limited, sending 1 PPR. 2708 Stage 3: Data-limited, sending 20 PPR. 2709 Several packets are lost in each RTT of Stage 3. 2710 During Stage 3, the sender would *like* to send 20 PPR. 2711 Response of Revised TFRC: For each loss event during 2712 the data-limited period, the `remembered' X_recv from before 2713 the data-limited period is effectively halved, and the most 2714 recent X_recv is reduced by 0.85. 2715 ------------------------------------------------------------------- 2717 Table 8: Example 4, Losses after Increasing the Sending Rate. 2719 Consider a Revised TFRC connection where the sender has been sending 2720 a hundred PPR, and then enters a data-limited period of sending only 2721 one PPR, and then, while still data-limited, increases its sending 2722 rate to twenty PPR, where it experiences a number of successive loss 2723 events. 2725 In this case, with Revised TFRC, for each loss event during the 2726 data-limited period, the sender halves its `remembered' X_recv from 2727 before the data-limited period, and the most recent X_recv is 2728 reduced by 0.85. 2730 C.5. Other Patterns 2732 Other possible patterns to consider in evaluating Revised TFRC would 2733 be to compare the behavior of TCP, Standard TFRC, and Revised TFRC 2734 for connections with alternating busy and idle periods, alternating 2735 idle and data-limited periods, or with idle or data-limited periods 2736 during Slow-Start. 2738 C.6. Evaluating TFRC's Response to Idle Periods 2740 In this section we focus on evaluating Revised TFRC's response to 2741 idle or data-limited periods. 2743 One drawback to Standard TFRC's strict response to idle or data- 2744 limited periods is that it could be seen as encouraging applications 2745 to pad their sending rate during idle or data-limited periods, by 2746 sending dummy data when there was no other data to send. Because 2747 Revised TFRC has a less strict response to data-limited periods than 2748 that of Standard TFRC, Revised TFRC also could be seen as giving 2749 applications less of an incentive to pad their sending rates during 2750 data-limited periods. Work in progress such as Faster Restart 2751 [KFS07] can also decrease an application's incentive to pad its 2752 sending rate, by allowing faster start-up after idle periods. 2753 Further research would be useful to understand in more detail the 2754 interaction between TCP or TFRC's congestion control mechanisms, and 2755 an application's incentive to pad its sending rate during idle or 2756 data-limited periods. 2758 TCP Congestion Window Validation, described in Appendix C.1 above, 2759 is an Experimental standard specifying that the TCP sender slowly 2760 reduces the congestion window during an idle or data-limited period 2761 [RFC2861]. While TFRC and Revised TFRC's responses to idle periods 2762 are roughly similar to those of TCP with Congestion Window 2763 Validation, Revised TFRC's response to data-limited periods is less 2764 conservative than those of TCP with Congestion Window Validation 2765 (and Standard TFRC's response to data-limited periods was 2766 considerably *more* conservative than those of Congestion Window 2767 Validation). Future work could include modifications to this 2768 document so that the response of Revised TFRC to a data-limited 2769 period includes a slow reduction of the allowed sending rate; 2770 Section C specifies a possible mechanism for this. Such a 2771 modification would be particularly compelling if Congestion Window 2772 Validation became a Proposed Standard in the IETF for TCP. 2774 Normative References 2776 [RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 2777 Friendly Rate Control (TFRC): Protocol 2778 Specification, RFC 3448, January 2003. 2780 Informational References 2782 [BRS99] Balakrishnan, H., Rahul, H., and Seshan, S., "An 2783 Integrated Congestion Management Architecture for 2784 Internet Hosts," Proc. ACM SIGCOMM, Cambridge, MA, 2785 September 1999. 2787 [CCID-4] Floyd, S., and E. Kohler, Profile for DCCP 2788 Congestion Control ID 4: the Small-Packet Variant of 2789 TFRC Congestion Control, Internet-draft draft-ietf- 2790 dccp-ccid4-02.txt, work in progress, February 2007. 2792 [FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, 2793 "Equation-Based Congestion Control for Unicast 2794 Applications", August 2000, Proc SIGCOMM 2000. 2796 [FHPW00a] S. Floyd, M. Handley, J. Padhye, and J. Widmer, 2797 "Equation-Based Congestion Control for Unicast 2798 Applications: the Extended Version", ICSI tech 2799 report TR-00-03, March 2000. 2801 [KFS07] E. Kohler, S. Floyd, and A. Sathiaseelan, Faster 2802 Restart for TCP Friendly Rate Control (TFRC), 2803 Internet-draft draft-ietf-dccp-tfrc-faster- 2804 restart-05.txt, work-in-progress, November 2007. 2806 [FF99] Floyd, S., and K. Fall, Promoting the Use of End-to- 2807 End Congestion Control in the Internet, IEEE/ACM 2808 Transactions on Networking, August 1999. 2810 [PFTK98] Padhye, J. and Firoiu, V. and Towsley, D. and 2811 Kurose, J., "Modeling TCP Throughput: A Simple Model 2812 and its Empirical Validation", Proc ACM SIGCOMM 2813 1998. 2815 [RFC2119] S. Bradner, Key Words For Use in RFCs to Indicate 2816 Requirement Levels, RFC 2119. 2818 [RFC2140] J. Touch, "TCP Control Block Interdependence", RFC 2819 2140, April 1997. 2821 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP 2822 Congestion Control", RFC 2581, April 1999. 2824 [RFC2581bis] Allman, M., Paxson, V., and W. Stevens, "TCP 2825 Congestion Control", internet-draft draft-ietf-tcpm- 2826 rfc2581bis-03.txt, work in progress, September 2007. 2828 [RFC2861] M. Handley, J. Padhye, and S. Floyd, TCP Congestion 2829 Window Validation, RFC2861, June 2000. 2831 [RFC2988] V. Paxson and M. Allman, "Computing TCP's 2832 Retransmission Timer", RFC 2988, November 2000. 2834 [RFC3168] K. Ramakrishnan and S. Floyd, "The Addition of 2835 Explicit Congestion Notification (ECN) to IP", RFC 2836 3168, September 2001. 2838 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing 2839 TCP's Initial Window", RFC 3390, October 2002. 2841 [RFC3448Err] RFC 3448 Errata, URL 2842 "http://www.icir.org/tfrc/rfc3448.errata". 2844 [RFC3540] Wetherall, D., Ely, D., and Spring, N., "Robust ECN 2845 Signaling with Nonces", RFC 3540, Experimental, June 2846 2003 2848 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2849 Congestion Control Protocol (DCCP)", RFC 4340, March 2850 2006. 2852 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 2853 Datagram Congestion Control Protocol (DCCP) 2854 Congestion Control ID 3: TCP-Friendly Rate Control 2855 (TFRC)", RFC 4342, March 2006. 2857 [RFC4828] Floyd, S., and E. Kohler, TCP Friendly Rate Control 2858 (TFRC): the Small-Packet (SP) Variant, RFC 4828, 2859 Experimental, April 2007. 2861 [W00] Widmer, J., "Equation-Based Congestion Control", 2862 Diploma Thesis, University of Mannheim, February 2863 2000. URL "http://www.icir.org/tfrc/". 2865 Authors' Addresses 2867 Mark Handley, 2868 Department of Computer Science 2869 University College London 2870 Gower Street 2871 London WC1E 6BT 2872 UK 2873 EMail: M.Handley@cs.ucl.ac.uk 2875 Sally Floyd 2876 ICSI 2877 1947 Center St, Suite 600 2878 Berkeley, CA 94708 2879 Email: floyd@icir.org 2881 Jitendra Padhye 2882 Microsoft Research 2883 Email: padhye@microsoft.com 2885 Joerg Widmer 2886 DoCoMo Euro-Labs 2887 Landsberger Strasse 312 2888 80687 Munich 2889 Germany 2890 Email: widmer@acm.org 2892 Full Copyright Statement 2894 Copyright (C) The IETF Trust (2008). 2896 This document is subject to the rights, licenses and restrictions 2897 contained in BCP 78, and except as set forth therein, the authors 2898 retain all their rights. 2900 This document and the information contained herein are provided on 2901 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2902 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2903 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2904 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2905 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2906 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2907 FOR A PARTICULAR PURPOSE. 2909 Intellectual Property 2911 The IETF takes no position regarding the validity or scope of any 2912 Intellectual Property Rights or other rights that might be claimed 2913 to pertain to the implementation or use of the technology described 2914 in this document or the extent to which any license under such 2915 rights might or might not be available; nor does it represent that 2916 it has made any independent effort to identify any such rights. 2917 Information on the procedures with respect to rights in RFC 2918 documents can be found in BCP 78 and BCP 79. 2920 Copies of IPR disclosures made to the IETF Secretariat and any 2921 assurances of licenses to be made available, or the result of an 2922 attempt made to obtain a general license or permission for the use 2923 of such proprietary rights by implementers or users of this 2924 specification can be obtained from the IETF on-line IPR repository 2925 at http://www.ietf.org/ipr. 2927 The IETF invites any interested party to bring to its attention any 2928 copyrights, patents or patent applications, or other proprietary 2929 rights that may cover technology that may be required to implement 2930 this standard. Please address the information to the IETF at ietf- 2931 ipr@ietf.org.