idnits 2.17.1 draft-floyd-tsvwg-besteffort-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 929. 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 461: '...ngle-user client SHOULD NOT maintain m...' RFC 2119 keyword, line 615: '...tent connections SHOULD limit the numb...' 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 (19 May 2008) is 5820 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Floyd 3 INTERNET-DRAFT M. Allman 4 Intended status: Informational ICIR/ICSI 5 Expires: 19 November 2008 19 May 2008 7 Comments on the Usefulness of Simple Best-Effort Traffic 8 draft-floyd-tsvwg-besteffort-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 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 19 November 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document presents some observations on "simple best-effort" 42 traffic, defined loosely for the purposes of this document as 43 Internet traffic that is not covered by Quality of Service 44 mechanisms, congestion-based pricing, cost-based fairness, admissions 45 control, or the like. One observation is that simple best-effort 46 traffic serves a useful role in the Internet, and is worth keeping. 47 While differential treatment of traffic can clearly be useful, we 48 believe such mechanisms are useful as **adjuncts** to simple best- 49 effort traffic, not as **replacements** of simple best-effort 50 traffic. A second observation is that for simple best-effort 51 traffic, some form of rough flow rate fairness is a useful goal for 52 resource allocation, where "flow rate fairness" is defined by the 53 goal of equal flow rates for different flows over the same path. 55 Table of Contents 57 1. Introduction ....................................................3 58 2. On Simple Best-Effort Traffic ...................................4 59 2.1. The Usefulness of Simple Best-Effort Traffic ...............5 60 2.2. The Limitations of Simple Best-Effort Traffic ..............5 61 2.2.1. Quality of Service (QoS) ............................5 62 2.2.2. The Avoidance of Congestion Collapse and the 63 Enforcement of Fairness ....................................7 64 2.2.3. Control of Traffic Surges ...........................7 65 3. On Flow-Rate Fairness for Simple Best-Effort Traffic ............7 66 3.1. The Usefulness of Flow-Rate Fairness .......................8 67 3.2. The Limitations of Flow-Rate Fairness ......................9 68 3.2.1. The Enforcement of Flow-Rate Fairness ...............9 69 3.2.2. The Precise Definition of Flow-based Fairness ......10 70 4. On the Difficulties of Incremental Deployment ..................12 71 5. Related Work ...................................................13 72 5.1. From the IETF .............................................13 73 5.2. From Elsewhere ............................................14 74 6. Security Considerations ........................................15 75 7. IANA Considerations ............................................15 76 8. Conclusions ....................................................15 77 9. Acknowledgements ...............................................15 78 Informative References ............................................15 79 Full Copyright Statement ..........................................19 80 Intellectual Property .............................................20 82 Changes from draft-floyd-tsvwg-besteffort-03.txt: 84 * General editing, from feedback in review by Ted Faber. 86 Changes from draft-floyd-tsvwg-besteffort-02.txt: 88 * Added to the discussion of QoS. Feedback from Ran Atkinson. 90 * Minor editing. 92 Changes from draft-floyd-tsvwg-besteffort-01.txt: 94 * Added Acknowledgements, Conclusions, and some references. 96 Changes from draft-floyd-tsvwg-besteffort-00.txt: 98 * Added a sentence about peer-to-peer traffic opening many 99 simultaneous connections in a session. From Tim Shephard. 101 * Added a discussion on the control of attacks, flash crowds, and 102 the like. Feedback from Tim Shephard. 104 * Clarified the requirements of cost-based fairness in terms of the 105 economic infrastructure. From feedback from Bob Briscoe: 107 * Clarified the definition of simple best-effort traffic. 108 Feedback from Bob Briscoe. 110 * Added a citation to a paper by Jim Roberts on "Internet Traffic, 111 QoS, and Pricing". 113 * Added a discussion of whether either the transport protocol 114 (TCP vs. UDP) or the application should affect the fairness 115 goals for simple best-effort traffic. Added a discussion of the 116 precision of fairness. Feedback from Mitchell Erblich. 118 * Added a sentence to the discussion of byte vs. packet fairness 119 about the bytes in packet headers. Feedback from Mitchell Erblich. 121 1. Introduction 123 This document gives some observations on the role of simple best- 124 effort traffic in the Internet. For the purposes of this document, 125 we define "simple best-effort traffic" as traffic that does not 126 *rely* on the *differential treatment* of flows either in routers or 127 in policers, enforcers, or other middleboxes along the path, and that 128 does not use admissions control. We define the term "simple best- 129 effort traffic" to avoid unproductive semantic discussions about what 130 the phrase "best-effort traffic" does or does not include. We note 131 that our definition of "simple best-effort traffic" includes traffic 132 that is not necessarily "simple", including mechanisms common in the 133 current Internet such as pairwise agreements between ISPs, volume- 134 based pricing, firewalls, and a wide range of mechanisms in 135 middleboxes. 137 "Simple best-effort traffic" in the current Internet uses end-to-end 138 transport protocols (e.g., TCP, UDP, or others), with minimal 139 requirements of the network in terms of resource allocation. 140 However, other implementations of simple best-effort service would be 141 possible, including those that would rely on Fair Queueing or some 142 other form of per-flow scheduling in congested routers. Our 143 intention is to define "simple best-effort traffic" to include the 144 dominant traffic class in the current Internet. 146 In contrast to "simple best-effort traffic", intserv or diffserv- 147 enabled traffic relies on differential scheduling mechanisms at 148 congested routers, with packets from different intserv or diffserv 149 classes receiving different treatment. Similarly, in contrast to 150 "simple best-effort traffic", cost-based fairness [B07] would most 151 likely require the deployment of traffic marking (e.g., ECN) at 152 congested routers, along with policing mechanisms near the two ends 153 of the connection providing differential treatment for packets in 154 different flows or in different traffic classes. Intserv/diffserv, 155 cost-based fairness, and congestion-based pricing could also require 156 more complex pairwise economic relationships among Internet Service 157 Providers (ISPs), and between end-users and ISPs. 159 This document suggests that it is important to retain the class of 160 "simple best-effort traffic" (though hopefully augmented by a wider 161 deployment of other classes of service). Further, this document 162 suggests that some form of rough flow-rate fairness is an appropriate 163 goal for simple best-effort traffic. We do not argue in this 164 document that flow-rate fairness is the *only possible* or *only 165 desirable* resource allocation goal for simple best-effort traffic. 166 We maintain, however, that it is an appropriate resource allocation 167 goal for simple best-effort traffic in the current Internet, evolving 168 from the Internet's past of end-point congestion control. 170 This document was motivated by [B07], a paper on "Flow Rate Fairness: 171 Dismantling a Religion" that asserts in the abstract that "Comparing 172 flow rates should never again be used for claims of fairness in 173 production networks." This document does not attempt to be a 174 rebuttal to [B07], or to answer any or all of the issues raised in 175 [B07], or to give the "intellectual heritage" for flow-based fairness 176 in philosophy or social science, or to commit the authors of this 177 document to an extended dialogue with the author of [B07]. This 178 document is simply a separate viewpoint on some related topics. 180 2. On Simple Best-Effort Traffic 182 This section makes some observations on the usefulness and 183 limitations of the class of simple best-effort traffic, in comparison 184 with traffic receiving differential treatment. 186 2.1. The Usefulness of Simple Best-Effort Traffic 188 We now list some useful aspects of simple best-effort traffic. 190 Minimal technical demands on the network infrastructure: 192 Simple best-effort traffic, as implemented in the current 193 Internet, makes minimal technical demands on the infrastructure. 194 There are no technical requirements for scheduling, queue 195 management or enforcement mechanisms in routers. 197 Minimal demands in terms of economic infrastructure: 199 Simple best-effort traffic makes minimal demands in terms of 200 economic infrastructure, relying on fairly simple pair-wise 201 economic relationships among ISPs, and between a user and their 202 immediate ISP. In contrast, Section 4 discusses some of the 203 difficulties in the incremental deployment of infrastructure for 204 additional classes of service. 206 Usefulness in the real world: 208 Simple best-effort traffic has been shown to work in the Internet 209 for the past 20 years, however imperfectly. Simple best-effort 210 traffic has supported everything from simple file and e-mail 211 transfer and web traffic to video and audio streaming and voice 212 communications. 214 As discussed below, simple best-effort traffic is not optimal. 215 However, experience in the Internet has shown that there has been 216 significant value in the mechanism of simple best-effort traffic, 217 generally allowing all users to get a portion of the resources 218 while still preventing congestion collapse. 220 2.2. The Limitations of Simple Best-Effort Traffic 222 We now discuss some limitations of simple best-effort traffic. 224 2.2.1. Quality of Service (QoS) 226 Some users would be happy to pay for more bandwidth, less delay, less 227 jitter, or fewer packet drops. It is desirable to accommodate such 228 goals within the Internet architecture while preserving a sufficient 229 amount of bandwidth for simple best-effort traffic. 231 One of the obvious dangers of simple differential traffic treatment 232 implementations that do not take steps to protect simple best-effort 233 traffic would be that the users with more money *could* starve users 234 with less money in times of congestion. There seems to be fairly 235 widespread agreement that this would not be a desirable goal. 237 As a sample of the range of positions, the Internet Society's 238 Internet 2020 Initiative, entitled "The Internet is (still) for 239 Everyone", states that "we remain committed to the openness that 240 ensures equal access and full participation for every user" 241 [Internet2020]. 243 The wide-ranging discussion of "network neutrality" in the United 244 States includes advocates of several positions, including that of 245 "absolute non-discrimination" (with no QoS considerations), "limited 246 discrimination without QoS tiering" (no fees charged for higher- 247 quality service), and "limited discrimination and tiering" (including 248 higher fees allowed for QoS) [NetNeutral]. The proponents of 249 "network neutrality" are opposed to charging based on content (e.g., 250 based on applications, or the content provider). 252 As the "network neutrality" discussion makes clear, there are many 253 voices in the discussion that would disagree with a resource 254 allocation goal of maximizing the combined aggregate utility 255 (advocated in [B07a]), particularly where a user's utility is 256 measured by the user's willingness to pay. "You get what you pay 257 for" ([B07], page 5) does not appear to be the consensus goal for 258 resource allocation in the community or in the commercial or 259 political realms of the Internet. However, there is a reasonable 260 agreement that higher-priced services, as an adjunct to simple best- 261 effort traffic, can play an important role in helping to finance the 262 Internet infrastructure. 264 Briscoe argues for cost-fairness [B07], so that senders are made 265 accountable for the congestion they cause. There are, of course, 266 differences of opinion about how well cost-based fairness could be 267 enforced, and how well it fits the commercial reality of the 268 Internet, with [B07] presenting an optimistic view. Another point of 269 view, e.g., from an earlier paper by Roberts on "Internet Traffic, 270 QoS, and Pricing", is that "many proposed schemes are overly 271 concerned with congestion control to the detriment of the primary 272 pricing function of return on investment" [R04]. 274 With *only* simple best-effort traffic, there would be fundamental 275 limitations to the performance that real-time applications could 276 deliver to users. In addition to the obvious needs for high 277 bandwidth, low delay or jitter, or low packet drop rates, some 278 applications would like a fast start-up, or to be able to resume 279 their old high sending rate after a relatively-long idle period, or 280 to be able to rely on a call-setup procedure so that the application 281 is not even started if network resources are not sufficient. There 282 are severe limitations to how effectively these requirements can be 283 accommodated by simple best-effort service in a congested 284 environment. Of course, Quality of Service architectures for the 285 Internet have their own limitations and difficulties, as discussed in 286 [RFC2990] and elsewhere. We are not going to discuss these 287 difficulties further here. 289 2.2.2. The Avoidance of Congestion Collapse and the Enforcement of 290 Fairness 292 As discussed in Section 3.2 below, there are well-known problems with 293 the enforcement of fairness and the avoidance of congestion collapse 294 [RFC2914] with simple best-effort traffic. In the current Internet, 295 end-to-end congestion control is relied upon to deal with these 296 concerns; this use of end-to-end congestion control essentially 297 requires cooperation from end hosts. 299 2.2.3. Control of Traffic Surges 301 Simple best-effort traffic can suffer from sudden aggregate 302 congestion from traffic surges (e.g., Distributed Denial of Service 303 (DDoS) attacks, flash crowds), resulting in degraded performance for 304 all simple best-effort traffic sharing the path. A wide range of 305 approaches for detecting and responding to sudden aggregate 306 congestion in the network have been proposed and used, including deep 307 packet inspection and rate-limiting traffic aggregates. There are 308 many open questions about both the goals and mechanisms of dealing 309 with aggregates within simple best-effort traffic on congested links. 311 3. On Flow-Rate Fairness for Simple Best-Effort Traffic 313 This section argues that rough flow-rate fairness is an acceptable 314 goal for simple best-effort traffic. We do not, however, claim that 315 flow-rate fairness is necessarily an *optimal* fairness goal or 316 resource allocation mechanism for simple best-effort traffic. Simple 317 best-effort traffic and flow-rate fairness are in general not about 318 optimality, but instead are about a low-overhead service (best-effort 319 traffic) along with a rough, simple fairness model (flow-rate 320 fairness). 322 Within simple best-effort traffic, it would be possible to have 323 explicit fairness mechanisms that are implemented by the end-hosts in 324 the network (as in proportional fairness or TCP-fairness), explicit 325 fairness mechanisms enforced by the routers (as in max-min fairness 326 with Fair Queueing), or a traffic class with no explicit fairness 327 mechanisms at all (as in the Internet before TCP congestion control). 329 This document does *not* address the issues about the implementation 330 of flow-rate fairness. In the current Internet, rough flow-rate 331 fairness is achieved by the fact that *most* of the traffic in the 332 Internet uses TCP, and *most* of the TCP connections in fact use 333 conformant TCP congestion control [MAF05]. However, rough flow-rate 334 fairness could also be achieved by the use of per-flow scheduling at 335 congested routers [DKS89] [LLSZ96], by related router mechanisms 336 [SSZ03], or by congestion-controlled transport protocols other than 337 TCP. This document does not address the pros and cons of TCP- 338 friendly congestion control, equation-based congestion control 339 [FHPW00], or any of the myriad of other issues concerning mechanisms 340 for approximating flow-rate fairness. Le Boudec's tutorial on rate 341 adaption, congestion control, and fairness gives an introduction to 342 some of these issues [B00]. 344 3.1. The Usefulness of Flow-Rate Fairness 346 We note that the limitations of flow-rate fairness are many, with a 347 long history in the literature. We discuss these limitations in the 348 next section. While the benefits of simple best-effort traffic and 349 rough flow-rate fairness are rarely discussed, this does *not* mean 350 that benefits do not exist. In this section we discuss the benefits 351 of flow-rate fairness. We note that many of the useful aspects of 352 simple best-effort traffic discussed above also qualify as useful 353 aspects of rough flow-rate fairness. For simple best-effort traffic 354 with rough flow-rate fairness, the quote from Winston Churchill about 355 democracy comes to mind: "Democracy is the worst form of government 356 except all those other forms that have been tried from time to time" 357 [C47]. 359 Minimal technical demands on the network infrastructure: 361 First, the rough flow-rate fairness for best-effort traffic 362 provided by TCP or other transport protocols makes minimal 363 technical demands on the infrastructure, as TCP's congestion 364 control algorithms are wholly implemented in the end-hosts. 365 However, mechanisms for *enforcement* of the flow-rate fairness 366 *would* require some support from the infrastructure. 368 Minimal demands in terms of economic infrastructure: 370 A system based on rough flow-rate fairness for simple best-effort 371 traffic makes minimal demands in terms of economic relationships 372 among ISPs or between users and ISPs. In contrast, Section 4 373 discusses some of the difficulties in the incremental deployment 374 of infrastructure for cost-based fairness or other fairness 375 mechanisms. 377 Usefulness in the real world: 379 The current system---based on rough flow-rate fairness and simple 380 best-effort traffic---has shown its usefulness in the real world. 382 Getting a share of the available bandwidth: 384 A system based on rough flow-rate fairness and simple best-effort 385 traffic gives all users a reasonable chance of getting a share of 386 the available bandwidth. This seems to be a quality that is much 387 appreciated by today's Internet users (as discussed above). 389 3.2. The Limitations of Flow-Rate Fairness 391 This section discusses some of the limitations of flow-rate fairness 392 for simple best-effort traffic. 394 3.2.1. The Enforcement of Flow-Rate Fairness 396 One of the limitations of rough flow-rate fairness is the difficulty 397 of enforcement. One possibility for implementing flow-rate fairness 398 would be an infrastructure designed from the start with a requirement 399 for ubiquitous per-flow scheduling in routers. However, when 400 starting with an infrastructure such as the current Internet with 401 best-effort traffic largely served by First-In First-Out (FIFO) 402 scheduling in routers and a design preference for intelligence at the 403 ends, enforcement of flow-rate fairness is difficult at best. 404 Further, a transition to an infrastructure that provides actual flow- 405 rate fairness for best-effort traffic enforced in routers would be 406 difficult. 408 A second possibility, which is largely how the current Internet is 409 operated, would be simple best-effort traffic where most of the 410 connections, packets, and bytes belong to connections using similar 411 congestion-control mechanisms (in this case, those of TCP congestion 412 control), with few if any enforcement mechanisms. Of course, when 413 this happens, the result is a rough approximation of flow-rate 414 fairness, with no guarantees that the simple best-effort traffic will 415 continue to be dominated by connections using similar congestion- 416 control mechanisms or that users or applications cannot game the 417 system for their benefit. That is our current state of affairs. The 418 good news is that the current Internet continues to successfully 419 carry traffic for many users. In particular, we are not aware of 420 reports of frequent congestion collapse, or of the Internet being 421 dominated by severe congestion or intolerable unfairness. 423 A third possibility would be simple best-effort traffic with flow- 424 rate fairness provided by the congestion control mechanisms in the 425 transport protocols, with some level of enforcement, either in 426 congested routers, in middleboxes, or by other mechanisms [MBFIPS01] 427 [MF01] [SSZ03]. There seems to us to be considerable promise that 428 incentives among the various players (ISPs, vendors, customers, 429 standards bodies, political entities, etc.) will align somewhat, and 430 that further progress will be made on the deployment of various 431 enforcement mechanisms for flow-rate fairness for simple best-effort 432 traffic. Of course, this is not likely to turn in to a fully- 433 reliable and ubiquitous enforcement of flow-rate fairness, or of any 434 related fairness goals, for simple best-effort traffic, so this is 435 not likely to be satisfactory to purists in this area. However, it 436 may be enough to continue to encourage most systems to use standard 437 congestion control. 439 3.2.2. The Precise Definition of Flow-based Fairness 441 A second limitation of flow-based fairness is that there is seemingly 442 no consensus within the research, standards, or technical communities 443 about the precise form of flow-based fairness that should be desired 444 for simple best-effort traffic. This area is very much still in 445 flux, as applications, transport protocols, and the Internet 446 infrastructure evolve. 448 Some of the areas where there are range of opinions about the desired 449 goals for rough flow-based fairness for simple best-effort traffic 450 include the following: 452 * Granularity: What is the appropriate fairness granularity? That 453 is, for flow-based fairness, what is the definition of a 'flow'? 454 (This question has been explicitly posed in [RFC2309], [RFC2914], and 455 many other places.) Should fairness be assessed on a per-connection 456 basis? Should fairness take into account multiple connections 457 between a pair of end-hosts (e.g., as suggested by [RFC3124])? If 458 congestion control applies to each individual connection, what 459 controls (if any) should constrain the number of connections opened 460 between a pair of end-hosts? As an example, RFC 2616 specifies that 461 with HTTP 1.1, a single-user client SHOULD NOT maintain more than two 462 persistent connections with any server or proxy [RFC2616] (Section 463 8.1.4). For peer-to-peer traffic, different operating systems have 464 different limitations on the maximum number of peer-to-peer 465 connections; Windows XP Pro has a limit of ten simultaneous peer-to- 466 peer connections, Windows XP Home (for the client) has a limit of 467 five, and an OS X client has a limit of ten [P2P]. 469 * RTT-fairness: What is the desired relationship between flow 470 bandwidth and round-trip times, for simple best-effort traffic? As 471 shown in Section 3.3 of [FJ92], it would be straightforward to modify 472 TCP's congestion control algorithms so that flows with similar packet 473 drop rates but different round-trip times would receive roughly the 474 same throughput. This question is further studied in [HSMK98]. It 475 remains an open question what would be the desired relationship 476 between throughput and round-trip times for simple best-effort 477 traffic, particularly for applications or transport protocols using 478 some form of feedback-based congestion control. 480 * Multiple congested routers: What is the desired relationship 481 between flow bandwidth and the number of congested routers along the 482 path, for simple best-effort traffic? It is well established that 483 for TCP traffic in particular, flows that traverse multiple congested 484 routers receive a higher packet drop rate, and therefore lower 485 throughput, than flows with the same round-trip time that traverse 486 only one congested router [F91]. There is also a long-standing 487 debate between max-min fairness [HG86] and proportional fairness 488 [KMT98], and no consensus within the research community on the 489 desired fairness goals in this area. 491 * Bursty vs. smooth traffic: What is the desired relationship between 492 flow bandwidth and the burstiness in the sending rate of the flow? 493 Is it a goal for a bursty flow to receive the same average or maximum 494 bandwidth as a flow with a smooth sending rate? How does the goal 495 depend on the time scale of the burstiness of the flow [K96]? For 496 instance, a flow that is bursty on time scales of less than a round- 497 trip time has different dynamics than a flow that is bursty on a time 498 scale of seconds or minutes. 500 * Packets or bytes: Should the rough fairness goals be in terms of 501 packets per second, or in bytes per second [RFC3714]? And if the 502 fairness goals are in terms of bytes per second, does this include 503 the bandwidth used by packet headers (e.g., TCP and IP headers)? 505 * Different transport protocols: Should the transport protocol used 506 (e.g., UDP, TCP, SCTP, DCCP) or the application affect the rough 507 fairness goals for simple best-effort traffic? 509 * Unicast vs. multicast: What should the fairness goals be between 510 unicast and multicast traffic [FD04] [ZOX05]? 512 * Precision of fairness: How precise should the fairness goals be? 513 Is the precision that is possible from per-flow scheduling the right 514 benchmark? Or, is a better touchstone the rough fairness over 515 multiple round-trip times achieved by TCP flows over FIFO scheduling? 516 Or, is a goal of even more rough fairness of an order of magnitude or 517 more between flows using different transport protocols right? 518 There is a range of literature for each of these topics, and we have 519 not attempted to cite it all above. Rough flow-based fairness for 520 simple best-effort traffic could evolve with a range of possibilities 521 for fairness in terms of round-trip times, the number of congested 522 routers, packet size, or the number of receivers per flow. (Further 523 discussion can be found in [RFC5166].) 525 Fairness over time: 527 One issue raised in [B07] concerns how fairness should be integrated 528 over time. For example, for simple best-effort traffic, should long 529 flows receive less bandwidth in bits per second than short flows? 530 For cost-based fairness or for QoS-based traffic, it seems perfectly 531 viable for there to be some scenarios where the cost is a function of 532 flow or session lifetime. It also seems viable for there to be some 533 scenarios where the cost of QoS-enabled traffic is independent of 534 flow or session lifetime (e.g., for a private Intranet that is 535 measured only by the bandwidth of the access link, but where any 536 traffic sent on that Intranet is guaranteed to receive a certain 537 QoS). 539 However, for simple best-effort traffic, the current form of rough 540 fairness seems acceptable, with fairness that is independent of 541 session length. That is, in the current Internet, a user who opens a 542 single TCP connection for ten hours *might* receive the same average 543 throughput in bits per second, during that TCP connection, as a user 544 who opens a single TCP connection for ten minutes and then goes off- 545 line. Similarly, a user who is on-line for ten hours each day 546 *might* receive the same throughput in bits per second, and pay 547 roughly the same cost, as a user who is on-line for ten minutes each 548 day. That seems acceptable to us. Other pricing mechanisms between 549 users and ISPs seem acceptable also. The current Internet includes a 550 wide range of pricing mechanisms between users and ISPs for best- 551 effort traffic. 553 4. On the Difficulties of Incremental Deployment 555 One of the advantages of simple best-effort service is that it is 556 currently operational in the Internet, along with the rough flow-rate 557 fairness that results from the dominance of TCP's congestion control. 559 While additional classes of service would clearly be of use in the 560 Internet, the deployment difficulties of such mechanisms have been 561 non-trivial [B03]. The problem of deploying interlocking changes to 562 the infrastructure do not necessarily have an easy fix as they stem 563 in part from the underlying architecture of the Internet. As 564 explained in RFC 1958 on "Architectural Principles of the Internet": 565 "Fortunately, nobody owns the Internet, there is no centralized 566 control, and nobody can turn it off [RFC1958]." Some of the 567 difficulties of making changes in the Internet infrastructure, 568 including the difficulties imposed by the political and economic 569 context have been discussed elsewhere (e.g., [CMB07]). The 570 difficulty of making changes to the Internet infrastructure is in 571 contrast to the comparative ease in making changes in Internet 572 applications. 574 The difficulties of deployment for end-to-end intserv or diffserv 575 mechanisms are well-known, having in part to do with the difficulties 576 of deploying the required economic infrastructure [B03]. It seems 577 likely that cost-based schemes based on re-ECN could also have a 578 difficult deployment path, involving the deployment of ECN-marking at 579 routers, policers at both ends of a connection, and a change in 580 pairwise economic relationships to include a congestion metric [B07]. 581 Some infrastructure deployment problems are sufficiently difficult 582 that they have their own working groups in the IETF [MBONED]. 584 5. Related Work 586 5.1. From the IETF 588 This section discusses IETF documents relating to simple best-effort 589 service and flow-rate fairness. 591 RFC 896 on congestion control: Nagle's RFC 896 on "Congestion Control 592 in IP/TCP", from 1984, raises the issue of congestion collapse, and 593 says that "improved handling of congestion is now mandatory" 594 [RFC896]. RFC 896 was written in the context of a heavily-loaded 595 network, the only private TCP/IP long-haul network in existence at 596 the time (that of Ford Motor Company, in 1984). In addition to 597 introducing the Nagle algorithm for minimizing the transmission of 598 small packets in TCP, RFC 896 considers the effectiveness of ICMP 599 Source Quench for congestion control, and comments that future 600 gateways should be capable of defending themselves against obnoxious 601 or malicious hosts. However, RFC 896 does not raise the question of 602 fairness between competing users or flows. 604 RFC 2309 on unresponsive flows: RFC 2309, an Informational document 605 from the End-to-End Research Group on "Recommendations on Queue 606 Management and Congestion Avoidance in the Internet" in 2000, 607 contains the following recommendation: "It is urgent to begin or 608 continue research, engineering, and measurement efforts contributing 609 to the design of mechanisms to deal with flows that are unresponsive 610 to congestion notification or are responsive but more aggressive than 611 TCP." [RFC2309] 613 RFC 2616 on opening multiple connections: RFC 2616, the standards 614 track document for HTTP/1.1, specifies that "clients that use 615 persistent connections SHOULD limit the number of simultaneous 616 connections that they maintain to a given server" [RFC2616] (Section 617 8.1.4.). 619 RFC 2914 on congestion control principles: RFC 2914, a Best Current 620 Practice document from 2000 on "Congestion Control Principles", 621 discusses the issues of preventing congestion collapse, maintaining 622 some form of fairness for best-effort traffic, and optimizing a 623 flow's performance in terms of throughput, delay, and loss for the 624 flow in question. In the discussion of fairness, RFC 2914 outlines 625 policy issues concerning the appropriate granularity of a "flow", and 626 acknowledges that end nodes can easily open multiple concurrent flows 627 to the same destination. RFC 2914 also discusses open issues 628 concerning fairness between reliable unicast, unreliable unicast, 629 reliable multicast and unreliable multicast transport protocols. 631 RFC 3714 on the amorphous problem of fairness: Section 3.3 of RFC 632 3714, an Informational document from the IAB (Internet Architecture 633 Board) discussing congestion control for best-effort voice traffic, 634 has a discussion of "the amorphous problem of fairness", discussing 635 complicating issues of packet sizes, round-trip times, application- 636 level functionality, and the like [RFC3714]. 638 RFCs on QoS: There is a long history in the IETF of the development 639 of QoS mechanisms for integrated and differentiated services 640 [RFC2212, RFC2475]. 642 5.2. From Elsewhere 644 This section briefly mentions some of the many papers in the 645 literature on best-effort traffic or on fairness for competing flows 646 or users. [B07] also has a section on some of the literature 647 regarding fairness in the Internet. 649 Fairness with AIMD: Fairness with AIMD (Additive Increase 650 Multiplicative Decrease) congestion control was studied by Chiu and 651 Jain in 1987, where fairness is maximized when each user or flow gets 652 equal allocations of the bottleneck bandwidth [CJ89]. Van Jacobson's 653 1988 paper on "Congestion Avoidance and Control" defined TCP's AIMD- 654 based congestion control mechanisms. 656 Fair Queueing: The 1989 paper of Fair Queueing by Demers et al. 657 promoted Fair Queueing scheduling at routers as providing fair 658 allocation of bandwidth, lower delay for low-bandwidth traffic, and 659 protection from ill-behaved sources [DKS89]. 661 Congestion-based pricing: One of the early papers on congestion-based 662 pricing in networks is the 1993 paper on "Pricing the Internet" by 663 MacKie-Mason and Varian [MV93]. This paper proposed a "Smart Market" 664 to price congestion in real time, with a per-packet-charge reflecting 665 marginal congestion costs. Frank Kelly's web page at [Proportional] 666 has citations to papers on proportional fairness, including [K97] on 667 "Charging and Rate Control for Elastic Traffic". 669 Other papers on pricing in computer networks include [SCEH96], which 670 is in part a critique of some of the pricing proposals in the 671 literature at the time. [SCEH96] argues that usage charges must 672 remain at significant levels even if congestion is extremely low. 674 6. Security Considerations 676 This document does not propose any new mechanisms for the Internet, 677 and so does not require any security considerations. 679 7. IANA Considerations 681 There are no IANA considerations in this document. 683 8. Conclusions 685 This document represents the views of the two authors on the role of 686 simple best-effort traffic in the Internet. 688 9. Acknowledgements 690 We thank Ran Atkinson, Bob Briscoe, Mitchell Erblich, Ted Faber, 691 Frank Kelly, Tim Shephard, and members of the Transport Area Working 692 Group for feedback on this document. 694 Informative References 696 [B00] J.-Y. Le Boudec, Rate adaptation, Congestion Control 697 and Fairness: A Tutorial, 2000. URL 698 "http://citeseer.ist.psu.edu/boudec00rate.html" or 699 "http://ica1www.epfl.ch/PS_files/LEB3132.pdf". 701 [B03] G. Bell, Failure to Thrive: QoS and the Culture of 702 Operational Networking, Proceedings of the ACM SIGCOMM 703 Workshop on Revisiting IP QoS: What Have We Learned, 704 Why Do We Care?, pp. 115-120, 2003, URL 705 "http://doi.acm.org/10.1145/944592.944595". 707 [B07] B. Briscoe, Flow Rate Fairness: Dismantling a 708 Religion, ACM SIGCOMM Computer Communication Review, 709 V.37 N.2, April 2007. 711 [B07a] B. Briscoe, Flow Rate Fairness: Dismantling a 712 Religion, internet draft draft-briscoe-tsvarea- 713 fair-02.pdf, work-in-progress, July 2007. 715 [CJ89] Chiu, D.-M., and Jain, R., Analysis of the Increase 716 and Decrease Algorithms for Congestion Avoidance in 717 Computer Networks, Computer Networks and ISDN Systems, 718 V. 17, pp. 1-14, 1989. [The DEC Technical Report DEC- 719 TR-509 was in 1987.] 721 [CMB07] kc claffy, Sascha D. Meinrath, and Scott O. Bradner, 722 The (un)Economic Internet?, IEEE Internet Computing, 723 vol. 11, no. 3, pp. 53--58, May 2007. URL "http:// 724 www.caida.org/publications/papers/2007/ieeecon/". 726 [C47] Churchill, W., speech, House of Commons, November 11, 727 1947. URL 728 "http://www.askoxford.com/quotations/827?view=uk". 730 [DKS89] A. Demers, S. Keshav, and S. Shenker, Analysis and 731 Simulation of a Fair Queueing Algorithm, SIGCOMM, 732 1989. 734 [F91] Floyd, S., Connections with Multiple Congested 735 Gateways in Packet-Switched Networks Part 1: One-way 736 Traffic, Computer Communication Review, Vol.21, No.5, 737 October 1991. 739 [FD04] F. Filali and W. Dabbous, Fair Bandwidth Sharing 740 between Unicast and Multicast Flows in Best-Effort 741 Networks, Computer Communications, V.27 N.4, pp. 742 330-344, March 2004. 744 [FHPW00] Floyd, S., Handley, M., Padhye, J., and Widmer, J, 745 Equation-Based Congestion Control for Unicast 746 Applications, SIGCOMM, August 2000. 748 [FJ92] On Traffic Phase Effects in Packet-Switched Gateways, 749 Floyd, S. and Jacobson, V., Internetworking: Research 750 and Experience, V.3 N.3, September 1992. 752 [HG86] E. Hahne and R. Gallager, Round Robin Scheduling for 753 Fair Flow Control in Data Communications Networks, 754 IEEE International Conference on Communications, June 755 1986. 757 [HSMK98] Henderson, T.R., E. Sahouria, S. McCanne, and R.H. 758 Katz, On Improving the Fairness of TCP Congestion 759 Avoidance, Globecom, November 1998. 761 [Internet2020] Internet Society, An Internet 2020 Initiative: The 762 Internet is (still) for Everyone, 2007. URL 763 "http://www.isoc.org/orgs/ac/cms/uploads/docs/ 764 2020_vision.pdf". 766 [K96] F. Kelly, Charging and Accounting for Bursty 767 Connections, In L. W. McKnight and J. P. Bailey, 768 editors, Internet Economics. MIT Press, 1997. 770 [K97] F. Kelly, Charging and Rate Control for Elastic 771 Traffic, European Transactions on Telecommunications, 772 8:33--37, 1997. 774 [KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in 775 Communication Networks: Shadow Prices, Proportional 776 Fairness and Stability. Journal of the Operational 777 Research Society 49, pp. 237-252, 1998. URL 778 "http://citeseer.ist.psu.edu/kelly98rate.html". 780 [LLSZ96] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang, 781 Congestion Control for Best-effort Service: Why We 782 Need a New Paradigm, IEEE Network, vol. 10, pp. 10-19, 783 Jan. 1996. 785 [MAF05] A. Medina, M. Allman, and S. Floyd, Measuring the 786 Evolution of Transport Protocols in the Internet, 787 Computer Communications Review, April 2005. 789 [MBFIPS01] R. Manajan, S. Bellovin, S. Floyd, J. Ioannidis, V. 790 Paxson, and S. Shenker, Controlling High Bandwidth 791 Aggregates in the Network, Computer Communications 792 Review, V.32 N.3, July 2002. 794 [MBONED] MBONE Deployment Working Group, URL 795 "http://www.ietf.org/html.charters/mboned- 796 charter.html". 798 [MF01] Mahajan, R., and Floyd, S., Controlling High-Bandwidth 799 Flows at the Congested Router, ICNP 2001, November 800 2001. 802 [MV93] J. K. Mackie-Mason and H. Varian, Pricing the 803 Internet, in the conference on Public Access to the 804 Internet, JFK School of Government, May 1993. 806 [NetNeutral] Network Neutrality, Wikipedia. URL 807 "http://en.wikipedia.org/wiki/Net_neutrality". [Added 808 for its citations to the literature.] 810 [P2P] "Maximum Number of Peer-to-Peer Connections", MAC OS X 811 Hints web site, February 2007, URL "http:// 812 forums.macosxhints.com/showthread.php?t=67237". 814 [Proportional] Kelly, F., papers on Proportional Fairness. 816 [R04] J. Roberts, Internet Traffic, QoS and Pricing, 817 Proceedings of the IEEE, V.92 N.9, September 2004. 819 [RFC896] Nagle, J., Congestion Control in IP/TCP, RFC 896, 820 January 1984. 822 [RFC1958] B. Carpenter, Architectural Principles of the 823 Internet, RFC 1958, June 1996. 825 [RFC2212] Shenker, S., Partridge, C. and R. Guerin, 826 Specification of Guaranteed Quality of Service, RFC 827 2212, September 1997. 829 [RFC2309] B. Braden at al, Recommendations on Queue Management 830 and Congestion Avoidance in the Internet, RFC 2309, 831 April 1998. 833 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, 834 Z. and W. Weiss, An Architecture for Differentiated 835 Services, RFC 2475, December 1998. 837 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 838 Masinter, L., Leach, P. and T. Berners-Lee, Hypertext 839 Transfer Protocol -- HTTP/1.1, RFC 2616, June 1999. 841 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, 842 September 2000. 844 [RFC2990] G. Huston, "Next Steps for the IP QoS Architecture", 845 RFC 2990, November 2000. 847 [RFC3124] H. Balakrishnan and S. Seshan, The Congestion Manager, 848 RFC 3124, June 2001. 850 [RFC3714] S. Floyd, IAB Concerns Regarding Congestion Control 851 for Voice Traffic in the Internet, RFC 3714, March 852 2004. 854 [RFC5166] S. Floyd, Metrics for the Evaluation of Congestion 855 Control Mechanisms, RFC 5166, March 2008. 857 [SCEH96] Shenker, D. D. Clark, D. Estrin, and S. Herzog, 858 Pricing in Computer Networks: Reshaping the Research 859 Agenda, ACM Computer Communication Review, vol. 26, 860 April 1996. 862 [SSZ03] I. Stoica, S. Shenker, and H. Zhang, Core-Stateless 863 Fair Queueing: a Scalable Architecture to Approximate 864 Fair Bandwidth Allocations in High-speed Networks, 865 IEEE/ACM Transactions on Networking 11(1): 33-46, 866 2003. 868 [ZOX05] Zhang, T., P. Osterberg, and Youzhi Xu, Multicast- 869 favorable Max-Min Fairness - a General Definition of 870 Multicast Fairness, Distributed Frameworks for 871 Multimedia Applications, February 2005. 873 Authors' Addresses 875 Sally Floyd 876 ICSI Center for Internet Research 877 1947 Center Street, Suite 600 878 Berkeley, CA 94704 879 USA 880 Email: floyd@icir.org 881 URL: http:/www.icir.org/floyd/ 883 Mark Allman 884 International Computer Science Institute 885 1947 Center Street, Suite 600 886 Berkeley, CA 94704-1198 887 Phone: (440) 235-1792 888 Email: mallman@icir.org 889 URL: http://www.icir.org/mallman/ 891 Full Copyright Statement 893 Copyright (C) The IETF Trust (2008). 895 This document is subject to the rights, licenses and restrictions 896 contained in BCP 78, and except as set forth therein, the authors 897 retain all their rights. 899 This document and the information contained herein are provided on an 900 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 901 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 902 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 903 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 904 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 905 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 907 Intellectual Property 909 The IETF takes no position regarding the validity or scope of any 910 Intellectual Property Rights or other rights that might be claimed to 911 pertain to the implementation or use of the technology described in 912 this document or the extent to which any license under such rights 913 might or might not be available; nor does it represent that it has 914 made any independent effort to identify any such rights. Information 915 on the procedures with respect to rights in RFC documents can be 916 found in BCP 78 and BCP 79. 918 Copies of IPR disclosures made to the IETF Secretariat and any 919 assurances of licenses to be made available, or the result of an 920 attempt made to obtain a general license or permission for the use of 921 such proprietary rights by implementers or users of this 922 specification can be obtained from the IETF on-line IPR repository at 923 http://www.ietf.org/ipr. 925 The IETF invites any interested party to bring to its attention any 926 copyrights, patents or patent applications, or other proprietary 927 rights that may cover technology that may be required to implement 928 this standard. Please address the information to the IETF at ietf- 929 ipr@ietf.org.