RFC 5290

Comments on the Usefulness of Simple Best-Effort Traffic

📅 published July 2008, from ietf

Status of This Memo ✨

okay bestie, first things first 🎀 this memo is informational 📚, so it's giving "here are some thoughts for the internet community," not "you MUST do this." It doesn't specify an Internet standard of any kind, and distribution is unlimited, so share it with everyone 💖

IESG Note 🫶

ngl this part is kind of a disclaimer 🙈 the content was once considered by the IETF, so it might look like a current IETF work in progress or a published IETF work. But this RFC is not a candidate for any level of Internet Standard. The IETF doesn't know whether it's fit for any purpose 💀, and the decision to publish wasn't based on IETF review, apart from IESG review for conflict with IETF work. The RFC Editor chose to publish it at its discretion. For more info, check RFC 3932 📖

Abstract 🌸

okay so this doc is about "simple best-effort traffic," which is loosely defined as internet traffic that isn't covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or stuff like that 💅 the big takeaway is that simple best-effort traffic is useful and worth keeping 🦋 differential treatment can be super useful too, but the authors think those mechanisms should be adjuncts to simple best-effort traffic, not replacements of it ✨

The second observation is that for simple best-effort traffic, some rough form of flow-rate fairness is a good goal for resource allocation 🫧 Here, "flow-rate fairness" means the goal of equal flow rates for different flows over the same path. Main character energy for equal sharing 👑

Table of Contents 🗂️

1. Introduction ....................................................2
2. On Simple Best-Effort Traffic ...................................3
   2.1. The Usefulness of Simple Best-Effort Traffic ...............4
   2.2. The Limitations of Simple Best-Effort Traffic ..............4
        2.2.1. Quality of Service (QoS) ............................4
        2.2.2. The Avoidance of Congestion Collapse and the
               Enforcement of Fairness..............................6
        2.2.3. Control of Traffic Surges ...........................6
3. On Flow-Rate Fairness for Simple Best-Effort Traffic ............6
   3.1. The Usefulness of Flow-Rate Fairness .......................7
   3.2. The Limitations of Flow-Rate Fairness ......................8
        3.2.1. The Enforcement of Flow-Rate Fairness ...............8
        3.2.2. The Precise Definition of Flow-Based Fairness .......9
4. On the Difficulties of Incremental Deployment ..................11
5. Related Work ...................................................12
   5.1. From the IETF .............................................12
   5.2. From Elsewhere ............................................13
6. Security Considerations ........................................14
7. Conclusions ....................................................14
8. Acknowledgements ...............................................14
9. Informative References .........................................14

Title Block Tea ☕🎀

Okay so this RFC is called "Comments on the Usefulness of Simple Best-Effort Traffic" 💖 It was written by S. Floyd and M. Allman, both from ICSI 🧚 It's dated July 2008, and it's categorized as Informational 📚 The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFCs 🫶

1. Introduction ✨

Okay so this doc gives some observations on how simple best-effort traffic fits into the Internet 🌈 For the purposes of this doc, "simple best-effort traffic" is traffic that does not rely on the differential treatment of flows, either in routers or in policers, enforcers, or other middleboxes along the path, and that doesn't use admissions control 💅 The authors picked this term to avoid endless semantic arguments about what "best-effort traffic" does or doesn't include 🙈

Also, their definition includes traffic that isn't necessarily "simple" 😭 Stuff like pairwise agreements between ISPs, volume-based pricing, firewalls, and a whole bunch of middlebox mechanisms in the current Internet all count, lol 💀

"Simple best-effort traffic" in the current Internet uses end-to-end transport protocols (for example TCP, UDP, or others), with minimal requirements of the network in terms of resource allocation 🦋 But other implementations of simple best-effort service would be possible too, including ones that rely on Fair Queueing or some other form of per-flow scheduling in congested routers ✨ The goal is for "simple best-effort traffic" to include the dominant traffic class in the current Internet, so it's basically the main character of the internet right now 👑

Now, the contrast 🫧 Intserv- or diffserv-enabled traffic relies on differential scheduling mechanisms at congested routers, so packets from different intserv or diffserv classes get different treatment 🎀 Similarly, cost-based fairness [B07] would most likely need traffic marking (for example Explicit Congestion Notification (ECN)) at congested routers, plus policing mechanisms near the two ends of the connection to give differential treatment to packets in different flows or traffic classes 🧚 Intserv/diffserv, cost-based fairness, and congestion-based pricing could also need more complex pairwise economic relationships among Internet Service Providers (ISPs), and between end-users and ISPs 💸

So the doc's big points are these 🌸 It's important to keep the class of "simple best-effort traffic" (hopefully augmented by wider deployment of other classes of service too). And some rough form of flow-rate fairness is an appropriate goal for simple best-effort traffic 💖 The authors aren't saying flow-rate fairness is the only possible or only desirable resource allocation goal for simple best-effort traffic 🙈 They do maintain that it's an appropriate goal for simple best-effort traffic in the current Internet, which is evolving from the Internet's past of end-point congestion control 🦋

This doc was motivated by [B07], a paper called "Flow Rate Fairness: Dismantling a Religion" 😭 Its abstract says that "comparing flow rates should never again be used for claims of fairness in production networks." Bold claim, babe 💀 This doc is NOT trying to rebut [B07], answer its issues, give the "intellectual heritage" for flow-based fairness in philosophy or social science, or start an extended dialogue with its author 🙅‍♀️ It's just a separate viewpoint on some related topics ✨

2. On Simple Best-Effort Traffic 🎀

This section makes some observations on the usefulness and limitations of the class of simple best-effort traffic, compared with traffic that gets differential treatment 🫶

2.1. The Usefulness of Simple Best-Effort Traffic 💖

Okay, here are some useful things about simple best-effort traffic 🌈

Minimal technical demands on the network infrastructure: Simple best-effort traffic, as implemented in the current Internet, makes minimal technical demands on the infrastructure 😌 There are no technical requirements for scheduling, queue management, or enforcement mechanisms in routers. Zero drama 🧚

Minimal demands in terms of economic infrastructure: It also makes minimal demands in terms of economic infrastructure 💸 It relies on fairly simple pairwise economic relationships among ISPs, and between a user and its immediate ISP. In contrast, Section 4 talks about some of the difficulties in the incremental deployment of infrastructure for additional classes of service 👀

Usefulness in the real world: Simple best-effort traffic has been shown to work in the Internet for the past 20 years, however imperfectly 🎂 It has supported everything from simple file and e-mail transfer and web traffic to video and audio streaming and voice communications 📞 Literally everything, iconic 🔥

As discussed below, simple best-effort traffic is not optimal 💅 But experience in the Internet has shown there's been significant value in the mechanism of simple best-effort traffic 🦋 It generally lets all users get a portion of the resources, while still preventing congestion collapse 🫧 That's the vibe 💖

2.2. The Limitations of Simple Best-Effort Traffic 🌸

Okay now for the tea ☕ The next part is about the limitations of simple best-effort traffic 👀

2.2.1. Quality of Service (QoS) 💅

Okay bestie, some users would totally be happy to pay for more bandwidth, less delay, less jitter, or fewer packet drops 🎀. It's desirable to make room for those goals inside the Internet architecture while still keeping a sufficient amount of bandwidth for simple best-effort traffic ✨.

One of the obvious dangers of simple differential traffic treatment implementations that don't take steps to protect simple best-effort traffic is that the users with more money could starve users with less money in times of congestion 😭. There's fairly widespread agreement that this would not be a desirable goal 🙈. As a sample of the range of positions, the Internet Society's Internet 2020 Initiative, titled "The Internet is (still) for Everyone", states that "we remain committed to the openness that ensures equal access and full participation for every user" [Internet2020] 🫶.

The wide-ranging discussion of "network neutrality" in the United States includes advocates of several positions, including that of "absolute non-discrimination" (with no QoS considerations), "limited discrimination without QoS tiering" (no fees charged for higher-quality service), and "limited discrimination and tiering" (including higher fees allowed for QoS) [NetNeutral] 🌈. The proponents of "network neutrality" are opposed to charging based on content (e.g., based on applications or the content provider) 🙅‍♀️.

As the "network neutrality" discussion makes clear, lots of voices would disagree with a resource allocation goal of maximizing the combined aggregate utility (advocated in [B07a]), especially where a user's utility is measured by the user's willingness to pay 💸. "You get what you pay for" ([B07], page 5) does not appear to be the consensus goal for resource allocation in the community or in the commercial or political realms of the Internet 🙃. However, there's a reasonable agreement that higher-priced services, as an adjunct to simple best-effort traffic, can play an important role in helping to finance the Internet infrastructure 🏗️✨.

Briscoe argues for cost-fairness [B07], so that senders are made accountable for the congestion they cause 🧾. There are, of course, differences of opinion about how well cost-based fairness could be enforced, and how well it fits the commercial reality of the Internet, with [B07] presenting an optimistic view 🌸. Another point of view, e.g., from an earlier paper by Roberts titled "Internet Traffic, QoS, and Pricing", is that "many proposed schemes are overly concerned with congestion control to the detriment of the primary pricing function of return on investment" [R04] 💅.

With only simple best-effort traffic, there would be fundamental limitations to the performance that real-time applications could deliver to users 😩. In addition to the obvious needs for high bandwidth, low delay or jitter, or low packet drop rates, some applications would like a fast start-up, or to be able to resume their old high sending rate after a relatively long idle period, or to be able to rely on a call-setup procedure so that the application is not even started if network resources are not sufficient 🚀. There are severe limitations to how effectively these requirements can be accommodated by simple best-effort service in a congested environment 💀. Of course, Quality of Service architectures for the Internet have their own limitations and difficulties, as discussed in [RFC2990] and elsewhere 🧐. We're not going to discuss these difficulties further here 🤐.

2.2.2. The Avoidance of Congestion Collapse and the Enforcement of Fairness ✨

As discussed in Section 3.2 below, there are well-known problems with the enforcement of fairness and the avoidance of congestion collapse [RFC2914] with simple best-effort traffic 🥲. In the current Internet, end-to-end congestion control is relied upon to deal with these concerns; this use of end-to-end congestion control essentially requires cooperation from end-hosts 🤝.

2.2.3. Control of Traffic Surges 🌊

Simple best-effort traffic can suffer from sudden aggregate congestion from traffic surges (e.g., Distributed Denial of Service (DDoS) attacks, flash crowds), resulting in degraded performance for all simple best-effort traffic sharing the path 😱. A wide range of approaches for detecting and responding to sudden aggregate congestion in the network has been proposed and used, including deep packet inspection and rate-limiting traffic aggregates 🔍. There are many open questions about both the goals and mechanisms of dealing with aggregates within simple best-effort traffic on congested links 🤔.

3. On Flow-Rate Fairness for Simple Best-Effort Traffic 🦋

This section argues that rough flow-rate fairness is an acceptable goal for simple best-effort traffic 💜. We do not, however, claim that flow-rate fairness is necessarily an optimal fairness goal or resource allocation mechanism for simple best-effort traffic 🙏. Simple best-effort traffic and flow-rate fairness are in general not about optimality, but instead are about a low-overhead service (best-effort traffic) along with a rough, simple fairness model (flow-rate fairness) 🧸.

Within simple best-effort traffic, it would be possible to have explicit fairness mechanisms that are implemented by the end-hosts in the network (as in proportional fairness or TCP fairness), explicit fairness mechanisms enforced by the routers (as in max-min fairness with Fair Queueing), or a traffic class with no explicit fairness mechanisms at all (as in the Internet before TCP congestion control) 🧩.

This document does not address the issues about the implementation of flow-rate fairness 🙅‍♀️. In the current Internet, rough flow-rate fairness is achieved by the fact that most of the traffic in the Internet uses TCP, and most of the TCP connections in fact use conformant TCP congestion control [MAF05] 🎯. However, rough flow-rate fairness could also be achieved by the use of per-flow scheduling at congested routers [DKS89] [LLSZ96], by related router mechanisms [SSZ03], or by congestion-controlled transport protocols other than TCP 🚦. This document does not address the pros and cons of TCP-friendly congestion control, equation-based congestion control [FHPW00], or any of the myriad of other issues concerning mechanisms for approximating flow-rate fairness 📚. Le Boudec's tutorial on rate adaption, congestion control, and fairness gives an introduction to some of these issues [B00] 🌟.

3.1. The Usefulness of Flow-Rate Fairness

We note that the limitations of flow-rate fairness are many, with a long history in the literature 📜. We discuss these limitations in the next section 👀. While the benefits of simple best-effort traffic and rough flow-rate fairness are rarely discussed, this does not mean that benefits don't exist 💅. In this section, we discuss the benefits of flow-rate fairness 🎀. We note that many of the useful aspects of simple best-effort traffic discussed above also qualify as useful aspects of rough flow-rate fairness ✨. For simple best-effort traffic with rough flow-rate fairness, the quote from Winston Churchill about democracy comes to mind: "Democracy is the worst form of government except all those other forms that have been tried from time to time" [C47] 🇬🇧.

Minimal technical demands on the network infrastructure:

First, the rough flow-rate fairness for best-effort traffic provided by TCP or other transport protocols makes minimal technical demands on the infrastructure, as TCP's congestion control algorithms are wholly implemented in the end-hosts 🧠. However, mechanisms for enforcement of the flow-rate fairness would require some support from the infrastructure 🏗️.

Minimal demands in terms of economic infrastructure:

A system based on rough flow-rate fairness for simple best-effort traffic makes minimal demands in terms of economic relationships among ISPs or between users and ISPs 💖. In contrast, Section 4 discusses some of the difficulties in the incremental deployment of infrastructure for cost-based fairness or other fairness mechanisms 🧐.

Usefulness in the real world:

The current system -- based on rough flow-rate fairness and simple best-effort traffic -- has shown its usefulness in the real world 🌍✨.

Getting a share of the available bandwidth:

A system based on rough flow-rate fairness and simple best-effort traffic gives all users a reasonable chance of getting a share of the available bandwidth 🥰. This seems to be a quality that is much appreciated by today's Internet users (as discussed above) 🫶.

3.2. The Limitations of Flow-Rate Fairness

This section discusses some of the limitations of flow-rate fairness for simple best-effort traffic 🥀.

3.2.1. The Enforcement of Flow-Rate Fairness

One of the limitations of rough flow-rate fairness is the difficulty of enforcement 😮‍💨. One possibility for implementing flow-rate fairness would be an infrastructure designed from the start with a requirement for ubiquitous per-flow scheduling in routers 🏛️. However, when starting with an infrastructure such as the current Internet with best-effort traffic largely served by First-In First-Out (FIFO) scheduling in routers and a design preference for intelligence at the ends, enforcement of flow-rate fairness is difficult at best 😅. Further, a transition to an infrastructure that provides actual flow-rate fairness for best-effort traffic enforced in routers would be difficult 🚧.

A second possibility, which is largely how the current Internet is operated, would be simple best-effort traffic where most of the connections, packets, and bytes belong to connections using similar congestion-control mechanisms (in this case, those of TCP congestion control), with few if any enforcement mechanisms 🛼. Of course, when this happens, the result is a rough approximation of flow-rate fairness, with no guarantees that the simple best-effort traffic will continue to be dominated by connections using similar congestion-control mechanisms or that users or applications cannot game the system for their benefit 🎲. That is our current state of affairs 🫠. The good news is that the current Internet continues to successfully carry traffic for many users 🎉. In particular, we are not aware of reports of frequent congestion collapse, or of the Internet being dominated by severe congestion or intolerable unfairness 🙌.

A third possibility would be simple best-effort traffic with flow-rate fairness provided by the congestion control mechanisms in the transport protocols, with some level of enforcement, either in congested routers, in middleboxes, or by other mechanisms [MBFIPS01] [MF01] [SSZ03] 🔮. There seems to us to be considerable promise that incentives among the various players (ISPs, vendors, customers, standards bodies, political entities, etc.) will align somewhat, and that further progress will be made on the deployment of various enforcement mechanisms for flow-rate fairness for simple best-effort traffic 🌈✨. Of course, this is not likely to turn in to a fully reliable and ubiquitous enforcement of flow-rate fairness, or of any related fairness goals, for simple best-effort traffic, so this is not likely to be satisfactory to purists in this area 🤓. However, it may be enough to continue to encourage most systems to use standard congestion control 💜.

3.2.2. The Precise Definition of Flow-Based Fairness 🦋

okay so the second limitation of flow-based fairness is that there's seriously no consensus in research, standards, or technical communities about the precise form of flow-based fairness we should want for simple best-effort traffic 😭 this area is still very much in flux 🌊 as apps, transport protocols, and the Internet infrastructure keep evolving.

Some of the areas where people have a range of opinions about the desired goals for rough flow-based fairness for simple best-effort traffic include the following:

Granularity: what's the right fairness granularity? like, for flow-based fairness, what even counts as a 'flow'? 🤔 (this question has been explicitly posed in [RFC2309], [RFC2914], and many other places.) should fairness be judged per connection? should it account for multiple connections between a pair of end-hosts (e.g., as suggested by [RFC3124])? and if congestion control applies to each individual connection, what controls (if any) should limit the number of connections opened between a pair of end-hosts? 👀 as an example, RFC 2616 says that with HTTP 1.1, a single-user client SHOULD NOT maintain more than two persistent connections with any server or proxy [RFC2616] (Section 8.1.4). for peer-to-peer traffic, different operating systems have different caps on the maximum number of peer-to-peer connections: Windows XP Pro has a limit of ten simultaneous peer-to-peer connections, Windows XP Home (for the client) has a limit of five, and an OS X client has a limit of ten [P2P]. 💅
RTT fairness: what's the desired relationship between flow bandwidth and round-trip times, for simple best-effort traffic? ✨ as shown in Section 3.3 of [FJ92], it would be straightforward to modify TCP's congestion control algorithms so that flows with similar packet drop rates but different round-trip times would receive roughly the same throughput. this question is further studied in [HSMK98]. it's still an open question what the desired relationship between throughput and round-trip times should be for simple best-effort traffic, particularly for applications or transport protocols using some form of feedback-based congestion control 🧚
Multiple congested routers: what's the desired relationship between flow bandwidth and the number of congested routers along the path, for simple best-effort traffic? 🌸 it's well established that for TCP traffic in particular, flows that traverse multiple congested routers receive a higher packet drop rate, and therefore lower throughput, than flows with the same round-trip time that traverse only one congested router [F91]. there's also a long-standing debate between max-min fairness [HG86] and proportional fairness [KMT98], and no consensus within the research community on the desired fairness goals in this area 💀
Bursty vs. smooth traffic: what's the desired relationship between flow bandwidth and the burstiness in the sending rate of the flow? is it a goal for a bursty flow to receive the same average or maximum bandwidth as a flow with a smooth sending rate? 🎀 how does the goal depend on the time scale of the burstiness of the flow [K96]? for instance, a flow that is bursty on time scales of less than a round-trip time has different dynamics than a flow that is bursty on a time scale of seconds or minutes. ⏱️
Packets or bytes: should the rough fairness goals be in terms of packets per second or bytes per second [RFC3714]? and if the goals are in terms of bytes per second, does that include the bandwidth used by packet headers (e.g., TCP and IP headers)? 🍓
Different transport protocols: should the transport protocol used (e.g., UDP, TCP, SCTP, DCCP) or the application affect the rough fairness goals for simple best-effort traffic? 🫶
Unicast vs. multicast: what should the fairness goals be between unicast and multicast traffic [FD04] [ZOX05]? 🌈
Precision of fairness: how precise should the fairness goals be? is the precision that's possible from per-flow scheduling the right benchmark? 🎯 or is a better touchstone the rough fairness over multiple round-trip times achieved by TCP flows over FIFO scheduling? or is a goal of even more rough fairness, of an order of magnitude or more, between flows using different transport protocols the right call? 👑

There's a range of literature for each of these topics, and we haven't tried to cite it all above. rough flow-based fairness for simple best-effort traffic could evolve with a range of possibilities for fairness in terms of round-trip times, the number of congested routers, packet size, or the number of receivers per flow. (Further discussion can be found in [RFC5166].) ✨

Fairness over time: one issue raised in [B07] is how fairness should be integrated over time. for example, for simple best-effort traffic, should long flows receive less bandwidth in bits per second than short flows? 🤨 for cost-based fairness or for QoS-based traffic, it seems perfectly viable for there to be some scenarios where the cost is a function of flow or session lifetime. it also seems viable for there to be some scenarios where the cost of QoS-enabled traffic is independent of flow or session lifetime (e.g., for a private Intranet that is measured only by the bandwidth of the access link, but where any traffic sent on that Intranet is guaranteed to receive a certain QoS). 💼

however, for simple best-effort traffic, the current form of rough fairness seems acceptable, with fairness that's independent of session length. that means, in the current Internet, a user who opens a single TCP connection for ten hours might receive the same average throughput in bits per second, during that TCP connection, as a user who opens a single TCP connection for ten minutes and then goes off-line. 🕰️ similarly, a user who is online for ten hours each day might receive the same throughput in bits per second, and pay roughly the same cost, as a user who is online for ten minutes each day. that seems acceptable to us 🫶 other pricing mechanisms between users and ISPs seem acceptable also. the current Internet includes a wide range of pricing mechanisms between users and ISPs for best-effort traffic. 🌸

4. On the Difficulties of Incremental Deployment ✨

one of the advantages of simple best-effort service is that it's currently operational in the Internet, along with the rough flow-rate fairness that results from the dominance of TCP's congestion control 💖

while additional classes of service would clearly be of use in the Internet, the deployment difficulties of such mechanisms have been non-trivial [B03]. the problems of deploying interlocking changes to the infrastructure don't necessarily have an easy fix, because they stem in part from the underlying architecture of the Internet 🏗️ as explained in RFC 1958 titled "Architectural Principles of the Internet": "Fortunately, nobody owns the Internet, there is no centralized control, and nobody can turn it off" [RFC1958]. 😂 some of the difficulties of making changes in the Internet infrastructure, including the difficulties imposed by the political and economic context, have been discussed elsewhere (e.g., [CMB07]). the difficulty of making changes to the Internet infrastructure is in contrast to the comparative ease of making changes in Internet applications 📱

the difficulties of deployment for end-to-end intserv or diffserv mechanisms are well-known, having in part to do with the difficulties of deploying the required economic infrastructure [B03]. it seems likely that cost-based schemes based on re-ECN could also have a difficult deployment path, involving the deployment of ECN-marking at routers, policers at both ends of a connection, and a change in pairwise economic relationships to include a congestion metric [B07]. 💸 some infrastructure deployment problems are sufficiently difficult that they have their own working groups in the IETF [MBONED]. 🧩

5.1. From the IETF 🌷

this section talks about IETF documents relating to simple best-effort service and flow-rate fairness 🎀

RFC 896 on congestion control: Nagle's RFC 896 titled "Congestion Control in IP/TCP", from 1984, raises the issue of congestion collapse, and says that "improved handling of congestion is now mandatory" [RFC896]. RFC 896 was written in the context of a heavily loaded network, the only private TCP/IP long-haul network in existence at the time (that of Ford Motor Company, in 1984). 🚗 in addition to introducing the Nagle algorithm for minimizing the transmission of small packets in TCP, RFC 896 considers the effectiveness of ICMP Source Quench for congestion control, and comments that future gateways should be capable of defending themselves against obnoxious or malicious hosts. however, RFC 896 doesn't raise the question of fairness between competing users or flows. 🙈

RFC 2309 on unresponsive flows: RFC 2309, an Informational document from the End-to-End Research Group titled "Recommendations on Queue Management and Congestion Avoidance in the Internet" from 2000, contains the following recommendation: "It is urgent to begin or continue research, engineering, and measurement efforts contributing to the design of mechanisms to deal with flows that are unresponsive to congestion notification or are responsive but more aggressive than TCP" [RFC2309]. 🚨

RFC 2616 on opening multiple connections: RFC 2616, the standards-track document for HTTP/1.1, specifies that "clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server" (Section 8.1.4 of [RFC2616]). 🌐

RFC 2914 on congestion control principles: RFC 2914, a Best Current Practice document, from 2000 titled "Congestion Control Principles", discusses preventing congestion collapse, maintaining some form of fairness for best-effort traffic, and optimizing a flow's performance in terms of throughput, delay, and loss for the flow in question. 📚 in the discussion of fairness, RFC 2914 outlines policy issues concerning the appropriate granularity of a "flow", and acknowledges that end nodes can easily open multiple concurrent flows to the same destination. RFC 2914 also discusses open issues concerning fairness between reliable unicast, unreliable unicast, reliable multicast, and unreliable multicast transport protocols. 🧠

RFC 3714 on the amorphous problem of fairness: Section 3.3 of RFC 3714, an Informational document from the IAB (Internet Architecture Board) discussing congestion control for best-effort voice traffic, has a discussion of "the amorphous problem of fairness", covering complicating issues of packet sizes, round-trip times, application-level functionality, and the like [RFC3714]. 🌀

RFCs on QoS: there's a long history in the IETF of developing QoS mechanisms for integrated and differentiated services [RFC2212, RFC2475]. these include lower effort per-domain behaviors that could be used to protect best-effort traffic from lower-priority traffic [RFC3662]. 🛡️✨

5.2. From Elsewhere ✨

okay so this section is a quick tour of some of the big papers on best-effort traffic and on fairness between competing flows or users 📚🦋. [B07] also has its own section on fairness literature for the Internet, so go read that too bestie 💜

Fairness with AIMD 🎀: Chiu and Jain studied fairness with AIMD (Additive Increase Multiplicative Decrease) congestion control back in 1987. They found fairness is maximized when every user or flow gets an equal allocation of the bottleneck bandwidth [CJ89]. Then Van Jacobson's 1988 paper "Congestion Avoidance and Control" defined TCP's AIMD-based congestion control mechanisms [J88] 👑

Fair Queueing 🌸: The 1989 Fair Queueing paper by Demers et al. pushed Fair Queueing scheduling at routers as a way to get fair bandwidth allocation, lower delay for low-bandwidth traffic, and protection from ill-behaved sources [DKS89] 🧚

Congestion-based pricing 💅: One of the early papers on congestion-based pricing in networks is MacKie-Mason and Varian's 1993 paper "Pricing the Internet" [MV93]. It proposed a "Smart Market" to price congestion in real time, with a per-packet charge that reflects marginal congestion costs. Frank Kelly's web page at [Proportional] has citations to papers on proportional fairness, including [K97] "Charging and Rate Control for Elastic Traffic" 🌈

Other pricing papers include [SCEH96], which is partly a critique of some of the pricing proposals floating around in the literature at the time. [SCEH96] argues that usage charges have to stay at significant levels even when congestion is extremely low 🙈

6. Security Considerations ✨

This document does not propose any new mechanisms for the Internet, and so does not require any security considerations. 🫶 no notes, no risks, just vibes 💜

7. Conclusions ✨

This document represents the views of the two authors on the role of simple best-effort traffic in the Internet. 🌸

8. Acknowledgements ✨

Big thank-you energy 🫶 to Ran Atkinson, Roland Bless, Bob Briscoe, Mitchell Erblich, Ted Faber, Frank Kelly, Tim Shephard, and members of the Transport Area Working Group for giving feedback on this document. You all ate this up 💖

9. Informative References ✨

Here's the full reference list, kept exactly as written so every detail is there 📚🔥

[B00]     J.-Y. Le Boudec, Rate adaptation, Congestion Control and
          Fairness: A Tutorial, 2000.  URL
          "http://citeseer.ist.psu.edu/boudec00rate.html" or
          "http://ica1www.epfl.ch/PS_files/LEB3132.pdf".

[B03]     G. Bell, Failure to Thrive: QoS and the Culture of
          Operational Networking, Proceedings of the ACM SIGCOMM
          Workshop on Revisiting IP QoS: What Have We Learned, Why Do
          We Care?, pp. 115-120, 2003, URL
          "http://doi.acm.org/10.1145/944592.944595".

[B07]     B. Briscoe, Flow Rate Fairness: Dismantling a Religion, ACM
          SIGCOMM Computer Communication Review, V.37 N.2, April
          2007.

[B07a]    B. Briscoe, "Flow Rate Fairness: Dismantling a Religion",
          Work in Progress, July 2007.

[CJ89]    Chiu, D.-M., and Jain, R., Analysis of the Increase and
          Decrease Algorithms for Congestion Avoidance in Computer
          Networks, Computer Networks and ISDN Systems, V. 17, pp.
          1-14, 1989.  [The DEC Technical Report DEC-TR-509 was in
          1987.]

[CMB07]   kc claffy, Sascha D. Meinrath, and Scott O. Bradner, The
          (un)Economic Internet?, IEEE Internet Computing, vol. 11,
          no. 3, pp. 53--58, May 2007.  URL
          "http://www.caida.org/publications/papers/2007/ieeecon/".

[C47]     Churchill, W., speech, House of Commons, November 11, 1947.
          URL
          "http://www.askoxford.com/quotations/827?view=uk".

[DKS89]   A. Demers, S. Keshav, and S. Shenker, Analysis and
          Simulation of a Fair Queueing Algorithm, SIGCOMM, 1989.

[F91]     Floyd, S., Connections with Multiple Congested Gateways in
          Packet-Switched Networks Part 1: One-way Traffic, Computer
          Communication Review, Vol.21, No.5, October 1991.

[FD04]    F. Filali and W. Dabbous, Fair Bandwidth Sharing between
          Unicast and Multicast Flows in Best-Effort Networks,
          Computer Communications, V.27 N.4, pp. 330-344, March 2004.

[FHPW00]  Floyd, S., Handley, M., Padhye, J., and Widmer, J,
          Equation-Based Congestion Control for Unicast Applications,
          SIGCOMM, August 2000.

[FJ92]    On Traffic Phase Effects in Packet-Switched Gateways,
          Floyd, S. and Jacobson, V., Internetworking: Research and
          Experience, V.3 N.3, September 1992.

[HG86]    E. Hahne and R. Gallager, Round Robin Scheduling for Fair
          Flow Control in Data Communications Networks, IEEE
          International Conference on Communications, June 1986.

[HSMK98]  Henderson, T.R., E. Sahouria, S. McCanne, and R.H.  Katz,
          On Improving the Fairness of TCP Congestion Avoidance,
          Globecom, November 1998.

[Internet2020]
          Internet Society, An Internet 2020 Initiative: The Internet
          is (still) for Everyone, 2007.  URL "http://
          www.isoc.org/orgs/ac/cms/uploads/docs/2020_vision.pdf".

[J88]     V. Jacobson, Congestion Avoidance and Control, SIGCOMM '88,
          August 1988.

[K96]     F. Kelly, Charging and Accounting for Bursty Connections,
          In L. W. McKnight and J. P. Bailey, editors, Internet
          Economics. MIT Press, 1997.

[K97]     F. Kelly, Charging and Rate Control for Elastic Traffic,
          European Transactions on Telecommunications, 8:33--37,
          1997.

[KMT98]   F. Kelly, A. Maulloo and D. Tan, Rate Control in
          Communication Networks: Shadow Prices, Proportional
          Fairness and Stability.  Journal of the Operational
          Research Society 49, pp.  237-252, 1998.  URL
          "http://citeseer.ist.psu.edu/kelly98rate.html".

[LLSZ96]  C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang,
          Congestion Control for Best-effort Service: Why We Need a
          New Paradigm, IEEE Network, vol. 10, pp. 10-19, Jan. 1996.

[MAF05]   A. Medina, M. Allman, and S. Floyd, Measuring the Evolution
          of Transport Protocols in the Internet, Computer
          Communications Review, April 2005.

[MBFIPS01]
          R. Manajan, S. Bellovin, S. Floyd, J. Ioannidis, V.
          Paxson, and S. Shenker, Controlling High Bandwidth
          Aggregates in the Network, Computer Communications Review,
          V.32 N.3, July 2002.

[MBONED]  MBONE Deployment Working Group, URL
          "http://www.ietf.org/html.charters/mboned-charter.html".

[MF01]    Mahajan, R., and Floyd, S., Controlling High-Bandwidth
          Flows at the Congested Router, ICNP 2001, November 2001.

[MV93]    J. K. MacKie-Mason and H. Varian, Pricing the Internet, in
          the conference on Public Access to the Internet, JFK School
          of Government, May 1993.

[NetNeutral]
          Network Neutrality, Wikipedia.  URL
          "http://en.wikipedia.org/wiki/Net_neutrality".

[P2P]     "Maximum Number of Peer-to-Peer Connections", MAC OS X
          Hints web site, February 2007, URL
          "http://forums.macosxhints.com/showthread.php?t=67237".

[Proportional]
          Kelly, F., papers on Proportional Fairness.  URL
          "http://www.statslab.cam.ac.uk/~frank/pf/".

[R04]     J. Roberts, Internet Traffic, QoS, and Pricing, Proceedings
          of the IEEE, V.92 N.9, September 2004.

[RFC896]  Nagle, J., "Congestion control in IP/TCP internetworks",
          RFC 896, January 1984.

[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
          Internet", RFC 1958, June 1996.

[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
          of Guaranteed Quality of Service", RFC 2212, September
          1997.

[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
          S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
          Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S.,
          Wroclawski, J., and L. Zhang, "Recommendations on Queue
          Management and Congestion Avoidance in the Internet", RFC
          2309, April 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
          and W. Weiss, "An Architecture for Differentiated Service",
          RFC 2475, December 1998.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
          L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
          Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
          2914, September 2000.

[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC
          2990, November 2000.

[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
          RFC 3124, June 2001.

[RFC3662] Bless, R., K. Nichols, and K. Wehrle, "A Lower Effort Per-
          Domain Behavior (PDB) for Differentiated Services", RFC
          3662, December 2003.

[RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns Regarding
          Congestion Control for Voice Traffic in the Internet", RFC
          3714, March 2004.

[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion
          Control Mechanisms", RFC 5166, March 2008.

[SCEH96]  Shenker, D. D. Clark, D. Estrin, and S. Herzog, Pricing in
          Computer Networks: Reshaping the Research Agenda, ACM
          Computer Communication Review, vol. 26, April 1996.

[SSZ03]   I. Stoica, S. Shenker, and H. Zhang, Core-Stateless Fair
          Queueing: a Scalable Architecture to Approximate Fair
          Bandwidth Allocations in High-speed Networks, IEEE/ACM
          Transactions on Networking 11(1): 33-46, 2003.

[ZOX05]   Zhang, T., P. Osterberg, and Youzhi Xu, Multicast-
          favorable Max-Min Fairness - a General Definition of
          Multicast Fairness, Distributed Frameworks for Multimedia
          Applications, February 2005.

Authors' Addresses ✨

Here are the two authors' contact details, copied exactly 📮💌

Sally Floyd
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704
USA
EMail: floyd@icir.org
URL: http:/www.icir.org/floyd/

Mark Allman
International Computer Science Institute
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 235-1792
EMail: mallman@icir.org
URL: http://www.icir.org/mallman/

Full Copyright Statement ✨

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Intellectual Property ✨

okay so the IETF is NOT picking a side on whether any patents or IP rights floating around could apply to the tech in this doc 🙈 it also isn't saying whether anyone can actually get a license for them, and it hasn't gone hunting for any rights either. if you want the rules on how IPR works for RFCs, check out BCP 78 and BCP 79 📚

the IETF keeps a public IPR repository online at http://www.ietf.org/ipr 💅 that's where you'll find copies of IPR disclosures sent to the IETF Secretariat, plus any promises to make licenses available. it also has the results of anyone trying to get a general license or permission to use those proprietary rights, which is super useful if you're an implementer or user of this spec 🫶

and lowkey the IETF is literally asking everyone to speak up 📣 if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to build this standard, please tell them! send it to ietf-ipr@ietf.org 🦋 it's giving community, and it keeps the whole thing transparent, no cap 💜

📦 where this page comes from

ietf: rfc5290 2008-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms