idnits 2.17.1 draft-ietf-rmt-bb-tfmcc-01.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 November 2002) is 7845 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) -- Looks like a reference, but probably isn't: 'WES01' on line 1211 == Unused Reference: '5' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1276, but no explicit reference was found in the text -- No information found for draft-ietf-rmt-norm-bb - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2988 (ref. '5') (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 2481 (ref. '6') (Obsoleted by RFC 3168) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1889 (ref. '8') (Obsoleted by RFC 3550) == Outdated reference: A later version (-04) exists of draft-ietf-tsvwg-tcp-nonce-00 ** Downref: Normative reference to an Historic draft: draft-ietf-tsvwg-tcp-nonce (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force RMT WG 2 INTERNET-DRAFT Joerg Widmer/Univ. Mannheim 3 draft-ietf-rmt-bb-tfmcc-01.txt Mark Handley/ICIR 5 1 November 2002 6 Expires: May 2003 8 TCP-Friendly Multicast Congestion Control (TFMCC): 9 Protocol Specification 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a product of the IETF RMT WG. Comments should be 32 addressed to the authors, or the WG's mailing list at rmt@lbl.gov. 34 Abstract 36 This document specifies TCP-Friendly Multicast Congestion 37 Control (TFMCC). TFMCC is a congestion control mechanism for 38 multicast transmissions in a best-effort Internet environment. 39 It is a single-rate congestion control scheme, where the 40 sending rate is adapted to the receiver experiencing the worst 41 Expires: May 2003 November 2002 43 network conditions. TFMCC is reasonably fair when competing 44 for bandwidth with TCP flows and has a relatively low 45 variation of throughput over time, making it suitable for 46 applications such as streaming media where a relatively smooth 47 sending rate is of importance. 49 Expires: May 2003 November 2002 51 Table of Contents 53 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . 5 55 1.2. Related Documents. . . . . . . . . . . . . . . . . . 5 56 1.3. Environmental Requirements and Considerations. . . . 5 57 2. Protocol Overview . . . . . . . . . . . . . . . . . . . 6 58 2.1. TCP Throughput Equation. . . . . . . . . . . . . . . 7 59 2.2. Packet Contents. . . . . . . . . . . . . . . . . . . 8 60 2.2.1. Data Packets. . . . . . . . . . . . . . . . . . . 8 61 2.2.2. Feedback Packets. . . . . . . . . . . . . . . . . 9 62 3. Data Sender Protocol. . . . . . . . . . . . . . . . . . 10 63 3.1. Sender Initialization. . . . . . . . . . . . . . . . 10 64 3.2. Determining the Maximum RTT. . . . . . . . . . . . . 10 65 3.3. Adjusting the Sending Rate . . . . . . . . . . . . . 11 66 3.4. Controlling Receiver Feedback. . . . . . . . . . . . 12 67 3.5. Assisting Receiver-Side RTT Measurements . . . . . . 13 68 3.6. Slowstart. . . . . . . . . . . . . . . . . . . . . . 14 69 3.7. Scheduling of Packet Transmissions . . . . . . . . . 15 70 4. Data Receiver Protocol. . . . . . . . . . . . . . . . . 15 71 4.1. Receiver Initalization . . . . . . . . . . . . . . . 16 72 4.2. Receiver Leave . . . . . . . . . . . . . . . . . . . 16 73 4.3. Measurement of the Network Conditions. . . . . . . . 16 74 4.3.1. Updating the Loss Event Rate. . . . . . . . . . . 16 75 4.3.2. Basic Round-Trip Time Measurement . . . . . . . . 16 76 4.3.3. One-Way Delay Adjustments . . . . . . . . . . . . 17 77 4.3.4. Receive Rate Measurements . . . . . . . . . . . . 17 78 4.4. Setting the Desired Rate . . . . . . . . . . . . . . 18 79 4.5. Feedback and Feedback Suppression. . . . . . . . . . 18 80 5. Calculation of the Loss Event Rate. . . . . . . . . . . 20 81 5.1. Detection of Lost or Marked Packets. . . . . . . . . 20 82 5.2. Translation from Loss History to Loss Events . . . . 21 83 5.3. Inter-Loss Event Interval. . . . . . . . . . . . . . 22 84 5.4. Average Loss Interval. . . . . . . . . . . . . . . . 22 85 5.5. History Discounting. . . . . . . . . . . . . . . . . 23 86 5.6. Initializing the Loss History after the First 87 Loss Event. . . . . . . . . . . . . . . . . . . . . . . . 25 88 6. Security Considerations . . . . . . . . . . . . . . . . 26 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . 27 90 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 27 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . 28 92 10. References . . . . . . . . . . . . . . . . . . . . . . 28 93 11. Full Copyright Statement . . . . . . . . . . . . . . . 29 94 Expires: May 2003 November 2002 96 1. Introduction 98 This document specifies TCP-Friendly Multicast Congestion Control 99 (TFMCC) [11]. TFMCC is a source-based, single-rate congestion control 100 scheme that builds upon the unicast TCP-Friendly Rate Control mechanism 101 (TFRC) [2]. TFMCC is stable and responsive under a wide range of network 102 conditions and scales to receivers sets on the order of several thousand 103 receivers. To support scalability, as much congestion control 104 functionality as possible is located at the receivers. Each receiver 105 continuously determines a desired receive rate that is TCP-friendly for 106 the path from the sender to this receiver. Selected receivers then 107 report the rate to the sender in feedback packets. 109 TFMCC is a building block as defined in RFC3048. Instead of specifying 110 a complete protocol, this document simply specifies a congestion control 111 mechanism that could be used in a transport protocol such as RTP [8], in 112 an application incorporating end-to-end congestion control at the 113 application level. This document does not discuss packet formats, 114 reliability, or implementation-related issues. 116 TFMCC is designed to be reasonably fair when competing for bandwidth 117 with TCP flows. A multicast flow is ``reasonably fair'' if its sending 118 rate is generally within a factor of two of the sending rate of a TCP 119 flow from the sender to the slowest receiver of the multicast group 120 under the same network conditions. 122 In general, TFMCC has a low variation of throughput, which makes it 123 suitable for applications such as streaming media where a relatively 124 smooth sending rate is of importance. The penalty of having smooth 125 throughput while competing fairly for bandwidth is a reduced 126 responsiveness to changes in available bandwidth. Thus TFMCC should be 127 used when the application has a requirement for smooth throughput, in 128 particular, avoiding halving of the sending rate in response to a single 129 packet drop. For applications that simply need to multicast as much 130 data as possible in as short a time as possible, PGMCC [7] may be more 131 suitable. 133 TFMCC is designed for applications that use a fixed packet size, and 134 vary their sending rate in packets per second in response to congestion. 135 Some audio applications require a fixed interval of time between packets 136 and vary their packet size instead of their packet rate in response to 137 congestion. The congestion control mechanism in this document cannot be 138 used by those applications. 140 Expires: May 2003 November 2002 142 1.1. Terminology 144 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 145 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 146 "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate 147 requirement levels for compliant TFMCC implementations. 149 1.2. Related Documents 151 As described in RFC3048, TFMCC is a building block that is intended to 152 be used, in conjunction with other building blocks, to help specify a 153 protocol instantiation. In particular, TFMCC is a suitable congestion 154 control building block for NACK-Oriented Reliable Multicast (NORM) [1]. 156 1.3. Environmental Requirements and Considerations 158 TFMCC is intended to be a congestion control scheme that can be used in 159 a complete protocol instantiation that delivers objects and streams 160 (both reliable content delivery and streaming of multimedia 161 information). 163 TFMCC is most applicable for sessions that deliver a substantial amount 164 of data, i.e., in length from hundreds of kilobytes to many gigabytes, 165 and whose duration is in the order of tens of seconds or more. 167 TFMCC is intended for multicast delivery. There are currently two 168 models of multicast delivery, the Any-Source Multicast (ASM) model as 169 defined in RFC1112 and the Source-Specific Multicast (SSM) model as 170 defined in [3]. TFMCC works with both multicast models, but in a 171 slightly different way. When using ASM, feedback from the receivers is 172 multicast to the sender as well as to all other receivers. Feedback can 173 be either multicast on the same group address used for sending data or 174 on a separate multicast feedback group address. For SSM, the receivers 175 must unicast the feedback directly to the sender. Hence, feedback from 176 a receiver will not be received by other receivers. 178 TFMCC inherently works with all types of networks, including LANs, WANs, 179 Intranets, the Internet, asymmetric networks, wireless networks, and 180 satellite networks. However, in some network environments varying the 181 sending rate to the receivers may not be advantageous (e.g., for a 182 satellite or wireless network, there may be no mechanism for receivers 183 to effectively reduce their reception rate since there may be a fixed 184 transmission rate allocated to the session). 186 Expires: May 2003 November 2002 188 2. Protocol Overview 190 TFMCC extends the basic mechanisms of TFRC into the multicast domain. 191 In order to compete fairly with TCP, TFMCC receivers individually 192 measure the prevalent network conditions and calculate a rate that is 193 TCP-friendly on the path from the sender to themselves. The rate is 194 determined using an equation for TCP throughput, which roughly describes 195 TCP's sending rate as a function of the loss event rate, round-trip time 196 (RTT), and packet size. We define a loss event as one or more lost or 197 marked packets from the packets received during one RTT, where a marked 198 packet refers to a congestion indication from Explicit Congestion 199 Notification (ECN) [6]. The sending rate of the multicast transmission 200 is adapted to the receiver experiencing the worst network conditions. 202 Basically, TFMCC's congestion control mechanism works as follows: 204 o Each receiver measures the loss event rate and its RTT to the sender. 206 o Each receiver then uses this information, together with an equation 207 for TCP throughput, to derive a TCP-friendly sending rate. 209 o Through a distributed feedback suppression mechanism, only a subset of 210 the receivers are allowed to give feedback to prevent a feedback 211 implosion at the sender. The feedback mechanism ensures that 212 receivers reporting a low desired transmission rate have a high 213 probability of sending feedback. 215 o Receivers whose feedback is not suppressed report the calculated 216 transmission rate back to the sender in so-called receiver reports. 217 The receiver reports serve two purposes: they inform the sender about 218 the appropriate transmit rate, and they allow the receivers to measure 219 their RTT. 221 o The sender selects the receiver that reports the lowest rate as 222 current limiting receiver (CLR). Whenever feedback with an even lower 223 rate reaches the sender, the corresponding receiver becomes CLR and 224 the sending rate is reduced to match that receiver's calculated rate. 225 The sending rate increases when the CLR reports a calculated rate 226 higher than the current sending rate. 228 The dynamics of TFMCC are sensitive to how the measurements are 229 performed and applied and what feedback suppression mechanism is chosen. 230 We recommend specific mechanisms below to perform and apply these 231 measurements. Other mechanisms are possible, but it is important to 232 understand how the interactions between mechanisms affect the dynamics 233 of TFMCC. 235 Expires: May 2003 November 2002 237 2.1. TCP Throughput Equation 239 Any realistic equation giving TCP throughput as a function of loss event 240 rate and RTT should be suitable for use in TFMCC. However, we note that 241 the TCP throughput equation used must reflect TCP's retransmit timeout 242 behavior, as this dominates TCP throughput at higher loss rates. We 243 also note that the assumptions implicit in the throughput equation about 244 the loss event rate parameter have to be a reasonable match to how the 245 loss rate or loss event rate is actually measured. While this match is 246 not perfect for the throughput equation and loss rate measurement 247 mechanisms given below, in practice the assumptions turn out to be close 248 enough. 250 The throughput equation we currently recommend for TFMCC is a slightly 251 simplified version of the throughput equation for Reno TCP from [4]: 253 8 s 254 X = --------------------------------------------------------- (1) 255 R * (sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2))) 257 where 259 X is the transmit rate in bits/second. 261 s is the packet size in bytes. 263 R is the round-trip time in seconds. 265 p is the loss event rate, between 0.0 and 1.0, of the number of 266 loss events as a fraction of the number of packets transmitted. 268 In future, different TCP equations may be substituted for this equation. 269 The requirement is that the throughput equation be a reasonable 270 approximation of the sending rate of TCP for conformant TCP congestion 271 control. 273 The parameters s (packet size), p (loss event rate) and R (RTT) need to 274 be measured or calculated by a TFMCC implementation. The measurement of 275 R is specified in Section 4.3.2, and the measurement of p is specified 276 in Section 5. The parameter s (packet size) is normally known to an 277 application. This may not be so in two cases: 279 o The packet size naturally varies depending on the data. In this case, 280 although the packet size varies, that variation is not coupled to the 281 Expires: May 2003 November 2002 283 transmit rate. It should normally be safe to use an estimate of the 284 mean packet size for s. 286 o The application needs to change the packet size rather than the number 287 of packets per second to perform congestion control. This would 288 normally be the case with packet audio applications where a fixed 289 interval of time needs to be represented by each packet. Such 290 applications need to have a different way of measuring parameters. 292 Currently, TFMCC cannot be used for the second class of applications. 294 2.2. Packet Contents 296 Before specifying the sender and receiver functionality, we describe the 297 contents of the data packet headers sent by the sender and feedback 298 packets sent by the receivers. As TFMCC will be used along with a 299 transport protocol, we do not specify packet formats, since these depend 300 on the details of the transport protocol used. 302 The recommended representation of the header fields is given below. 303 Alternatively, if the computational overhead of a floating point 304 representation is prohibitive, fixed point arithmetic can be used at the 305 expense of larger packet headers. 307 2.2.1. Data Packets 309 Each packet sent by the data sender contains the following information: 311 o A sequence number i. This number is incremented by one for each data 312 packet transmitted. The field must be sufficiently large that it does 313 not wrap causing two different packets with the same sequence number 314 to be in the receiver's recent packet history at the same time. In 315 most cases the sequence number will be supplied by the transport 316 protocol used along with TFMCC. 318 o A suppression rate X_supp in bits/s. Only receivers with a calculated 319 rate lower than the suppression rate are eligible to give feedback, 320 unless their RTT is higher than the maximum RTT described below in 321 which case they are also eligible to give feedback. The suppression 322 rate should be represented as a 12 bit floating point value with 5 323 bits for the unsigned exponent and 7 bits for the unsigned mantissa 324 (to represent rates from 100 bit/s to 400 Gbit/s with an error of less 325 than 1%). 327 o A timestamp ts_i indicating when the packet is sent. The resolution 328 of the timestamp should typically be milliseconds and the timestamp 329 Expires: May 2003 November 2002 331 should be an unsigned integer value no less than 16 bits wide. 333 o A receiver ID r and a copy of the timestamp ts_r of that receiver's 334 last report, which allows the receiver to measure its RTT. The 335 receiver ID is described in the next section. The resolution of the 336 timestamp echo should be milliseconds and the timestamp should be an 337 unsigned integer value no less than 16 bits wide. 339 o A flag is_CLR indicating whether the receiver with ID r is the CLR. 341 o A feedback round counter fb_nr. This counter is incremented by the 342 sender at the beginning of a new feedback round to notify the 343 receivers than all feedback for older rounds should be suppressed. 344 The feedback round counter should be at least 4 bits wide. 346 o A maximum RTT value R_max, representing the maximum of the RTTs of all 347 receivers. The RTT should be measured in milliseconds. An 8 bit 348 floating point value with 4 bits for the unsigned exponent and 4 bits 349 for the unsigned mantissa (to represent RTTs from 1 millisecond to 64 350 seconds with an error of ca. 6%) should be used for the 351 representation. 353 2.2.2. Feedback Packets 355 TFMCC receivers use two different formats for feedback packets depending 356 on whether they have made at least one RTT measurement or not. Each 357 feedback packet sent by a data receiver contains the following 358 information: 360 o A unique receiver ID r. In most cases the receiver ID will be 361 supplied by the transport protocol, but it may simply be the IP 362 address of the receiver. 364 o A flag have_RTT indicating whether the receiver has made at least one 365 RTT measurement since it joined the session. 367 o A flag have_loss indicating whether the receiver experienced at least 368 one loss event since it joined the session. 370 o A flag receiver_leave indicating that the receiver will leave the 371 session (and should therefore not be CLR). 373 o A timestamp ts_r indicating when the feedback packet is sent. The 374 representation of the timestamp should be the same as that of the 375 timestamp echo in the data packets. 377 Expires: May 2003 November 2002 379 o An echo of the timestamp of the last data packet received. If the 380 last packet received at the receiver has sequence number i, then ts_i 381 is included in the feedback. If there is a delay t_d between 382 receiving that last data packet and sending feedback, then ts_i' = 383 ts_i + t_d is included in the feedback instead of ts_i. The 384 representation of the timestamp echo should be the same as that of the 385 timestamp in the data packets. 387 o A feedback round echo fb_nr, reflecting the highest feedback round 388 counter value received so far. The representation of the feedback 389 round echo should be the same as the one used for the feedback round 390 counter in the data packets. 392 o The desired sending rate X_r. This is the rate calculated by the 393 receiver to be TCP-friendly on the path from the sender to this 394 receiver. The representation of the desired sending rate should be 395 the same as that of the suppression rate in the data packets. 397 3. Data Sender Protocol 399 The data sender multicasts a stream of data packets to the data 400 receivers at a controlled rate. Whenever feedback is received, the 401 sender checks if it is necessary to switch CLRs and to readjust the 402 sending rate. 404 The main tasks that have to be provided by a TFMCC sender are: 406 o adjusting the sending rate, 408 o controlling receiver feedback, and 410 o assisting receiver-side RTT measurements. 412 3.1. Sender Initialization 414 At initialization of the sender, the maximum RTT is set to a value that 415 should be larger than the highest RTT to any of the receivers. It 416 should not be smaller than 500 milliseconds for operation in the public 417 Internet. The sending rate X is initialized to 1 packet per maximum 418 RTT. 420 3.2. Determining the Maximum RTT 422 For each feedback packet that arrives at the sender, the sender computes 423 the instantaneous RTT to the receiver as 424 Expires: May 2003 November 2002 426 R_r = t_now - ts_i 428 where t_now is the time the feedback packet arrived. Receivers will 429 have adjusted ts_i for the time interval between receiving the last data 430 packet and sending the corresponding report so that this interval will 431 not be included in R_r. If the instantaneous RTT is larger than the 432 current maximum RTT, the maximum RTT is increased to that value 434 R_max = R_r 436 Otherwise, if no feedback with a higher instantaneous RTT than the 437 maximum RTT is received during a feedback round (see Section 3.4), the 438 maximum RTT is reduced exponentially to 440 R_max = R_max * 0.9 442 which results in a slow decrease over a number of feedback rounds. 444 The maximum RTT is mainly used for feedback suppression among receivers 445 with heterogeneous RTTs. Feedback suppression is closely coupled to the 446 sending of data packets and for this reason, the maximum RTT must not 447 decrease below the maximum time interval between consecutive data 448 packets: 450 R_max = max(R_max, s/X + t_gran) 452 where t_gran is the granularity of the sender's system clock (see 453 Section 3.7). 455 3.3. Adjusting the Sending Rate 457 When a feedback packet from receiver r arrives at the sender, the sender 458 has to check whether it is necessary to adjust the transmission rate and 459 to switch to a new CLR. 461 How the rate is adjusted depends on the desired rate X_r of the receiver 462 report. We distinguish four cases: 464 1 If no CLR is present, receiver r becomes the current limiting 465 receiver. The sending rate X is directly set to X_r, so long as 466 this would result in a rate increase of less than 8s/R_max bits/s. 467 Otherwise X is gradually increased to X_r at an increase rate of no 468 more than 8s/R_max bits/s every R_max seconds. 470 2 If receiver r is not the CLR but a CLR is present, then receiver r 471 becomes the current limiting receiver if X_r is less than the 472 current sending rate X and the receiver_leave flag of that 473 Expires: May 2003 November 2002 475 receiver's report is not set. Furthermore, the sending rate is 476 reduced to X_r. 478 3 If receiver r is not the CLR but a CLR is present and the 479 receiver_leave flag of the CLR's last report was set, then receiver 480 r becomes the current limiting receiver. However, if X_r > X, the 481 sending rate is not increased to X_r for the duration of a feedback 482 round to allow other (lower rate) receivers to give feedback and be 483 selected as CLR. 485 4 If receiver r is the CLR, the sending rate is set to the minimum of 486 X_r and X + 8s/R_max bits/s. 488 If the receiver has not yet measured its RTT (i.e., the have_RTT flag is 489 set), the receiver report will include a desired rate that is based on 490 the maximum RTT rather than the actual RTT to that receiver. In this 491 case, the sender adjusts the desired rate using its measurement of the 492 instantaneous RTT R_r to that receiver: 494 X_r' = X_r * R_max / R_r 496 X_r' is then used instead of X_r to detect whether to switch to a new 497 CLR. 499 If the TFMCC sender receives no reports from the CLR for at least 10 500 RTTs, it assumes that the CLR crashed or left the group. A new CLR is 501 selected from the feedback that subsequently arrives at the sender, and 502 we increase as in case 3 above. 504 In the absence of any feedback from any of the receivers it is necessary 505 to reduce the sending rate. For every 10 consecutive RTTs without 506 feedback, the sending rate is cut in half. The rate is at most reduced 507 to one packet every 64 seconds. Note that when receivers stop receiving 508 data packets, they will stop sending feedback. This eventually causes 509 the sending rate to be reduced in the case of network failure. If the 510 network subsequently recovers, a linear increase to the calculated rate 511 of the CLR will occur at 8s/R_max bits/s every R_max. 513 3.4. Controlling Receiver Feedback 515 The receivers allowed to send a receiver report are determined in so- 516 called feedback rounds. Feedback rounds have a duration T of six times 517 the maximum RTT. In case the multicast model is ASM, i.e., receiver 518 feedback is multicast to the whole group, the duration of a feedback 519 round may be reduced to four times the maximum RTT. 521 Expires: May 2003 November 2002 523 Only receivers wishing to report a rate that is lower than the 524 suppression rate X_supp, or those with a higher RTT than R_max may send 525 feedback. At the beginning of each feedback round, X_supp is set to the 526 highest possible value that can be represented. When feedback arrives 527 at the sender over the course of a feedback round, X_supp is decreased 528 such that more and more feedback is suppressed towards the end of the 529 round. How receiver feedback is spread out over the feedback round is 530 discussed in Section 4.5. 532 Whenever non-CLR feedback for the current round arrives at the sender, 533 X_supp is reduced to 535 X_supp = (1-g) * X_r 537 if X_supp > X_r. Feedback that causes the corresponding receiver to be 538 selected as CLR, but was from a non-CLR receiver at the time of sending 539 also contributes to the feedback suppression. Note that X_r must not be 540 adjusted by the sender to reflect the receiver's real RTT in case X_r 541 was calculated using the maximum RTT, as is done for setting the sending 542 rate (Section 3.3), otherwise a feedback implosion is possible. The 543 parameter g determines to what extent higher rate feedback can suppress 544 lower rate feedback. This mechanism guarantees, that the lowest 545 calculated rate reported lies within a factor of g of the actual lowest 546 calculated rate of the receiver set (see [10]). A value of g of 0.1 is 547 recommended. 549 After a time span of T, the feedback round ends if non-CLR feedback was 550 received during that time. Otherwise, the feedback round ends as soon 551 as the first non-CLR feedback meesage arrives at the sender but at most 552 after 2T. The feedback round counter is incremented by one and the 553 suppression rate X_supp is reset to the highest representable value. 554 The feedback round counter restarts with round 0 after a wrap-around. 556 3.5. Assisting Receiver-Side RTT Measurements 558 Receivers measure their RTT by sending a timestamp with a receiver 559 report, which is echoed in the next data packet. Only one receiver ID 560 and timestamp can be included in a data packet. If multiple feedback 561 messages from different receivers arrive at the sender during the time 562 interval between two data packets, the sender has to decide which 563 receiver to allow to measure RTT. 565 The sender's timestamp echoes are prioritized in the following order: 567 1. a new CLR (after a change of CLR's) or a CLR without any previous 568 RTT measurements 569 Expires: May 2003 November 2002 571 2. receivers without any previous RTT measurements in the order of the 572 feedback round echo of the corresponding receiver report (i.e., 573 older feedback first) 575 3. non-CLR receivers with previous RTT measurements, again in 576 ascending order of the feedback round echo of the report 578 4. the CLR 580 Ties are broken in favor of the receiver with the lowest reported rate. 582 It is necessary to account for the time that elapses between receiving a 583 report and sending the next data packet. This time needs to be deducted 584 from the RTT and thus has to be added to the receiver's timestamp value. 585 The receiver ID and the adjusted timestamp of the receiver with the 586 highest priority are then included in the next data packet. 588 Whenever no feedback packets arrive in the interval between two data 589 packets, the CLR's last timestamp, adjusted by the appropriate offset, 590 is echoed. When the number of packets per RTT is so low that all 591 packets carry a non-CLR receiver's timestamp, the CLR's timestamp and ID 592 are included in a data packet at least once per feedback round. 594 3.6. Slowstart 596 TFMCC uses a slowstart mechanism to quickly approach its fair bandwidth 597 share at the start of a session. During slowstart, the sending rate 598 increases exponentially. The rate increase is limited to the minimum of 599 the rates included in the receiver reports and receivers report twice 600 the rate at which they currently receive data. As in normal congestion 601 control mode, the receiver with the smallest reported rate becomes CLR. 602 Since a receiver can never receive data at a rate higher than its link 603 bandwidth, this effectively limits the overshoot to twice this 604 bandwidth. In case the resulting increase over R_max is less than 605 8s/R_max bits/s, the sender may choose to increase the rate by up to 606 8s/R_max bits/s every R_max. The current sending rate is gradually 607 adjusted to the target rate reported in the receiver reports over the 608 course of a RTT. Slowstart is terminated as soon as any one of the 609 receivers experiences its first packet loss. Since that receiver's 610 calculated rate will be lower than the current sending rate, the 611 receiver will be selected as CLR. 613 During slowstart, the upper bound on the rate increase of 8s/R_max 614 bits/s every RTT does not apply. Only after the TFMCC sender receives 615 the first report with the have_loss flag set is the rate increase 616 limited in this way. 618 Expires: May 2003 November 2002 620 3.7. Scheduling of Packet Transmissions 622 As TFMCC is rate-based, and as operating systems typically cannot 623 schedule events precisely, it is necessary to be opportunistic about 624 sending data packets so that the correct average rate is maintained 625 despite the coarse-grain or irregular scheduling of the operating 626 system. Thus a typical sending loop will calculate the correct inter- 627 packet interval, t_ipi, as follows: 629 t_ipi = s/X 631 When a sender first starts sending at time t_0, it calculates t_ipi, and 632 calculates a nominal send time t_1 = t_0 + t_ipi for packet 1. When the 633 application becomes idle, it checks the current time, t_now, and then 634 requests re-scheduling after (t_ipi - (t_now - t_0)) seconds. When the 635 application is re-scheduled, it checks the current time, t_now, again. 636 If (t_now > t_1 - delta) then packet 1 is sent (see below for delta). 638 Now a new t_ipi may be calculated, and used to calculate a nominal send 639 time t_2 for packet 2: t2 = t_1 + t_ipi. The process then repeats, with 640 each successive packet's send time being calculated from the nominal 641 send time of the previous packet. 643 In some cases, when the nominal send time, t_i, of the next packet is 644 calculated, it may already be the case that t_now > t_i - delta. In 645 such a case the packet should be sent immediately. Thus if the 646 operating system has coarse timer granularity and the transmit rate is 647 high, then TFMCC may send short bursts of several packets separated by 648 intervals of the OS timer granularity. 650 The parameter delta is to allow a degree of flexibility in the send time 651 of a packet. If the operating system has a scheduling timer granularity 652 of t_gran seconds, then delta would typically be set to: 654 delta = min(t_ipi/2, t_gran/2) 656 t_gran is 10 milliseconds on many Unix systems. If t_gran is not known, 657 a value of 10 milliseconds can be safely assumed. 659 4. Data Receiver Protocol 661 Receivers measure the current network conditions, namely RTT and loss 662 event rate, and use this information to calculate a rate that is fair to 663 competing traffic. The rate is then communicated to the sender in 664 receiver reports. Due to the potentially large number of receivers, it 665 is undesirable that all receivers send reports, especially not at the 666 same time. 668 Expires: May 2003 November 2002 670 In the description of the receiver functionality, we will first address 671 how the receivers measure the network parameters and then discuss the 672 feedback process. 674 4.1. Receiver Initalization 676 The receiver is initialized when it receives the first data packet. The 677 RTT is set to the maximum RTT value contained in the data packet. This 678 initial value is used as the receiver's RTT until the first real RTT 679 measurement is made. The loss event rate is initialized to 0. 681 4.2. Receiver Leave 683 A receiver that sends feedback but wishes to leave the TFMCC session 684 within the next feedback round may indicate the pending leave by setting 685 the receiver_leave flag in its report. If the leaving receiver is the 686 CLR, the receiver_leave flag should be set for all the reports within 687 the feedback round before the leave takes effect. 689 4.3. Measurement of the Network Conditions 691 Receivers have to update their estimate of the network parameters with 692 each new data packet they receive. 694 4.3.1. Updating the Loss Event Rate 696 When a data packet is received, the receiver adds the packet to the 697 packet history. It then recalculates the new value of the loss event 698 rate p. The loss event rate measurement mechanism is described 699 separately in Section 5. 701 4.3.2. Basic Round-Trip Time Measurement 703 When a receiver gets a data packet that carries the receiver's own ID in 704 the r field, the receiver updates its RTT estimate. 706 1. The current RTT is calculated as: 708 R_sample = t_now - ts_r 710 where t_now is the time the data packet arrives at the receiver and 711 ts_r is the receiver report timestamp echoed in the data packet. 713 Expires: May 2003 November 2002 715 2. The smoothed RTT estimate R is updated: 717 If no feedback has been received before 718 R = R_sample 719 Else 720 R = q*R + (1-q)*R_sample 722 A filter parameter q of 0.5 is recommended for non-CLR receivers. 723 The CLR performs RTT measurements much more frequently and hence 724 should use a higher filter value. We recommend using q=0.9. Note 725 that TFMCC is not sensitive to the precise value for the filter 726 constant. 728 4.3.3. One-Way Delay Adjustments 730 When a RTT measurement is performed, the receiver also determines the 731 one-way delay D_r from itself to the sender: 733 D_r = ts_r - ts_i 735 where ts_i and ts_r are the timestamp and timestamp echo contained in 736 the data packet. With each new data packet i', the receiver can now 737 calculate an updated RTT estimate as: 739 R' = D_r + t_now - ts_i' 741 Inbetween RTT measurements, the updated R' is used instead of the 742 smoothed RTT R. When a new measurement is made, all interim one-way 743 delay measurements are discarded (i.e., the smoothed RTT is updated 744 according to Section 4.3.2 without taking one-way delay adjustments into 745 account). 747 For the one-way delay measurements, the clocks of sender and receivers 748 need not be synchronized. Clock skew will cancel itself out when both 749 one-way measurements are added to form a RTT estimate, as long as clock 750 drift between real RTT measurements is negligible. 752 4.3.4. Receive Rate Measurements 754 When a receiver has not experienced any loss events, it cannot calculate 755 a TCP-friendly rate to include in the receiver reports. Instead, the 756 receiver measures the current receive rate and sets the desired rate X_r 757 to twice the receive rate. 759 The receive rate in bits/s is measured as the number of bits received 760 over the last k RTTs, taking into account the IP and transport packet 761 Expires: May 2003 November 2002 763 headers, but excluding the link-layer packet headers. A value for k 764 between 2 and 4 is recommended. 766 4.4. Setting the Desired Rate 768 When a receiver measures a non-zero loss event rate, it calculates the 769 desired rate using Equation (1). In case no RTT measurement is 770 available yet, the maximum RTT is used instead of the receiver's RTT. 771 The desired rate is updated whenever the loss event rate or the RTT 772 changes. 774 As mentioned above, calculation of the desired rate is not possible 775 before the receiver experiences the first loss event and in that case 776 twice the rate at which data is received is included in the receiver 777 reports as X_r. This mechanism allows the sender to slowstart as 778 described in Section 3.6. 780 4.5. Feedback and Feedback Suppression 782 Let fb_nr be the highest feedback round counter value received by a 783 receiver. When a new data packet arrives with a higher feedback round 784 counter than fb_nr, a new feedback round begins and fb_nr is updated. 785 Outstanding feedback for the old round is cancelled. In case a feedback 786 number with a value that is more than half the feedback number space 787 lower than fb_nr is received, the receiver assumes that the feedback 788 round counter wrapped and also cancels the feedback timer and updates 789 fb_nr. 791 The CLR sends its feedback independently from all the other receivers 792 once per RTT. Its feedback does not suppress other feedback and cannot 793 be suppressed by other receiver's feedback. 795 Non-CLR receivers set a feedback timer at the beginning of a feedback 796 round. Using an exponentially weighted random timer mechanism, the 797 feedback timer is set to expire after 799 t = max(T * (1 + log(x)/log(N)), 0) 801 where 803 x is a random variable uniformly distributed in (0,1], 805 T is the duration of a feedback round, 807 N is an estimated upper bound on the number of receivers. 809 Expires: May 2003 November 2002 811 N is a constant specific to the TFMCC protocol. Since TFMCC scales to 812 up to thousands of receivers, setting N to 10,000 for all receivers (and 813 limiting the TFMCC session to at most 10,000 receivers) is recommended. 815 A feedback packet is sent when the feedback timer expires, unless the 816 timer is cancelled beforehand. When the multicast model is ASM, 817 feedback is multicast to the whole group, otherwise the feedback is 818 unicast to the sender. The feedback packet includes the calculated rate 819 valid at the time the feedback packet is sent (not the rate at the point 820 of time when the feedback timer is set). The copy of the timestamp ts_i 821 of the last data packet received, which is included in the feedback 822 packet, needs to be adjusted by the time interval between receiving the 823 data packet and sending the report to allow the sender to correctly 824 infer the instantaneous RTT (i.e., that time interval has to be added to 825 the timestamp value). 827 The timer is cancelled if a data packet with a lower suppression rate 828 than the receiver's calculated rate and a higher or equal maximum RTT 829 than the receiver's RTT is received. Likewise, a data packet indicating 830 the beginning of a new feedback round cancels all feedback for older 831 rounds. In case of ASM, the timer is also cancelled if a feedback 832 packet from another non-CLR receiver reporting a lower rate is received. 834 The feedback suppression process is complicated by the fact that the 835 calculated rates of the receivers will change during a feedback round. 836 If the calculated rates decrease rapidly for all receivers, feedback 837 suppression can no longer prevent a feedback implosion since earlier 838 feedback will always report a higher rate than current feedback. To make 839 the feedback suppression mechanism robust in the face of changing rates, 840 it is necessary to introduce X_fbr, the calculated rate of a receiver at 841 the beginning of a feedback round. A receiver needs to suppress its 842 feedback not only when the suppression rate is less than the receiver's 843 current calculated rate but also in the case that the suppression rate 844 falls below X_fbr. 846 When the maximum RTT changes significantly during one feedback round, it 847 is necessary to reschedule the feedback timer in proportion to the 848 change. 850 t = t * R_max / R_max' 852 where R_max is the new maximum RTT and R_max' is the previous maximum 853 RTT. The same considerations hold, when the last data packets were 854 received more than a time interval of R_max ago. In this case, it is 855 necessary to add the difference of the inter-packet gap and the maximum 856 RTT to the feedback time to prevent a feedback implosion (e.g., in case 857 the sender crashed). 859 Expires: May 2003 November 2002 861 t = t + max(t_now - tr_i - R_max, 0) 863 where tr_i is the time when the last data packet arrived at the 864 receiver. 866 More details on the characteristics of the feedback suppression 867 mechanism can be found in [10] and [11]. 869 5. Calculation of the Loss Event Rate 871 Obtaining an accurate and stable measurement of the loss event rate is 872 of primary importance for TFMCC. Loss rate measurement is performed at 873 the receiver, based on the detection of lost or marked packets from the 874 sequence numbers of arriving packets. 876 5.1. Detection of Lost or Marked Packets 878 TFMCC assumes that all packets contain a sequence number that is 879 incremented by one for each packet that is sent. For the purposes of 880 this specification, we require that if a lost packet is retransmitted, 881 the retransmission is given a new sequence number that is the latest in 882 the transmission sequence, and not the same sequence number as the 883 packet that was lost. If a transport protocol has the requirement that 884 it must retransmit with the original sequence number, then the transport 885 protocol designer must figure out how to distinguish delayed from 886 retransmitted packets and how to detect lost retransmissions. 888 The receivers each maintain a data structure that keeps track of which 889 packets have arrived and which are missing. For the purposes of 890 specification, we assume that the data structure consists of a list of 891 packets that have arrived along with the timestamp when each packet was 892 received. In practice this data structure will normally be stored in a 893 more compact representation, but this is implementation-specific. 895 The loss of a packet is detected by the arrival of at least three 896 packets with a higher sequence number than the lost packet. The 897 requirement for three subsequent packets is the same as with TCP, and is 898 to make TFMCC more robust in the presence of reordering. In contrast to 899 TCP, if a packet arrives late (after 3 subsequent packets arrived) at a 900 receiver, the late packet can fill the hole in the reception record, and 901 the receiver can recalculate the loss event rate. Future versions of 902 TFMCC might make the requirement for three subsequent packets adaptive 903 based on experienced packet reordering, but we do not specify such a 904 mechanism here. 906 Expires: May 2003 November 2002 908 For an ECN-capable connection, a marked packet is detected as a 909 congestion event as soon as it arrives, without having to wait for the 910 arrival of subsequent packets. 912 5.2. Translation from Loss History to Loss Events 914 TFMCC requires that the loss event rate be robust to several consecutive 915 packets lost where those packets are part of the same loss event. This 916 is similar to TCP, which (typically) only performs one halving of the 917 congestion window during any single RTT. Thus the receivers needs to 918 map the packet loss history into a loss event record, where a loss event 919 is one or more packets lost in a RTT. 921 To determine whether a lost or marked packet should start a new loss 922 event, or be counted as part of an existing loss event, we need to 923 compare the sequence numbers and timestamps of the packets that arrived 924 at the receiver. For a marked packet S_new, its reception time T_new 925 can be noted directly. For a lost packet, we can interpolate to infer 926 the nominal "arrival time". Assume: 928 S_loss is the sequence number of a lost packet. 930 S_before is the sequence number of the last packet to arrive with 931 sequence number before S_loss. 933 S_after is the sequence number of the first packet to arrive with 934 sequence number after S_loss. 936 T_before is the reception time of S_before. 938 T_after is the reception time of S_after. 940 Note that T_before can either be before or after T_after due to 941 reordering. 943 For a lost packet S_loss, we can interpolate its nominal "arrival time" 944 at the receiver from the arrival times of S_before and S_after. Thus 946 T_loss = T_before + ( (T_after - T_before) 947 * (S_loss - S_before)/(S_after - S_before) ); 949 Note that if the sequence space wrapped between S_before and S_after, 950 then the sequence numbers must be modified to take this into account 951 before performing the calculation. If the largest possible sequence 952 number is S_max, and S_before > S_after, then modifying each sequence 953 number S by S' = (S + (S_max + 1)/2) mod (S_max + 1) would normally be 954 Expires: May 2003 November 2002 956 sufficient. 958 If the lost packet S_old was determined to have started the previous 959 loss event, and we have just determined that S_new has been lost, then 960 we interpolate the nominal arrival times of S_old and S_new, called 961 T_old and T_new respectively. 963 If T_old + R >= T_new, then S_new is part of the existing loss event. 964 Otherwise S_new is the first packet of a new loss event. 966 5.3. Inter-Loss Event Interval 968 If a loss interval, A, is determined to have started with packet 969 sequence number S_A and the next loss interval, B, started with packet 970 sequence number S_B, then the number of packets in loss interval A is 971 given by (S_B - S_A). 973 5.4. Average Loss Interval 975 To calculate the loss event rate p, we first calculate the average loss 976 interval. This is done using a filter that weights the n most recent 977 loss event intervals in such a way that the measured loss event rate 978 changes smoothly. 980 Weights w_0 to w_(n-1) are calculated as: 982 If (i < n/2) 983 w_i = 1; 984 Else 985 w_i = 1 - (i - (n/2 - 1))/(n/2 + 1); 987 Thus if n=8, the values of w_0 to w_7 are: 989 1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2 991 The value n for the number of loss intervals used in calculating the 992 loss event rate determines TFMCC's speed in responding to changes in the 993 level of congestion. As currently specified, TFMCC should not be used 994 for values of n significantly greater than 8, for traffic that might 995 compete in the global Internet with TCP. At the very least, safe 996 operation with values of n greater than 8 would require a slight change 997 to TFMCC's mechanisms to include a more severe response to two or more 998 round-trip times with heavy packet loss. 1000 Expires: May 2003 November 2002 1002 When calculating the average loss interval we need to decide whether to 1003 include the interval since the most recent packet loss event. We only 1004 do this if it is sufficiently large to increase the average loss 1005 interval. 1007 Thus if the most recent loss intervals are I_0 to I_n, with I_0 being 1008 the interval since the most recent loss event, then we calculate the 1009 average loss interval I_mean as: 1011 I_tot0 = 0; 1012 I_tot1 = 0; 1013 W_tot = 0; 1014 for (i = 0 to n-1) { 1015 I_tot0 = I_tot0 + (I_i * w_i); 1016 W_tot = W_tot + w_i; 1017 } 1018 for (i = 1 to n) { 1019 I_tot1 = I_tot1 + (I_i * w_(i-1)); 1020 } 1021 I_tot = max(I_tot0, I_tot1); 1022 I_mean = I_tot/W_tot; 1024 The loss event rate, p is simply: 1026 p = 1 / I_mean; 1028 5.5. History Discounting 1030 As described in Section 5.4, the most recent loss interval is only 1031 assigned 4/(3*n) of the total weight in calculating the average loss 1032 interval, regardless of the size of the most recent loss interval. This 1033 section describes an optional history discounting mechanism that allows 1034 the TFMCC receivers to adjust the weights, concentrating more of the 1035 relative weight on the most recent loss interval, when the most recent 1036 loss interval is more than twice as large as the computed average loss 1037 interval. 1039 To carry out history discounting, we associate a discount factor DF_i 1040 with each loss interval L_i, where each discount factor is a floating 1041 point number. The discount array maintains the cumulative history of 1042 discounting for each loss interval. At the beginning, the values of 1043 DF_i in the discount array are initialized to 1: 1045 Expires: May 2003 November 2002 1047 for (i = 1 to n) { 1048 DF_i = 1; 1049 } 1051 History discounting also uses a general discount factor DF, also a 1052 floating point number, that is also initialized to 1. First we show how 1053 the discount factors are used in calculating the average loss interval, 1054 and then we describe later in this section how the discount factors are 1055 modified over time. 1057 As described in Section 5.4 the average loss interval is calculated 1058 using the n previous loss intervals I_1, ..., I_n, and the interval I_0 1059 that represents the number of packets received since the last loss 1060 event. The computation of the average loss interval using the discount 1061 factors is a simple modification of the procedure in Section 5.4, as 1062 follows: 1064 I_tot0 = I_0 * w_0 1065 I_tot1 = 0; 1066 W_tot0 = w_0 1067 W_tot1 = 0; 1068 for (i = 1 to n-1) { 1069 I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF); 1070 W_tot0 = W_tot0 + w_i * DF_i * DF; 1071 } 1072 for (i = 1 to n) { 1073 I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i); 1074 W_tot1 = W_tot1 + w_(i-1) * DF_i; 1075 } 1076 p = min(W_tot0/I_tot0, W_tot1/I_tot1); 1078 The general discounting factor, DF is updated on every packet arrival as 1079 follows. First, a receiver computes the weighted average I_mean of the 1080 loss intervals I_1, ..., I_n: 1082 I_tot = 0; 1083 W_tot = 0; 1084 for (i = 1 to n) { 1085 W_tot = w_(i-1) * DF_i; 1086 I_tot = I_tot + (I_i * w_(i-1) * DF_i); 1087 } 1088 I_mean = I_tot / W_tot; 1090 This weighted average I_mean is compared to I_0, the number of packets 1091 received since the last loss event. If I_0 is greater than twice 1092 I_mean, then the new loss interval is considerably larger than the old 1093 ones, and the general discount factor DF is updated to decrease the 1094 relative weight on the older intervals, as follows: 1096 Expires: May 2003 November 2002 1098 if (I_0 > 2 * I_mean) { 1099 DF = 2 * I_mean/I_0; 1100 if (DF < THRESHOLD) 1101 DF = THRESHOLD; 1102 } else 1103 DF = 1; 1105 A nonzero value for THRESHOLD ensures that older loss intervals from an 1106 earlier time of high congestion are not discounted entirely. We 1107 recommend a THRESHOLD of 0.5. Note that with each new packet arrival, 1108 I_0 will increase further, and the discount factor DF will be updated. 1110 When a new loss event occurs, the current interval shifts from I_0 to 1111 I_1, loss interval I_i shifts to interval I_(i+1), and the loss interval 1112 I_n is forgotten. The previous discount factor DF has to be 1113 incorporated into the discount array. Because DF_i carries the discount 1114 factor associated with loss interval I_i, the DF_i array has to be 1115 shifted as well. This is done as follows: 1117 for (i = 1 to n) { 1118 DF_i = DF * DF_i; 1119 } 1120 for (i = n-1 to 0 step -1) { 1121 DF_(i+1) = DF_i; 1122 } 1123 I_0 = 1; 1124 DF_0 = 1; 1125 DF = 1; 1127 This completes the description of the optional history discounting 1128 mechanism. We emphasize that this is an optional mechanism whose sole 1129 purpose is to allow TFMCC to response somewhat more quickly to the 1130 sudden absence of congestion, as represented by a long current loss 1131 interval. 1133 5.6. Initializing the Loss History after the First Loss Event 1135 The number of packets received before the first loss event ususally does 1136 not reflect the current loss event rate. When the first loss event 1137 occurs, a TFMCC receiver assumes that the correct data rate is the rate 1138 at which data was received during the last RTT when the loss occurred. 1139 Instead of initializing the first loss interval to the number of packets 1140 sent until the first loss event, the TFMCC receiver calculates the loss 1141 interval that would be required to produce the receive rate X_recv, and 1142 uses this synthetic loss interval l_0 to seed the loss history 1143 mechanism. 1145 Expires: May 2003 November 2002 1147 The initial loss interval is calculated by inverting a simplified 1148 version of the TCP Equation (1). 1150 s 1151 X_recv = sqrt(3/2) * ----------------- 1152 R * sqrt(1/l_0) 1154 X_recv * R 1155 ==> l_0 = (---------------)^2 1156 sqrt(3/2) * s 1158 The resulting initial loss interval is too small at higher loss rates 1159 compared to using the more accurate Eqation (1), which leads to a more 1160 conservative initial loss event rate. 1162 If a receiver still uses the initial RTT R_max instead of its real RTT, 1163 the initial loss interval is too large in case the initial RTT is higher 1164 than the actual RTT. As a consequence, the receiver will calculate a 1165 too high desired rate when the first RTT measurement R is made and the 1166 initial loss interval is still in the loss history. The receiver has to 1167 adjust l_0 as follows: 1169 l_0 = l_0 * (R/R_max)^2 1171 No action needs to be taken when the first RTT measurement is made after 1172 the initial loss interval left the loss history. 1174 6. Security Considerations 1176 TFMCC is not a transport protocol in its own right, but a congestion 1177 control mechanism that is intended to be used in conjunction with a 1178 transport protocol. Therefore security primarily needs to be considered 1179 in the context of a specific transport protocol and its authentication 1180 mechanisms. 1182 Congestion control mechanisms can potentially be exploited to create 1183 denial of service. This may occur through spoofed feedback. Thus any 1184 transport protocol that uses TFMCC should take care to ensure that 1185 feedback is only accepted from valid receivers of the data. The precise 1186 mechanism to achieve this will however depend on the transport protocol 1187 itself. 1189 Expires: May 2003 November 2002 1191 Congestion control mechanisms may potentially be manipulated by a greedy 1192 receiver that wishes to receive more than its fair share of network 1193 bandwidth. However, in TFMCC a receiver can only influence the sending 1194 rate if it is the CLR and thus has the lowest calculated rate of all 1195 receivers. If the calculated rate is then manipulated such that it 1196 exceeds the calculated rate of the second to lowest receiver, it will 1197 cease to be CLR. A greedy receiver can only significantly increase then 1198 transmission rate if it is the only participant in the session. If such 1199 scenarios are of concern, possible defenses against such a receiver 1200 would normally include some form of nonce that the receiver must feed 1201 back to the sender to prove receipt. However, the details of such a 1202 nonce would depend on the transport protocol, and in particular on 1203 whether the transport protocol is reliable or unreliable. 1205 It is possible that a receiver sends feedback claiming it has a very low 1206 calculated rate. This will reduce the rate of the multicast session and 1207 might render it useless but obviously cannot hurt the network itself. 1209 We expect that protocols incorporating ECN with TFMCC will also want to 1210 incorporate feedback from the receiver to the sender using the ECN nonce 1211 [WES01]. The ECN nonce is a modification to ECN that protects the 1212 sender from the accidental or malicious concealment of marked packets. 1213 Again, the details of such a nonce would depend on the transport 1214 protocol, and are not addressed in this document. 1216 7. IANA Considerations 1218 There are no IANA actions required for this document. 1220 8. Authors' Addresses 1222 Joerg Widmer 1223 Lehrstuhl Praktische Informatik IV 1224 University of Mannheim 1225 L 15, 16 - Room 415 1226 D-68131 Mannheim 1227 Germany 1228 widmer@informatik.uni-mannheim.de 1230 Mark Handley 1231 ICSI Center for Internet Research 1232 1947 Center St, Suite 600 1233 Berkeley, CA 94708 1234 mjh@icir.org 1235 Expires: May 2003 November 2002 1237 9. Acknowledgments 1239 We would like to acknowledge feedback and discussions on equation-based 1240 congestion control with a wide range of people, including members of the 1241 Reliable Multicast Research Group, the Reliable Multicast Transport 1242 Working Group, and the End-to-End Research Group. 1244 10. References 1246 [1] B. Adamson, C. Bormann, M. Handley, and J. Macker, "NACK-Oriented 1247 Reliable Multicast (NORM) Protocol Building Blocks", Internet Draft 1248 draft-ietf-rmt-norm-bb-02.txt, July 2001, work in progress. 1249 Citation for informational purposes only. 1251 [2] S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-Based 1252 Congestion Control for Unicast Applications", Proc ACM SIGCOMM 1253 2000, Stockholm, August 2000 1255 [3] H. W. Holbrook, "A Channel Model for Multicast," Ph.D. 1256 Dissertation, Stanford University, Department of Computer Science, 1257 Stanford, California, August 2001. 1259 [4] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP 1260 Throughput: A Simple Model and its Empirical Validation", Proc ACM 1261 SIGCOMM 1998. 1263 [5] V. Paxson and M. Allman, "Computing TCP's Retransmission Timer", RFC 1264 2988, November 2000. 1266 [6] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit Congestion 1267 Notification (ECN) to IP", RFC 2481, January 1999. 1269 [7] L. Rizzo, "pgmcc: a TCP-friendly single-rate multicast congestion 1270 control scheme", Proc ACM SIGCOMM 2000, Stockholm, August 2000 1272 [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 1273 Transport Protocol for Real-Time Applications", RFC 1889, January 1274 1996. 1276 [9] D. Wetherall, D. Ely, and N. Spring, "Robust ECN Signaling with 1277 Nonces", Internet Draft draft-ietf-tsvwg-tcp-nonce-00.txt, January 1278 2001, work in progress. Citation for informational purposes only. 1280 [10] J. Widmer and T. Fuhrmann, "Extremum Feedback for Very Large 1281 Multicast Groups", Proc NGC 2001, London, November 2001. 1283 Expires: May 2003 November 2002 1285 [11] J. Widmer and M. Handley, "Extending Equation-Based Congestion 1286 Control to Multicast Applications", Proc ACM SIGCOMM 2001, San 1287 Diego, August 2001 1289 11. Full Copyright Statement 1291 Copyright (C) The Internet Society (2001). All Rights Reserved. 1293 This document and translations of it may be copied and furnished to 1294 others, and derivative works that comment on or otherwise explain it or 1295 assist in its implementation may be prepared, copied, published and 1296 distributed, in whole or in part, without restriction of any kind, 1297 provided that the above copyright notice and this paragraph are included 1298 on all such copies and derivative works. However, this document itself 1299 may not be modified in any way, such as by removing the copyright notice 1300 or references to the Internet Society or other Internet organizations, 1301 except as needed for the purpose of developing Internet standards in 1302 which case the procedures for copyrights defined in the Internet 1303 languages other than English. 1305 The limited permissions granted above are perpetual and will not be 1306 revoked by the Internet Society or its successors or assigns. 1308 This document and the information contained herein is provided on an "AS 1309 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1310 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1311 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1312 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1313 FITNESS FOR A PARTICULAR PURPOSE."