Congestion Control Principles
RFC 2914

Document Type RFC - Best Current Practice (September 2000; No errata)
Updated by RFC 7141
Also known as BCP 41
Author Sally Floyd 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2914 (Best Current Practice)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         S. Floyd
Request for Comments: 2914                                       ACIRI
BCP: 41                                                 September 2000
Category: Best Current Practice

                     Congestion Control Principles

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


   The goal of this document is to explain the need for congestion
   control in the Internet, and to discuss what constitutes correct
   congestion control.  One specific goal is to illustrate the dangers
   of neglecting to apply proper congestion control.  A second goal is
   to discuss the role of the IETF in standardizing new congestion
   control protocols.

1.  Introduction

   This document draws heavily from earlier RFCs, in some cases
   reproducing entire sections of the text of earlier documents
   [RFC2309, RFC2357].  We have also borrowed heavily from earlier
   publications addressing the need for end-to-end congestion control

2.  Current standards on congestion control

   IETF standards concerning end-to-end congestion control focus either
   on specific protocols (e.g., TCP [RFC2581], reliable multicast
   protocols [RFC2357]) or on the syntax and semantics of communications
   between the end nodes and routers about congestion information (e.g.,
   Explicit Congestion Notification [RFC2481]) or desired quality-of-
   service (diff-serv)).  The role of end-to-end congestion control is
   also discussed in an Informational RFC on "Recommendations on Queue
   Management and Congestion Avoidance in the Internet" [RFC2309].  RFC
   2309 recommends the deployment of active queue management mechanisms
   in routers, and the continuation of design efforts towards mechanisms

Floyd, ed.               Best Current Practice                  [Page 1]
RFC 2914             Congestion Control Principles        September 2000

   in routers to deal with flows that are unresponsive to congestion
   notification.  We freely borrow from RFC 2309 some of their general
   discussion of end-to-end congestion control.

   In contrast to the RFCs discussed above, this document is a more
   general discussion of the principles of congestion control.  One of
   the keys to the success of the Internet has been the congestion
   avoidance mechanisms of TCP.  While TCP is still the dominant
   transport protocol in the Internet, it is not ubiquitous, and there
   are an increasing number of applications that, for one reason or
   another, choose not to use TCP.  Such traffic includes not only
   multicast traffic, but unicast traffic such as streaming multimedia
   that does not require reliability; and traffic such as DNS or routing
   messages that consist of short transfers deemed critical to the
   operation of the network.  Much of this traffic does not use any form
   of either bandwidth reservations or end-to-end congestion control.
   The continued use of end-to-end congestion control by best-effort
   traffic is critical for maintaining the stability of the Internet.

   This document also discusses the general role of the IETF in the
   standardization of new congestion control protocols.

   The discussion of congestion control principles for differentiated
   services or integrated services is not addressed in this document.
   Some categories of integrated or differentiated services include a
   guarantee by the network of end-to-end bandwidth, and as such do not
   require end-to-end congestion control mechanisms.

3.  The development of end-to-end congestion control.

3.1.  Preventing congestion collapse.

   The Internet protocol architecture is based on a connectionless end-
   to-end packet service using the IP protocol.  The advantages of its
   connectionless design, flexibility and robustness, have been amply
   demonstrated.  However, these advantages are not without cost:
   careful design is required to provide good service under heavy load.
   In fact, lack of attention to the dynamics of packet forwarding can
   result in severe service degradation or "Internet meltdown".  This
   phenomenon was first observed during the early growth phase of the
   Internet of the mid 1980s [RFC896], and is technically called
   "congestion collapse".

   The original specification of TCP [RFC793] included window-based flow
   control as a means for the receiver to govern the amount of data sent
   by the sender.  This flow control was used to prevent overflow of the
   receiver's data buffer space available for that connection.  [RFC793]

Floyd, ed.               Best Current Practice                  [Page 2]
RFC 2914             Congestion Control Principles        September 2000
Show full document text