idnits 2.17.1 draft-irtf-tmrg-metrics-00.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 592. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 560), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 August 2005) is 6821 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) == Unused Reference: 'RFC 2434' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC 2581' is defined on line 513, but no explicit reference was found in the text == Unused Reference: 'YL00' is defined on line 540, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-dccp-tfrc-voip-02 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 10 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 draft-irtf-tmrg-metrics-00.txt 17 August 2005 4 Expires: February 2006 6 Metrics for the Evaluation of Congestion Control Mechanisms 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she becomes aware will be disclosed, in accordance with 15 Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document discusses the metrics to be considered in an 42 evaluation of new or modified congestion control mechanisms for the 43 Internet. This document is intended to be the first in a series of 44 documents aimed at improving the models that we use in the 45 evaluation of transport protocols. 47 Table of Contents 49 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Throughput, Delay, and Drop Rates. . . . . . . . . . . . 5 53 3.1.1. Throughput. . . . . . . . . . . . . . . . . . . . . 5 54 3.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1.3. Packet Drop Rates . . . . . . . . . . . . . . . . . 6 56 3.2. Response Times and Minimizing Oscillations . . . . . . . 6 57 3.2.1. Response to Changes . . . . . . . . . . . . . . . . 6 58 3.2.2. Minimizing Oscillations . . . . . . . . . . . . . . 7 59 3.3. Fairness and Convergence . . . . . . . . . . . . . . . . 7 60 3.4. Robustness for Challenging Environments. . . . . . . . . 10 61 3.5. Robustness to Failures and to Misbehaving 62 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.6. Deployability. . . . . . . . . . . . . . . . . . . . . . 10 64 3.7. Metrics for Specific Types of Transport. . . . . . . . . 10 65 4. Comments on Methodology . . . . . . . . . . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 11 69 Informative References . . . . . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 71 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 14 74 1. Conventions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC 2119]. 80 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 82 Changes from draft-floyd-transport-metrics-00.txt: 84 * Added metrics for: 85 - robustness in challenging environments, 86 - deployability, 87 - robustness to failures and to misbehaving users 89 * Added a discussion of fairness and packet size. 91 2. Introduction 93 As a step towards improving our methodologies for evaluating 94 congestion control mechanisms, in this document we discuss some of 95 the metrics to be considered. We also consider the relationship 96 between metrics, e.g., the well-known tradeoff between throughput 97 and delay. 99 Subsequent documents will discuss the models that are used in 100 analysis, simulations, or experiments for the evaluation of 101 transport protocols in general, and of congestion control mechanisms 102 in particular. These are intended to become documents in the newly- 103 chartered Transport Modeling Research Group (TMRG) in the IRTF 104 (Internet Research Task Force). 106 3. Metrics 108 The metrics that we discuss are the following: 110 o Throughput; 112 o Delay; 114 o Packet drop rates; 116 o Response to sudden changes or to transient events; 118 o Minimizing oscillations in throughput or in delay; 119 o Fairness and convergence times; 121 o Robustness for challenging environments; 123 o Robustness to failures and to misbehaving users; 125 o Deployability; 127 o Metrics for specific types of transport. 129 We consider each of these below. Many of the metrics have both 130 network-based and user-based interpretations. For some of the 131 metrics, such as fairness between flows, there is not a clear 132 agreement in the network community about the desired goals. 134 3.1. Throughput, Delay, and Drop Rates 136 Because of the clear tradeoffs between throughput, delay, and drop 137 rates, it can be useful to consider the three metrics together. 139 An alternative would be to consider a separate metric such as power, 140 defined in this context as throughput over delay, that combines 141 throughput and delay. However, we do not propose in this document a 142 clear target in terms of the tradeoffs between throughput and delay; 143 we are simply proposing that the evaluation of transport protocols 144 include an exploration of the competing metrics. 146 3.1.1. Throughput 148 Throughput can be measured both as a router-based metric of 149 aggregate link throughput, and as a user metric of per-connection 150 transfer times. It is a clear goal of most congestion control 151 mechanisms to maximize throughput, subject to application demand and 152 to the constraints of the other metrics. We note that maximizing 153 throughput is of concern in a wide range of environments, from 154 highly-congested networks to under-utilized ones. 156 In some contexts, it might be sufficient to consider the aggregate 157 throughput or the mean per-flow throughput, while in other contexts 158 it might be necessary to consider the distribution of per-flow 159 throughput. Some researchers evaluate transport protocols in terms 160 of maximizing the aggregate user utility, where a user's utility is 161 generally defined as a function of the user's throughput [KMT98]. 163 Individual applications can have application-specific needs in terms 164 of throughput. For example, real-time video traffic can have highly 165 variable bandwidth demands; VoIP traffic is sensitive to the amount 166 of bandwidth received immediately after idle periods. Thus, user 167 metrics for throughput can be more complex than simply the per- 168 connection transfer time. 170 3.1.2. Delay 172 Like throughput, delay can be measured as a router-based metric of 173 queueing delay over time, or in terms of per-packet transfer times. 174 For reliable transfer, the per-packet transfer time includes the 175 possible delay of retransmitting a dropped packet. 177 Users of bulk data transfer applications might care about per-packet 178 transfer times only in so far as they affect the per-connection 179 transfer time. On the other end of the spectrum, for users of 180 streaming media, per-packet delay can be a significant concern. 181 Note that in some cases the average delay might not capture the 182 metric of interest to the users; for example, some users might care 183 about the worst-case delay, or about the tail of the delay 184 distribution. 186 3.1.3. Packet Drop Rates 188 Packet drop rates can be measured as a network-based or as a user- 189 based metric. 191 Some users might care about packet drop rates only in so far as they 192 affect per-connection transfer times, while other users might care 193 about packet drop rates directly. One network-related reason to 194 avoid high steady-state packet drop rates is to avoid congestion 195 collapse in environments containing paths with multiple congested 196 links. In such environments, high packet drop rates could result in 197 congested links wasting scarce bandwidth by carrying packets that 198 will only be dropped downstream, before being delivered to the 199 receiver. 201 3.2. Response Times and Minimizing Oscillations 203 In this section we consider response times and oscillations 204 together, as there are well-known tradeoffs between improving 205 response times and minimizing oscillations. In addition, the 206 scenarios that illustrate the dangers of poor response times are 207 often quite different from the scenarios that illustrate the dangers 208 of unnecessary oscillations. 210 3.2.1. Response to Changes 212 One of the key concerns in the design of congestion control 213 mechanisms has been the response times to sudden congestion in the 214 network. On the one hand, congestion control mechanisms should 215 respond reasonably promptly to sudden congestion from routing or 216 bandwidth changes, or from a burst of competing traffic. At the 217 same time, congestion control mechanisms should not respond too 218 severely to transient changes, e.g., to a sudden increase in delay 219 that will dissipate in less than the connection's round-trip time. 221 Evaluating the response to sudden or transient changes can be of 222 particular concern for slowly-responding congestion control 223 mechanisms such as equation-based congestion control [RFC 3448], and 224 for AIMD (Additive Increase Multiplicative Decrease) or related 225 mechanisms using parameters that make them more slowly-responding 226 that TCP [BB01, BBFS01]. 228 In addition to the responsiveness and smoothness of aggregate 229 traffic, one can consider the tradeoffs between responsiveness, 230 smoothness, and aggressiveness for an individual connection [FHP00]. 231 In this case smoothness can be defined by the largest reduction in 232 the sending rate in one round-trip time, in a deterministic 233 environment with a packet drop exactly every 1/p packets. The 234 responsiveness is defined as the number of round-trip times of 235 sustained congested required for the sender to halve the sending 236 rate, and the aggressiveness is defined as the maximum increase in 237 the sending rate in one round-trip time, in packets per second, in 238 the absence of congestion. 240 3.2.2. Minimizing Oscillations 242 One goal is that of stability, in terms of minimizing oscillations 243 of queueing delay or of throughput. Scenarios illustrating 244 oscillations are often dominated by long-lived connections, perhaps 245 with a small number of changes in the level of congestion. 247 An orthogonal goal for some congestion control mechanisms, e.g., for 248 equation-based congestion control, is to minimize the oscillations 249 in the sending rate for an individual connection, given an 250 environment with a fixed, steady-state packet drop rate. (As is 251 well known, TCP congestion control is characterized by a pronounced 252 oscillation in the sending rate, with the sender halving the sending 253 rate in response to congestion.) One metric for the level of 254 oscillations is the smoothness metric given above. 256 3.3. Fairness and Convergence 258 Another set of metrics are those of fairness and of convergence 259 times. Fairness can be considered between flows of the same 260 protocol, and between flows using different protocols (e.g., 261 fairness between TCP and a new transport protocol). 263 There are a number of different fairness measures. These include 264 max-min fairness [HG86], proportional fairness [KMT98, K01], the 265 fairness index proposed in [JCH84], and the product measure, a 266 variant of network power [BJ81]. 268 Max-min fairness: In order to satisfy the max-min fairness criteria, 269 the smallest throughput rate must be as large as possible. Given 270 this condition, the next-smallest throughput rate must be as large 271 as possible, and so on. Thus, the max-min fairness gives absolute 272 priority to the smallest flows. 274 Epsilon-fairness: A metric related to max-min fairness is epsilon- 275 fairness, where a rate allocation is defined as epsilon-fair if 277 min_i x_i / max_i x_i >= 1 - epsilon. 279 where x_i is the resource allocation to the i-th user. Epsilon- 280 fairness measures the worst-case ratio between any two throughput 281 rates [ZKL04]. 283 Proportional fairness: In contrast, an allocation x is defined as 284 proportionally fair if for any other feasible allocation x*, the 285 aggregate of proportional changes is zero or negative: 287 sum_i (x*_i - x_i)/x_i <= 0. 289 "This criterion favours smaller flows, but less emphatically than 290 max-min fairness" [K01]. 292 Jain's fairness index: The fairness index in [JCH84] is 294 (( sum_i x_i )^2) / (n * sum_i (x_i)^2 ) , 296 where there are n users. This fairness index ranges from 0 to 1, 297 and is maximum when all users receive the same allocation. This 298 index is k/n when k users equally share the resource, and the other 299 n-k users receive zero allocation. 301 The product measure: The product measure 303 product_i x_i , 305 the product of the throughput of the individual connections, is also 306 used as a measure of fairness. For our purposes, let x_i be the 307 throughput for the i-th connection. (In other contexts x_i is taken 308 as the power of the i-th connection, and the product measure is 309 referred to as network power.) The product measure is particularly 310 sensitive to segregation; the product measure is zero if any 311 connection receives zero throughput. In [MS90] it is shown that for 312 a network with many connections and one shared gateway, the product 313 measure is maximized when all connections receive the same 314 throughput. 316 Fairness and the number of congested links: Some of these fairness 317 metrics are discussed in more detail in [F91]. We note that there 318 is not a clear consensus for the fairness goals, in particular for 319 fairness between flows that traverse different numbers of congested 320 links [F91]. 322 Fairness and round-trip times: One goal cited in a number of new 323 transport protocols has been that of fairness between flows with 324 different round-trip times [KHR02, XHR04]. We note that there is not 325 a consensus in the networking community about the desirability of 326 this goal, or about the implications and interactions between this 327 goal and other metrics [FJ92] (Section 3.3). 329 Fairness and packet size: One fairness issue is that of the relative 330 fairness for flows with different packet sizes. Many file transfer 331 applications will use the maximum packet size possible; in 332 contrast, low-bandwidth VoIP flows are likely to send small packets, 333 sending a new packet every 10 to 40 ms., to limit delay. Should a 334 small-packet VoIP connection receive the same sending rate in bytes 335 per second as a large-packet TCP connection in the same environment, 336 or should it receive the same sending rate in *packets* per second? 337 This fairness issue has been discussed in more detail in [FK04], 338 with [FK05] also describing the ways that packet size can effect the 339 packet drop rate experienced by a flow. 341 Convergence times: Convergence times concern the time for 342 convergence to fairness between an existing flow and a newly- 343 starting one, and are a special concern for environments with high- 344 bandwidth flows. As with fairness, convergence times can matter 345 both between flows of the same protocol, and between flows using 346 different protocols [SLFK03]. 348 One metric used for convergence times is the delta-fair convergence 349 time, defined as the time taken for two flows with the same round- 350 trip time to go from shares of 100/101-th and 1/101-th of the link 351 bandwidth, to having close to fair sharing with shares of 352 (1+delta)/2 and (1-delta)/2 of the link bandwidth [BBFS01]. A 353 similar metric for convergence times measures the convergence time 354 as the number of round-trip times for two flows to reach epsilon- 355 fairness, when starting from a maximally-unfair state [ZKL04]. ' 357 3.4. Robustness for Challenging Environments 359 While congestion control mechanisms are generally evaluated first 360 over environments with static routing in a network of two-way point- 361 to-point links, some environments bring up more challenging problems 362 (e.g., corrupted packets, variable bandwidth, mobility) as well as 363 new metrics to be considered (e.g., energy consumption). 365 Robustness for challenging environments: Robustness needs to be 366 explored for paths with reordering, corruption, variable bandwidth, 367 asymmetric routing, router configuration changes, mobility, and the 368 like. In general, Internet architecture has valued robustness over 369 efficiency, e.g., when there are tradeoffs between robustness and 370 the throughput, delay, and fairness metrics described above. 372 Energy consumption: In mobile environments the energy consumption 373 for the mobile end-node can be a key metric that is affected by the 374 transport protocol [TM02]. 376 Goodput: For wireless networks, goodput can be a useful metric, 377 where goodput is defined as the fraction of useful data from all of 378 the data delivered. High goodput indicates an efficient use of the 379 radio spectrum and lower interference to other users [GF04]. 381 3.5. Robustness to Failures and to Misbehaving Users 383 One goal is for congestion control mechanisms to be robust to 384 misbehaving users, such as receivers that `lie' to data senders 385 about the congestion experienced along the path or otherwise attempt 386 to bypass the congestion control mechanisms of the sender [SCWA99]. 387 Another goal is for congestion control mechanisms to be as robust as 388 possible to failures, such as failures of routers in using explicit 389 feedback to end-nodes or failures of end-nodes to follow the 390 prescribed protocols, 392 3.6. Deployability 394 One metric for congestion control mechanisms is their deployability 395 in the current Internet. Metrics related to deployability include 396 the ease of failure diagnosis, and the overhead in terms of packet 397 header size or added complexity at end-nodes or routers. 399 3.7. Metrics for Specific Types of Transport 401 In some cases modified metrics are needed for evaluting transport 402 protocols intended for QoS-enabled environments or for below-best- 403 effort traffic [VKD02, KK03]. 405 4. Comments on Methodology 407 The types of scenarios that are used to test specific metrics, and 408 the range of parameters that it is useful to consider, will be 409 discussed in separate documents, e.g., along with specific scenarios 410 for use in evaluating congestion control mechanisms. 412 We note that it can be important to evaluate metrics over a wide 413 range of environments, with a range of link bandwidths, congestion 414 levels, and levels of statistical multiplexing. It is also 415 important to evaluate congestion control mechanisms in a range of 416 scenarios, including typical ranges of connection sizes and round- 417 trip times [FK02]. It is also useful to compare metrics for new or 418 modified transport protocols with those of the current standards for 419 TCP. 421 More general references on methodology include [J91]. 423 5. Security Considerations 425 There are no security considerations in this document. 427 6. IANA Considerations 429 There are no IANA considerations in this document. 431 7. Acknowledgements 433 Thanks to Doug Leith for feedback. 435 Informative References 437 [BB01] D. Bansal and H. Balakrishnan, Binomial Congestion Control 438 Algorithms, IEEE Infocom, April 2001. 440 [BBFS01] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, 441 Dynamic Behavior of Slowly-Responsive Congestion Control 442 Algorithms, SIGCOMM 2001. 444 [BJ81] K. Bharath-Kumar and J. Jeffrey, A New Approach to 445 Performance-Oriented Flow Control, IEEE Transactions on 446 Communications, Vol.COM-29 N.4, April 1981. 448 [F91] S. Floyd, Connections with Multiple Congested Gateways in 449 Packet-Switched Networks Part 1: One-way Traffic, Computer 450 Communication Review, Vol.21, No.5, October 1991, p. 30-47. 452 [FK05] S. Floyd and E. Kohler, TFRC for Voice: the VoIP Variant, 453 draft-ietf-dccp-tfrc-voip-02.txt, internet draft, work in 454 progress, July 2005. 456 [FHP00] S. Floyd, M. Handley, and J. Padhye, A Comparison of 457 Equation-Based and AIMD Congestion Control, May 2000. URL 458 "http://www.icir.org/tfrc/". 460 [FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in Packet- 461 Switched Gateways, Internetworking: Research and Experience, V.3 462 N.3, September 1992, p.115-156. 464 [FK04] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion 465 Control for Voice Traffic in the Internet, RFC 3714, March 2004. 467 [FK02] S. Floyd and E. Kohler, Internet Research Needs Better 468 Models, Hotnets-I. October 2002. 470 [GF04] A. Gurtov and S. Floyd, Modeling Wireless Links for Transport 471 Protocols, ACM CCR, 34(2):85-96, April 2004. 473 [HG86] E. Hahne and R. Gallager, Round Robin Scheduling for Fair 474 Flow Control in Data Communications Networks, IEEE International 475 Conference on Communications, June 1986. 477 [J91] R. Jain, The Art of Computer Systems Performance Analysis: 478 Techniques for Experimental Design, Measurement, Simulation, and 479 Modeling, John Wiley & Sons, 1991. 481 [JCH84] R. Jain, D.M. Chiu, and W. Hawe, A Quantitative Measure of 482 Fairness and Discrimination for Resource Allocation in Shared 483 Systems, DEC TR-301, Littleton, MA: Digital Equipment 484 Corporation, 1984. 486 [K01] F. Kelly, Mathematical Modelling of the Internet, "Mathematics 487 Unlimited - 2001 and Beyond" (Editors B. Engquist and W. 488 Schmid), Springer-Verlag, Berlin, pp. 685-702, 2001. 490 [KHR02] D. Katabi, M. Handley, and C. Rohrs, Congestion Control for 491 High Bandwidth-Delay Product Networks, ACM Sigcomm, 2002. 493 [KK03] A. Kuzmanovic and E. W. Knightly, TCP-LP: A Distributed 494 Algorithm for Low Priority Data Transfer, IEEE INFOCOM 2003, 495 April 2003. 497 [KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in 498 Communication Networks: Shadow Prices, Proportional Fairness and 499 Stability. Journal of the Operational Research Society 49, pp. 501 237-252, 1998. 503 [MS90] D. Mitra and J. Seery, Dynamic Adaptive Windows for High 504 Speed Data Networks: Theory and Simulations, ATT Bell 505 Laboratories report, April 1990. 507 [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate 508 Requirement Levels. RFC 2119. 510 [RFC 2434] T. Narten and H. Alvestrand. Guidelines for Writing an 511 IANA Considerations Section in RFCs. RFC 2434. 513 [RFC 2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 514 Control. RFC 2581. 516 [RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 517 Friendly Rate Control (TFRC): Protocol Specification, RFC 3448, 518 Proposed Standard, January 2003. 520 [SLFK03] R.N. Shorten, D.J. Leith, J. Foy, and R. Kilduff, Analysis 521 and Design of Congestion Control in Synchronised Communication 522 Networks. Proc. 12th Yale Workshop on Adaptive & Learning 523 Systems, May 2003. 525 [SCWA99] TCP Congestion Control with a Misbehaving Receiver, ACM 526 Computer Communications Review, October 1999. 528 [TM02] V. Tsaoussidis and I. Matta, Open Issues of TCP for Mobile 529 Computing, Journal of Wireless Communications and Mobile 530 Computing: Special Issue on Reliable Transport Protocols for 531 Mobile Computing, February 2002. 533 [VKD02] A. Venkataramani, R. Kokku, and M. Dahlin, TCP Nice: A 534 Mechanism for Background Transfers, Fifth USENIX Symposium on 535 Operating System Design and Implementation (OSDI), 2002. 537 [XHR04] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion 538 Control for Fast, Long Distance Networks, Infocom 2004. 540 [YL00] Y. R. Yang and S. S. Lam, General AIMD Congestion Control, 541 Technical Report TR-00-09, Department of Computer Sciences, UT 542 Austin, May 2000. 544 [ZKL04] Y. Zhang, S.-R. Kang, and D. Loguinov, Delayed Stability and 545 Performance of Distributed Congestion Control, ACM SIGCOMM, 546 August 2004. 548 Authors' Addresses 550 Sally Floyd 551 ICSI Center for Internet Research 552 1947 Center Street, Suite 600 553 Berkeley, CA 94704 554 USA 556 Full Copyright Statement 558 Copyright (C) The Internet Society 2005. This document is subject 559 to the rights, licenses and restrictions contained in BCP 78, and 560 except as set forth therein, the authors retain all their rights. 562 This document and the information contained herein are provided on 563 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 564 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 565 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 566 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 567 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 568 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 570 Intellectual Property 572 The IETF takes no position regarding the validity or scope of any 573 Intellectual Property Rights or other rights that might be claimed 574 to pertain to the implementation or use of the technology described 575 in this document or the extent to which any license under such 576 rights might or might not be available; nor does it represent that 577 it has made any independent effort to identify any such rights. 578 Information on the procedures with respect to rights in RFC 579 documents can be found in BCP 78 and BCP 79. 581 Copies of IPR disclosures made to the IETF Secretariat and any 582 assurances of licenses to be made available, or the result of an 583 attempt made to obtain a general license or permission for the use 584 of such proprietary rights by implementers or users of this 585 specification can be obtained from the IETF on-line IPR repository 586 at http://www.ietf.org/ipr. 588 The IETF invites any interested party to bring to its attention any 589 copyrights, patents or patent applications, or other proprietary 590 rights that may cover technology that may be required to implement 591 this standard. Please address the information to the IETF at ietf- 592 ipr@ietf.org.