Network Working Group S. Floyd
Request for Comments: 5290 M. Allman
Category: Informational ICSI
July 2008
Comments on the Usefulness of Simple Best-Effort Traffic
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
IESG Note
The content of this RFC was at one time considered by the IETF, and
therefore it may resemble a current IETF work in progress or a
published IETF work.
This RFC is not a candidate for any level of Internet Standard. The
IETF disclaims any knowledge of the fitness of this RFC for any
purpose and notes that the decision to publish is not based on IETF
review apart from IESG review for conflict with IETF work. The RFC
Editor has chosen to publish this document at its discretion. See
RFC 3932 for more information.
Abstract
This document presents some observations on "simple best-effort
traffic", defined loosely for the purposes of this document as
Internet traffic that is not covered by Quality of Service (QOS)
mechanisms, congestion-based pricing, cost-based fairness, admissions
control, or the like. One observation is that simple best-effort
traffic serves a useful role in the Internet, and is worth keeping.
While differential treatment of traffic can clearly be useful, we
believe such mechanisms are useful as *adjuncts* to simple best-
effort traffic, not as *replacements* of simple best-effort traffic.
A second observation is that for simple best-effort traffic, some
form of rough flow-rate fairness is a useful goal for resource
allocation, where "flow-rate fairness" is defined by the goal of
equal flow rates for different flows over the same path.
Floyd & Allman Informational [Page 1]RFC 5290 Simple Best-Effort Traffic July 2008Table 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
1. Introduction
This document gives some observations on the role of simple best-
effort traffic in the Internet. For the purposes of this document,
we define "simple best-effort traffic" as 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
does not use admissions control. We define the term "simple best-
effort traffic" to avoid unproductive semantic discussions about what
the phrase "best-effort traffic" does or does not include. We note
that our definition of "simple best-effort traffic" includes traffic
that is not necessarily "simple", including mechanisms common in the
current Internet such as pairwise agreements between ISPs, volume-
based pricing, firewalls, and a wide range of mechanisms in
middleboxes.
"Simple best-effort traffic" in the current Internet uses end-to-end
transport protocols (e.g., TCP, UDP, or others), with minimal
requirements of the network in terms of resource allocation.
However, other implementations of simple best-effort service would be
possible, including those that would rely on Fair Queueing or some
other form of per-flow scheduling in congested routers. Our
intention is to define "simple best-effort traffic" to include the