idnits 2.17.1 draft-ietf-tsvwg-tfrc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (17 November 2000) is 8562 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force TSV WG 2 INTERNET-DRAFT Mark Handley/ACIRI 3 draft-ietf-tsvwg-tfrc-00.txt Jitendra Padhye/ACIRI 4 Sally Floyd/ACIRI 6 Joerg Widmer/Univ. Mannheim 7 17 November 2000 8 Expires: May 2001 10 TCP Friendly Rate Control (TFRC): 11 Protocol Specification 13 Status of this Document 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a product of the IETF TSV WG. Comments should be 34 addressed to the authors. 36 Abstract 38 This document specifies TCP-Friendly Rate Control (TFRC). 39 TFRC is a congestion control mechanism for unicast flows 40 operating in a best-effort Internet environment. It is 41 reasonably fair when competing for bandwidth with TCP flows, 42 but has a much lower variation of throughput over time 43 compared with TCP, which makes it more suitable for 44 applications such as telephony or streaming media where a 45 relatively smooth sending rate is of importance. 47 Table of Contents 49 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Protocol Mechanism. . . . . . . . . . . . . . . . . . . 4 52 3.1. TCP Throughput Equation. . . . . . . . . . . . . . . 5 53 3.2. Packet Contents. . . . . . . . . . . . . . . . . . . 6 54 3.2.1. Data Packets. . . . . . . . . . . . . . . . . . . 6 55 3.2.2. Feedback Packets. . . . . . . . . . . . . . . . . 7 56 4. Data Sender Protocol. . . . . . . . . . . . . . . . . . 7 57 4.1. Measuring the Packet Size. . . . . . . . . . . . . . 7 58 4.2. Sender behavior when a feedback packet is 59 received. . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Expiration of nofeedback timer . . . . . . . . . . . 9 61 4.4. Sender Initialization. . . . . . . . . . . . . . . . 10 62 4.5. Preventing Oscillations. . . . . . . . . . . . . . . 10 63 4.6. Scheduling of Packet Transmissions . . . . . . . . . 11 64 5. Calculation of the loss rate (p). . . . . . . . . . . . 11 65 5.1. Detection of Lost Packets. . . . . . . . . . . . . . 12 66 5.2. Translation from Loss History to Loss Events . . . . 12 67 5.3. Inter-loss Event Interval. . . . . . . . . . . . . . 13 68 5.4. Average Loss Interval. . . . . . . . . . . . . . . . 14 69 6. Data Receiver Protocol. . . . . . . . . . . . . . . . . 15 70 6.1. Receiver behavior when a data packet is 71 received. . . . . . . . . . . . . . . . . . . . . . . . . 15 72 6.2. Expiration of feedback timer . . . . . . . . . . . . 16 73 6.3. Receiver initialization. . . . . . . . . . . . . . . 17 74 7. Modifying the Packet Size . . . . . . . . . . . . . . . 17 75 8. Security Considerations . . . . . . . . . . . . . . . . 17 76 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 17 77 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . 18 78 11. References . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a 83 congestion control mechanism for unicast flows operating in a best- 84 effort Internet environment. 86 TFRC is designed to be reasonably fair when competing for bandwidth with 87 TCP flows [1]. However it has a much lower variation of throughput over 88 time compared with TCP, which makes it more suitable for applications 89 such as telephony or streaming media where a relatively smooth sending 90 rate is of importance. 92 The penalty of having smoother throughput than TCP whilst competing 93 fairly for bandwidth is that TFRC responds slower than TCP to changes in 94 available bandwidth. Thus TFRC should only be used when the application 95 has a strong requirement for smooth and predictable throughput. For 96 applications that simply require to transfer as much data as possible in 97 as short a time as possible we recommend using TCP, or if reliability is 98 not required, using an Additive-Increase, Multiplicative-Decrease (AIMD) 99 congestion control scheme with similar parameters to those used by TCP. 101 2. Terminology 103 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 104 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 105 "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate 106 requirement levels for compliant TFRC implementations. 108 3. Protocol Mechanism 110 For its congestion control mechanism, TFRC directly uses a throughput 111 equation for the allowed sending rate as a function of the loss event 112 rate and round-trip time. In order to compete fairly with TCP, TFRC 113 uses the TCP throughput equation, which roughly describes TCP's sending 114 rate as a function of the loss event rate and round-trip time. 116 Generally speaking, TFRC's congestion control mechanism works as 117 follows: 119 o The receiver measures the loss event rate and feeds this 120 information back to the sender. 122 o The sender also uses these feedback messages to measure the round- 123 trip time (RTT). 125 o The loss rate and RTT are then fed into TFRC's throughput equation, 126 giving the acceptable transmit rate. 128 o The sender then adjusts its transmit rate to match the calculated 129 rate. 131 The dynamics of TFRC are sensitive to how the measurements are performed 132 and applied. We recommend specific mechanisms below to perform and 133 apply these measurements. Other mechanisms are possible, but it is 134 important to understand how the interactions between mechanisms affect 135 the dynamics of TFRC. 137 3.1. TCP Throughput Equation 139 Any realistic equation of TCP throughput as a function of loss event 140 rate and RTT should be suitable for use in TFRC. However, we note that 141 the TCP throughput equation used must reflect TCP's retransmit timeout 142 behavior, as this dominates TCP throughput at higher loss rates. We 143 also note that the assumptions implicit in the throughput equation about 144 the loss rate parameter have to be a reasonable match to how the loss 145 rate is actually measured. Whilst this match is not perfect for the 146 throughput equation and loss rate measurement mechanisms given below, in 147 practice the assumptions turn out to be close enough. 149 The throughput equation we currently recommend for TFRC is a slightly 150 simplified version of the throughput equation for Reno TCP from [2]. 151 Ideally we'd prefer a throughput equation based on SACK TCP, but the 152 differences between the two equations are relatively minor. 154 The throughput equation is: 156 s 157 X = ---------------------------------------------------------- 158 R*sqrt(2*p/3) + (t_RTO * (3*sqrt(3*p/8) * p * (1+32*p^2))) 160 Where: 162 X is the transmit rate in bytes/second. 164 s is the packet size in bytes. 166 R is the round trip time in seconds. 168 p is the loss event rate, between 0 and 1.0, of the number of loss 169 events as a fraction of the number of packets transmitted. 171 t_RTO is the TCP retransmission timeout value in seconds. 173 We further simplify this by setting t_RTO = 4*R. A more accurate 174 calculation of t_RTO is possible, but does not appear to be necessary in 175 practice. Another possibility would be to set t_RTO = max(4R, 1 176 second). 178 In future, different TCP equations may be substituted for this equation. 179 The requirement is that the throughput equation be a reasonable 180 approximation of the sending rate of TCP for conformant TCP congestion 181 control. 183 The parameters s (packet size), p (loss rate) and R (RTT) need to be 184 measured or calculated by a TFRC implementation. The measurement of s 185 is specified in Section 4.1, measurement of R is specified in Section 186 4.2, and measurement of p is specified in Secion 4.2. 188 3.2. Packet Contents 190 Before specifying the sender and receiver functionality, we describe the 191 contents of the data packets sent by the sender and feedback packets 192 sent by the receiver. As TFRC will be used along with a transport 193 protocol, we do not specify packet formats, as these depend on the 194 details of the transport protocol used. 196 3.2.1. Data Packets 198 Each data packet sent by the data sender contains the following 199 information: 201 o A sequence number. This number is incremented by one for each data 202 packet transmitted. The field must be sufficiently large that it 203 does not wrap causing two different packets with the same sequence 204 number to be in the receiver's recent packet history at the same 205 time. 207 o A timestamp indicating when the packet is sent. We denote by ts_i 208 the timestamp of the packet with sequence number i. The resolution 209 of the timestamp should typically be measured in milliseconds. 211 o The sender's current estimate of the round trip time. The estimate 212 reported in packet i is denoted by R_i. 214 o The sender's current transmit rate. The estimate reported in packet 215 i is denoted by X_i. 217 3.2.2. Feedback Packets 219 Each feedback packet sent by the data receiver contains the following 220 information: 222 o The timestamp of the last data packet received. We denote this by 223 t_recvdata. If the last packet received at the receiver has 224 sequence number i, then t_recvdata = ts_i. 226 o The amount of time elapsed between the receipt of the last data 227 packet at the receiver, and the generation of this feedback report. 228 We denote this by t_delay. 230 o The rate at which the receiver estimates that data was received 231 since the last feedback report was sent. We denote this by X_recv. 233 o The receiver's current estimate of the loss event rate, p. 235 4. Data Sender Protocol 237 The data sender sends a stream of data packets to the data receiver at a 238 controlled rate. When a feedback packet is received from the data 239 receiver, the data sender changes its sending rate, based on the 240 information contained in the feedback report. If the sender does not 241 receive a feedback report for two round trip times, it cuts its sending 242 rate in half. This is achieved by means of a timer called the 243 nofeedback timer. 245 We specify the sender-side protocol in the following steps: 247 o Measurement of the mean packet size being sent. 249 o The sender behavior when a feedback packet is received. 251 o The sender behavior when the nofeedback timer expires. 253 o Oscillation prevention (optional) 255 o Scheduling of transmission on non-realtime operating systems. 257 4.1. Measuring the Packet Size 259 The parameter s (packet size) is normally known to an application. This 260 may not be the case in two cases: 262 o The packet size naturally varies depending on the data. In this 263 case, although the packet size varies, that variation is not 264 coupled to the transmit rate. It should normally be safe to use an 265 estimate of the mean packet size for s. 267 o The application needs to change the packet size rather than the 268 number of packets per second to perform congestion control. This 269 would normally be the case with packet audio applications where a 270 fixed interval of time needs to be represented by each packet. 271 Such applications need to have a completely different way of 272 measuring parameters. 274 The second class of applications are discussed separately in Section 7. 275 For the remainder of this section we assume the sender can estimate the 276 packet size, and that congestion control is performed by adjusting the 277 number of packets sent per second. 279 4.2. Sender behavior when a feedback packet is received 281 The sender knows its current sending rate, X, and maintains an estimate 282 of the current round trip time, R, and an estimate of the timeout 283 interval, t_RTO. 285 When a feedback packet is received by the sender at time t_now, the 286 following actions should be performed: 288 1) Calculate a new round trip sample. 289 R_sample = (t_now - t_recvdata) - t_delay. 291 2) Update the round trip time estimate: 293 If no feedback has been received before 294 R = R_sample 295 Else 296 R = q*R + (1-q)*R_sample 298 TFRC is not sensitive to the precise value for the filter constant 299 q, but we recommend a default value of 0.9. 301 3) Update the timeout interval: 303 t_RTO = 4*R. 305 4) Update the sending rate: 307 First, calculate the allowed transmit rate, X_calc, using the TCP 308 equation from Section 3.1. 310 Then: 312 If p > 0 313 X = min(X_calc, 2*X_recv) 314 Else 315 X = max(min(2*X, 2*X_recv), s/RTT). 317 Note that if p == 0, then the sender is in slow-start phase, where 318 it approximately doubles the sending rate each round-trip time 319 until a loss occurs. 321 5) Reset the nofeedback timer to expire after max(2*R, 2*s/X) seconds. 323 4.3. Expiration of nofeedback timer 325 If the nofeedback timer expires, the sender should perform the following 326 actions: 328 1) Cut the sending rate in half. This is done by modifying the 329 sender's cached copy of X_recv (the receive rate) as this will 330 trigger the correct slowstart behavior after the problem has been 331 resolved: 333 If X_calc > 2*X_recv 334 X_recv = max(X_recv/2, s/128) 335 Else 336 X_recv = X_calc/4 338 The s/128 term limits the backoff to one packet every 64 seconds in 339 the case of persistent absense of feedback. 341 2) The value of X must then be recalculated as described under point 342 (4) above. 344 3) Restart the nofeedback timer to expire after max(4*R, 2*s/X) 345 seconds. 347 Note that when the sender stops sending, the receiver will stop sending 348 feedback. This will cause the nofeedback timer to start to expire and 349 decrease X_recv. If the sender subsequently starts to send again, 350 X_recv will limit the transmit rate, and a normal slowstart phase will 351 occur until the transmit rate reached X_calc. 353 4.4. Sender Initialization 355 To initialize the sender, the value of X is set to 1 packet/second and 356 the nofeedback timer is set to expire after 2 seconds. The initial 357 values for R (RTT) and t_RTO are undefined until they are set as 358 described above. 360 4.5. Preventing Oscillations 362 To prevent oscillatory behavior in environments with a low degree of 363 statistical multiplexing it is useful to modify sender's transmit rate 364 to provide congestion avoidance behavior by reducing the transmit rate 365 as the queuing delay (and hence RTT) increases. To do this the sender 366 maintains an estimate of the long-term RTT and modifies its sending rate 367 depending on how the most recent sample of the RTT differs from this 368 value. The long-term sample is R_sqmean, and is set as follows: 370 If no feedback has been received before 371 R_sqmean = sqrt(R_sample) 372 Else 373 R_sqmean = q2*R_sqmean + (1-q2)*sqrt(R_sample) 375 Thus R_sqmean gives the exponentially weighted moving average of the 376 square root of the RTT samples. The constant q2 should be set similarly 377 to q, and we recommend a value of 0.9 as the default. 379 The sender obtains the base tranmit rate, X, from the throughput 380 function. It then calculates a modified instantaneous transmit rate, 381 X_inst, as follows: 383 X_inst = X * R_sqmean / sqrt(R_sample) 385 When sqrt(R_sample) is greater than R_sqmean then the queue is typically 386 increasing and so the transmit rate needs to be decreased for stable 387 operation. 389 Note: This modification is not always strictly required, especially if 390 the degree of statistical multiplexing in the network is high. However 391 we recommend that it is done because it does make TFRC behave better in 392 environments with a low level of statistical multiplexing. If it is not 393 done, we recommend using a very low value of q, such that q is close to 394 or exactly zero. 396 4.6. Scheduling of Packet Transmissions 398 As TFRC is rate-based, and as operating systems typically cannot 399 schedule events precisely, it is necessary to be opportunistic about 400 sending data packets so that the correct average rate is maintained 401 despite the course-grain or irregular scheduling of the operating 402 system. Thus a typical sending loop will calculate the correct inter- 403 packet interval, t_ipi, as follows: 405 t_ipi = 1/(X_inst * s) 407 When a sender first starts sending at time t_0, it calculates t_ipi, and 408 calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. When the 409 application becomes idle, it checks the current time, t_now, and then 410 requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the 411 application is re-scheduled, it checks the current time, t_now, again. 412 If (t_now > t_1 - delta) then packet 1 is sent. 414 Now a new t_ipi may be calculated, and used to calculate a nominal send 415 time t_2 for packet 2: t2 = t_1 + t_ipi. The process then repeats, with 416 each successive packet's send time being calculated from the nominal 417 send time of the previous packet. 419 In some cases, when the nominal send time, t_i, of the next packet is 420 calculated, it may already be the case that t_now > t_i - delta. In 421 such a case the packet should be sent immediately. Thus if the 422 operating system has coarse timer granularity and the transmit rate is 423 high, then TFRC may send short bursts of several packets separated by 424 intervals of the OS timer granularity. 426 The parameter delta is to allow a degree of flexibility in the send time 427 of a packet. If the operating system has a scheduling timer granularity 428 of t_gran seconds, then delta would typically be set to: 430 delta = min(t_ipi/2, t_gran/2) 432 t_gran is 10ms on many Unix systems. If t_gran is not known, a value of 433 10ms can be safely assumed. 435 5. Calculation of the loss rate (p) 437 Obtaining a accurate and stable measurement of the loss rate is of 438 primary importance for TFRC. Loss rate measurement is performed at the 439 receiver, based on the detection of lost packets from the sequence 440 numbers of arriving packets. We describe this process before describing 441 the rest of the receiver protocol. 443 5.1. Detection of Lost Packets 445 TFRC assumes that all packets contain a sequence number that is 446 incremented by one for each packet that is sent. For the purposes of 447 this specification, we require that if a lost packet is retransmitted, 448 the retransmission is given a new sequence number that is the latest in 449 the transmission sequence, and not the same sequence number as the 450 packet that was lost. If a transport protocol has the requirement that 451 it must retransmit with the original sequence number, then the transport 452 protocol designer must figure out how to distinguish delayed from 453 retransmitted packets and how to detect lost retransmissions. 455 The receiver maintains a data structure that keeps track of which 456 packets have arrived and which are missing. For the purposes of 457 specification, we assume that the data structure consists of a list of 458 packets that have arrived along with the receiver timestamp when each 459 packet was received. In practice this data structure will normally be 460 stored in a more compact representation, but this is implementation- 461 specific. 463 The loss of a packet is detected by the arrival of at least three 464 packets with a higher sequence number than the lost packet. The 465 requirement for three subsequent packets is the same as with TCP, and is 466 to make TFRC more robust in the presence of reordering. In contrast to 467 TCP, if a packet arrives late (after 3 subsequent packets arrived) in 468 TFRC, the late packet can fill the hole in TFRC's reception record, and 469 the receiver can recalculate the loss event rate. Future versions of 470 TFRC might make the requirement for three subsequent packets adaptive 471 based on experienced packet reordering, but we do not specify such a 472 mechanism here. 474 5.2. Translation from Loss History to Loss Events 476 TFRC requires that the loss fraction be robust to several consecutive 477 packets lost where those packets are part of the same loss event. This 478 is similar to TCP, which (typically) only performs one halving of the 479 congestion window during any single RTT. Thus the receiver needs to map 480 the packet loss history into a loss event record, where a loss event is 481 one or more packets lost in an RTT. To perform this mapping, the 482 receiver needs to know the RTT to use, and this is supplied periodically 483 by the sender, typically as control information piggy-backed onto a data 484 packet. TFRC is not sensitive to how the RTT measurement sent to the 485 receiver is made, but we recommend using the sender's calculated RTT, R, 486 (see Section 4.2) for this purpose. 488 To determine whether a lost packet should start a new loss event, or be 489 counted as part of an existing loss event, we need to compare the 490 sequence numbers and timestamps of the packets that arrived at the 491 receiver. Assume: 493 S_loss is the sequence number of a lost packet. 495 S_before is the sequence number of the last packet to arrive with 496 sequence number before S_loss. 498 S_after is the sequence number of the first packet to arrive with 499 sequence number after S_loss. 501 T_before is the reception time of S_before. 503 T_after is the reception time of S_after. 505 Note that T_before can either be before or after T_after due to 506 reordering. 508 We can interpolate the nominal "arrival time" of S_loss at the receiver 509 from the arrival times of S_before and S_after. Thus 511 T_loss = T_before + ( (T_after - T_before) 512 * (S_loss - S_before)/(S_after - S_before) ) 514 Note that if the sequence space wrapped between S_before and S_after, 515 then the sequence numbers must be modified to take this into account 516 before performing this calculation. If the largest possible sequence 517 number is S_max, and S_before > S_after, then modifying each sequence 518 number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally be 519 sufficient. 521 If the lost packet S_old was determined to have started the previous 522 loss event, and we have just determined that S_new has been lost, then 523 we interpolate the nominal arrival times of S_old and S_new, called 524 T_old and T_new respectively. 526 If T_old + R >= T_new, then S_new is part of the existing loss event. 527 Otherwise S_new is the first packet in a new loss event. 529 5.3. Inter-loss Event Interval 531 If a loss interval, A, is determined to have started with packet 532 sequence number S_A and the next loss interval, B, started with packet 533 sequence number S_B, then the number of packets in loss interval A is 534 given by (S_B - S_A). 536 5.4. Average Loss Interval 538 To calculate the loss event rate p, we first calculate the average loss 539 interval. This is done using a filter that weights the n most recent 540 loss event intervals in such a way that the measured loss event rate 541 changes smoothly. 543 Weights w_0 to w_(n-1) are calculated as: 545 If i < n/2 546 w_i = 1 547 Else 548 w_i = 1 - (i - (n/2 - 1))/(n/2 + 1) 550 Thus if n=8, the values of w_0 to w_7 are: 552 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2 554 The value n for the number of loss intervals used in calculating the 555 loss event rate determines TRFC's speed in responding to changes in the 556 level of congestion. As currently specified, TFRC should not be used 557 for values of n significantly greater than 8, for traffic that might 558 compete in the global Internet with TCP. At the very least, safe 559 operation with values of n greater than 8 would require a slight change 560 to TFRC's mechanisms to include a more severe response to two or more 561 round-trip times with heavy packet loss. 563 To calculate the average loss interval we need to decide whether to 564 include the interval since the most recent packet loss event. We only 565 do this if it is sufficiently large to increase the average loss 566 interval. 568 Thus if the most recent loss intervals are I_0 to I_n, with I_0 being 569 the interval since the most recent loss event, then we calculate the 570 average loss interval I_mean as: 572 I_tot0 = 0 573 I_tot1 = 0 574 W_tot = 0 575 for i = 0 to n-1 { 576 I_tot0 = I_tot0 + (I_i * w_i) 577 W_tot = W_tot + w_i 578 } 579 for i = 1 to n { 580 I_tot1 = I_tot1 + (I_i * w_(i-1)) 581 } 582 I_tot = max(I_tot0, I_tot1) 584 I_mean = I_tot / W_tot 586 The loss event rate, p is simply: 588 p = 1 / I_mean 590 6. Data Receiver Protocol 592 The receiver periodically sends feedback messages to the sender. 593 Feedback packets should normally be sent at least once per RTT, unless 594 the sender is sending at a rate of less than one packet per RTT, in 595 which case a feedback packet should be send for every data packet 596 received. A feedback packet should also be sent whenever a new loss 597 event is detected without waiting for the end of an RTT, and whenever an 598 out-of-order data packet is received that removes a loss event from the 599 history. 601 If the sender is transmitting at a high rate (many packets per RTT) 602 there may be some advantages to sending periodic feedback messages more 603 than once per RTT as this allows faster response to changing RTT 604 measurements, and more resilience to feedback packet loss. However 605 there is little gain from sending a large number of feedback messages 606 per RTT. 608 6.1. Receiver behavior when a data packet is received 610 When a data packet is received, the receiver performs the following 611 steps: 613 1) Add the packet to the packet history. 615 2) Let the previous value of p be p_prev. Calculate the new value of 616 p as described in Section 5. 618 3) If p < p_prev, cause the feedback timer to expire, and perform the 619 actions described in Section 6.2. 621 If p >= p_prev no action need be performed. 623 However an optimization might check to see if the arrival of the 624 packet caused a hole in the packet history to be filled and 625 consequently two loss intervals were merged into one. If this is 626 the case, the receiver might also send feedback immediately. The 627 effects of such an optimization are normally expected to be small. 629 6.2. Expiration of feedback timer 631 When the feedback timer at the receiver expires, the action to be taked 632 depends on whether data packets have been received since the last 633 feedback was sent. 635 Let the maximum sequence number of a packet at the receiver so far be 636 S_m, and the value of the RTT measurement included in packet S_m be R_m. 637 If data packets have been received since the pervious feedback was sent, 638 the receiver performs the following steps: 640 1) Calculate the average loss event rate using the algorithm described 641 above. 643 2) Calculate the measured receive rate, X_sample, based on the packets 644 received within the previous R_m seconds. 646 3) Calculate X_recv as follows: 648 X_recv = q3*X_sample + (1-q3)*X_recv 650 Where q3 is a constant with recommended value 0.5. 652 4) Prepare and send a feedback packet containing the information 653 described in Section 3.2.2. 655 5) Restart the feedback timer to expire after R_m seconds. 657 If no data packets have been received since the last feedback was sent, 658 no feedback packet is sent, and the feedback timer is restarted to 659 expire after R_m seconds. 661 6.3. Receiver initialization 663 The receiver is initialized by the first packet that arrives at the 664 receiver. Let the sequence number of this packet be i. 666 When the first packet is received: 668 o Set p=0 670 o Set X_recv = X_send, where X_send is the sending rate the sender 671 reports in the first data packet. 673 o Prepare and send a feedback packet. 675 o Set the feedback timer to expire after R_i seconds. 677 7. Modifying the Packet Size 679 8. Security Considerations 681 TFRC is not a transport protocol in its own right, but a congestion 682 control mechanism that is intended to be used in conjunction with a 683 transport protocol. Therefore security primarily needs to be considered 684 in the context of a specific transport protocol and its authentication 685 mechanisms. 687 Congestion control mechanisms can potentially be exploited to create 688 denial of service. This may occur through spoofed feedback. Thus any 689 transport protocol that uses TFRC should take care to ensure that 690 feedback is only accepted from the receiver of the data. The precise 691 mechanism to achieve this will however depend on the transport protocol 692 itself. 694 In addition, congection control mechanisms may potentially be 695 manipulated by a greedy receiver that wishes to receive more than its 696 fair share of network bandwidth. A receiver might do this by claiming 697 to have received packets that in fact were lost due to congestion. 698 Possible defenses against such a receiver would normally include some 699 form of nonce that the receiver must feed back to the sender to prove 700 receipt. However, the details of such a nonce would depend on the 701 transport protocol, and in particular on whether the transport protocol 702 is reliable or unreliable. 704 9. Authors' Addresses 705 Mark Handley, Jitendra Padhye, Sally Floyd 706 ACIRI/ICSI 707 1947 Center St, Suite 600 708 Berkeley, CA 94708 709 mjh@aciri.org, padhye@aciri.org, floyd@aciri.org 711 Joerg Widmer 712 Lehrstuhl Praktische Informatik IV 713 Universitat Mannheim 714 L 15, 16 - Room 415 715 D-68131 Mannheim 716 Germany 717 widmer@informatik.uni-mannheim.de 719 10. Acknowledgments 721 We would like to acknowledge feedback and discussions on equation-based 722 congestion control with a wide range of people, including members of the 723 Reliable Multicast Research Group, the Reliable Multicast Transport 724 Working Group, and the End-to-End Research Group. 726 11. References 728 [1] Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer, 729 "Equation-Based Congestion Control for Unicast Applications", 730 August 2000, Proc SIGCOMM 2000. 732 [2] Padhye, J. and Firoiu, V. and Towsley, D. and Kurose, J., "Modeling 733 TCP Throughput: A Simple Model and its Empirical Validation", Proc 734 ACM SIGCOMM 1998.