idnits 2.17.1 draft-ietf-dccp-tfrc-voip-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2087. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2111. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3448]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (20 November 2006) is 6366 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) == Outdated reference: A later version (-06) exists of draft-ietf-dccp-rfc3448bis-00 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Sally Floyd 3 INTERNET-DRAFT ICIR 4 draft-ietf-dccp-tfrc-voip-07.txt Eddie Kohler 5 Expires: May 2007 UCLA 6 20 November 2006 8 TCP Friendly Rate Control (TFRC): 9 the Small-Packet (SP) Variant 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 2007. 36 Abstract 38 This document proposes a mechanism for further experimentation, but 39 not for widespread deployment at this time in the global Internet. 41 TCP-Friendly Rate Control (TFRC) is a congestion control mechanism 42 for unicast flows operating in a best-effort Internet environment 43 [RFC3448]. TFRC was intended for applications that use a fixed 44 packet size, and was designed to be reasonably fair when competing 45 for bandwidth with TCP connections using the same packet size. This 46 document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that 47 is designed for applications that send small packets. The design 48 goal for TFRC-SP is to achieve the same bandwidth in bps (bits per 49 second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP 50 enforces a minimum interval of 10 ms between data packets, to 51 prevent a single flow from sending small packets arbitrarily 52 frequently. 54 Flows using TFRC-SP compete reasonably fairly with large-packet TCP 55 and TFRC flows in environments where large-packet flows and small- 56 packet flows experience similar packet drop rates. However, in 57 environments where small-packet flows experience lower packet drop 58 rates than large-packet flows (e.g., with Drop-Tail queues in units 59 of bytes), TFRC-SP can receive considerably more than its share of 60 the bandwidth. 62 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 63 Changes from draft-ietf-dccp-tfrc-voip-06.txt: 64 * Fixed nits introduced in the last round of editing. 65 Feedback from Gorry Fairhurst. 66 * Fixed Tables 1-4, in terms of taking account of packet 67 header sizes for 536-byte packets. Feedback from Ladan 68 Gharai. 69 * Added a paragraph about apps gaming about the packet size, 70 in Section 6 on "TFRC-SP with Applications that Modify 71 the Packet Size". Feedback from Gorry Fairhurst. 72 * Added a paragraph that if the endpoint knows the MSS of 73 the path, the endpoint SHOULD use that for the nominal 74 segment size. From discussions with Gorry Fairhurst and 75 Richard Nelson. 76 * Added several paragrahs about TFRC-SP over paths 77 with small MTUs. Feedback from Gorry Fairhurst and 78 Richard Nelson. 79 * Added pseudocode to Section 3 on "TFRC-SP Congestion Control" 80 for the change of not using the current interval in 81 estimating the loss event rate if the current interval 82 is short. Feedback from Ladan Gharai. 84 Changes from draft-ietf-dccp-tfrc-voip-05.txt: 85 * Feedback from Gorry Fairhurst: 86 - Small editing changes, rephrasing, and bug fixes. 87 - Explicitly stated that assuming a 40-byte header 88 is OK even if IPv6 is used. 89 - Moved most of Section 7 on Simulations to 90 the appendix. 91 - Added a subsection to Section 8 on "Fairness with 92 different packet header sizes" 93 - Add a paragraph about TFRC-SP and TFRC-PS. 94 - A sudden step-change in the packet size? - 95 no change made to algorithm. 96 - Clarified text on impact of a reduced TCP MSS. 97 * Feedback from Lars Eggert: 98 - Small editing changes, rephrasing, and bug fixes. 99 * Feedback from Mark Handley: 100 - No change made to algorithm, but added Appendix C 101 to discuss the issue. 102 * Feedback from Ladan Gharai: 103 - Added the restriction that the most recent loss interval 104 is not included in the calculation of the average 105 loss interval if the most recent loss interval is short. 106 - Corrected use of "packet" and "segment" in a few places. 108 Changes from draft-ietf-dccp-tfrc-voip-04.txt: 109 * Added tables showing the response function for TCP, TFRC, 110 and TFRC-SP, for a range of packet sizes, for both 111 packet and byte drop rates. In response to feedback 112 from Magnus Westerlund. 113 * Along with response function, added that TCP's sending 114 rate varies linearly with packet size. From a 115 suggestion by Magnus Westerlund. 116 * Added a sentence saying that TCP has a range of sender 117 algorithms for setting the RTO. 118 * Deleted the sentence equating TFRC-SP with TFRC-PS 119 referred to in RFC 3448. From a suggestion 120 by Colin Perkins. 121 * Added that wireless links sometimes are less likely to 122 drop small packets. Reported from Pete Sholander. 123 * Added simulations to the end of Section 7.3 comparing 124 the effects of TFRC and of TFRC-SP, for an environment 125 with a Drop-Tail queue in bytes, showing the possible 126 negative consequences of TFRC-SP. In response to email 127 from Magnus Westerlund. 128 * Added an explanation for the Adaptive RED simulation 129 with packet drop rates greater than 50%. In response 130 to email from Magnus Westerlund. 131 * Added a Conclusions section, with a sentence that a 132 separate document will be used to specify an 133 experimental CCID based on TFRC-SP. In response 134 to feedback during Working Group Last Call. 135 * Added a paragraph about "Initializing the Loss History 136 after the First Loss Event" in TFRC-SP. 138 Changes from draft-ietf-dccp-tfrc-voip-03.txt: 139 * Added a paragraph saying that this is intended for 140 Experimental, for further experimentation and not 141 for widespread deployment. 142 * Editing of abstract so that it still fits the 25-line 143 limit. 145 Changes from draft-ietf-dccp-tfrc-voip-02.txt: 146 * Changed name from "VoIP variant of TFRC" to "TFRC-SP". 147 * Added Section 4.5 on "The Nominal Packet Size", discussing 148 possible differences in packet drop rates between small 149 and large packets. 150 * Added text to Section 5 on "A Comparison with RFC 3714". 151 * Added text to Section 6 on "TFRC-SP with Applications that 152 Modify the Packet Size" 153 * Added simulations with small-packet TCP flows. 154 * Added a Security Considerations section. 155 * Minor editing. 157 Changes from draft-ietf-dccp-tfrc-voip-01.txt: 159 * Added modified algorithm for calculating the loss event rate, 160 for short intervals with multiple packet drops. 161 * Moved Faster Restart to a separate document. 162 * Added simulations with a configured byte drop rate. 163 * Added many more simulations, including Drop-Tail with a queue 164 in bytes. 165 * Added a discussion of unfairness for Drop-Tail with a queue 166 in bytes. 168 Changes from draft-ietf-dccp-tfrc-voip-00.txt: 169 * Added more simulations. 170 * Added a Related Work section. 172 Table of Contents 174 1. Conventions ....................................................7 175 2. Introduction ...................................................7 176 3. TFRC-SP Congestion Control .....................................9 177 4. TFRC-SP Discussion ............................................13 178 4.1. Response Functions and Throughput Equations ..............13 179 4.2. Accounting for Header Size ...............................16 180 4.3. The TFRC-SP Min Interval .................................17 181 4.4. Counting Packet Losses ...................................18 182 4.5. The Nominal Packet Size ..................................19 183 4.5.1. Packet Size and Packet Drop Rates .................19 184 4.5.2. Fragmentation and the Path MTU ....................21 185 4.5.3. The Nominal Segment Size and the Path MTU .........21 186 4.6. The Loss Interval Length for Short Loss Intervals ........22 187 5. A Comparison with RFC 3714 ....................................23 188 6. TFRC-SP with Applications that Modify the Packet Size .........23 189 7. Simulations ...................................................24 190 8. General Discussion ............................................25 191 9. Security Considerations .......................................26 192 10. IANA Considerations ..........................................27 193 11. Conclusions ..................................................27 194 12. Thanks .......................................................27 195 A. Appendix: Related Work on Small-Packet Variants of TFRC .......27 196 B. Simulation Results ............................................29 197 B.1. Simulations with Configured Packet Drop Rates ............29 198 B.2. Simulations with Configured Byte Drop Rates ..............32 199 B.3. Packet Dropping Behavior at Routers with Drop-Tail Queues 200 ...............................................................35 201 B.4. Packet Dropping Behavior at Routers with AQM .............40 202 C. Appendix: Exploring Possible Oscillations in the Loss Event 203 Rate .............................................................44 204 D. Appendix: A Discussion of Packet Size and Packet Dropping .....45 205 Normative References .............................................46 206 Informative References ...........................................46 207 Authors' Addresses ...............................................48 208 Full Copyright Statement .........................................48 209 Intellectual Property ............................................48 211 1. Conventions 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 2. Introduction 219 This document specifies TFRC-SP, an experimental, Small-Packet 220 variant of TCP-friendly rate control (TFRC) [RFC3448]. 222 TFRC was designed to be reasonably fair when competing for bandwidth 223 with TCP flows, but to avoid the abrupt changes in the sending rate 224 characteristic of TCP's congestion control mechanisms. TFRC is 225 intended for applications such as streaming media applications where 226 a relatively smooth sending rate is of importance. Conventional 227 TFRC measures loss rates by estimating the loss event ratio as 228 described in [RFC3448], and uses this loss event rate to determine 229 the sending rate in packets per round-trip time. This has 230 consequences for the rate that a TFRC flow can achieve when sharing 231 a bottleneck with large-packet TCP flows. In particular, a low- 232 bandwidth, small-packet TFRC flow sharing a bottleneck with high- 233 bandwidth, large-packet TCP flows may be forced to slow down, even 234 though the TFRC application's nominal rate in bytes per second is 235 less than the rate achieved by the TCP flows. Intuitively, this 236 would be "fair" only if the network limitation was in packets per 237 second (such as a routing lookup), rather than bytes per second 238 (such as link bandwidth). Conventional wisdom is that many of the 239 network limitations in today's Internet are in bytes per second, 240 even though the network limitations of the future might move back 241 towards limitations in packets per second. 243 TFRC-SP is intended for flows that need to send frequent small 244 packets, with less than 1500 bytes per packet, limited by a minimum 245 interval between packets of 10 ms. It will better support 246 applications that do not want their sending rates in bytes per 247 second to suffer from their use of small packets. This variant is 248 restricted to applications that send packets no more than once every 249 10 ms (the Min Interval or minimum interval). Given this 250 restriction, TFRC-SP effectively calculates the TFRC fair rate as if 251 the bottleneck restriction was in bytes per second. Applications 252 using TFRC-SP could have a fixed or naturally-varying packet size, 253 or could vary their packet size in response to congestion. 254 Applications that are not willing to be limited by a minimum 255 interval of 10 ms. between packets, or that want to send packets 256 larger than 1500 bytes, should not use TFRC-SP. However, for 257 applications with a minimum interval of at least 10 ms. between 258 packets and with data packets of at most 1500 bytes, the performance 259 of TFRC-SP should be at least as good as that from TFRC. 261 RFC 3448, the protocol specification for TFRC, stated that TFRC-PS 262 (for TFRC-PacketSize), a variant of TFRC for applications that have 263 a fixed sending rate but vary their packet size in response to 264 congestion, would be specified in a later document. This document 265 instead specifies TFRC-SP, a variant of TFRC designed for 266 applications that send small packets, where applications could 267 either have a fixed or varying packet size or could adapt their 268 packet size in response to congestion. However, as discussed in 269 Section 6 of this document, there are many questions about how such 270 an adaptive application would use TFRC-SP that are beyond the scope 271 of this document, and that would need to be addressed in documents 272 that are more application-specific. 274 TFRC-SP is motivated in part by the approach in RFC 3714, which 275 argues that it is acceptable for VoIP flows to assume that the 276 network limitation is in bytes per second (Bps) rather in packets 277 per second (pps), and to have the same sending rate in bytes per 278 second as a TCP flow with 1500-byte packets and the same packet drop 279 rate. RFC 3714 states the following: 281 "While the ideal would be to have a transport protocol that is 282 able to detect whether the bottleneck links along the path are 283 limited in Bps or in pps, and to respond appropriately when the 284 limitation is in pps, such an ideal is hard to achieve. We would 285 not want to delay the deployment of congestion control for 286 telephony traffic until such an ideal could be accomplished. In 287 addition, we note that the current TCP congestion control 288 mechanisms are themselves not very effective in an environment 289 where there is a limitation along the reverse path in pps. 290 While the TCP mechanisms do provide an incentive to use large 291 data packets, TCP does not include any effective congestion 292 control mechanisms for the stream of small acknowledgement 293 packets on the reverse path. Given the arguments above, it 294 seems acceptable to us to assume a network limitation in Bps 295 rather than in pps in considering the minimum sending rate of 296 telephony traffic." 298 Translating the discussion in [RFC3714] to the congestion control 299 mechanisms of TFRC, it seems acceptable to standardize a variant of 300 TFRC that allows low-bandwidth flows sending small packets to 301 achieve a rough fairness with TCP flows in terms of the sending rate 302 in Bps, rather than in terms of the sending rate in pps. This is 303 accomplished by TFRC-SP, a small modification to TFRC, as described 304 below. 306 Maintaining incentives for large packets: Because the bottlenecks in 307 the network in fact can include limitations in pps as well as in 308 Bps, we pay special attention to the potential dangers of 309 encouraging a large deployment of best-effort traffic in the 310 Internet consisting entirely of small packets. This is discussed in 311 more detail in Section 4.3. In addition, as again discussed in 312 Section 4.3, TFRC-SP includes the limitation of the Min Interval 313 between packets of 10 ms. 315 Packet drop rates as a function of packet size: TFRC-SP essentially 316 assumes that the small-packet TFRC-SP flow receives roughly the same 317 packet drop rate as a large-packet TFRC or TCP flow. As we show, 318 this assumption is not necessarily correct for all environments in 319 the Internet. 321 Initializing the Loss History after the First Loss Event: Section 322 6.3.1 of RFC 3448 specifies that the TFRC receiver initializes the 323 loss history after the first loss event by calculating the loss 324 interval that would be required to produce the receive rate measured 325 over the most recent round-trip time. In calculating this loss 326 interval, TFRC-SP uses the segment size of 1460 bytes, rather than 327 the actual segment size used in the connection. 329 Calculating the loss event rate for TFRC-SP: TFRC-SP requires a 330 modification in TFRC's calculation of the loss event rate, because a 331 TFRC-SP connection can send many small packets when a standard TFRC 332 or TCP connection would send a single large packet. It is not 333 possible for a standard TFRC or TCP connection to repeatedly send 334 multiple packets per round-trip time in the face of a high packet 335 drop rate. As a result, TCP and standard TFRC only respond to a 336 single loss event per round-trip time, and are still able to detect 337 and respond to increasingly heavy packet loss rates. However, in a 338 highly-congested environment, when a TCP connection might be 339 sending, on average, one large packet per round-trip time, a 340 corresponding TFRC-SP connection might be sending many small packets 341 per round-trip time. As a result, in order to maintain fairness 342 with TCP, and to be able to detect changes in the degree of 343 congestion, TFRC-SP needs to be sensitive to the actual packet drop 344 rate during periods of high congestion. This is discussed in more 345 detail in the section below. 347 3. TFRC-SP Congestion Control 349 TFRC uses the TCP throughput equation given in Section 3.1 of 350 [RFC3448], which gives the allowed sending rate X in bytes per 351 second as a function of the loss event rate, segment size, and 352 round-trip time. [RFC3448] specifies that the segment size s used 353 in the throughput equation should be the segment size used by the 354 application, or the estimated mean segment size if there are 355 variations in the segment size depending on the data. This gives 356 rough fairness with TCP flows using the same segment size. 358 TFRC-SP changes this behavior in the following ways. 360 o The nominal segment size: The nominal segment size s is set to 361 1460 bytes. Following [RFC3714], this provides a goal of 362 fairness, in terms of the sending rate in bytes per second, with 363 a TCP flow with 1460 bytes of application data per packet but 364 with the same packet drop rate. If the endpoint knows the MTU 365 (Maximum Transmission Unit) of the path and the derived MSS 366 (Maximum Segment Size) is less than 1460 bytes, then the endpoint 367 SHOULD set the nominal segment size s to MSS bytes. In addition, 368 if the endpoint knows the MTU of the path and the resulting MSS 369 is less than 536 bytes, then the endpoint MUST set the nominal 370 segment size s to MSS bytes. 372 However, this document does not require that TFRC-SP endpoints 373 determine the path MTU. While most paths allow an MSS of 1460 374 bytes, some paths have a slightly smaller MSS due to tunnels 375 (e.g., IPv6 over IPv4). In some specific cases, IPv4 paths may 376 experience a much smaller path MTU. Due to the complications of 377 estimating the path MTU, and to the fact that most paths support 378 an MSS of at least 536 bytes, TFRC-SP as a default uses a nominal 379 segment size of 1460 bytes. 381 o Taking packet headers into account: The allowed transmit rate X 382 in bytes per second is reduced by a factor that accounts for 383 packet header size. This gives the application some incentive, 384 beyond the Min Interval, not to use unnecessarily small packets. 385 In particular, we introduce a new parameter H, which represents 386 the expected size in bytes of network and transport headers to be 387 used on the TFRC connection's packets. This is used to reduce 388 the allowed transmit rate X as follows: 390 X := X * s_true / (s_true + H), 392 where s_true is the true average data segment size for the 393 connection in bytes, excluding the transport and network headers. 394 Section 4.1 of RFC 3448 states that where the packet size varies 395 naturally with the data, an estimate of the mean segment size can 396 be used for s_true. As suggested in Section 4.1 of [RFC3448bis], 397 when an estimate of the mean segment size is used for s_true, the 398 estimate SHOULD be calculated over at least the last four loss 399 intervals. However, this document does not specify a specific 400 algorithm for estimating the mean segment size. 402 The H parameter is set to the constant 40 bytes. Thus, if the 403 TFRC-SP application used 40-byte data segments, the allowed 404 transmit rate X would be halved to account for the fact that half 405 of the sending rate would be used by the headers. Section 4.2 406 justifies this definition. However, a connection using TFRC-SP 407 MAY instead use a more precise estimate of H, based on the actual 408 network and transport headers to be used on the connection's 409 packets. For example, a DCCP connection [RFC4340] over IPv4, 410 where data packets use the DCCP-Data packet type, and there are 411 no IP or DCCP options, could set H to 20 + 12 = 32 bytes. If the 412 TFRC implementation knows that the IP layer is using IPv6 instead 413 of IPv4, then the connection using TFRC-SP MAY use an estimate of 414 40 bytes instead of 60 bytes for H, for simplicity of 415 implementation. 417 o Measuring the loss event rate in times of high loss: During short 418 loss intervals (those at most two round-trip times), the loss 419 rate is computed by counting the actual number of packets lost or 420 marked, not by counting at most one loss event per loss interval. 421 Without this change, TFRC-SP could send multiple packets per 422 round-trip time even in the face of heavy congestion, for a 423 steady-state behavior of multiple packets dropped each round-trip 424 time. 426 In standard TFRC, the TFRC receiver estimates the loss event rate 427 by calculating the average loss interval in packets, and 428 inverting to get the loss event rate. Thus, for a short loss 429 interval with N packets and K losses, standard TFRC calculates 430 the size of that loss interval as N packets, contributing to a 431 loss event rate of 1/N. However, for TFRC-SP, for small loss 432 intervals of at most two round-trip times, if the loss interval 433 consists of N packets including K losses, the size of the loss 434 interval is calculated as N/K, contributing to a loss event rate 435 of K/N instead of 1/N. 437 Section 5.4 of RFC 3448 specifies that the calculation of the 438 average loss interval includes the most recent loss interval only 439 if this increases the calculated average loss interval, as in the 440 pseudocode below. However, in TFRC-SP the calculated loss 441 interval size for a short loss interval varies as a function of 442 the number of packet losses that have been detected, allowing 443 either increases or decreases in the calculated loss interval 444 size for the current short loss interval as new packets are 445 received. Therefore, TFRC-SP adds the restriction that the 446 calculation of the average loss interval can include the most 447 recent loss interval only if more than two round-trip times have 448 passed since the beginning of that loss interval. 450 Let the most recent loss intervals be I_0 to I_n, with I_0 being 451 the interval including the most recent loss event, with the 452 corresponding weights w_i as defined in RFC 3448. In RFC 3448 453 (Section 5.4), the average loss interval I_mean is calculated as 454 follows: 456 I_tot0 = 0; 457 I_tot1 = 0; 458 W_tot = 0; 459 for (i = 0 to n-1) { 460 I_tot0 = I_tot0 + (I_i * w_i); 461 W_tot = W_tot + w_i; 462 } 463 for (i = 1 to n) { 464 I_tot1 = I_tot1 + (I_i * w_(i-1)); 465 } 466 I_tot = max(I_tot0, I_tot1); 467 I_mean = I_tot/W_tot; 469 In TFRC-SP, the average loss interval I_mean is instead 470 calculated as follows: 472 I_tot0 = 0; 473 I_tot1 = 0; 474 W_tot = 0; 475 for (i = 0 to n-1) { 476 I_tot0 = I_tot0 + (I_i * w_i); 477 W_tot = W_tot + w_i; 478 } 479 for (i = 1 to n) { 480 I_tot1 = I_tot1 + (I_i * w_(i-1)); 481 } 482 If the current loss interval I_0 is "short" 483 then I_tot = I_tot1; 484 else I_tot = max(I_tot0, I_tot1); 485 I_mean = I_tot/W_tot; 487 o A minimum interval between packets: TFRC-SP enforces a Min 488 Interval between packets of 10 ms. A flow that wishes its 489 transport protocol to exceed this Min Interval MUST use the 490 conventional TFRC equations, rather than TFRC-SP. The motivation 491 for this is discussed below. 493 4. TFRC-SP Discussion 495 4.1. Response Functions and Throughput Equations 497 TFRC uses the TCP throughput equation given in [RFC3448], with the 498 sending rate X in bytes per second as follows: 500 s 501 X = ------------------------------------------------------- , 502 R*sqrt(2*p/3) + (4*R* (3*sqrt(3*p/8) * p * (1+32*p^2))) 504 where: 506 s is the packet size in bytes; 508 R is the round trip time in seconds; 510 p is the loss event rate, between 0 and 1.0, of the number of 511 loss events as a fraction of the number of packets transmitted. 513 This equation uses an RTO of 4*R, and assumes that the TCP 514 connection sends an acknowledgement for every data packet. 516 This equation essentially gives the response function for TCP as 517 well as for standard TFRC (modulo TCP's range of sender algorithms 518 for setting the RTO). As shown in Table 1 of [RFC3714], for high 519 packet drop rates, this throughput equation gives rough fairness 520 with the most aggressive possible current TCP: a SACK TCP flow using 521 timestamps and ECN. Because it is not recommended for routers to 522 use ECN-marking in highly-congested environments with high packet 523 dropping/marking rates [RFC3168] (Section 7), we note that it would 524 be useful to have a throughput equation with a somewhat more 525 moderate sending rate for packet drop rates of 40% and above. 527 The effective response function of TFRC-SP can be derived from the 528 TFRC response function by using a segment size s of 1460 bytes, and 529 using the loss event rate actually experienced by the TFRC-SP flow. 530 In addition, for loss intervals of at most two round-trip times, the 531 loss event rate for TFRC-SP is estimated by counting the actual 532 number of lost or marked packets, rather than by counting loss 533 events. In addition, the sending rate for TFRC-SP is constrained to 534 be at most 100 packets per second. 536 For an environment with a fixed packet drop rate p, regardless of 537 packet size, the response functions of TCP, TFRC, and TFRC-SP are 538 illustrated as follows, given in KBps (Kilo Bytes per second), for a 539 flow with a round-trip time of 100 ms: 541 <-- TCP and Standard TFRC --> 542 Packet 14-byte 536-byte 1460-byte 543 DropRate Segments Segments Segments 544 -------- -------- -------- -------- 545 0.00001 209.25 2232.00 5812.49 546 0.00003 120.79 1288.41 3355.24 547 0.00010 66.12 705.25 1836.58 548 0.00030 38.10 406.44 1058.45 549 0.00100 20.74 221.23 576.12 550 0.00300 11.76 125.49 326.79 551 0.01000 6.07 64.75 168.61 552 0.03000 2.99 31.90 83.07 553 0.10000 0.96 10.21 26.58 554 0.20000 0.29 3.09 8.06 555 0.30000 0.11 1.12 2.93 556 0.40000 0.05 0.48 1.26 557 0.50000 0.02 0.24 0.63 559 Table 1: Response Function for TCP and TFRC. 560 Sending Rate in KBps, as a Function of Packet Drop Rate. 562 <---------- TFRC-SP --------> 563 Packet 14-byte 536-byte 1460-byte 564 DropRate Segments Segments Segments 565 -------- -------- -------- -------- 566 0.00001 5.40 57.60 150.00 567 0.00003 5.40 57.60 150.00 568 0.00010 5.40 57.60 150.00 569 0.00030 5.40 57.60 150.00 570 0.00100 5.40 57.60 150.00 571 0.00300 5.40 57.60 150.00 572 0.01000 5.40 57.60 150.00 573 0.03000 5.40 57.60 83.07 574 0.10000 5.40 26.58 26.58 575 0.20000 5.40 8.06 8.06 576 0.30000 2.93 2.93 2.93 577 0.40000 1.26 1.26 1.26 578 0.50000 0.63 0.63 0.63 580 Table 2: Response Function for TFRC-SP. 581 Sending Rate in KBps, as a Function of Packet Drop Rate. 582 Maximum Sending Rate of 100 Packets per Second. 584 The calculations for Tables 1 and 2 use the packet loss rate for an 585 approximation for the loss event rate p. Scripts and graphs for the 586 tables are available from [VOIPSIMS]. As the well-known TCP 587 response function in Table 1 shows, the sending rate for TCP and 588 standard TFRC varies linearly with segment size. The TFRC-SP 589 response function shown in Table 2 reflects the maximum sending rate 590 of a hundred packets per second; when not limited by this maximum 591 sending rate, the TFRC-SP flow receives the same sending rate in 592 KBps as the TCP flow with 1460-byte segments, given the same packet 593 drop rate. Simulations showing the TCP, standard TFRC, and TFRC-SP 594 sending rates in response to a configured packet drop rate are given 595 in Tables 7, 8, and 9, and are consistent with the response 596 functions shown here. 598 <-- TCP and Standard TFRC --> 599 Byte 14-byte 536-byte 1460-byte 600 DropRate Segments Segments Segments 601 -------- -------- -------- -------- 602 0.0000001 284.76 929.61 1498.95 603 0.0000003 164.39 536.17 863.16 604 0.0000010 90.01 292.64 468.49 605 0.0000030 51.92 167.28 263.68 606 0.0000100 28.34 88.56 132.75 607 0.0000300 16.21 46.67 61.70 608 0.0001000 8.60 19.20 16.25 609 0.0003000 4.56 4.95 1.70 610 0.0010000 1.90 0.37 0.15 611 0.0030000 0.52 0.05 0.06 612 0.0100000 0.04 0.02 0.06 613 0.0300000 0.00 0.02 0.06 615 Table 3: Response Function for TCP and TFRC. 616 Sending Rate in KBps, as a Function of Byte Drop Rate. 618 <---------- TFRC-SP --------> 619 Byte 14-byte 536-byte 1460-byte 620 DropRate Segments Segments Segments 621 -------- -------- -------- -------- 622 0.0000001 5.40 57.60 150.00 623 0.0000003 5.40 57.60 150.00 624 0.0000010 5.40 57.60 150.00 625 0.0000030 5.40 57.60 150.00 626 0.0000100 5.40 57.60 132.75 627 0.0000300 5.40 57.60 61.70 628 0.0001000 5.40 50.00 16.25 629 0.0003000 5.40 12.89 1.70 630 0.0010000 5.40 0.95 0.15 631 0.0030000 5.40 0.12 0.06 632 0.0100000 1.10 0.06 0.06 633 0.0300000 0.13 0.06 0.06 635 Table 4: Response Function for TFRC-SP. 636 Sending Rate in KBps, as a Function of Byte Drop Rate. 637 Maximum Sending Rate of 100 Packets per Second. 639 For Tables 3 and 4, the packet drop rate is calculated as 1-(1-b)^N, 640 for a byte drop rate of b, and a packet size of N bytes. These 641 tables use the packet loss rate as an approximation for the loss 642 event rate p. The TCP response functions shown in Table 3 for fixed 643 byte drop rates are rather different from the response functions 644 shown in Table 1 for fixed packet drop rates; with higher byte drop 645 rates, a TCP connection can have a higher sending rate using 646 *smaller* packets. Table 4 also shows that with fixed byte drop 647 rates, the sending rate for TFRC-SP can be significantly higher than 648 that for TCP or standard TFRC, regardless of the TCP segment size. 649 This is because in this environment, with small packets, TFRC-SP 650 receives a small packet drop rate, but is allowed to send at the 651 sending rate of a TCP or standard TFRC flow using larger packets but 652 receiving the same packet drop rate. 654 Simulations showing TCP, standard TFRC, and TFRC-SP sending rates in 655 response to a configured byte drop rate are given in Appendix B.2 . 657 4.2. Accounting for Header Size 659 [RFC3714] makes the optimistic assumption that the limitation of the 660 network is in bandwidth in bytes per second (Bps), and not in CPU 661 cycles or in packets per second (pps). However, some attention must 662 be paid to the load in pps as well as to the load in Bps. Even 663 aside from the Min Interval, TFRC-SP gives the application some 664 incentive to use fewer but larger packets, when larger packets would 665 suffice, by including the bandwidth used by the packet header in the 666 allowed sending rate. 668 As an example, a sender using 120-byte packets needs a TCP-friendly 669 rate of 128 Kbps to send 96 Kbps of application data. This is 670 because the TCP-friendly rate is reduced by a factor of 671 s_true/(s_true + H) = 120/160, to account for the effect of packet 672 headers. If the sender suddenly switched to 40-byte data segments, 673 the allowed sending rate would reduce to 64 Kbps of application 674 data; and the use of one-byte data segments would reduce the allowed 675 sending rate to 3.12 Kbps of application data. (In fact, the Min 676 Interval would prevent senders from achieving these rates, since 677 applications using TFRC-SP cannot send more than 100 packets per 678 second.) 680 Unless it has a more precise estimate of the header size, TFRC-SP 681 assumes 40 bytes for the header size, although the header could be 682 larger (due to IP options, IPv6, IP tunnels, and the like) or 683 smaller (due to header compression) on the wire. Requiring the use 684 of the exact header size in bytes would require significant 685 additional complexity, and would have little additional benefit. 686 TFRC-SP's default assumption of a 40-byte header is sufficient to 687 get a rough estimate of the throughput, and to give the application 688 some incentive not to use unnecessarily-many small packets. Because 689 we are only aiming at rough fairness, and at a rough incentive for 690 applications, the default use of a 40-byte header in the 691 calculations of the header bandwidth is sufficient for both IPv4 and 692 IPv6. 694 4.3. The TFRC-SP Min Interval 696 The header size calculation provides an incentive for applications 697 to use fewer, but larger, packets. Another incentive is that when 698 the path limitation is in pps, the application using more small 699 packets is likely to cause higher packet drop rates, and to have to 700 reduce its sending rate accordingly. That is, if the congestion is 701 in terms of pps, then the flow sending more pps will increase the 702 packet drop rate, and have to adjust its sending rate accordingly. 703 However, the increased congestion caused by the use of small packets 704 in an environment limited by pps is experienced not only by the flow 705 using the small packets, but by all of the competing traffic on that 706 congested link. These incentives are therefore insufficient to 707 provide sufficient protection for pps network limitations. 709 TFRC-SP, then, includes a Min Interval of 10 ms. This provides 710 additional restrictions on the use of unnecessarily many small 711 packets. 713 One justification for the Min Interval is the practical one that the 714 applications that currently want to send small packets are the VoIP 715 applications that send at most one packet every 10 ms, so this 716 restriction does not affect current traffic. A second justification 717 is that there is no pressing need for best-effort traffic in the 718 current Internet to send small packets more frequently than once 719 every 10 ms (rather than taking the 10 ms delay at the sender, and 720 merging the two small packets into one larger one). This 10 ms 721 delay for merging small packets is likely to be dominated by the 722 network propagation, transmission, and queueing delays of best- 723 effort traffic in the current Internet. As a result, our judgment 724 would be that the benefit to the user of having less than 10 ms 725 between packets is outweighed by the benefit to the network of 726 avoiding unnecessarily many small packets. 728 The Min Interval causes TFRC-SP not to support applications sending 729 small packets very frequently. Consider a TFRC flow with a fixed 730 packet size of 100 bytes, but with a variable sending rate and a 731 fairly uncongested path. When this flow was sending at most 100 732 pps, it would be able to use TFRC-SP. If the flow wished to 733 increase its sending rate to more than 100 pps, but to keep the same 734 packet size, it would no longer be able to achieve this with TFRC- 735 SP, and would have to switch to the default TFRC, receiving a 736 dramatic, discontinuous decrease in its allowed sending rate. This 737 seems not only acceptable, but desirable for the global Internet. 739 What is to prevent flows from opening multiple connections, each 740 with a 10 ms Min Interval, and thereby getting around the limitation 741 of the Min Interval? Obviously, there is nothing to prevent flows 742 from doing this, just as there is currently nothing to prevent flows 743 from using UDP, or from opening multiple parallel TCP connections, 744 or from using their own congestion control mechanism. Of course, 745 implementations or middleboxes are also free to limit the number of 746 parallel TFRC connections opened to the same destination in times of 747 congestion, if that seems desirable. And flows that open multiple 748 parallel connections are subject to the inconveniences of reordering 749 and the like. 751 4.4. Counting Packet Losses 753 It is not possible for a TCP connection to persistently send 754 multiple packets per round-trip time in the face of high congestion, 755 with a steady-state with multiple packets dropped per round-trip 756 time. For TCP, when one or more packets are dropped each round-trip 757 time, the sending rate is quickly dropped to less than one packet 758 per round-trip time. In addition, for TCP with Tahoe, NewReno, or 759 SACK congestion control mechanisms, the response to congestion is 760 largely independent of the number of packets dropped per round-trip 761 time. 763 As a result, standard TFRC can best achieve fairness with TCP, even 764 in highly congested environments, by calculating the loss event rate 765 rather than the packet drop rate, where a loss event is one or more 766 packets dropped or marked from a window of data. 768 However, with TFRC-SP, it is no longer possible to achieve fairness 769 with TCP or with standard TFRC by counting only the loss event rate 770 [WBL04]. Instead of sending one large packet per round-trip time, 771 TFRC-SP could be sending N small packets (where N small packets 772 equal one large 1500-byte packet). The loss measurement used with 773 TFRC-SP has to be able to detect a connection that is consistently 774 receiving multiple packet losses or marks per round-trip time, to 775 allow TFRC-SP to respond appropriately. 777 In TFRC-SP, the loss event rate is calculated by counting at most 778 one loss event in loss intervals longer than two round-trip times, 779 and by counting each packet lost or marked in shorter loss 780 intervals. In particular, for a short loss interval with N packets, 781 including K lost or marked packets, the loss interval length is 782 calculated as N/K, instead as N. The average loss interval I_mean 783 is still averaged over the most recent eight loss intervals, as 784 specified in Section 5.4 of RFC 3448. Thus, if eight successive 785 loss intervals are short loss intervals with N packets and K losses, 786 the loss event rate is calculated as K/N, rather than as 1/N. 788 4.5. The Nominal Packet Size 790 4.5.1. Packet Size and Packet Drop Rates 792 The guidelines in Section 3 above say that the nominal segment size 793 s is set to 1460 bytes, providing a goal of fairness, in terms of 794 the sending rate in bytes per second, with a TCP flow with 1460 795 bytes of application data per packet but with the same packet drop 796 rate. This follows the assumption that a TCP flow with 1460-byte 797 segments will have a higher sending rate than a TCP flow with 798 smaller segments. While this assumption holds in an environment 799 where the packet drop rate is independent of packet size, this 800 assumption does not necessarily hold in an environment where larger 801 packets are more likely to be dropped than are small packets. 803 The table below shows the results of simulations with standard 804 (SACK) TCP flows, where, for each *byte*, the packet containing that 805 byte is dropped with probability p. Consider the approximation for 806 the TCP response function for packet drop rates up to 10% or so; for 807 this environments, the sending rate in bytes per RTT is roughly 1.2 808 s/sqrt(p), for a packet size of s bytes and packet drop rate p. 810 Given a fixed *byte* drop rate p1, and a TCP packet size of s bytes, 811 the packet drop rate is roughly s*p1, producing a sending rate in 812 bytes per RTT of roughly 1.2 sqrt(s)/sqrt(p1). Thus, for TCP in an 813 environment with a fixed byte drop rate, the sending rate should 814 grow roughly as sqrt(s), for packet drop rates up to 10% or so. 816 Each row of Table 5 below shows a separate simulation with ten TCP 817 connection and a fixed byte drop rate of 0.0001, with each 818 simulation using a different segment size. For each simulation, the 819 TCP sending rate and goodput are averaged over the ten flows. As 820 one would expect from the paragraph above, the TCP sending rate 821 grows somewhat less than linearly with an increase in packet size, 822 up to a packet size of 1460 bytes, corresponding to a packet drop 823 rate of 13%. After that, further increases in the packet size 824 result in a *decrease* in the TCP sending rate, as the TCP 825 connection enters the regime of exponential backoff of the 826 retransmit timer. 828 Segment Packet TCP Rates (Kbps) 829 Size (B) DropRate SendRate Goodput 830 -------- -------- -------- ------- 831 14 0.005 6.37 6.34 832 128 0.016 30.78 30.30 833 256 0.028 46.54 44.96 834 512 0.053 62.43 58.37 835 1460 0.134 94.15 80.02 836 4000 0.324 35.20 21.44 837 8000 0.531 15.36 5.76 839 Table 5: TCP Median Send Rate vs. Packet Size I: 840 Byte Drop Rate 0.0001 842 Table 6 below shows similar results for a byte drop rate of 0.001. 843 In this case, the TCP sending rate grows with increasing packet size 844 up to a packet size of 128 bytes, corresponding to a packet drop 845 rate of 16%. After than, the TCP sending rate decreases and then 846 increases again, as the TCP connection enters the regime of 847 exponential backoff of the retransmit timer. Note that with this 848 byte drop rate, with packet sizes of 4000 and 8000 bytes, the TCP 849 sending rate increases but the TCP goodput rate remains essentially 850 zero. This makes sense, as almost all packets that are sent are 851 dropped. 853 Segment Packet TCP Rates (Kbps) 854 Size (B) DropRate SendRate Goodput 855 -------- -------- -------- ------- 856 14 0.053 1.68 1.56 857 128 0.159 7.66 6.13 858 256 0.248 6.21 4.32 859 512 0.402 1.84 1.11 860 1460 0.712 1.87 0.47 861 4000 0.870 3.20 0.00 862 8000 0.890 5.76 0.00 864 Table 6: TCP Median Send Rate vs. Packet Size II: 865 Byte Drop Rate 0.001 867 The TCP behavior in the presence of a fixed byte drop rate suggests 868 that instead of the goal of a TFRC-SP flow achieving the same 869 sending rate in bytes per second as a TCP flow using 1500-byte 870 packets, it makes more sense to consider an ideal goal of a TFRC-SP 871 flow achieving the same sending rate as a TCP flow with the optimal 872 packet size, given that the packet size is at most 1500 bytes. This 873 does not mean that we need to change the TFRC-SP mechanisms for 874 computing the allowed transmit rate; this means simply that in 875 evaluating the fairness of TFRC-SP, we should consider fairness 876 relative to the TCP flow using the optimal packet size (though still 877 at most 1500 bytes) for that environment. 879 4.5.2. Fragmentation and the Path MTU 881 This document doesn't specify TFRC-SP behavior in terms of packet 882 fragmentation and Path MTU Discovery (PMTUD). That is, should the 883 transport protocol using TFRC-SP use PMTUD information to set an 884 upper bound on the segment size? Should the transport protocol 885 allow packets to be fragmented in the network? We leave these as 886 questions for the transport protocol. As an example, we note that 887 DCCP requires that endpoints keep track of the current PMTU, and 888 says that fragmentation should not be the default [RFC4340] (Section 889 14). 891 4.5.3. The Nominal Segment Size and the Path MTU 893 When TFRC-SP is used with a nominal segment size s of 1460 bytes on 894 a path where the TCP MSS is in fact only 536 bytes, the TFRC-SP flow 895 could receive almost three times the bandwidth, in bytes per second, 896 as that of a TCP flow using an MSS of 536 bytes. Similarly, in an 897 environment with an MSS close to 4000 bytes, a TCP flow could 898 receive almost three times the bandwidth of a TFRC-SP flow with its 899 nominal segment size s of 1460 bytes. In both cases, we feel that 900 these levels of "unfairness" with factors of two or three are 901 acceptable; in particular, they won't result in one flow grabbing 902 all of the available bandwidth, to the exclusion of the competing 903 TCP or TFRC-SP flow. 905 All IPv4 *end hosts* are required to accept and reassemble IP 906 packets of size 576 bytes [RFC791], but IPv4 *links* do not 907 necessarily have to support this packet size. In slow networks, the 908 largest possible packet may take a considerable amount of time to 909 send [RFC3819], and a smaller MTU may be desirable, e.g. 100's of 910 bytes. If the first-hop link had a small MTU, then TCP would choose 911 an appropriately small MSS [RFC879]. [RFC1144] quotes cases of very 912 low link speeds were the MSS may be tens of bytes (and notes this is 913 an extreme case). We note that if TFRC-SP is used over a path with 914 an MTU considerably smaller than 576 bytes, and the TFRC-SP flow 915 uses a nominal segment size s of 1460 bytes, then the TFRC-SP flow 916 could receive considerably more than three times the bandwidth of 917 competing TCP flows. 919 If TFRC-SP is used with a nominal segment size s of less than 536 920 bytes (becauses the path MTU is known to be less than 576 bytes), 921 then TFRC-SP is likely to be of minimal benefit to applications. If 922 TFRC-SP was to be used on paths that have a path MTU of considerably 923 less than 576 bytes, and the transport protocol was not required to 924 keep track of the path MTU, this could result in the TFRC-SP flow 925 using the default nominal segment size of 1460 bytes, and as a 926 result receiving considerably more bandwidth than competing TCP 927 flows. As a result, TFRC-SP is not recommended for use with 928 transport protocols that don't maintain some knowledge of the path 929 MTU. 931 4.6. The Loss Interval Length for Short Loss Intervals 933 For a TFRC-SP receiver, the guidelines from Section 6 of RFC 3448 934 govern when the receiver should send feedback messages. In 935 particular, from [RFC3448], "a feedback packet should ... be sent 936 whenever a new loss event is detected without waiting for the end of 937 an RTT". In addition, feedback packets are sent at least once per 938 RTT. 940 For a TFRC-SP connection with a short current loss interval (less 941 than two round-trip times), it is possible for the loss interval 942 length calculated for that loss interval to change in odd ways as 943 additional packet losses in that loss interval are detected. To 944 prevent unnecessary oscillations in the average loss interval, 945 Section 3 specifies that the current loss interval can be included 946 in the calculation of the average loss interval only if the current 947 loss interval is longer than two round-trip times. 949 5. A Comparison with RFC 3714 951 RFC 3714 considers the problems of fairness, potential congestion 952 collapse, and poor user quality that could occur with the deployment 953 of non-congestion-controlled IP telephony over congested best-effort 954 networks. The March 2004 document cites ongoing efforts in the 955 IETF, including work on TFRC and DCCP. RFC 3714 recommends that for 956 best-effort traffic with applications that have a fixed or minimum 957 sending rate, the application or transport protocol should monitor 958 the packet drop rate, and discontinue sending for a period if the 959 steady-state packet drop rate significantly exceeds the allowed 960 threshold for that minimum sending rate. 962 In determining the allowed packet drop rate for a fixed sending 963 rate, RFC 3714 assumes that an IP telephony flow should be allowed 964 to use the same sending rate in bytes per second as a 1500-byte- 965 packet TCP flow experiencing the same packet drop rate as that of 966 the IP telephony flow. As an example, following this guideline, a 967 VoIP connection with a round-trip time of 0.1 sec and a minimum 968 sending rate of 64 Kbps would be required to terminate or suspend 969 when the persistent packet drop rate significantly exceeded 25%. 971 One limitation of the lack of fine-grained control in the minimal 972 mechanism described in RFC 3714 is that an IP telephony flow would 973 not adapt its sending rate in response to congestion. In contrast, 974 with TFRC-SP, a small-packet flow would reduce its sending rate 975 somewhat in response to moderate packet drop rates, possibly 976 avoiding a period with unnecessarily-heavy packet drop rates in the 977 network. 979 Because RFC 3714 assumes that the allowed packet drop rate for an IP 980 telephony flow is determined by the sending rate that a TCP flow 981 would use *with the same packet drop rate*, the minimal mechanism in 982 RFC 3714 would not provide fairness between TCP and IP telephony 983 traffic in an environment where small packets are less likely to be 984 dropped than large packets. In such an environment, the small- 985 packet IP telephony flow would make the optimistic assumption that a 986 large-packet TCP flow would receive the same packet drop rate as the 987 IP telephony flow, and as a result the small-packet IP telephony 988 flow would receive a larger fraction of the link bandwidth than a 989 competing large-packet TCP flow. 991 6. TFRC-SP with Applications that Modify the Packet Size 993 One possible use for TFRC-SP would be with applications that 994 maintain a fixed sending rate in packets per second, but modify 995 their packet size in response to congestion. TFRC-SP monitors the 996 connection's packet drop rate, and determines the allowed sending 997 rate in bytes per second. Given an application with a fixed sending 998 rate in packets per second, the TFRC-SP sender could determine the 999 data packet size that would be needed for the sending rate in bytes 1000 per second not to exceed the allowed sending rate. In environments 1001 where the packet drop rate is affected by the packet size, 1002 decreasing the packet size could also result in a decrease in the 1003 packet drop rate experienced by the flow. 1005 There are many questions about how an adaptive application would use 1006 TFRC-SP that are beyond the scope of this document. In particular, 1007 an application might wish to avoid unnecessary reductions in the 1008 packet size. In this case, an application might wait for some 1009 period of time before reducing the packet size, to avoid an 1010 unnecessary reduction in the packet size. The details of how long 1011 an application might wait before reducing the packet size can be 1012 addressed in documents that are more application-specific. 1014 Similarly, an application using TFRC-SP might only have a few packet 1015 sizes that it is able to use. In this case, the application might 1016 not reduce the packet size until the current packet drop rate has 1017 significantly exceeded the packet drop rate threshold for the 1018 current sending rate, to avoid unnecessary oscillations between two 1019 packet sizes and two sending rates. Again, the details will have to 1020 be addressed in documents that are more application-specific. 1022 Because the allowed sending rate in TFRC-SP is in bytes per second 1023 rather than in packets per second, there is little opportunity for 1024 applications to manipulate the packet size in order to "game" the 1025 system. This differs from TFRC in CCID 3 ([RFC4342] (Section 5.3)), 1026 where the allowed sending rate is in packets per second. In 1027 particular, a TFRC-SP application that sends small packets for a 1028 while, building up a fast sending rate, and then switches to large 1029 packets, would not increase its overall sending rate by the change 1030 of packet size. 1032 7. Simulations 1034 This section describes the performance of TFRC-SP in simulation 1035 scenarios with configured packet or byte drop rates, and in 1036 scenarios with a range of queue management mechanisms at the 1037 congested link. The simulations, described in detail in Appendix B, 1038 explore environments where standard TFRC significantly limits the 1039 throughput of small-packet flows, and TFRC-SP gives the desired 1040 throughput. The simulations also explore environments where 1041 standard TFRC allows small-packet flows to receive good performance, 1042 while TFRC-SP is overly aggressive. 1044 The general lessons from the simulations are as follows. 1046 o In scenarios where large and small packets receive similar packet 1047 drop rates, TFRC-SP gives roughly the desired sending rate 1048 (Appendix B.1, B.2). 1050 o In scenarios where each *byte* is equally likely to be dropped, 1051 standard TFRC gives reasonable fairness between small-packet TFRC 1052 flows and large-packet TCP flows (Appendix B.2). 1054 o In scenarios where small packets are less likely to be dropped 1055 than large packets, TFRC-SP does not give reasonable fairness 1056 between small-packet TFRC-SP flows and large-packet TCP flows; 1057 small-packet TFRC-SP flows can receive considerably more 1058 bandwidth than competing large-packet TCP flows, and in some 1059 cases large-packet TCP flows can be essentially starved by 1060 competing small-packet TFRC-SP flows. (Appendix B.2, B.3, B.4). 1062 o Scenarios where small packets are less likely to be dropped than 1063 large packets include those with Drop-Tail queues in bytes, and 1064 with AQM mechanisms in byte mode (Appendix B.3, B.4). It has 1065 also been reported that wireless links are sometimes good enough 1066 to let small packets through, while larger packets have a much 1067 higher error rate, and hence a higher drop probability [S05]. 1069 8. General Discussion 1071 Dropping rates for small packets: The goal of TFRC-SP is for small- 1072 packet TFRC-SP flows to have rough fairness with large-packet TCP 1073 flows in the sending rate in bps, in a scenario where each packet 1074 receives roughly the same probability of being dropped. In a 1075 scenario where large packets are more likely to be dropped than 1076 small packets, or where flows with a bursty sending rate are more 1077 likely to have packets dropped than are flows with a smooth sending 1078 rate, small-packet TFRC-SP flows can receive significantly more 1079 bandwidth than competing large-packet TCP flows. 1081 The accuracy of the TCP response function used in TFRC: For 1082 applications with a maximum sending rate of 96 Kbps or less (i.e., 1083 packets of at most 120 bytes) TFRC-SP only restricts the sending 1084 rate when the packet drop rate is fairly high, e.g., greater than 1085 10%. [Derivation: A TFRC-SP flow with a 200 ms round-trip time and 1086 a maximum sending rate with packet headers of 128 Kbps would have a 1087 sending rate in bytes per second equivalent to a TCP flow with 1088 1460-byte segments sending 2.2 packets per round-trip time. From 1089 Table 1 of RFC 3714, this sending rate can be sustained with a 1090 packet drop rate slightly greater than 10%.] In this high-packet- 1091 drop regime, the performance of TFRC-SP is determined in part by the 1092 accuracy of the TCP response function in representing the actual 1093 sending rate of a TCP connection. 1095 In the regime of high packet drop rates, TCP performance is also 1096 affected by the TCP algorithm (e.g., SACK or not), by the minimum 1097 RTO, by the use or not of Limited Transmit, by the use of ECN, and 1098 the like. It is good to ensure that simulations or experiments 1099 exploring fairness include the exploration of fairness with the most 1100 aggressive TCP mechanisms conformant with the current standards. 1101 Our simulations use SACK TCP with Limited Transmit and with a 1102 minimum RTO of 200 ms. The simulation results are largely the same 1103 with or without timestamps; timestamps were not used for simulations 1104 reported in this paper. We didn't use TCP with ECN in setting the 1105 target sending rate for TFRC, because, as explained in Appendix B.1, 1106 our expectation is that in high packet drop regimes, routers will 1107 drop rather than mark packets, either from policy or from buffer 1108 overflow. 1110 Fairness with different packet header sizes: In an environment with 1111 IPv6 and/or several layers of network-layer tunnels (e.g., IPsec, 1112 GRE), the packet header could be 60, 80, or 100 bytes instead of the 1113 default 40 bytes assumed in Section 3. For an application with 1114 small ten-byte data segments, this means that the actual packet size 1115 could be 70, 90, or 110 bytes, instead of the 50 bytes assumed by 1116 TFRC-SP in calculating the allowed sending rate. Thus, a TFRC-SP 1117 application with large headers could receive more than twice the 1118 bandwidth (including the bandwidth used by headers) than a TFRC-SP 1119 application with small headers. We do not expect this to be a 1120 problem; in particular, TFRC-SP applications with large headers will 1121 not significantly degrade the performance of competing TCP 1122 applications, or of competing TFRC-SP applications with small 1123 headers. 1125 General issues for TFRC: The congestion control mechanisms in TFRC 1126 and TFRC-SP limit a flow's sending rate in packets per second. 1127 Simulations by Tom Phelan [P04] explore how such a limitation in 1128 sending rate can lead to unfairness for the TFRC flow in some 1129 scenarios, e.g., when competing with bursty TCP web traffic, in 1130 scenarios with low levels of statistical multiplexing at the 1131 congested link. 1133 9. Security Considerations 1135 There are no security considerations introduced in this document. 1137 General security considerations for TFRC are discussed in RFC 3448. 1138 The security considerations for TFRC include the need to protect 1139 against spoofed feedback, and the need for protection mechanisms to 1140 protect the congestion control mechanisms against incorrect 1141 information from the receiver. 1143 Security considerations for DCCP's Congestion Control ID 3, TFRC 1144 Congestion Control, are discussed in [RFC4342]. That document 1145 extensively discussed the mechanisms the sender can use to verify 1146 the information sent by the receiver. 1148 10. IANA Considerations 1150 There are no IANA considerations in this document. 1152 11. Conclusions 1154 This document has specified TFRC-SP, a Small-Packet (SP) variant of 1155 TFRC, designed for applications that send small packets, with at 1156 most a hundred packets per second, but that desire the same sending 1157 rate in bps as a TCP connection experiencing the same packet drop 1158 rate but sending packets of 1500 bytes. TFRC-SP competes reasonably 1159 fairly with large-packet TCP and TFRC flows in environments where 1160 large-packet flows and small-packet flows experience similar packet 1161 drop rates, but receives more than its share of the bandwidth in bps 1162 in environments where small packets are less likely to be dropped or 1163 marked than are large packets. As a result, TFRC-SP is 1164 experimental, and is not intended for widespread deployment at this 1165 time in the global Internet. 1167 In order to allow experimentation with TFRC-SP in the Datagram 1168 Congestion Control Protocol (DCCP), an experimental Congestion 1169 Control IDentifier (CCID) will be used, based on TFRC-SP but 1170 specified in a separate document. 1172 12. Thanks 1174 We thank Tom Phelan for discussions of TFRC-SP and for his paper 1175 exploring the fairness between TCP and TFRC-SP flows. We thank Lars 1176 Eggert, Gorry Fairhurst, Mark Handley, Ladan Gharai, Richard Nelson, 1177 Colin Perkins, Pete Sholander, Magnus Westerlund, and Joerg Widmer 1178 for feedback on earlier versions of this draft. We also thank the 1179 DCCP Working Group for feedback and discussions. 1181 A. Appendix: Related Work on Small-Packet Variants of TFRC 1183 Other proposals for variants of TFRC for applications with variable 1184 packet sizes include [WBL04] and [V00]. [V00] proposed that TFRC 1185 should be modified so that flows are not penalized by sending 1186 smaller packets. In particular, [V00] proposes using the path MTU 1187 in the TCP-friendly equation, instead of the actual packet size used 1188 by TFRC, and counting the packet drop rate by using an estimation 1189 algorithm that aggregates both packet drops and received packets 1190 into MTU-sized units. 1192 [WBL04] also argues that adapting TFRC for variable packet sizes by 1193 just using the packet size of a reference TCP flow in the TFRC 1194 equation would not suffice in the high-packet-loss regime; such a 1195 modified TFRC would have a strong bias in favor of smaller packets, 1196 because multiple lost packets in a single round-trip time would be 1197 aggregated into a single packet loss. [WBL04] proposes modifying 1198 the loss measurement process to account for the bias in favor of 1199 smaller packets. 1201 The TFRC-SP variant of TFRC proposed in our document differs from 1202 [WBL04] in restricting its attention to flows that send at most 100 1203 packets per second. The TFRC-SP variant proposed in our document 1204 also differs from the straw proposal discussed in [WBL04] in that 1205 the allowed bandwidth includes the bandwidth used by packet headers. 1207 [WBL04] discusses four methods for modifying the loss measurement 1208 process, "unbiasing", "virtual packets", "random sampling", and 1209 "Loss Insensitive Period (LIP) scaling". [WBL04] finds only the 1210 second and third methods sufficiently robust when the network drops 1211 packets independently of packet size. They find only the second 1212 method sufficiently robust when the network is more likely to drop 1213 large packets than small packets. Our method for calculating the 1214 loss event rate is somewhat similar to the random sampling method 1215 proposed in [WBL04], except that randomization is not used; instead 1216 of randomization, the exact packet loss rate is computed for short 1217 loss intervals, and the standard loss event rate calculation is used 1218 for longer loss intervals. [WBL04] includes simulations with a 1219 Bernoulli loss model, a Bernoulli loss model with a drop rate 1220 varying over time, and a Gilbert loss model, as well as more 1221 realistic simulations with a range of TCP and TFRC flows. 1223 [WBL04] produces both a byte-mode and a packet-mode variant of the 1224 TFRC transport protocol, for connections over paths with per-byte 1225 and per-packet dropping respectively. We would argue that in the 1226 absence of transport-level mechanisms for determining whether the 1227 packet dropping in the network is per-packet, per-byte, or somewhere 1228 in between, a single TFRC implementation is needed, independently of 1229 the packet-dropping behaviors of the routers along the path. It 1230 would of course be preferable to have a mechanism that gives roughly 1231 acceptable behavior, to the connection and to the network as a 1232 whole, on paths with both per-byte and per-packet dropping (and on 1233 paths with multiple congested routers, some with per-byte dropping 1234 mechanisms, some with per-packet dropping mechanisms, and some with 1235 dropping mechanisms that lie somewhere between per-byte and per- 1236 packet). 1238 An important contribution would be to investigate the range of 1239 behaviors actually present in today's networks, in terms of packet- 1240 dropping as a function of packet size. 1242 B. Simulation Results 1244 This appendix reports on the simulation results outlined in Section 1245 7 . TFRC-SP has been added to the NS simulator, and is illustrated 1246 in the validation test "./test-all-friendly" in the directory 1247 tcl/tests. The simulation scripts and graphs for the simulations in 1248 this document are available at [VOIPSIMS]. 1250 B.1. Simulations with Configured Packet Drop Rates 1252 In this section we describe simulation results from simulations 1253 comparing the throughput of standard (SACK) TCP flows, TCP flows 1254 with timestamps and ECN, TFRC-SP flows, and standard TFRC (Stnd 1255 TFRC) flows. In these simulations we configure the router to 1256 randomly drop or mark packets at a specified rate, independently of 1257 the packet size. For each specified packet drop rate, we give a 1258 flow's average sending rate in Kbps over the second half of a 1259 100-second simulation, averaged over ten flows. 1261 Packet Send Rates (Kbps, 1460B seg) 1262 DropRate TCP ECN TCP TFRC 1263 -------- -------- -------- -------- 1264 0.001 2020.85 1904.61 982.09 1265 0.005 811.10 792.11 878.08 1266 0.01 515.45 533.19 598.90 1267 0.02 362.93 382.67 431.41 1268 0.04 250.06 252.64 284.82 1269 0.05 204.48 218.16 268.51 1270 0.1 143.30 148.41 146.03 1271 0.2 78.65 93.23* 55.14 1272 0.3 26.26 59.65* 32.87 1273 0.4 9.87 47.79* 25.45 1274 0.5 3.53 32.01* 18.52 1276 * ECN scenarios marked with an asterisk are not realistic, 1277 as routers are not recommended to mark packets when packet 1278 drop/mark rates are 20% or higher. 1280 Table 7: Send Rate vs. Packet Drop Rate I: 1281 1460B TFRC Segments 1282 (1.184 Kbps Maximum TFRC Data Sending Rate) 1284 Table 7 shows the sending rate for a TCP and a standard TFRC flow 1285 for a range of configured packet drop rates, when both flows have 1286 1460-byte data segments, in order to illustrate the relative 1287 fairness of TCP and TFRC when both flows use the same packet size. 1288 For example, a packet drop rate of 0.1 means that 10% of the TCP and 1289 TFRC packets are dropped. The TFRC flow is configured to send at 1290 most 100 packets per second. There is good relative fairness until 1291 the packet drop percentages reach 40 and 50%, when the TFRC flow 1292 receives three to five times more bandwidth than the standard TCP 1293 flow. We note that an ECN TCP flow would receive a higher 1294 throughput than the TFRC flow at these high packet drop rate, if 1295 ECN-marking was still being instead of packet-dropping. However, we 1296 don't use the ECN TCP sending rate in these high-packet-drop 1297 scenarios as the target sending rate for TFRC, as routers are 1298 advised to drop rather than mark packets during high levels of 1299 congestion [RFC3168] (Section 7). In addition, there is likely to 1300 be buffer overflow in scenarios with such high packet 1301 dropping/marking rates, forcing routers to drop packets instead of 1302 ECN-marking them. 1304 < - - - - - - Send Rates (Kbps) - - - - - > 1305 Packet TCP ECN TCP TFRC-SP Stnd TFRC 1306 DropRate (1460B seg) (1460B seg) (14B seg) (14B seg) 1307 -------- ----------- ----------- --------- --------- 1308 0.001 1787.54 1993.03 17.71 17.69 1309 0.005 785.11 823.75 18.11 17.69 1310 0.01 533.38 529.01 17.69 17.80 1311 0.02 317.16 399.62 17.69 13.41 1312 0.04 245.42 260.57 17.69 8.84 1313 0.05 216.38 223.75 17.69 7.63 1314 0.1 142.75 138.36 17.69 4.29 1315 0.2 58.61 91.54* 17.80 1.94 1316 0.3 21.62 63.96* 10.26 1.00 1317 0.4 10.51 41.74* 4.78 0.77 1318 0.5 1.92 19.03* 2.41 0.56 1320 * ECN scenarios marked with an asterisk are not realistic, 1321 as routers are not recommended to mark packets when packet 1322 drop/mark rates are 20% or higher. 1324 Table 8: Send Rate vs. Packet Drop Rate II: 1325 14B TFRC Segments 1326 (5.6 Kbps Maximum TFRC Data Sending Rate) 1328 Table 8 shows the results of simulations where each TFRC-SP flow has 1329 a maximum data sending rate of 5.6 Kbps, with 14-byte data packets 1330 and a 32-byte packet header for DCCP and IP. Each TCP flow has a 1331 receive window of 100 packets and a data packet size of 1460 bytes, 1332 with a 40-byte packet header for TCP and IP. The TCP flow uses SACK 1333 TCP with Limited Transmit, but without timestamps or ECN. Each flow 1334 has a round-trip time of 240 ms in the absence of queueing delay. 1336 The TFRC sending rate in Table 8 is the sending rate for the 14-byte 1337 data packet with the 32-byte packet header. Thus, only 30% of the 1338 TFRC sending rate is for data, and with a packet drop rate of p, 1339 only a fraction 1-p of that data makes it to the receiver. Thus, 1340 the TFRC data receive rate can be considerably less than the TFRC 1341 sending rate in the table. Because TCP uses large packets, 97% of 1342 the TCP sending rate is for data, and the same fraction 1-p of that 1343 data makes it to the receiver. 1345 Table 8 shows that for the 5.6 Kbps data stream with TFRC, Standard 1346 TFRC (Stnd TFRC) gives a very poor sending rate in bps, relative to 1347 the sending rate for the large-packet TCP connection. In contrast, 1348 the sending rate for the TFRC-SP flow is relatively close to the 1349 desired goal of fairness in bps with TCP. 1351 Table 8 shows that with TFRC-SP, the 5.6 Kbps data stream doesn't 1352 reduce its sending rate until packet drop rates greater than 20%, as 1353 desired. With packet drop rates of 30-40%, the sending rate for the 1354 TFRC-SP flow is somewhat less than that of the average large-packet 1355 TCP flow, while for packet drop rates of 50% the sending rate for 1356 the TFRC-SP flow is somewhat greater than that of the average large- 1357 packet TCP flow. 1359 < - - - - - - Send Rates (Kbps) - - - - - > 1360 Packet TCP ECN TCP TFRC-SP Stnd TFRC 1361 DropRate (1460B seg) (1460B seg) (200B seg) (200B seg) 1362 -------- ----------- ----------- ---------- ---------- 1363 0.001 1908.98 1869.24 183.45 178.35 1364 0.005 854.69 835.10 185.06 138.06 1365 0.01 564.10 531.10 185.33 92.43 1366 0.02 365.38 369.10 185.57 62.18 1367 0.04 220.80 257.81 185.14 45.43 1368 0.05 208.97 219.41 180.08 39.44 1369 0.1 141.67 143.88 127.33 21.96 1370 0.2 62.66 91.87* 54.66 9.40 1371 0.3 16.63 65.52* 24.50 4.73 1372 0.4 6.62 42.00* 13.47 3.35 1373 0.5 1.01 21.34* 10.51 2.92 1375 * ECN scenarios marked with an asterisk are not realistic, 1376 as routers are not recommended to mark packets when packet 1377 drop/mark rates are 20% or higher. 1379 Table 9: Sending Rate vs. Packet Drop Rate III: 1380 200B TFRC Segments 1381 (160 Kbps Maximum TFRC Data Sending Rate) 1383 Table 9 shows results with configured packet drop rates when the 1384 TFRC flow uses 200-byte data packets, with a maximum data sending 1385 rate of 160 Kbps. As in Table 8, the performance of Standard TFRC 1386 is quite poor, while the performance of TFRC-SP is essentially as 1387 desired for packet drop rates up to 30%. Again as expected, with 1388 packet drop rates of 40-50% the TFRC-SP sending rate is somewhat 1389 higher than desired. 1391 For these simulations, the sending rate of a TCP connection using 1392 timestamps is similar to the sending rate shown for a standard TCP 1393 connection without timestamps. 1395 B.2. Simulations with Configured Byte Drop Rates 1397 In this section we explore simulations where the router is 1398 configured to drop or mark each *byte* at a specified rate. When a 1399 byte is chosen to be dropped (or marked), the entire packet 1400 containing that byte is dropped (or marked). 1402 < - - - - - Send Rates (Kbps) - - - - - > 1403 Byte TCP TFRC-SP Stnd TFRC 1404 DropRate SegSize TCP ECN TCP (14B seg) (14B seg) 1405 -------- ------- -------- -------- --------- --------- 1406 0.00001 1460 423.02 431.26 17.69 17.69 1407 0.0001 1460 117.41 114.34 17.69 17.69 1408 0.001 128 10.78 11.50 17.69 8.37 1409 0.005 14 1.75 2.89 18.39 1.91 1410 0.010 1460 0.31 0.26 7.07 0.84 1411 0.020 1460 0.29 0.26 1.61 0.43 1412 0.040 1460 0.12 0.26* 0.17 0.12 1413 0.050 1460 0.15 0.26* 0.08 0.06 1415 * ECN scenarios marked with an asterisk are not realistic, 1416 as routers are not recommended to mark packets when packet 1417 drop/mark rates are 20% or higher. 1419 TFRC's maximum data sending rate is 5.6 Kbps. 1421 Table 10: Sending Rate vs. Byte Drop Rate 1423 Table 10 shows the TCP and TFRC send rates for various byte drop 1424 rates. For each byte drop rate, Table 10 shows the TCP sending 1425 rate, with and without ECN, for the TCP segment size that gives the 1426 highest TCP sending rate. Simulations were run with TCP segments of 1427 14, 128, 256, 512, and 1460 bytes. Thus, for a byte drop rate of 1428 0.00001, the table shows the TCP sending rate with 1460-byte data 1429 segments, but with a byte drop rate of 0.001, the table shows the 1430 TCP sending rate with 128-byte data segments. For each byte drop 1431 rate, Table 10 also shows the TFRC-SP and that Standard TFRC sending 1432 rates. With configured byte drop rates, TFRC-SP gives an unfair 1433 advantage to the TFRC-SP flow, while Standard TFRC gives essentially 1434 the desired performance. 1436 TCP Pkt TFRC Pkt 1437 Byte DropRate DropRate TCP/TFRC 1438 DropRate (1460B seg) (14B seg) Pkt Drop Ratio 1439 -------- ----------- --------- -------------- 1440 0.00001 0.015 0.0006 26.59 1441 0.0001 0.13 0.0056 24.94 1442 0.001 0.77 0.054 14.26 1443 0.005 0.99 0.24 4.08 1444 0.01 1.00 0.43 2.32 1445 0.05 1.00 0.94 1.05 1447 Table 11: Packet Drop Rate Ratio vs. Byte Drop Rate 1449 Table 11 converts the byte drop rate p to packet drop rates for the 1450 TCP and TFRC packets, where the packet drop rate for an N-byte 1451 packet is 1-(1-p)^N. Thus, a byte drop rate of 0.001, with each 1452 byte being dropped with probability 0.001, converts to a packet drop 1453 rate of 0.77, or 77%, for the 1500-byte TCP packets, and a packet 1454 drop rate of 0.054, or 5.4%, for the 56-byte TFRC packets. 1456 The right column of Table 11 shows the ratio between the TCP packet 1457 drop rate and the TFRC packet drop rate. For low byte drop rates, 1458 this ratio is close to 26.8, the ratio between the TCP and TFRC 1459 packet sizes. For high byte drop rates, where even most small TFRC 1460 packets are likely to be dropped, this drop ratio approaches 1. As 1461 Table 10 shows, with byte drop rates, the Standard TFRC sending rate 1462 is close to optimal, competing fairly with a TCP connection using 1463 the optimal packet size within the allowed range. In contrast, the 1464 TFRC-SP connection gets more than its share of the bandwidth, though 1465 it does reduce its sending rate for a byte drop rate of 0.01 or more 1466 (corresponding to a TFRC-SP *packet* drop rate of 0.43. 1468 Table 10 essentially shows three separate regions. In the low- 1469 congestion region, with byte drop rates less than 0.0001, the TFRC- 1470 SP connection is sending at its maximum sending rate. In this 1471 region the optimal TCP connection is the one with 1460-byte 1472 segments, and the TCP sending rate goes as 1/sqrt(p), for packet 1473 drop rate p. This low-congestion region holds for packet drop rates 1474 up to 10-15%. 1476 In the middle region of Table 10, with byte drop rates from 0.0001 1477 to 0.005, the optimal TCP segment size is a function of the byte 1478 drop rate. In particular, the optimal TCP segment size seems to be 1479 the one that keeps the packet drop rate at most 15%, keeping the TCP 1480 connection in the regime controlled by a 1/sqrt(p) sending rate, for 1481 packet drop rate p. For a TCP packet size of S bytes (including 1482 headers), and a *byte* drop rate of B, the packet drop rate is 1483 roughly B*S. For a given byte drop rate in this regime, if the 1484 optimal TCP performance occurs with a packet size chosen to give a 1485 packet drop rate of at most 15%, keeping the TCP connection out of 1486 the regime of exponential backoffs of the retransmit timer, then 1487 this requires B*S = 0.15, or S = 0.15/B. 1489 In the high-congestion regime of Table 10, with high congestion and 1490 with byte drop rates of 0.01 and higher, the TCP performance is 1491 dominated by the exponential backoff of the retransmit timer 1492 regardless of the segment size. Even a 40-byte packet with a zero- 1493 byte data segment would have a packet drop rate of at least 33%. In 1494 this regime, the optimal TCP *sending* rate comes with a large, 1495 1460-byte data segment, but the TCP sending rate is low with any 1496 segment size, considerably less than one packet per round-trip time. 1498 We note that in this regime, while a larger packet gives a higher 1499 TCP *sending* rate, a smaller packet gives a better *goodput* rate. 1501 In general, Tables 8 and 9 show good performance for TFRC-SP in 1502 environments with stable packet drop rates, where the decision to 1503 drop a packet is independent of the packet size. However, in some 1504 environments the packet size might affect the likelihood that a 1505 packet is dropped. For example, with heavy congestion and a Drop 1506 Tail queue with a fixed number of bytes rather than a fixed number 1507 of packet-sized buffers, small packets might be more likely than 1508 large packets to find room at the end of an almost-full queue. As 1509 a further complication, in a scenario with Active Queue Management, 1510 the AQM mechanism could either be in packet mode, dropping each 1511 packet with equal probability, or in byte mode, dropping each byte 1512 with equal probability. Sections B.3 and B.4 show simulations with 1513 packets dropped at Drop Tail or AQM queues, rather that from a 1514 probabilistic process. 1516 B.3. Packet Dropping Behavior at Routers with Drop-Tail Queues 1518 One of the problems with comparing the throughput of two flows using 1519 different packet sizes is that the packet size itself can influence 1520 the packet drop rate [V00, WBL04]. 1522 The default TFRC was designed for rough fairness with TCP, for TFRC 1523 and TCP flows with the same packet size and experiencing the same 1524 packet drop rate. When the issue of fairness between flows with 1525 different packets sizes is addressed, it matters whether the packet 1526 drop rates experienced by the flows is related to the packet size. 1527 That is, are small packets just as likely to be dropped as large TCP 1528 packets, or are the smaller packets less likely to be dropped 1529 [WBL04]. And what is the relationship between the packet-dropping 1530 behavior of the path, and the loss event measurements of TFRC? 1531 < - - - - - Send Rates in Kbps - - - - > 1532 Web TCP (1460B seg) TFRC-SP (200B seg) 1533 Sessions DropRate SendRate DropRate SendRate 1534 -------- -------- -------- -------- -------- 1535 10 0.04 316.18 0.05 183.05 1536 25 0.07 227.47 0.07 181.23 1537 50 0.08 181.10 0.08 178.32 1538 100 0.14 85.97 0.12 151.42 1539 200 0.17 61.20 0.14 73.88 1540 400 0.20 27.79 0.18 36.81 1541 800 0.29 3.50 0.27 16.33 1542 1600 0.37 0.63 0.33 6.29 1544 Table 12: Drop and Send Rates for Drop-Tail Queues in Packets 1546 Table 12 shows the results of the second half of 100-second 1547 simulations, with five TCP connections and five TFRC-SP connections 1548 competing with web traffic in a topology with a 3 Mbps shared link. 1549 The TFRC-SP application generates 200-byte data packets every 10 ms, 1550 for a maximum data rate of 160 Kbps. The five long-lived TCP 1551 connections use a data packet size of 1460 bytes, and the web 1552 traffic uses a data packet size of 512 bytes. The five TCP 1553 connections have roundtrip times from 40 to 240 ms, and the five 1554 TFRC connections have the same set of round-trip times. The SACK 1555 TCP connections in these simulations use the default parameters in 1556 the NS simulator, with Limited Transmit, and a minimum RTO of 1557 200 ms. Adding timestamps to the TCP connection didn't change the 1558 results appreciably. The simulations include reverse-path traffic, 1559 to add some small control packets to the forward path, and some 1560 queueing delay to the reverse path. The number of web sessions is 1561 varied to create different levels of congestion. The Drop-Tail 1562 queue is in units of packets, which each packet arriving to the 1563 queue requires a single buffer, regardless of the packet size. 1565 Table 12 shows the average TCP and TFRC sending rates, each averaged 1566 over the five flows. As expected, the TFRC-SP flows see similar 1567 packet drop rates as the TCP flows, though the TFRC-SP flows 1568 receives higher throughput than the TCP flows with packet drop rates 1569 of 25% or higher. 1571 < - - - - - Send Rates in Kbps - - - - > 1572 Web TCP (1460B seg) TFRC-SP (200B seg) 1573 Sessions DropRate SendRate DropRate SendRate 1574 -------- -------- -------- -------- -------- 1575 10 0.061 239.81 0.004 185.19 1576 25 0.089 189.02 0.006 184.95 1577 50 0.141 99.46 0.013 185.07 1578 100 0.196 16.42 0.022 183.77 1579 200 0.256 4.46 0.032 181.98 1580 400 0.291 4.61 0.051 151.88 1581 800 0.487 1.01 0.078 113.10 1582 1600 0.648 0.67 0.121 65.17 1584 Table 13: Drop and Send Rates for Drop-Tail Queues in Bytes I: 1585 1460B TCP Segments 1587 However, the fairness results can change significantly if the Drop- 1588 Tail queue at the congested output link is in units of bytes rather 1589 than packets. For a queue in packets, the queue has a fixed number 1590 of buffers, and each buffer can hold exactly one packet, regardless 1591 of its size in bytes. For a queue in bytes, the queue has a fixed 1592 number of *bytes*, and an almost-full queue might have room for a 1593 small packet but not for a large one. This, for a simulation with a 1594 Drop-Tail queue in bytes, large packets are more likely to be 1595 dropped than are small ones. The NS simulator doesn't yet have a 1596 more realistic intermediate model, where the queue has a fixed 1597 number of buffers, each buffer has a fixed number of bytes, and each 1598 packet would require one or more free buffers. In this model, a 1599 small packet would use one buffer, while a larger packet would 1600 require several buffers. 1602 The scenarios in Table 13 are identical to those in Table 12, except 1603 that the Drop-Tail queue is in units of bytes instead of packets. 1604 Thus, five TCP connections and five TFRC-SP connections compete with 1605 web traffic in a topology with a 3 Mbps shared link, with each TFRC- 1606 SP application generating 200-byte data packets every 10 ms, for a 1607 maximum data rate of 160 Kbps. The number of web sessions is varied 1608 to create different levels of congestion. However, instead of Drop- 1609 Tail queues able to accommodate at most a hundred packets, the 1610 routers' Drop-Tail queues are each able to accommodate at most 1611 50,000 bytes (computed in NS as a hundred packets times the mean 1612 packetsize of 500 bytes). 1614 As Table 13 shows, with a Drop-Tail queue in bytes, the TFRC-SP flow 1615 sees a much smaller packet drop rate than the TCP flow, and as a 1616 consequence receives a much larger sending rate. For the 1617 simulations in Table 13, the TFRC-SP flows use 200-byte data 1618 segments, while the long-lived TCP flows use 1460-byte data 1619 segments. For example, when the five TCP flows and five TFRC-SP 1620 flows share the link with 800 web sessions, the five TCP flows see 1621 an average drop rate of 49% in the second half of the simulation, 1622 while the five TFRC-SP flows receive an average drop rate of 8%, and 1623 as a consequence receive more than 100 times the throughput of the 1624 TCP flows. This raises serious questions about making the 1625 assumption that flows with small packets see the same packet drop 1626 rate as flows with larger packets. Further work will have to 1627 include an investigation into the range of realistic Internet 1628 scenarios, in terms of whether large packets are considerably more 1629 likely to be dropped than are small ones. 1631 < - - - - - Send Rates in Kbps - - - - > 1632 Web TCP (512B seg) TFRC-SP (200B seg) 1633 Sessions DropRate SendRate DropRate SendRate 1634 -------- -------- -------- -------- -------- 1635 10 0.02 335.05 0.00 185.16 1636 25 0.02 289.94 0.00 185.36 1637 50 0.04 139.99 0.01 184.98 1638 100 0.06 53.50 0.01 184.66 1639 200 0.10 16.14 0.04 167.87 1640 400 0.16 6.36 0.07 114.85 1641 800 0.24 0.90 0.11 67.23 1642 1600 0.42 0.35 0.18 39.32 1644 Table 14: Drop and Send Rates for Drop-Tail Queues in Bytes II: 1645 512B TCP Segments 1647 Table 14 shows that in the scenario the long-lived TCP flows receive 1648 a higher packet drop rate than the TFRC-SP flows, and receive 1649 considerably less throughput, even when the long-lived TCP flows use 1650 512-byte segments. 1652 To show the potential negative effect of TFRC-SP in such an 1653 environment, we consider a simulation with N TCP flows, N TFRC-SP 1654 flows, and 10*N web sessions, for N ranging from 1 to 50, so that 1655 the demand increases from all types of traffic, with routers with 1656 Drop-Tail queues in bytes. 1658 < - - - - - Send Rates in Kbps - - - - > 1659 Web TCP (1460B seg) TFRC-SP (200B seg) 1660 Sessions DropRate SendRate DropRate SendRate 1661 -------- -------- -------- -------- -------- 1662 10 0.014 2085.36 0.001 180.29 1663 20 0.040 788.88 0.004 183.87 1664 30 0.074 248.80 0.006 182.94 1665 40 0.113 163.20 0.008 185.33 1666 50 0.127 94.70 0.011 185.14 1667 60 0.177 53.24 0.015 185.30 1668 70 0.174 35.31 0.016 185.07 1669 80 0.221 19.38 0.019 183.91 1670 90 0.188 15.63 0.019 180.42 1671 100 0.265 7.08 0.023 176.71 1672 200 0.324 0.38 0.042 139.48 1673 300 0.397 0.32 0.076 93.53 1674 400 0.529 0.40 0.100 70.40 1675 500 0.610 0.37 0.121 57.59 1677 Table 15: Drop and Send Rates for Drop-Tail Queues in Bytes III: 1678 TFRC-SP, 1460B TCP Segments 1680 < - - - - - Send Rates in Kbps - - - - > 1681 Web TCP (1460B seg) TFRC (200B seg) 1682 Sessions DropRate SendRate DropRate SendRate 1683 -------- -------- -------- -------- -------- 1684 10 0.016 1926.00 0.002 178.47 1685 20 0.030 805.20 0.003 178.23 1686 30 0.062 346.24 0.005 161.19 1687 40 0.093 219.18 0.007 136.28 1688 50 0.110 132.77 0.010 83.02 1689 60 0.170 88.88 0.014 69.75 1690 70 0.149 70.73 0.015 55.59 1691 80 0.213 43.17 0.020 42.82 1692 90 0.188 36.19 0.017 43.61 1693 100 0.233 24.77 0.026 35.17 1694 200 0.311 5.46 0.034 24.85 1695 300 0.367 3.74 0.049 20.19 1696 400 0.421 2.59 0.055 17.71 1697 500 0.459 1.10 0.069 15.95 1698 Table 16: Drop and Send Rates for Drop-Tail Queues in Bytes IV: 1699 Standard TFRC, 1460B TCP Segments 1701 Table 15 shows simulations using TFRC-SP, while Table 16 shows 1702 simulations using TFRC instead of TFRC-SP. This is the only 1703 difference between the simulations in the two tables. Note that 1704 when TFRC-SP is used, the TCP flows and web traffic are essentially 1705 starved, while the TFRC-SP flows each continue to send 57 Kbps. In 1706 contrast, when standard TFRC is used instead of TFRC-SP for the 1707 flows sending 200-byte segments, the TCP flows are not starved 1708 (although they still don't receive their "share" of the link 1709 bandwidth when their packet drop rates are 30% or higher.) These 1710 two sets of simulations illustrate the dangers of a widespread 1711 deployment of TFRC-SP in an environment where small packets are less 1712 likely to be dropped than large ones. 1714 B.4. Packet Dropping Behavior at Routers with AQM 1716 As expected, the packet dropping behavior also can be varied by 1717 varying the Active Queue Management (AQM) mechanism in the router. 1718 When the routers use RED (Random Early Detection), there are several 1719 parameters than can affect the packet dropping or marking behavior 1720 as a function of the packet size. 1722 First, as with Drop-Tail, the RED queue can be either in units of 1723 packets or of bytes. This can affect the packet dropping behavior 1724 when RED is unable to control the average queue size, and the queue 1725 overflows. 1727 Second, and orthogonally, RED can be configured to be either in 1728 packet mode or in byte mode. In packet mode, each *packet* has the 1729 same probability of being dropped by RED, while in byte mode, each 1730 *byte* has the same probability of being dropped. In packet mode, 1731 large-packet and small-packet flows receive roughly the same packet 1732 drop rate, while in byte mode, large-packet and small-packet flows 1733 with the same throughput in bps receive roughly the same *number* of 1734 packet drops. [EA03] assessed the impact of byte vs. packet modes 1735 on RED performance. 1737 The simulations reported below show that for RED in packet mode, the 1738 packet drop rates for the TFRC-SP flows are similar to those for the 1739 TCP flows, with a resulting acceptable throughput for the TFRC-SP 1740 flows. This is true with the queue in packets or in bytes, and 1741 with or without Adaptive RED (discussed below). As we show below, 1742 this fairness between TCP and TFRC-SP flows does not hold for RED in 1743 byte mode. 1745 The third RED parameter that affects the packet dropping or marking 1746 behavior as a function of packet size is whether the RED mechanism 1747 is using Standard RED or Adaptive RED; Adaptive RED tries to 1748 maintain the same average queue size, regardless of the packet drop 1749 rate. The use of Adaptive RED allows the RED mechanism to function 1750 more effectively in the presence of high packet drop rates (e.g., 1751 greater than 10%). Without Adaptive RED, there is a fixed dropping 1752 threshold, and all arriving packets are dropped when the dropping or 1753 marking rate exceeds this threshold. In contrast, with Adaptive 1754 RED, the dropping function is adapted to accommodate high-drop-rate 1755 regimes. One consequence is that when byte mode is used with 1756 Adaptive RED, the byte mode extends even to high-drop-rate regimes. 1757 When byte mode is used with standard RED, however, the byte mode is 1758 no longer in use when the drop rate exceeds the fixed dropping 1759 threshold (set by default to 10% in the NS simulator). 1761 In the simulations in this section, we explore the TFRC-SP behavior 1762 over some of this range of scenarios. In this simulations, as in 1763 Section B.3 above, the application for the TFRC-SP flow uses 1764 200-byte data packets, generating 100 packets per second. 1766 < - - - - - Send Rates in Kbps - - - - > 1767 Web TCP (1460B seg) TFRC-SP (200B seg) 1768 Sessions DropRate SendRate DropRate SendRate 1769 -------- -------- -------- -------- -------- 1770 10 0.05 305.76 0.04 182.82 1771 25 0.06 224.16 0.06 175.91 1772 50 0.09 159.12 0.08 152.51 1773 100 0.13 90.77 0.11 106.13 1774 200 0.14 48.53 0.14 70.25 1775 400 0.20 22.08 0.19 41.50 1776 800 0.27 3.55 0.25 17.50 1777 1600 0.42 1.87 0.34 8.81 1779 Table 17: Drop and Send Rates for RED Queues in Packet Mode 1781 For the simulations in Table 17, with a congested router with a RED 1782 queue in packet mode, the results are similar to those with a Drop- 1783 Tail queue in packets, as in Table 12 above. The TFRC-SP flow 1784 receives similar packet drop rates as the TCP flow, though it 1785 receives higher throughput in the more congested environments. The 1786 simulations are similar with a RED queue in packet mode with the 1787 queue in bytes, and with or without Adaptive RED. In these 1788 simulations, TFRC-SP gives roughly the desired performance. 1790 < - - - - - Send Rates in Kbps - - - - > 1791 Web TCP (1460B seg) TFRC-SP (200B seg) 1792 Sessions DropRate SendRate DropRate SendRate 1793 -------- -------- -------- -------- -------- 1794 10 0.06 272.16 0.02 184.37 1795 25 0.07 175.82 0.02 184.06 1796 50 0.10 75.65 0.04 180.56 1797 100 0.14 38.98 0.07 151.65 1798 200 0.19 16.66 0.11 106.80 1799 400 0.26 4.85 0.15 69.41 1800 800 0.35 3.12 0.20 27.07 1801 1600 0.42 0.67 0.29 10.68 1803 Table 18: Drop and Send Rates for RED Queues in Byte Mode 1805 Table 18 shows that with a standard RED queue in byte mode instead 1806 of packet mode, there is a somewhat greater different between the 1807 packet drop rates between the TCP and TFRC-SP flows, particularly 1808 for lower packet drop rates. For the simulation in Table 18, the 1809 packet drop rates for the TCP flows can range from 1 1/2 to four 1810 times greater than the packet drop rates for the TFRC-SP flows. 1811 However, because the TFRC-SP flow has an upper bound on the sending 1812 rate, its sending rate is not affected in the lower packet-drop-rate 1813 regimes; its sending rate is only affected in the regimes with 1814 packet drop rates of 10% or more. The sending rate for TFRC-SP in 1815 the scenarios in Table 18 with higher packet drop rates are greater 1816 than desired, e.g., for the scenarios with 400 web sessions or 1817 greater. However, the results with TFRC-SP are at least better than 1818 that of small-packet flows with no congestion control at all. 1820 < - - - - - Send Rates in Kbps - - - - > 1821 Web TCP (512B seg) TFRC-SP (200B seg) 1822 Sessions DropRate SendRate DropRate SendRate 1823 -------- -------- -------- -------- -------- 1824 10 0.01 337.86 0.01 184.06 1825 25 0.02 258.71 0.01 184.03 1826 50 0.02 184.71 0.01 183.99 1827 100 0.04 63.63 0.03 184.43 1828 200 0.08 28.95 0.06 149.80 1829 400 0.12 17.03 0.10 88.21 1830 800 0.24 5.94 0.15 36.80 1831 1600 0.32 3.37 0.21 19.45 1833 Table 19: Drop and Send Rates for RED Queues in Byte Mode 1835 Table 19 shows that with a standard RED queue in byte mode and with 1836 long-lived TCP flows with 512-byte data segments, there is only a 1837 moderate difference between the packet drop rate for the 552-byte 1838 TCP packets and the 240-byte TFRC-SP packets. However, the sending 1839 rate for TFRC-SP in the scenarios in Table 19 with higher packet 1840 drop rates are still greater than desired, even given the goal of 1841 fairness with TCP flows with 1500-byte data segments instead of 1842 512-byte data segments. 1844 < - - - - - Send Rates in Kbps - - - - > 1845 Web TCP (1460B seg) TFRC-SP (200B seg) 1846 Sessions DropRate SendRate DropRate SendRate 1847 -------- -------- -------- -------- -------- 1848 10 0.04 318.10 0.02 185.34 1849 25 0.08 175.34 0.03 184.38 1850 50 0.10 81.60 0.04 181.95 1851 100 0.12 28.51 0.05 178.79 1852 200 0.20 3.65 0.06 173.78 1853 400 0.27 1.44 0.08 161.41 1854 800 0.40 0.58 0.06 159.62 1855 1600 0.55 0.29 0.02 180.92 1857 Table 20: Drop and Send Rates with Adaptive RED Queues in Byte Mode 1859 For the simulations in Table 20, the congested router uses an 1860 Adaptive RED queue in byte mode. 1862 For this router, the output queue is in units of bytes rather than 1863 of packets, each *byte* is dropped with the same probability, and 1864 because of the use of Adaptive RED, this byte-dropping mode extends 1865 even for the high-packet-drop-rate regime. 1867 As Table 20 shows, for a scenario with Adaptive RED in byte mode, 1868 the packet drop rate for the TFRC-SP traffic is *much* lower than 1869 that for the TCP traffic, and as a consequence, the sending rate for 1870 the TFRC-SP traffic in a highly congested environment is *much* 1871 higher than that of the TCP traffic. In fact, in these scenarios 1872 the TFRC-SP congestion control mechanisms are largely ineffective 1873 for the small-packet traffic. 1875 The simulation with 1600 web servers is of particular concern, 1876 because the TCP packet drop rate increases, while the TFRC-SP packet 1877 drop rate decreases significantly. This is due to a detail of the 1878 Adaptive RED implementation in the NS simulator, and not about the 1879 dynamics of TFRC-SP. In particular, Adaptive RED is configured not 1880 to "adapt" to packet drop rates over 50%. When the packet drop rate 1881 is at most 50%, Adaptive RED is moderately successful in keeping the 1882 packet drop rate proportional to the packet size - TCP packets are 1883 six times larger than the TFRC-SP packets (including headers), so 1884 the TCP packets should see a packet drop rate roughly six times 1885 larger. But for packet drop rates over 50%, Adaptive RED is no 1886 longer in this regime, so it is no longer successful in keeping the 1887 drop rate for TCP packets at most six times the drop rate of the 1888 TFRC-SP packets. 1890 We note that the unfairness in these simulations, in favor of TFRC- 1891 SP, is even more severe than the unfairness shown in Table 13 for a 1892 Drop-Tail queue in bytes. At the same time, it is not known if 1893 there is any deployment in the Internet of any routers with Adaptive 1894 RED in byte mode, or of any AQM mechanisms with similar behavior; 1895 we don't know the extent of the deployment of standard RED, or or 1896 any of the proposed AQM mechanisms. 1898 < - - - - - Send Rates in Kbps - - - - > 1899 Web TCP (512B seg) TFRC-SP (200B seg) 1900 Sessions DropRate SendRate DropRate SendRate 1901 -------- -------- -------- -------- -------- 1902 10 0.01 306.56 0.01 185.11 1903 25 0.02 261.41 0.01 184.41 1904 50 0.02 185.07 0.01 184.54 1905 100 0.04 59.25 0.03 181.58 1906 200 0.08 16.32 0.06 150.87 1907 400 0.12 11.53 0.10 98.10 1908 800 0.25 5.85 0.15 46.59 1909 1600 0.32 1.43 0.22 19.40 1911 Table 21: Drop and Send Rates for Adaptive RED Queues in Byte Mode 1913 Table 21 shows that when TFRC-SP with 240-byte packets competes with 1914 TCP with 552-byte packets in a scenario with Adaptive RED in byte 1915 mode, the TFRC-SP flows still receive more bandwidth that the TCP 1916 flows, but the level of unfairness is less severe, and the packet 1917 drop rates of the TCP flows is at most twice that of the TFRC-SP 1918 flows. That is, the TFRC-SP flows still receive more than their 1919 share of the bandwidth, but the TFRC-SP congestion control is more 1920 effective that than in Table 20 above. 1922 C. Appendix: Exploring Possible Oscillations in the Loss Event Rate 1924 TFRC-SP estimates the loss interval size differently for short and 1925 long loss intervals, counting only one loss event for long loss 1926 intervals, but counting all packet losses as loss events for the 1927 short loss intervals. One question that has been raised is whether 1928 this can lead to oscillations in the average loss event rate in 1929 environments where there are many packet drops in a single loss 1930 event, and loss events switch from short to long and vice versa. As 1931 an example, consider a loss interval with N packets, including N/4 1932 losses. If this loss interval is short (at most two round-trip 1933 times), the loss interval length is measured as 4 packets. If this 1934 loss interval is long, then the loss interval length is measured as 1935 N packets. 1937 If the loss interval switching from short to long and back leads to 1938 severe oscillations in the average packet drop rate, and therefore 1939 in the allowed sending rate, one solution would be to have a more 1940 gradual transition between the calculation of the loss interval 1941 length for short and long loss intervals. For example, one 1942 possibility would be to use all of the packet losses for a loss 1943 interval of one round-trip time in calculating the loss interval 1944 length, to use 2/3-rds of the packet losses from a loss interval of 1945 two round-trip times, to use 1/3-rd of the packet losses from a loss 1946 interval of three round-trip time, and to use only one packet loss 1947 from a loss interval of four or more round-trip times. This more 1948 gradual mechanism would give a gradual transition to counting all 1949 losses for a loss interval of only one round-trip time, and counting 1950 only one loss event for a loss interval of four or more round-trip 1951 times. 1953 However, our simulations so far have not shown a great difference in 1954 oscillations in the estimate loss event rate between the default 1955 mechanism for estimating the loss interval length for short loss 1956 interval and the gradual mechanism described above. Simulation 1957 scripts are available from [VOIPSIMS]. Therefore, for now we are 1958 staying with the simple default mechanism for estimating the loss 1959 event rate for short loss intervals described in this document. 1961 D. Appendix: A Discussion of Packet Size and Packet Dropping 1963 The table below gives a general summary of the relative advantages 1964 of packet-dropping behavior at routers independent of packet size, 1965 versus packet dropping behavior where large packets are more likely 1966 to be dropped than small ones. 1968 Advantages of Packet Dropping Independent of Packet Size: 1969 --------------------------------------------------------- 1970 1. Adds another incentive for end nodes to use large packets. 1972 2. Matches an environment with a limitation in pps rather than 1973 bps. 1974 --------------------------------------------------------- 1976 Advantages of Packet Dropping as a Function of Packet Size: 1977 --------------------------------------------------------- 1978 1. Small control packets are less likely to be dropped than are 1979 large data packets, improving TCP performance. 1981 2. Matches an environment with a limitation in bps rather than 1982 pps. 1984 3. Reduces the penalty of TCP and other transport protocols 1985 against flows with small packets (where the allowed sending 1986 rate is roughly a linear function of packet size). 1988 4. A queue limited in bytes is better than a queue limited in 1989 packets for matching the worst-case queue size to the 1990 worst-case queueing delay in seconds. 1991 --------------------------------------------------------- 1993 Normative References 1995 [RFC2119] S. Bradner. Key Words For Use in RFCs to Indicate 1996 Requirement Levels. RFC 2119. 1998 [RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 1999 Friendly Rate Control (TFRC): Protocol 2000 Specification, RFC 3448, Proposed Standard, January 2001 2003. 2003 Informative References 2005 [EA03] W. Eddy and M. Allman. A Comparison of RED's Byte 2006 and Packet Modes, Computer Networks, 42(2), June 2007 2003. 2009 [P04] T. Phelan, TFRC with Self-Limiting Sources, October 2010 2004. URL "http://www.phelan-4.com/dccp/". 2012 [RFC791] J. Postel, Internet Protocol, RFC 791, September 2013 1981. 2015 [RFC879] J. Postel, The TCP Maximum Segment Size and Related 2016 Topics, RFC 879, November 1983. 2018 [RFC1144] V. Jacobson, Compressing TCP/IP Headers for Low- 2019 Speed Serial Links, RFC 1144, February 1990. 2021 [RFC3168] K. Ramakrishnan, S. Floyd, and D. Black, The 2022 Addition of Explicit Congestion Notification (ECN) 2023 to IP, RFC 3168, September 2001. 2025 [RFC3714] S. Floyd and J. Kempf, Editors. IAB Concerns 2026 Regarding Congestion Control for Voice Traffic in 2027 the Internet. RFC 3714. 2029 [RFC3819] P. Karn et al., Advice for Internet Subnetwork 2030 Designers, RFC 3819, July 2004. 2032 [RFC4340] E. Kohler, M. Handley, and S. Floyd. Datagram 2033 Congestion Control Protocol (DCCP), RFC 4340, March 2034 2006. 2036 [RFC4342] S. Floyd, E. Kohler, and J. Padhye. Profile for 2037 Datagram Congestion Control Protocol (DCCP) 2038 Congestion Control ID 3: TCP-Friendly Rate Control 2039 (TFRC). RFC 4342, March 2006. 2041 [RFC3448bis] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 2042 Friendly Rate Control (TFRC): Protocol 2043 Specification, internet draft draft-ietf-dccp- 2044 rfc3448bis-00.txt, work in progress, October 2006. 2046 [S05] Peter Sholander, private communications, August 2047 2005. Citation for acknowledgement purposes only. 2049 [V00] P. Vasallo. Variable Packet Size Equation-Based 2050 Congestion Control. ICSI Technical Report 2051 TR-00-008, April 2000. URL 2052 "http://www.icsi.berkeley.edu/techreports/ 2053 2000.abstracts/tr-00-008.html". 2055 [VOIPSIMS] Web page "http://www.icir.org/tfrc/voipsims.html". 2057 [WBL04] J. Widmer, C. Boutremans, and Jean-Yves Le Boudec. 2058 Congestion Control for Flows with Variable Packet 2059 Size, ACM CCR, 34(2), 2004. 2061 Authors' Addresses 2063 Sally Floyd 2064 ICSI Center for Internet Research 2065 1947 Center Street, Suite 600 2066 Berkeley, CA 94704 2067 USA 2069 Eddie Kohler 2070 4531C Boelter Hall 2071 UCLA Computer Science Department 2072 Los Angeles, CA 90095 2073 USA 2075 Full Copyright Statement 2077 Copyright (C) The Internet Society (2006). This document is subject 2078 to the rights, licenses and restrictions contained in BCP 78, and 2079 except as set forth therein, the authors retain all their rights. 2081 This document and the information contained herein are provided on 2082 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2083 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2084 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2085 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2086 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2087 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2089 Intellectual Property 2091 The IETF takes no position regarding the validity or scope of any 2092 Intellectual Property Rights or other rights that might be claimed 2093 to pertain to the implementation or use of the technology described 2094 in this document or the extent to which any license under such 2095 rights might or might not be available; nor does it represent that 2096 it has made any independent effort to identify any such rights. 2097 Information on the procedures with respect to rights in RFC 2098 documents can be found in BCP 78 and BCP 79. 2100 Copies of IPR disclosures made to the IETF Secretariat and any 2101 assurances of licenses to be made available, or the result of an 2102 attempt made to obtain a general license or permission for the use 2103 of such proprietary rights by implementers or users of this 2104 specification can be obtained from the IETF on-line IPR repository 2105 at http://www.ietf.org/ipr. 2107 The IETF invites any interested party to bring to its attention any 2108 copyrights, patents or patent applications, or other proprietary 2109 rights that may cover technology that may be required to implement 2110 this standard. Please address the information to the IETF at ietf- 2111 ipr@ietf.org.