idnits 2.17.1 draft-irtf-tmrg-metrics-11.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1123. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1129. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([DM06]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (5 October 2007) is 6047 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-irtf-tmrg-tools-04 -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) -- Obsolete informational reference (is this intentional?): RFC 3782 (Obsoleted by RFC 6582) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sally Floyd 2 INTERNET-DRAFT Editor 3 Intended status: Informational 5 October 2007 4 Expires: April 2008 6 Metrics for the Evaluation of Congestion Control Mechanisms 7 draft-irtf-tmrg-metrics-11.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document discusses the metrics to be considered in an 41 evaluation of new or modified congestion control mechanisms for the 42 Internet. These include metrics for the evaluation of new transport 43 protocols, of proposed modifications to TCP, of application-level 44 congestion control, and of Active Queue Management (AQM) mechanisms 45 in the router. This document is the first in a series of documents 46 aimed at improving the models that we use in the evaluation of 47 transport protocols. 49 This document is a product of the Transport Modeling Research Group 50 (TMRG), and has received detailed feedback from many members of the 51 Research Group (RG). As the document tries to make clear, there is 52 not necessarily a consensus within the research community (or the 53 IETF community, the vendor community, the operations community, or 54 any other community) about the metrics that congestion control 55 mechanisms should be designed to optimize, in terms of tradeoffs 56 between throughput and delay, fairness between competing flows, and 57 the like. However, we believe that there is a clear consensus that 58 congestion control mechanisms should be evaluated in terms of 59 tradeoffs between a range of metrics, rather than in terms of 60 optimizing for a single metric. 62 Table of Contents 64 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1. Throughput, Delay, and Loss Rates. . . . . . . . . . . . 8 67 2.1.1. Throughput. . . . . . . . . . . . . . . . . . . . . 8 68 2.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.1.3. Packet Loss Rates . . . . . . . . . . . . . . . . . 10 70 2.2. Response Times and Minimizing Oscillations . . . . . . . 11 71 2.2.1. Response to Changes . . . . . . . . . . . . . . . . 11 72 2.2.2. Minimizing Oscillations . . . . . . . . . . . . . . 12 73 2.3. Fairness and Convergence . . . . . . . . . . . . . . . . 13 74 2.3.1. Metrics for fairness between flows. . . . . . . . . 13 75 2.3.2. Metrics for fairness between flows with 76 different resource requirements. . . . . . . . . . . . . . 14 77 2.3.3. Comments on fairness. . . . . . . . . . . . . . . . 15 78 2.4. Robustness for Challenging Environments. . . . . . . . . 17 79 2.5. Robustness to Failures and to Misbehaving 80 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 2.6. Deployability. . . . . . . . . . . . . . . . . . . . . . 17 82 2.7. Metrics for Specific Types of Transport. . . . . . . . . 18 83 2.8. User-Based Metrics . . . . . . . . . . . . . . . . . . . 18 84 3. Metrics in the IP Performance Metrics (IPPM) Working 85 Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 4. Comments on Methodology . . . . . . . . . . . . . . . . . . . 19 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 20 90 Informative References . . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 92 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 25 93 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 25 94 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 96 Changes from draft-irtf-tmrg-metrics-10.txt: 98 * Added tunnels (e.g., IPsec) and non-router queues 99 (e.g. Ethernet switches) to the discussion on deployability. 100 Feedback from Aaron Falk in the IRSG poll. 102 * Minor editing in response to feedback from Lachlan Andrew. 104 * Added a new citation to [DM06]. 106 Changes from draft-irtf-tmrg-metrics-09.txt: 108 * Copied a paragraph from the Abstract to the Introduction, and 109 updated references. From feedback from Tony Li in the IRSG 110 review. 112 Changes from draft-irtf-tmrg-metrics-08.txt: 114 * General feedback from Michael Welzl, adding explanations 115 to some of the fairness discussions. 117 Changes from draft-irtf-tmrg-metrics-07.txt: 119 * General feedback from Mark Allman. 121 * Feedback and contributions from Lachlan Andrew about fairness. 123 Changes from draft-irtf-tmrg-metrics-06.txt: 125 * Added a paragraph about tradeoffs between 126 fairness and throughput. 128 * Minor editing changes. 130 Changes from draft-irtf-tmrg-metrics-05.txt: 132 * Added a sentence about drop synchronization. 133 Feedback from David Ros. 135 * Added a citation to fairness draft by Briscoe. 137 Changes from draft-irtf-tmrg-metrics-04.txt: 139 * Added text to the abstract. 141 Changes from draft-irtf-tmrg-metrics-03.txt: 143 * Added a paragraph about sudden changes due to mobility 144 and the heterogeneity of wireless access types. 145 Suggestion from Andras Veres. 147 * Add covariance as one of the metrics for oscillations. 148 Suggestion from Saverio Mascolo, original text 149 contribution from Injong Rhee. 151 Changes from draft-irtf-tmrg-metrics-02.txt: 153 * Added a few sentences to the Abstract about the 154 status of the document. 156 Changes from draft-irtf-tmrg-metrics-01.txt: 158 * Added a discussion about the metrics in IPPM. 160 Changes from draft-irtf-tmrg-metrics-01c.txt: 162 * Added to the discussion of network-based, flow-based, 163 and user-based metrics, based on email from Dado Colussi, 164 Sean Moore, Damon Wischik, Dah Ming Chiu, and others. 166 * Changed "packet drop rate" to "packet loss rate". 167 Suggestion from Nelson Fonseca. 169 * Added a discussion of the Colussi et al. paper on a new 170 definition of fairness. 172 * Added a discussion of the Chiu and Tan paper on redefining 173 fairness for inelastic traffic. 175 Changes from draft-irtf-tmrg-metrics-01b.txt: 177 * Added a discussion of goodput vs. throughput. 178 Suggestion from Nelson Fonseca. 180 Changes from draft-irtf-tmrg-metrics-01a.txt: 182 * Added to the discussion of packet drop rate metrics. 183 Suggestions from Janardhan Iyengar, Sean Moore, 184 Armando Caro, and Nelson Fonseca. 186 * Added a sentence about throughput used as a metric for 187 transfer times for very short flows. 188 Response to email from Sean Moore. 190 Changes from draft-irtf-tmrg-metrics-00.txt: 192 * Added a list of relevant congestion control mechanisms to 193 the abstract. Suggestion from Sean Moore. 195 * Added to the Introduction. Suggestion from Dado Colussi. 197 * Added a sentence about jitter to the discussion of minimizing 198 oscillations. Suggestion from Wesley Eddy. 200 * Added a note about convergence between existing flows after 201 a change in bandwidth. Suggestion from Wesley Eddy. 203 * Added to the section on deployability. Suggestion from 204 Wesley Eddy. 206 Changes from draft-floyd-transport-metrics-00.txt: 208 * Added metrics for: 209 - robustness in challenging environments, 210 - deployability, 211 - robustness to failures and to misbehaving users 213 * Added a discussion of fairness and packet size. 215 1. Introduction 217 As a step towards improving our methodologies for evaluating 218 congestion control mechanisms, in this document we discuss some of 219 the metrics to be considered. We also consider the relationship 220 between metrics, e.g., the well-known tradeoff between throughput 221 and delay. This document doesn't attempt to specify every metric 222 that a study might consider; for example, there are domain-specific 223 metrics that researchers might consider that are over and above the 224 metrics laid out in this document. 226 We consider metrics for aggregate traffic (taking into account the 227 effect of flows on competing traffic in the network) as well as the 228 heterogeneous goals of different applications or transport protocols 229 (e.g., of high throughput for bulk data transfer, and of low delay 230 for interactive voice or video). Different transport protocols or 231 AQM mechanisms might have goals of optimizing different sets of 232 metrics, with one transport protocol optimized for per-flow 233 throughput and another optimized for robustness over wireless links, 234 and with different degrees of attention to fairness with competing 235 traffic. We hope this document will be used as a step in evaluating 236 proposed congestion control mechanisms for a wide range of metrics, 237 for example, noting that Mechanism X is good at optimizing Metric A, 238 but pays the price with poor performance for Metric B. The goal 239 would be to have a broad view of both the strengths and weaknesses 240 of newly-proposed congestion control mechanisms. 242 Subsequent documents are planned to present sets of simulation and 243 testbed scenarios for the evaluation of transport protocols and of 244 congestion control mechanisms, based on the best current practice of 245 the research community. These are not intended to be complete or 246 final benchmark test suites, but simply to be one step of many to be 247 used by researchers in evaluating congestion control mechanisms. 248 Subsequent documents are also planned on the methodologies in using 249 these sets of scenarios. 251 This document is a product of the Transport Modeling Research Group 252 (TMRG), and has received detailed feedback from many members of the 253 Research Group (RG). As the document tries to make clear, there is 254 not necessarily a consensus within the research community (or the 255 IETF community, the vendor community, the operations community, or 256 any other community) about the metrics that congestion control 257 mechanisms should be designed to optimize, in terms of tradeoffs 258 between throughput and delay, fairness between competing flows, and 259 the like. However, we believe that there is a clear consensus that 260 congestion control mechanisms should be evaluated in terms of 261 tradeoffs between a range of metrics, rather than in terms of 262 optimizing for a single metric. 264 2. Metrics 266 The metrics that we discuss are the following: 268 o Throughput; 270 o Delay; 272 o Packet loss rates; 274 o Response to sudden changes or to transient events; 276 o Minimizing oscillations in throughput or in delay; 278 o Fairness and convergence times; 280 o Robustness for challenging environments; 282 o Robustness to failures and to misbehaving users; 284 o Deployability; 285 o Metrics for specific types of transport; 287 o User-based metrics. 289 We consider each of these below. Many of the metrics have network- 290 based, flow-based, and user-based interpretations. For example, 291 network-based metrics can consider aggregate bandwidth and aggregate 292 drop rates, flow-based metrics can consider end-to-end transfer 293 times for file transfers or end-to-end delay and packet drop rates 294 for interactive traffic, and user-based metrics can consider user 295 wait time or user satisfaction with the multimedia experience. Our 296 main goal in this document is to explain the set of metrics that can 297 be relevant, and not to legislate on the most appropriate 298 methodology for using each general metric. 300 For some of the metrics, such as fairness, there is not a clear 301 agreement in the network community about the desired goals. In 302 these cases, the document attempts to present the range of 303 approaches. 305 2.1. Throughput, Delay, and Loss Rates 307 Because of the clear tradeoffs between throughput, delay, and loss 308 rates, it can be useful to consider these three metrics together. 309 The tradeoffs are most clear in terms of queue management at the 310 router; is the queue configured to maximize aggregate throughput, to 311 minimize delay and loss rates, or some compromise between the two? 312 An alternative would be to consider a separate metric such as power, 313 defined in this context as throughput over delay, that combines 314 throughput and delay. However, we do not propose in this document a 315 clear target in terms of the tradeoffs between throughput and delay; 316 we are simply proposing that the evaluation of transport protocols 317 include an exploration of the competing metrics. 319 Using flow-based metrics instead of router-based metrics, the 320 relationship between per-flow throughput, delay, and loss rates can 321 often be given by the transport protocol itself. For example, in 322 TCP, the sending rate s in packets per second is given as 324 s = 1.2/(RTT*sqrt(p)), 326 for the round-trip time RTT and loss rate p [FF99]. 328 2.1.1. Throughput 330 Throughput can be measured as a router-based metric of aggregate 331 link utilization, as a flow-based metric of per-connection transfer 332 times, and as user-based metrics of utility functions or user wait 333 times. It is a clear goal of most congestion control mechanisms to 334 maximize throughput, subject to application demand and to the 335 constraints of the other metrics. 337 Throughput is sometimes distinguished from goodput, where throughput 338 is the link utilization or flow rate in bytes per second, and 339 goodput, also measured in bytes per second, is the subset of 340 throughput consisting of useful traffic. That is, `goodput' 341 excludes duplicate packets, packets that will be dropped downstream, 342 packet fragments or ATM cells that are dropped at the receiver 343 because they can't be re-assembled into complete packets, and the 344 like. In general, this document doesn't distinguish between 345 throughput and goodput, and uses the general term "throughput". 347 We note that maximizing throughput is of concern in a wide range of 348 environments, from highly-congested networks to under-utilized ones, 349 and from long-lived flows to very short ones. As an example, 350 throughput has been used as one of the metrics for evaluating Quick- 351 Start, a proposal to allow flows to start-up faster than slow-start, 352 where throughput has been evaluated in terms of the transfer times 353 for connections with a range of transfer sizes [RFC4782] [SAF06]. 355 In some contexts, it might be sufficient to consider the aggregate 356 throughput or the mean per-flow throughput [DM06], while in other 357 contexts it might be necessary to consider the distribution of per- 358 flow throughput. Some researchers evaluate transport protocols in 359 terms of maximizing the aggregate user utility, where a user's 360 utility is generally defined as a function of the user's throughput 361 [KMT98]. 363 Individual applications can have application-specific needs in terms 364 of throughput. For example, real-time video traffic can have highly 365 variable bandwidth demands; VoIP traffic is sensitive to the amount 366 of bandwidth received immediately after idle periods. Thus, user 367 metrics for throughput can be more complex than simply the per- 368 connection transfer time. 370 2.1.2. Delay 372 Like throughput, delay can be measured as a router-based metric of 373 queueing delay over time, or as a flow-based metric in terms of per- 374 packet transfer times. Per-packet delay can also include delay at 375 the sender waiting for the transport protocol to send the packet. 376 For reliable transfer, the per-packet transfer time seen by the 377 application includes the possible delay of retransmitting a lost 378 packet. 380 Users of bulk data transfer applications might care about per-packet 381 transfer times only in so far as they affect the per-connection 382 transfer time. On the other end of the spectrum, for users of 383 streaming media, per-packet delay can be a significant concern. 384 Note that in some cases the average delay might not capture the 385 metric of interest to the users; for example, some users might care 386 about the worst-case delay, or about the tail of the delay 387 distribution. 389 Note that queueing delay at a router is shared by all flows at a 390 FIFO (First-In First-Out) queue. Thus, the router-based queueing 391 delay induced by bulk data transfers can be important even if the 392 bulk data transfers themselves are not concerned with per-packet 393 transfer times. 395 2.1.3. Packet Loss Rates 397 Packet loss rates can be measured as a network-based or as a flow- 398 based metric. 400 When evaluating the effect of packet losses or ECN marks (Explicit 401 Congestion Notification) [RFC3168] on the performance of a 402 congestion control mechanism for an individual flow, researchers 403 often use both the packet loss/mark rate for that connection, and 404 the congestion event rate (also called the loss event rate), where a 405 congestion event or loss event consists of one or more lost or 406 marked packets in one round-trip time [RFC3448]. 408 Some users might care about the packet loss rate only in so far as 409 it affects per-connection transfer times, while other users might 410 care about packet loss rates directly. RFC 3611, RTP Control 411 Protocol Extended Reports, describes a VoIP performance-reporting 412 standard called RTCP XR, which includes a set of burst metrics. In 413 RFC 3611, a burst is defined as the maximal sequence starting and 414 ending with a lost packet, and not including a sequence of Gmin or 415 more packets that are not lost [RFC3611]. The burst metrics in RFC 416 3611 consist of the burst density (the fraction of packets in 417 bursts), gap density (the fraction of packets in the gaps between 418 bursts), burst duration (the mean duration of bursts in seconds), 419 and gap duration (the mean duration of gaps in seconds). RFC 3357 420 derives metrics for "loss distance" and "loss period", along with 421 statistics that capture loss patterns experienced by packet streams 422 on the Internet [RFC3357]. 424 In some cases it is useful to distinguish between packets dropped at 425 routers due to congestion, and packets lost in the network due to 426 corruption. 428 One network-related reason to avoid high steady-state packet loss 429 rates is to avoid congestion collapse in environments containing 430 paths with multiple congested links. In such environments, high 431 packet loss rates could result in congested links wasting scarce 432 bandwidth by carrying packets that will only be dropped downstream, 433 before being delivered to the receiver [RFC2914]. We also note that 434 in some cases the retransmit rate can be high, and the goodput 435 correspondingly low, even with a low packet drop rate [AEO03]. 437 2.2. Response Times and Minimizing Oscillations 439 In this section we consider response times and oscillations 440 together, as there are well-known tradeoffs between improving 441 response times and minimizing oscillations. In addition, the 442 scenarios that illustrate the dangers of poor response times are 443 often quite different from the scenarios that illustrate the dangers 444 of unnecessary oscillations. 446 2.2.1. Response to Changes 448 One of the key concerns in the design of congestion control 449 mechanisms has been the response times to sudden congestion in the 450 network. On the one hand, congestion control mechanisms should 451 respond reasonably promptly to sudden congestion from routing or 452 bandwidth changes, or from a burst of competing traffic. At the 453 same time, congestion control mechanisms should not respond too 454 severely to transient changes, e.g., to a sudden increase in delay 455 that will dissipate in less than the connection's round-trip time. 457 Congestion control mechanisms also have to contend with sudden 458 changes in the bandwidth-delay product due to mobility. Such 459 bandwith-delay product changes are expected to become more frequent 460 and to have greater impact than path changes today. As a result of 461 both mobility and of the heterogeneity of wireless access types 462 (802.11b,a,g, WIMAX, WCDMA, HS-WCDMA, E-GPRS, Bluetooth, etc.), both 463 the bandwidth and the round-trip delay can change suddenly, 464 sometimes by several orders of magnitude. 466 Evaluating the response to sudden or transient changes can be of 467 particular concern for slowly-responding congestion control 468 mechanisms such as equation-based congestion control [RFC3448], and 469 for AIMD (Additive Increase Multiplicative Decrease) or related 470 mechanisms using parameters that make them more slowly-responding 471 than TCP [BB01] [BBFS01]. 473 In addition to the responsiveness and smoothness of aggregate 474 traffic, one can consider the tradeoffs between responsiveness, 475 smoothness, and aggressiveness for an individual connection [FHP00] 476 [YKL01]. In this case smoothness can be defined by the largest 477 reduction in the sending rate in one round-trip time, in a 478 deterministic environment with a packet drop exactly every 1/p 479 packets. The responsiveness is defined as the number of round-trip 480 times of sustained congestion required for the sender to halve the 481 sending rate, and the aggressiveness is defined as the maximum 482 increase in the sending rate in one round-trip time, in packets per 483 second, in the absence of congestion. This aggressiveness can be a 484 function of the mode of the transport protocol; for TCP, the 485 aggressiveness of slow-start is quite different from the 486 aggressiveness of congestion avoidance mode. 488 2.2.2. Minimizing Oscillations 490 One goal is that of stability, in terms of minimizing oscillations 491 of queueing delay or of throughput. In practice, stability is 492 frequently associated with rate fluctuations or variance. Rate 493 variations can result in fluctuations in router queue size and 494 therefore of queue overflows. These queue overflows can cause loss 495 synchronizations across co-existing flows and periodic under- 496 utilization of link capacity, both of which are considered to be 497 general signs of network instability. Thus, measuring the rate 498 variations of flows is often used to measure the stability of 499 transport protocols. To measure rate variations, [JWL04], [RX05], 500 and [FHPW00] use the coefficient of variation (CoV) of per-flow 501 transmission rates and [WCL05] suggests the use of standard 502 deviations of per-flow rates. Since rate variations are a function 503 of time scales, it makes sense to measure these rate variations over 504 various time scales. 506 Measuring per-flow rate variations, however, is only one aspect of 507 transport protocol stability. A realistic experiment setting always 508 involves multiple flows of the transport protocol being observed, 509 along with a significant amount of cross traffic, with rates varying 510 over time, on both the forward and reverse paths. As a congestion 511 control protocol must adapt its rate to the varying rates of 512 competing traffic, just measuring the per-flow statistics of a 513 subset of the traffic could be misleading because it measures the 514 rate fluctuations due in part to the adaptation to competing traffic 515 on the path. Thus, per-flow statistics are most meaningful if they 516 are accompanied by the statistics measured at the network level. As 517 a complementary metric to the per-flow statistics, [HKLRX06] uses 518 measurements of the rate variations of the aggregate flows observed 519 in bottleneck routers over various time scales. 521 Minimizing oscillations in queueing delay or throughput has related 522 per-flow metrics of minimizing jitter in round-trip times and loss 523 rates. 525 An orthogonal goal for some congestion control mechanisms, e.g., for 526 equation-based congestion control, is to minimize the oscillations 527 in the sending rate for an individual connection, given an 528 environment with a fixed, steady-state packet drop rate. (As is 529 well known, TCP congestion control is characterized by a pronounced 530 oscillation in the sending rate, with the sender halving the sending 531 rate in response to congestion.) One metric for the level of 532 oscillations is the smoothness metric given in Section 2.2.1 above. 534 As discussed in [FK07], the synchronization of loss events can also 535 affect convergence times, throughput, and delay. 537 2.3. Fairness and Convergence 539 Another set of metrics is that of fairness and convergence times. 540 Fairness can be considered between flows of the same protocol, and 541 between flows using different protocols (e.g., TCP-friendliness, 542 referring to fairness between TCP and a new transport protocol). 543 Fairness can also be considered between sessions, between users, or 544 between other entities. 546 There are a number of different fairness measures. These include 547 max-min fairness [HG86], proportional fairness [KMT98] [K01], the 548 fairness index proposed in [JCH84], and the product measure, a 549 variant of network power [BJ81]. 551 2.3.1. Metrics for fairness between flows 553 This section discusses fairness metrics that consider the fairness 554 between flows, but that don't take into account different 555 characteristics of flows (e.g., the number of links in the path, or 556 the round-trip time). For the discussion of fairness metrics, let 557 x_i be the throughput for the i-th connection. 559 Jain's fairness index: The fairness index in [JCH84] is 561 (( sum_i x_i )^2) / (n * sum_i ( (x_i)^2 )), 563 where there are n users. This fairness index ranges from 0 to 1, 564 and is maximum when all users receive the same allocation. This 565 index is k/n when k users equally share the resource, and the other 566 n-k users receive zero allocation. 568 The product measure: The product measure 569 product_i x_i , 571 the product of the throughput of the individual connections, is also 572 used as a measure of fairness. (In some contexts x_i is taken as 573 the power of the i-th connection, and the product measure is 574 referred to as network power.) The product measure is particularly 575 sensitive to segregation; the product measure is zero if any 576 connection receives zero throughput. In [MS91] it is shown that for 577 a network with many connections and one shared gateway, the product 578 measure is maximized when all connections receive the same 579 throughput. 581 Epsilon-fairness: A rate allocation is defined as epsilon-fair if 583 (min_i x_i) / (max_i x_i) >= 1 - epsilon. 585 Epsilon-fairness measures the worst-case ratio between any two 586 throughput rates [ZKL04]. Epsilon-fairness is related to max-min 587 fairness, defined later in this document. 589 2.3.2. Metrics for fairness between flows with different resource 590 requirements 592 This section discusses metrics for fairness between flows with 593 different resource requirements, that is, with different utility 594 functions, round-trip times, or numbers of links on the path. Many 595 of these metrics can be described as solutions to utility 596 maximization problems [K01]; the total utility quantifies both the 597 fairness and the throughput. 599 Max-min fairness: In order to satisfy the max-min fairness criteria, 600 the smallest throughput rate must be as large as possible. Given 601 this condition, the next-smallest throughput rate must be as large 602 as possible, and so on. Thus, the max-min fairness gives absolute 603 priority to the smallest flows. (Max-min fairness can be explained 604 by the progressive filling algorithm, where all flow rates start at 605 zero, and the rates all grow at the same pace. Each flow rate stops 606 growing only when one or more links on the path reaches link 607 capacity.) 609 Proportional fairness: In contrast, a feasible allocation x is 610 defined as proportionally fair if for any other feasible allocation 611 x*, the aggregate of proportional changes is zero or negative: 613 sum_i ( (x*_i - x_i)/x_i ) <= 0. 615 "This criterion favours smaller flows, but less emphatically than 616 max-min fairness" [K01]. (Using the language of utility functions, 617 proportional fairness can be achieved by using logarithmic utility 618 functions, and maximizing the sum of the per-flow utility functions; 619 see [KMT98] for a fuller explanation.) 621 Minimum potential delay fairness: Minimum potential delay fairness 622 has been shown to model TCP [KS03], and is a compromise between max- 623 min fairness and proportional fairness. An allocation x is defined 624 as having minimum potential delay fairness if 626 sum_i (1/x_i) 628 is smaller than for any other feasible allocation. That is, it 629 would minimize the average download time if each flow was an equal- 630 sized file. 632 In [CRM05], Colussi et al. propose a new definition of TCP fairness, 633 that "a set of TCP fair flows do not cause more congestion than a 634 set of TCP flows would cause", where congestion is defined in terms 635 of queueing delay, queueing delay variation, the congestion event 636 rate [e.g., loss event rate], and the packet loss rate. 638 Chiu and Tan in [CT06] argue for redefining the notion of fairness 639 when studying traffic controls for inelastic traffic, proposing that 640 inelastic flows adopt other traffic controls such as admission 641 control. 643 Briscoe in [B07] argues that flow-rate fairness should not be a 644 desired goal, and that instead "a realistic fairness mechanism must 645 share out the `cost' of each users actions on others". 647 2.3.3. Comments on fairness 649 Tradeoffs between fairness and throughput: The fairness measures in 650 the section above generally measure both fairness and throughput, 651 giving different weights to each. Potential tradeoffs between 652 fairness and throughput are also discussed by Tang et al. in 653 [TWL06], for a framework where max-min fairness is defined as the 654 most fair. In particular, [TWL06] shows that in some topologies 655 throughput is proportional to fairness, while in other topologies 656 throughput is inversely proportional to fairness. 658 Fairness and the number of congested links: Some of these fairness 659 metrics are discussed in more detail in [F91]. We note that there 660 is not a clear consensus for the fairness goals, in particular for 661 fairness between flows that traverse different numbers of congested 662 links [F91]. Utility maximization provides one framework for 663 describing this tradeoff in fairness. 665 Fairness and round-trip times: One goal cited in a number of new 666 transport protocols has been that of fairness between flows with 667 different round-trip times [KHR02] [XHR04]. We note that there is 668 not a consensus in the networking community about the desirability 669 of this goal, or about the implications and interactions between 670 this goal and other metrics [FJ92] (Section 3.3). One common 671 argument against the goal of fairness between flows with different 672 round-trip times has been that flows with long round-trip times 673 consume more resources; this aspect is covered by the previous 674 paragraph. Researchers have also noted the difference between the 675 RTT-unfairness of standard TCP, and the greater RTT-unfairness of 676 some proposed modifications to TCP [LLS05]. 678 Fairness and packet size: One fairness issue is that of the relative 679 fairness for flows with different packet sizes. Many file transfer 680 applications will use the maximum packet size possible; in 681 contrast, low-bandwidth VoIP flows are likely to send small packets, 682 sending a new packet every 10 to 40 ms., to limit delay. Should a 683 small-packet VoIP connection receive the same sending rate in 684 *bytes* per second as a large-packet TCP connection in the same 685 environment, or should it receive the same sending rate in *packets* 686 per second? This fairness issue has been discussed in more detail 687 in [RFC3714], with [RFC4828] also describing the ways that packet 688 size can effect the packet drop rate experienced by a flow. 690 Convergence times: Convergence times concern the time for 691 convergence to fairness between an existing flow and a newly- 692 starting one, and are a special concern for environments with high- 693 bandwidth long-delay flows. Convergence times also concern the time 694 for convergence to fairness after a sudden change such as a change 695 in the network path, the competing cross-traffic, or the 696 characteristics of a wireless link. As with fairness, convergence 697 times can matter both between flows of the same protocol, and 698 between flows using different protocols [SLFK03]. One metric used 699 for convergence times is the delta-fair convergence time, defined as 700 the time taken for two flows with the same round-trip time to go 701 from shares of 100/101-th and 1/101-th of the link bandwidth, to 702 having close to fair sharing with shares of (1+delta)/2 and 703 (1-delta)/2 of the link bandwidth [BBFS01]. A similar metric for 704 convergence times measures the convergence time as the number of 705 round-trip times for two flows to reach epsilon-fairness, when 706 starting from a maximally-unfair state [ZKL04]. 708 2.4. Robustness for Challenging Environments 710 While congestion control mechanisms are generally evaluated first 711 over environments with static routing in a network of two-way point- 712 to-point links, some environments bring up more challenging problems 713 (e.g., corrupted packets, reordering, variable bandwidth, mobility) 714 as well as new metrics to be considered (e.g., energy consumption). 716 Robustness for challenging environments: Robustness needs to be 717 explored for paths with reordering, corruption, variable bandwidth, 718 asymmetric routing, router configuration changes, mobility, and the 719 like [GF04]. In general, the Internet architecture has valued 720 robustness over efficiency, e.g., when there are tradeoffs between 721 robustness and the throughput, delay, and fairness metrics described 722 above. 724 Energy consumption: In mobile environments the energy consumption 725 for the mobile end-node can be a key metric that is affected by the 726 transport protocol [TM02]. 728 The goodput ratio: For wireless networks, the goodput ratio can be a 729 useful metric, where the goodput ratio can be defined as the useful 730 data delivered to users as a fraction of the total amount of data 731 transmitted on the network. A high goodput ratio indicates an 732 efficient use of the radio spectrum and lower interference with 733 other users. 735 2.5. Robustness to Failures and to Misbehaving Users 737 One goal is for congestion control mechanisms to be robust to 738 misbehaving users, such as receivers that `lie' to data senders 739 about the congestion experienced along the path or otherwise attempt 740 to bypass the congestion control mechanisms of the sender [SCWA99]. 741 Another goal is for congestion control mechanisms to be as robust as 742 possible to failures, such as failures of routers in using explicit 743 feedback to end-nodes or failures of end-nodes to follow the 744 prescribed protocols. 746 2.6. Deployability 748 One metric for congestion control mechanisms is their deployability 749 in the current Internet. Metrics related to deployability include 750 the ease of failure diagnosis, and the overhead in terms of packet 751 header size or added complexity at end-nodes or routers. 753 One key aspect of deployability concerns the range of deployment 754 needed for a new congestion control mechanism. Consider the 755 following possible deployment requirements: 757 * Only at the sender (e.g., NewReno in TCP [RFC3782]); 758 * Only at the receiver (e.g., delayed acknowledgements in TCP); 759 * Both the sender and receiver (e.g., SACK TCP [RFC2018]); 760 * At a single router (e.g., RED [FJ93]); 761 * All of the routers along the end-to-end path; 762 * Both end nodes and all routers along the path (e.g., XCP [KHR02]). 764 Some congestion control mechanisms (e.g., XCP [KHR02], Quick-Start 765 [RFC4782]) may also have deployment issues with IPsec, IP in IP, 766 MPLS, or other tunnels, or with non-router queues such as those in 767 Ethernet switches. 769 Another deployability issue concerns the complexity of the code. 770 How complex is the code required to implement the mechanism in 771 software? Is floating point math required? How much new state must 772 be kept to implement the new mechanism, and who holds that state, 773 the routers or the end-nodes? We note that we don't suggest these 774 questions as ways to reduce the deployability metric to a single 775 number; we suggest them as issues that could be considered in 776 evaluating the deployability of a proposed congestion control 777 mechanism. 779 2.7. Metrics for Specific Types of Transport 781 In some cases modified metrics are needed for evaluating transport 782 protocols intended for QoS-enabled environments or for below-best- 783 effort traffic [VKD02] [KK03]. 785 2.8. User-Based Metrics 787 An alternate approach that has been proposed for the evaluation of 788 congestion control mechanisms would be to evaluate in terms of user 789 metrics such as user satisfaction, or in terms of application- 790 specific utility functions. Such an approach would require the 791 definition of a range of user metrics or of application-specific 792 utility functions for the range of applications under consideration 793 (e.g., FTP, HTTP, VoIP). 795 3. Metrics in the IP Performance Metrics (IPPM) Working Group 797 The IPPM Working Group [IPPM] was established to define performance 798 metrics to be used by network operators, end users, or independent 799 testing groups. The metrics include metrics for connectivity 800 [RFC2678], delay and loss [RFC2679] [RFC2680] [RFC2681], delay 801 variation [RFC3393], loss patterns [RFC3357], packet reordering 803 [RFC4737], bulk transfer capacity [RFC3148], and link capacity 804 [CI07]. The IPPM documents give concrete, well-defined metrics, 805 along with a methodology for measuring the metric. The metrics 806 discussed in this document have a different purpose from the IPPM 807 metrics; in this document we are discussing metrics as used in 808 analysis, simulations, and experiments for the evaluation of 809 congestion control mechanisms. Further, we are discussing these 810 metrics in a general sense, rather than looking for specific 811 concrete definitions for each metric. However, there are many cases 812 where the metric definitions from IPPM could be useful, for specific 813 issues of how to measure these metrics in simulations or in 814 testbeds, and for providing common definitions for talking about 815 these metrics. 817 4. Comments on Methodology 819 The types of scenarios that are used to test specific metrics, and 820 the range of parameters that it is useful to consider, will be 821 discussed in separate documents, e.g., along with specific scenarios 822 for use in evaluating congestion control mechanisms. 824 We note that it can be important to evaluate metrics over a wide 825 range of environments, with a range of link bandwidths, congestion 826 levels, and levels of statistical multiplexing. It is also 827 important to evaluate congestion control mechanisms in a range of 828 scenarios, including typical ranges of connection sizes and round- 829 trip times [FK02]. It is also useful to compare metrics for new or 830 modified transport protocols with those of the current standards for 831 TCP. 833 As an example from the literature on evaluating transport protocols, 834 Li et al. in "Experimental Evaluation of TCP Protocols for High- 835 Speed Networks" [LLS05] focus on the performance of TCP in high- 836 speed networks, and consider metrics for aggregate throughput, loss 837 rates, fairness (including fairness between flows with different 838 round-trip times), response times (including convergence times), and 839 incremental deployment. More general references on methodology 840 include [J91]. Papers that discuss the range of metrics for 841 evaluating congestion control include [MTZ04]. 843 5. Security Considerations 845 There are no security considerations in this document. 847 6. IANA Considerations 849 There are no IANA considerations in this document. 851 7. Acknowledgements 853 Thanks to Lachlan Andrew, Mark Allman, Armando Caro, Dah Ming Chiu, 854 Eric Coe, Dado Colussi, Wesley Eddy, Nelson Fonseca, Janardhan 855 Iyengar, Doug Leith, Tony Li, Saverio Mascolo, Sean Moore, Injong 856 Rhee, David Ros, Juergen Schoenwaelder, Andras Veres, Michael Welzl, 857 and Damon Wischik, and members of the Transport Modeling Research 858 Group for feedback and contributions. 860 Informative References 862 [AEO03] M. Allman, W. Eddy, and S. Ostermann, Estimating Loss Rates 863 With TCP, ACM Performance Evaluation Review, 31(3), December 864 2003. 866 [BB01] D. Bansal and H. Balakrishnan, Binomial Congestion Control 867 Algorithms, IEEE Infocom, April 2001. 869 [BBFS01] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, 870 Dynamic Behavior of Slowly-Responsive Congestion Control 871 Algorithms, SIGCOMM 2001. 873 [BJ81] K. Bharath-Kumar and J. Jeffrey, A New Approach to 874 Performance-Oriented Flow Control, IEEE Transactions on 875 Communications, Vol.29 N.4, April 1981. 877 [B07] B. Briscoe, Flow Rate Fairness: Dismantling a Religion, 878 internet-draft draft-briscoe-tsvarea-fair-02.txt, work-in- 879 progress, July 2007. 881 [CI07] P. Chimento and J. Ishac, Defining Network Capacity, 882 internet-draft draft-ietf-ippm-bw-capacity-05, work-in-progress, 883 May 2007. 885 [CRM05] D. Colussi, A New Approach to TCP-Fairness, Report 886 C-2005-49, University of Helsinki, Finland, 2005. 888 [CT06] D. Chiu and A. Tam, Redefining Fairness in the Study of TCP- 889 friendly Traffic Controls, Technical Report, 2006. 891 [DM06] N. Dukkipati and N. McKeown, Why Flow-Completion Time is the 892 Right Metric for Congestion Control, ACM SIGCOMM, January 2006. 894 [F91] S. Floyd, Connections with Multiple Congested Gateways in 895 Packet-Switched Networks Part 1: One-way Traffic, Computer 896 Communication Review, Vol.21 No.5, October 1991, p. 30-47. 898 [FF99] Floyd, S., and Fall, K., "Promoting the Use of End-to-End 899 Congestion Control in the Internet", IEEE/ACM Transactions on 900 Networking, August 1999. 902 [FHP00] S. Floyd, M. Handley, and J. Padhye, A Comparison of 903 Equation-Based and AIMD Congestion Control, May 2000. URL 904 "http://www.icir.org/tfrc/". 906 [FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, Equation- 907 Based Congestion Control for Unicast Applications, SIGCOMM 2000, 908 August 2000. 910 [FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in Packet- 911 Switched Gateways, Internetworking: Research and Experience, V.3 912 N.3, September 1992, p.115-156. 914 [FJ93] S. Floyd and V. Jacobson, Random Early Detection gateways for 915 Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 916 N.4, August 1993, 918 [FK02] S. Floyd and E. Kohler, Internet Research Needs Better 919 Models, Hotnets-I. October 2002. 921 [FK07] S. Floyd and E. Kohler, Tools for the Evaluation of 922 Simulation and Testbed Scenarios, internet-draft draft-irtf- 923 tmrg-tools-04.txt, July 2007. 925 [GF04] A. Gurtov and S. Floyd, Modeling Wireless Links for Transport 926 Protocols, ACM CCR, 34(2):85-96, April 2004. 928 [HKLRX06] S. Ha, Y. Kim, L. Le, I. Rhee, and L. Xu, A Step Toward 929 Realistic Evaluation of High-speed TCP Protocols, technical 930 report, North Carolina State University, January 2006. 932 [HG86] E. Hahne and R. Gallager, Round Robin Scheduling for Fair 933 Flow Control in Data Communications Networks, IEEE International 934 Conference on Communications, June 1986. 936 [IPPM] IP Performance Metrics (IPPM) Working Group, URL 937 "http://www.ietf.org/html.charters/ippm-charter.html". 939 [J91] R. Jain, The Art of Computer Systems Performance Analysis: 940 Techniques for Experimental Design, Measurement, Simulation, and 941 Modeling, John Wiley & Sons, 1991. 943 [JCH84] R. Jain, D.M. Chiu, and W. Hawe, A Quantitative Measure of 944 Fairness and Discrimination for Resource Allocation in Shared 945 Systems, DEC TR-301, Littleton, MA: Digital Equipment 946 Corporation, 1984. 948 [JWL04] C. Jin, D. Wei, and S. Low, FAST TCP: Motivation, 949 Architecture, Algorithms, Performance, IEEE INFOCOM, March 2004. 951 [K01] F. Kelly, Mathematical Modelling of the Internet, "Mathematics 952 Unlimited - 2001 and Beyond" (Editors B. Engquist and W. 953 Schmid), Springer-Verlag, Berlin, pp. 685-702, 2001. 955 [KHR02] D. Katabi, M. Handley, and C. Rohrs, Congestion Control for 956 High Bandwidth-Delay Product Networks, ACM Sigcomm, 2002. 958 [KK03] A. Kuzmanovic and E. W. Knightly, TCP-LP: A Distributed 959 Algorithm for Low Priority Data Transfer, IEEE INFOCOM 2003, 960 April 2003. 962 [KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in 963 Communication Networks: Shadow Prices, Proportional Fairness and 964 Stability. Journal of the Operational Research Society 49, pp. 965 237-252, 1998. 967 [KS03] S. Kunniyur and R. Srikant, End-to-end Congestion Control 968 Schemes: Utility Functions, Random Losses and ECN Marks, 969 IEEE/ACM Transactions on Networking, 11(5):689-702, October 970 2003. 972 [LLS05] Y-T. Li, D. Leith, and R. Shorten, Experimental Evaluation 973 of TCP Protocols for High-Speed Networks, Hamilton Institute, 974 2005. URL "http://www.hamilton.ie/net/eval/results-HI2005.pdf". 976 [MS91] D. Mitra and J. Seery, Dynamic Adaptive Windows for High 977 Speed Data Networks with Multiple Paths and Propagation Delays, 978 INFOCOM '91, pp 39-48. 980 [MTZ04] L. Mamatas, V. Tsaoussidis, and C. Zhang, Approaches to 981 Congestion Control in Packet Networks, 2004. 983 [RFC2018] TCP Selective Acknowledgement Options. M. Mathis, J. 984 Mahdavi, D. Floyd, and A. Romanow. RFC 2018, Proposed Standard, 985 April 1996. 987 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 988 Packet Loss Metric for IPPM", RFC 2680, September 1999. 990 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 991 Connectivity", RFC 2678, September 1999. 993 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 994 Delay Metric for IPPM", RFC 2679, September 1999. 996 [RFC2681] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-Trip 997 Delay Metric for IPPM". RFC 2681, STD 1, September 1999. 999 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, 1000 September 2000. 1002 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1003 Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001. 1005 [RFC3168] K.K. Ramakrishnan, S. Floyd, and D. Black, The Addition of 1006 Explicit Congestion Notification (ECN) to IP, RFC 3168, 1007 September 2001. 1009 [RFC3357] R. Koodli and R. Ravikanth, One-way Loss Pattern Sample 1010 Metrics, RFC 3357, Informational, August 2002. 1012 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1013 Metric for IP Performance Metrics (IPPM)", RFC 3393, November 1014 2002. 1016 [RFC3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 1017 Friendly Rate Control (TFRC): Protocol Specification, RFC 3448, 1018 Proposed Standard, January 2003. 1020 [RFC3611] T. Friedman, R. Caceres, and A. Clark, RTP Control 1021 Protocol Extended Reports (RTCP XR), RFC 3611, November 2003. 1023 [RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion 1024 Control for Voice Traffic in the Internet, RFC 3714, March 2004. 1026 [RFC3782] S. Floyd, T. Henderson, and A. Gurtov, The NewReno 1027 Modification to TCP's Fast Recovery Algorithm, RFC 3782, 1028 Proposed Standard, April 2004. 1030 [RFC4737] A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. 1031 Perser, Packet Reordering Metrics, RFC 4737, November 2006. 1033 [RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, Quick- 1034 Start for TCP and IP, RFC 4782, Experimental, January 2007. 1036 [RFC4828] S. Floyd and E. Kohler, TCP Friendly Rate Control (TFRC): 1037 the Small-Packet (SP) Variant, RFC 4828, April 2007. 1039 [RX05] I. Rhee and L. Xu, CUBIC: A New TCP-Friendly High-Speed TCP 1040 Variant, PFLDnet 2005. 1042 [SAF06] P. Sarolahti, M. Allman, and S. Floyd, Determining an 1043 Appropriate Sending Rate Over an Underutilized Network Path, 1044 Computer Networks, September 2006. 1046 [SLFK03] R.N. Shorten, D.J. Leith, J. Foy, and R. Kilduff, Analysis 1047 and Design of Congestion Control in Synchronised Communication 1048 Networks. Proc. 12th Yale Workshop on Adaptive & Learning 1049 Systems, May 2003. 1051 [SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson, TCP 1052 Congestion Control with a Misbehaving Receiver, ACM Computer 1053 Communications Review, October 1999. 1055 [TM02] V. Tsaoussidis and I. Matta, Open Issues of TCP for Mobile 1056 Computing, Journal of Wireless Communications and Mobile 1057 Computing: Special Issue on Reliable Transport Protocols for 1058 Mobile Computing, February 2002. 1060 [TWL06] A. Tang, J. Wang and S. H. Low. Counter-Intuitive 1061 Throughput Behaviors in Networks Under End-to-End Control, 1062 IEEE/ACM Transactions on Networking, 14(2):355-368, April 2006. 1064 [WCL05] D. X. Wei, P. Cao and S. H. Low, Time for a TCP Benchmark 1065 Suite?, Technical Report, Caltech CS, Stanford EAS, Caltech, 1066 2005. 1068 [VKD02] A. Venkataramani, R. Kokku, and M. Dahlin, TCP Nice: A 1069 Mechanism for Background Transfers, Fifth USENIX Symposium on 1070 Operating System Design and Implementation (OSDI), 2002. 1072 [XHR04] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion 1073 Control for Fast, Long Distance Networks, Infocom 2004. 1075 [YKL01] Y. Yang, M. Kim, and S. Lam, Transient Behaviors of TCP- 1076 friendly Congestion Control Protocols, Infocom 2001. 1078 [ZKL04] Y. Zhang, S.-R. Kang, and D. Loguinov, Delayed Stability and 1079 Performance of Distributed Congestion Control, ACM SIGCOMM, 1080 August 2004. 1082 Authors' Addresses 1084 Sally Floyd 1085 ICSI Center for Internet Research 1086 1947 Center Street, Suite 600 1087 Berkeley, CA 94704 1088 USA 1090 Full Copyright Statement 1092 Copyright (C) The IETF Trust (2007). 1094 This document is subject to the rights, licenses and restrictions 1095 contained in BCP 78, and except as set forth therein, the authors 1096 retain all their rights. 1098 This document and the information contained herein are provided on 1099 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1100 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1101 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1102 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1103 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1104 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1105 FOR A PARTICULAR PURPOSE. 1107 Intellectual Property 1109 The IETF takes no position regarding the validity or scope of any 1110 Intellectual Property Rights or other rights that might be claimed 1111 to pertain to the implementation or use of the technology described 1112 in this document or the extent to which any license under such 1113 rights might or might not be available; nor does it represent that 1114 it has made any independent effort to identify any such rights. 1115 Information on the procedures with respect to rights in RFC 1116 documents can be found in BCP 78 and BCP 79. 1118 Copies of IPR disclosures made to the IETF Secretariat and any 1119 assurances of licenses to be made available, or the result of an 1120 attempt made to obtain a general license or permission for the use 1121 of such proprietary rights by implementers or users of this 1122 specification can be obtained from the IETF on-line IPR repository 1123 at http://www.ietf.org/ipr. 1125 The IETF invites any interested party to bring to its attention any 1126 copyrights, patents or patent applications, or other proprietary 1127 rights that may cover technology that may be required to implement 1128 this standard. Please address the information to the IETF at ietf- 1129 ipr@ietf.org.