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 (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
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
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