Comments on the Usefulness of Simple Best-Effort Traffic
RFC 5290

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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 2008

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

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