Network Working Group M. Welzl
Internet-Draft University of Innsbruck
Expires: January 2, 2007 W. Eddy
Verizon Federal Network Systems
July 2006
Congestion Control in the RFC Series
draft-irtf-iccrg-cc-rfcs-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document is a survey of congestion control topics within the RFC
series. The intent of this document is to be an informational
snapshot of the current state of Internet standards and other IETF
products related to congestion control. This is an initial product
of the IRTF's Internet Congestion Control Research Group and may be
used as one reference or starting point for the future work of the
research group.
Welzl & Eddy Expires January 2, 2007 [Page 1]
Internet-Draft Congestion Control RFCs July 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architectural Documents . . . . . . . . . . . . . . . . . . . 5
3. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 7
4. Challenging Link and Path Characteristics . . . . . . . . . . 8
5. Explicit Congestion Notification . . . . . . . . . . . . . . . 10
6. Non-TCP Unicast Congestion Control . . . . . . . . . . . . . . 12
7. Multicast Congestion Control . . . . . . . . . . . . . . . . . 15
8. Historic Interest . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 25
Welzl & Eddy Expires January 2, 2007 [Page 2]
Internet-Draft Congestion Control RFCs July 2006
1. Introduction
In this document, we define congestion control as the feedback-based
adjustment of the rate at which data is sent into the network.
Congestion control is an indispensible set of principles and
mechanisms for maintaining the stability of the Internet. Congestion
control has been closely associated with TCP since Van Jacobson's
work in 1988 [Jac88], but there has also been a great deal of
congestion control work outside of TCP (e.g. for real-time multimedia
applications, multicast, and router-based mechanisms). Several such
proposals have been produced within the IETF and published as RFCs,
along with RFCs that give architectural guidance (e.g. by pointing
out the importance of performing some form of congestion control).
Several of these mechanisms are in use within the Internet.
When designing a new Internet protocol, it is therefore important to
not only understand how congestion control works in TCP but also have
a broader understanding of congestion control and know about other
related RFCs -- some of them give guidance, some of them describe
mechanisms which may have a direct influence on a newly designed
protocol, and some of them may only be "related work" worth knowing
about. The purpose of this document is to facilitate and encourage
this search for knowledge by providing an overview of RFCs related to
congestion control that have been published thus far. This document
is a product of the IRTF's Internet Congestion Control Research Group
(ICCRG) as a strong grasp of the existing literature should benefit
further ICCRG work. The format of this document is similar to an
annotated bibliography. Although host and router requirements for
congestion control functions are discussed, this is only an
informational document and does not contain any formal standards
bearing of its own.
Congestion control is a large and active topic, and so the scope of
this document is limited to published RFCs and a small number of
current working group drafts. This allows the document to focus on
congestion control principles and mechanisms that in some sense are
more well-known, well-accepted, or widely-used. Significant
contributions to this subject also exist in both the academic
literature and in the form of individual submission Internet-drafts,
however we exclude these from this study. In many cases the RFC
describing some mechanism will contain references to relevent
academic publications in journals or conference proceedings that
presented the research and validation of the mechanism. For
instance, RFC 2581 cites Jacobson's 1988 SIGCOMM paper that has a
less standards-oriented but more illustrative treatment and
explanation of some of the mechanisms in RFC 2581.
The majority of the documents discussed here pertain to end-host
Welzl & Eddy Expires January 2, 2007 [Page 3]
Internet-Draft Congestion Control RFCs July 2006
based congestion control. Many network-based mechanisms, such as a
number of queue management algorithms, do not require any protocol
exchanges between elements, but merely operate within a single host.
Thus, network-based congestion control mechanisms have often not been
described in any RFC, as they generally fall under the domain of
implementation details that do not influence interoperability.
We specifically do not include the vast amount of quality of service
(QoS) work into the scope of this document, as it is a full field in
its own right, and deals with issues that are mostly orthogonal to
end-host congestion control and router queue management. Scheduling
mechanisms used to implement QoS (on either per-flow or an aggregate
basis), for instance, can be used independently of the end-host
congestion control and queue management functions also in use.
Similar arguments can be made for traffic-shaping, admission control,
and other functions that are topical to QoS, and only side-notes for
congestion control.
To organize the subject matter in this document, the content is
classified into several broad categories. First, we list documents
relating to Internet architecture and general architectural concepts
in Section 2. Next, the congestion control algorithms used in the
TCP transport protocol are discussed in Section 3. Discussion of the
interactions between link properties and mechanisms with the kinds of
algorithms and heuristics used within TCP congestion control is
contained in Section 4. One method that has been developed by the
IETF (and deployed to some extent) for allowing network-based and
host-based congestion control to interact without dropping packets is
the subject of Section 5. The congestion control algorithms used by
unicast transport protocols other than TCP are described in
Section 6. Work that has been done on congestion control for
multicast transports and applications is listed in Section 7.
Finally, documents that have historic significance, but perhaps not
current direct technical application have been classified into
Section 8.
Welzl & Eddy Expires January 2, 2007 [Page 4]
Internet-Draft Congestion Control RFCs July 2006
2. Architectural Documents
Some documents in this section contain architectural guidance and
concerns, while others specify congestion control related mechanisms
which are broadly applicability and have impacts on more than a
single class of traffic as per our classification. Some of these
documents are direct products of the IAB, giving their thoughts on
specific aspects of congestion control in the Internet.
RFC 1958: "Architectural Principles of the Internet" (June 1996)
Several guidelines for network systems design that have proven
useful in the evolution of the Internet are sketched in this
document. Congestion control is not specifically mentioned or
alluded to, but the general principles apply to congestion
control. For instance, performing end-to-end functions at end
nodes, lack of centralized control, heterogeneity, scalability,
simplicity, avoiding options and parameters, etc. are all valid
concerns in the design and assessment of congestion control
schemes for the Internet.
RFC 2309: "Recommendations on Queue Management and Congestion
Avoidance in the Internet" (April 1998)
This document briefly discusses the history of congestion and the
origin of congestion control in the Internet. The focus is mainly
on network- or router-based queue management algorithms. This RFC
recommends to test, standardize and deploy Active Queue Management
(AQM) in routers; it provides an overview of one such mechanism,
Random Early Detection (RED) and explains how and why AQM
mechanisms can improve the performance of the Internet. Finally,
this document explains the danger of a possible "congestion
collapse" from unresponsive flows and makes a strong
recommendation to develop and eventually deploy router mechanisms
to protect the Internet from such traffic.
RFC 2914: "Congestion Control Principles" (September 2000)
This document is a general discussion of the principles of
congestion control. It points out that there are an increasing
number of applications which do not use TCP, and elaborates on the
importance of carrying out congestion control for such traffic in
order to prevent congestion collapse. The TCP Reno congestion
control mechanisms are described as an example of end-to-end
congestion control within transport protocols.
Welzl & Eddy Expires January 2, 2007 [Page 5]
Internet-Draft Congestion Control RFCs July 2006
RFC 3124: "The Congestion Manager" (June 2001)
This document specifies the Congestion Manager, an end-system
module that realizes congestion control on a per-host rather than
a per-connection basis, which may be a more appropriate way to
carry out congestion control. Using the Congestion Manager,
multiple streams between two hosts (which may include TCP flows)
can easily adapt to network congestion in a unified fashion.
RFC 3426: "General Architectural and Policy Considerations" (November
2002) RFC 3426 lists a number of questions that can be answered for a
particular technical solution in order to determine its
architectural impact and desirability. These are highly valid for
congestion control mechanisms, and end-point congestion management
is used as an example case-study several times in RFC 3426.
RFC 3439: "Some Internet Architectural Guidelines and Philosophy"
(December 2002)
Primarily focused on the design of Internet "backbone" networks,
this document supplements RFC 1958. Simplicity is stressed, as
the unpredictable results of complexity (due to amplification and
coupling) are described. Congestion control issues stemming from
layering interactions between transport and lower protocols are
presented, as well as other items relevent to congestion control,
including asymmetry and the "myth of over-provisioning".
RFC 3714: "IAB Concerns Regarding Congestion Control for Voice
Traffic in the Internet" (March 2004)
This document expresses the IAB's concern over the lack of
effective end-to-end congestion control for best-effort voice
traffic, which is noted as currently being an available service
with growing demand. An example of a VoIP connection between
Atlanta, Georgia, USA, and Nairobi, Kenya, is given, where a
single VoIP call consumed more than half of the access link
capacity (which is normally shared across several different
users). This example is used as the basis for further discussion,
making it clear that using some form of congestion control for
VoIP traffic is highly recommended.
Welzl & Eddy Expires January 2, 2007 [Page 6]
Internet-Draft Congestion Control RFCs July 2006
3. TCP Congestion Control
Basic TCP congestion control is defined in RFC 2581, with many other
RFCs that specify ancillary modifications and enhancements. The
reader may refer to the TCP Roadmap [RFC4614] for more information on
this subject.
Recently, significant effort has been put into experimental TCP
congestion control modifications for obtaining high throughput with
reduced startup and recovery times. RFCs have been published on some
of these modifications, including HighSpeed TCP, and Limited Slow-
Start. Other schemes, such as H-TCP, have been published as
Internet-Drafts and been discussed by the IETF, but much of the work
in this area has not been brought to the IETF (e.g. FAST, BIC/CUBIC,
Scalable TCP, and others), so the majority of this work is outside
the RFC series and will be discussed in other products of the ICCRG.
Welzl & Eddy Expires January 2, 2007 [Page 7]
Internet-Draft Congestion Control RFCs July 2006
4. Challenging Link and Path Characteristics
Congestion control mechanisms adjust the sending rate on the basis of
feedback that would reflect the state of the path between the sender
and the receiver. Such feedback can take many forms, binary or with
a finer granularity, implicit as well as explicit. TCP, SCTP and
DCCP make use of implicit feedback -- packet loss, which is commonly
interpreted as a sign of congestion, and RTT measurements -- which
can lead to adverse interactions with certain links. Other link
characteristics (such as a large bandwidth*delay product) are
challenging for congestion control mechanisms because they tend to
magnify any problems that such mechanisms may have. The documents in
these section discuss challenging link characteristics; many of them
were written by the "Performance Implications of Link
Characteristics" (PILC) Working Group.
While these documents often refer to specific problems with TCP, the
link characteristics that they describe can be expected to affect
other congestion control mechanisms too. In particular, any
interactions between special links and TCP congestion control will be
similar for protocols that use the same congestion control behavior,
such as SCTP and DCCP with CCID 2 (see Section 6), and should be
taken into consideration by designers of congestion control
mechanisms which utilize the same kind of feedback as TCP.
Some RFCs only make recommendations regarding the implementation and
configuration of TCP based upon characteristics of special links. As
these RFCs are so closely connected to the specification of TCP
itself, they are not included in this document.
RFC 3135: "Performance Enhancing Proxies Intended to Mitigate Link-
Related Degradations" (June 2001)
This document is a survey of Performance Enhancing Proxies (PEPs)
often employed to improve degraded TCP performance caused by
characteristics of specific link environments, for example, in
satellite, wireless WAN, and wireless LAN environments. Different
types of Performance Enhancing Proxies are described as well as
the mechanisms used to improve performance. While there is a
specific focus on TCP in this document, PEPs can operate on any
protocol, and the performance enhancements that PEPs achieve are
often closely related to congestion control.
RFC 3150: "End-to-end Performance Implications of Slow Links" (July
2001)
This document makes performance-related recommendations for users
Welzl & Eddy Expires January 2, 2007 [Page 8]
Internet-Draft Congestion Control RFCs July 2006
of network paths that traverse "very low bit-rate" links. It
includes a discussion of interactions between such links and TCP
congestion control.
RFC 3366: "Advice to link designers on link Automatic Repeat reQuest
(ARQ)" (August 2002)
Link-layer ARQ techniques are a popular means to increase the
robustness of a particular links to transmission errors. As this
RFC explains, ARQ techniques on a link can interact poorly with
TCP's end-to-end congestion control if they lead to additional
delay variation or reordering. This RFC gives some advice on
limiting the extent of these types of problematic interactions.
RFC 3449: "TCP Performance Implications of Network Path Asymmetry"
(December 2002)
This document describes performance limitations of TCP when the
capacity of the ACK path is limited. Several techniques to aid
TCP in these circumstances are discussed, particularly ACK
congestion control and sender pacing are relevent to other non-TCP
congestion control schemes. For instance, in the design of the
RMT protocols for multicast, preventing ACK-implosion at multicast
sources can be seen as a form of ACK congestion control.
RFC 3819: "Advice for Internet Subnetwork Designers" (July 2004)
Several challenging characteristics in link design and
optimization for carrying IP traffic are discussed in this
document. The emphasis is mostly on designs that will behave well
with TCP running over them, however, most of these principles
apply to other transport-layer congestion control techniques as
well.
Welzl & Eddy Expires January 2, 2007 [Page 9]
Internet-Draft Congestion Control RFCs July 2006
5. Explicit Congestion Notification
There are two bits in the IP header which enable an Active Queue
Management mechanism (see [RFC2309] or Section 2) to explicitly
convey the information "there was congestion" to endpoints when it
would normally drop a packet. This mechanism, which is called
"Explicit Congestion Notification" (ECN), can therefore reduce the
loss experienced by a transport endpoint in the presence of Active
Queue Management. While Explicit Congestion Notification is most
frequently discussed in the context of TCP (and therefore included in
the TCP Roadmap [RFC4614]), its applicability is broader, and ECN use
has also been specified for protocols such as DCCP and SCTP.
RFC 2481: "A Proposal to add Explicit Congestion Notification (ECN)
to IP" (January 1999)
This document introduces ECN, describing when the Congestion
Experienced (CE) bit in the IP header would be set in routers, and
what modifications would be needed to TCP to make it ECN-capable.
It includes a discussion of issues related to non-compliant
behavior in end nodes and inside the network, IPSec tunnels and
dropped or corrupted packets as well as a summary of related work.
RFC 2884: "Performance Evaluation of Explicit Congestion Notification
(ECN) in IP Networks" (July 2000)
This document presents a performance study of ECN as specified in
[RFC2481] using an implementation on the Linux Operating System.
The experiments focused on ECN for both bulk and transactional
transfers, showing that there is improvement in throughput over
TCP without ECN in the case of bulk transfers and substantial
improvement for transactional transfers.
RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to
IP" (September 2001)
This document, which obsoletes [RFC2481], specifies the
incorporation of ECN into TCP and IP. One notable change in this
significantly extended specification is the definition of a bit
combination that was not defined in [RFC2481], which can be used
to realize a nonce that would prevent a receiver from falsely
claiming that there was no congestion. Potential issues related
to ECN are discussed at length, including those already included
in [RFC2481] and backwards compatibility with implementations that
would follow the specification in the obsoleted document.
Welzl & Eddy Expires January 2, 2007 [Page 10]
Internet-Draft Congestion Control RFCs July 2006
RFC 3540: "Robust Explicit Congestion Notification (ECN) Signaling
with Nonces" (June 2003)
A nonce mechanism that makes use of the previously undefined bit
combination that is defined in [RFC2481] is specified in this
document, including the definition of a Nonce Sum (NS) field in
the TCP header that would be necessary for ensuring that an ACK
which does not indicate congestion is credible for the sender.
The mechanism improves the robustness of congestion control by
preventing receivers from exploiting ECN to gain an unfair share
of network bandwidth.
Welzl & Eddy Expires January 2, 2007 [Page 11]
Internet-Draft Congestion Control RFCs July 2006
6. Non-TCP Unicast Congestion Control
In the past, TCP dominated Internet traffic, as it was used for all
of the predominant applications (SMTP, FTP, HTTP, TELNET). The
majority of early congestion control work focused on TCP, and the
introduction of congestion control into TCP alone is often credited
with saving the Internet from additional congestion collapse events.
Today, TCP has been joined by other transport protocols (e.g. SCTP,
DCCP, RTP over UDP, etc.), and so having properly functioning
congestion control within these other protocols is important for the
Internet's health (as explained in RFC 3714, for instance, or see the
discussion of the "congestion control arms race" scenario in RFC
2914). Documents that describe unicast congestion control methods
for non-TCP transport protocols have been grouped into this section.
Note that SCTP is not discussed because its congestion control
behavior is designed to be similar to TCP.
RFC 3448: "TCP Friendly Rate Control (TFRC): Protocol Specification"
(January 2003)
This document specifies TCP-Friendly Rate Control (TFRC), a rate-
based congestion control mechanism for unicast flows operating in
a best-effort Internet environment where flows are competing with
standard TCP traffic. TFRC ensures conformance with TCP by
continuously calculating the rate that a TCP sender would obtain
under similar circumstances using a slightly simplified version of
the TCP Reno throughput equation in [Pad98]. Its sending rate is
smoother than the rate of TCP, making it suitable for multimedia
applications. TFRC is not a wire protocol but rather a mechanism
which could, for instance, be used within a UDP based application,
in a transport protocol such as RTP, or in the context of endpoint
congestion management [RFC3124].
RFC 3550: "RTP: A Transport Protocol for Real-Time Applications"
(July 2003)
This document specifies the real-time transport protocol RTP along
with its control protocol RTCP. RTP/RTCP does not prescribe a
specific congestion control behavior, but it is recommended that
such a behavior be specified in each RTP profile (which is due to
the fact that the potential for reducing the sending rate is often
content dependent in the case of real-time streams).
Specifically, [RFC3550] states: "For some profiles, it may be
sufficient to include an applicability statement restricting the
use of that profile to environments where congestion is avoided by
engineering. For other profiles, specific methods such as data
rate adaptation based on RTCP feedback may be required."
Welzl & Eddy Expires January 2, 2007 [Page 12]
Internet-Draft Congestion Control RFCs July 2006
[RFC4585], which discusses RTCP feedback and adaptation
mechanisms, points out that RTCP feedback may operate on much
slower timescales than transport layer feedback mechanisms, and
that additional mechanisms are therefore required to perform
proper congestion control. One way to make use of such additional
mechanisms is to run RTP over DCCP.
RFC 4336: "Problem Statement for the Datagram Congestion Control
Protocol (DCCP)" (March 2006)
This document provides the motivation leading to the design of
DCCP. In doing so, other possibilities of implementing similar
functionality are discussed, including unreliable extensions of
SCTP, RTP based congestion control, and providing congestion
control above or below UDP.
RFC 4340: "Datagram Congestion Control Protocol" (March 2006)
This document specifies DCCP, the Datagram Congestion Control
Protocol. This protocol provides bidirectional unicast
connections of congestion-controlled unreliable datagrams. It is
suitable for applications that transfer fairly large amounts of
data and that can benefit from control over the tradeoff between
timeliness and reliability. The core DCCP specification does not
include a specific congestion control behavior; rather, it
functions as a framework for such mechanisms, which can be
selected via the Congestion Control Identifier (CCID).
RFC 4341: "Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 2: TCP-like Congestion Control" (March 2006)
This is the specification of TCP-like congestion control for DCCP,
which is chosen by selecting CCID 2. This should be used by
senders who would like to take advantage of the available
bandwidth in an environment with rapidly changing conditions, and
who are able to adapt to the abrupt changes in the congestion
window typical of TCP's Additive Increase Multiplicative Decrease
(AIMD) congestion control.
RFC 4342: "Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)" (March
2006)
This is the specification of TCFRC congestion control as described
Welzl & Eddy Expires January 2, 2007 [Page 13]
Internet-Draft Congestion Control RFCs July 2006
in [RFC3448] for DCCP, which is chosen by selecting CCID 3. This
should be used by senders who want a TCP-friendly sending rate,
possibly with Explicit Congestion Notification (ECN), while
minimizing abrupt rate changes.
Welzl & Eddy Expires January 2, 2007 [Page 14]
Internet-Draft Congestion Control RFCs July 2006
7. Multicast Congestion Control
In the IETF, congestion control for multicast (one-to-many)
communication has primarily been tackled in the "Reliable Multicast
Transport" (RMT) Working Group. Except for [RFC2357] and [RFC3208],
all the documents in this section were written by this group. Since
a "one size fits all" protocol cannot meet the requirements of all
possible applications, the approach taken is a modular one,
consisting of "protocol cores" and "building blocks". YYY RMT RFCs
not included because not very relevant for congestion control: 3269,
3451, 3452, 3453, 3695
RFC 2357: "IETF Criteria for Evaluating Reliable Multicast Transport
and Application Protocols" (June 1998)
Some early multicast content dissemination proposals did not
incorporate proper congestion control; this is pointed out as
being a severe mistake in RFC 2357, as large-scale multicast
applications have the potential to do vast congestion related
damage. This document clearly makes the case that congestion
control mechanisms should be developed and incorporated into
multicast content dissemination protocols intended for use over
the Internet.
RFC 2887: "The Reliable Multicast Design Space for Bulk Data
Transfer" (August 2000)
Several classes of potential congestion control schemes for
single-sender multicast protocols are briefly sketched as
possibilities, but no specific protocols are developed or selected
in this document.
RFC 3048: "Reliable Multicast Transport Building Blocks for One-to-
Many Bulk-Data Transfer" (January 2001)
RFC 3048 discusses the building block approach to RMT protocols
and mentions that several different congestion control building
blocks may be required in order to deal with different situations.
Some of the possible interactions between building blocks for
congestion control and those for FEC, acknowledgement, and group
management are also mentioned.
Welzl & Eddy Expires January 2, 2007 [Page 15]
Internet-Draft Congestion Control RFCs July 2006
RFC 3208: "PGM Reliable Transport Protocol Specification" (December
2001)
As discussed in RFC 3208's Appendix B, a PGM protocol source can
request congestion control feedback from both network elements
(routers) and receivers (end hosts). These reports can indicate
the load on the worst link in a particular path, or the load on
the worst path. The actual proceedure used in response to this
feedback is not part of RFC 3208, but the notion of using
multicast routers to assist in congestion control is significant.
RFC 3450: "Asynchronous Layered Coding (ALC) Protocol Instantiation"
(December 2002)
This document specifies ALC, a rough header format using the RMT
building blocks, that can be used by multicast content
dissemination protocols. ALC is intended to use a multi-rate
congestion control building block, where the sender does not
require any feedback, but where multiple multicast groups with
different transmission rates are available within and ALC session,
and receivers control their rates by joining or leaving groups.
RFC 3738: "Wave and Equation Based Rate Control (WEBRC) Building
Block" (April 2004)
The abstract of RFC 3738 is: "This document specifies Wave and
Equation Based Rate Control (WEBRC), which provides rate and
congestion control for data delivery. WEBRC is specifically
designed to support protocols using IP multicast. It provides
multiple-rate, congestion-controlled delivery to receivers, i.e.,
different receivers joined to the same session may be receiving
packets at different rates depending on the bandwidths of their
individual connections to the sender and on competing traffic
along these connections. WEBRC requires no feedback from
receivers to the sender, i.e., it is a completely receiver-driven
congestion control protocol. Thus, it is designed to scale to
potentially massive numbers of receivers attached to a session
from a single sender. Furthermore, because each individual
receiver adjusts to the available bandwidth between the sender and
that receiver, there is the potential to deliver data to each
individual receiver at the fastest possible rate for that
receiver, even in a highly heterogeneous network architecture,
using a single sender."
Welzl & Eddy Expires January 2, 2007 [Page 16]
Internet-Draft Congestion Control RFCs July 2006
RFC 3940: "NACK-Oriented Reliable Multicast Protocol (NORM)"
(November 2004) and RFC 3941 "NACK-Oriented Reliable Multicast (NORM)
Building Blocks"
The NORM protocol incorporates a congestion control building
block. A NORM sender can request congestion control information
from receivers and use the TFMCC building block (RFC 4654) or
PGMCC [Riz00] to provide congestion control, as discussed in the
experimental NORM specification in RFC 3940 and 3941.
RFC 4654: "TCP-Friendly Multicast Congestion Control (TFMCC):
Protocol Specification" (August 2006)
The abstract of RFC 4654 is: " This document specifies TCP-
Friendly Multicast Congestion Control (TFMCC). TFMCC is a
congestion control mechanism for multicast transmissions in a
best-effort Internet environment. It is a single-rate congestion
control scheme, where the sending rate is adapted to the receiver
experiencing the worst network conditions. TFMCC is reasonably
fair when competing for bandwidth with TCP flows and has a
relatively low variation of throughput over time, making it
suitable for applications where a relatively smooth sending rate
is of importance, such as streaming media."
Welzl & Eddy Expires January 2, 2007 [Page 17]
Internet-Draft Congestion Control RFCs July 2006
8. Historic Interest
Early in the RFC series, there are many documents that merely contain
an author's short thoughts on a subject or brief summaries from
measurement and experimentation, rather than the result of a long
formal IETF process. Some of the RFCs listed in this section have
this distinction.
RFC 889: "Internet Delay Experiments" (December 1983)
Based on reported measurement experiments, changes to the TCP
retransmission timeout calculation are suggested in this document.
It is noted that the original TCP RTO calculation leads to
congestion when a delay spike occurs because it takes too long for
the RTO to adapt, leading to superfluous retransmissions.
RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984)
This is the first document known to the authors where the term
"congestion collapse" was used. Here, it refers to the stable
state which was observed when a sudden load on the net caused the
round-trip time to rise faster than the sending hosts measured RTT
could be updated. Two problems are discussed: the "small-packet
problem" (now commonly known by the name "silly window syndrome")
and the "source-quench problem", which is about inappropriately
deciding when to send and how to react to ICMP source-quench
messages. Solutions for these problems are presented.
RFC 1254: "Gateway Congestion Control Survey" (August 1991)
This survey of congestion control approaches in routers first
discusses general congestion control performance goals (such as
fairness), and then elaborates on the use of Source Quench
messages, Random Drop (which would now be called "Active Queue
Management"), Congestion Indication (DEC Bit) (an early form of
ECN), "Selective Feedback Congestion Indication" (one particular
method for applying ECN), and Fair Queuing. Finally, end system
congestion control policies are discussed, including the well
known algorithms in [Jac88] and their predecessor "CUTE".
Welzl & Eddy Expires January 2, 2007 [Page 18]
Internet-Draft Congestion Control RFCs July 2006
9. Security Considerations
This document introduces no new security considerations. Each RFC
listed in this document attempts to address the security
considerations of the specification it contains.
Welzl & Eddy Expires January 2, 2007 [Page 19]
Internet-Draft Congestion Control RFCs July 2006
10. IANA Considerations
This document contains no IANA considerations.
Welzl & Eddy Expires January 2, 2007 [Page 20]
Internet-Draft Congestion Control RFCs July 2006
11. Acknowledgments
Several participants in the ICCRG contributed useful comments in the
development of this document.
12. Informative References
[Jac88] Jacobson, V., "Congestion Avoidance and Control, ACM
SIGCOMM 1988 Proceedings, in ACM Computer Communication
Review, 18 (4), pp. 314-329", 1988.
[Pad98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose,
"Modeling TCP Throughput: A Simple Model and its Empirical
Validation, Proc. ACM SIGCOMM 1998.".
[RFC0889] Mills, D., "Internet delay experiments", RFC 889,
December 1983.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984.
[RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion
Control Survey", RFC 1254, August 1991.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[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.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481,
January 1999.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, July 2000.
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R.,
Vicisano, L., and M. Luby, "The Reliable Multicast Design
Welzl & Eddy Expires January 2, 2007 [Page 21]
Internet-Draft Congestion Control RFCs July 2006
Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
"End-to-end Performance Implications of Slow Links",
BCP 48, RFC 3150, July 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D.,
Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo,
L., Tweedly, A., Bhaskar, N., Edmonstone, R.,
Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport
Protocol Specification", RFC 3208, December 2001.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
August 2002.
[RFC3426] Floyd, S., "General Architectural and Policy
Considerations", RFC 3426, November 2002.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, December 2002.
Welzl & Eddy Expires January 2, 2007 [Page 22]
Internet-Draft Congestion Control RFCs July 2006
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
Control for Voice Traffic in the Internet", RFC 3714,
March 2004.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004.
[RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC3941] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-Acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Building Blocks", RFC 3941,
November 2004.
[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement
for the Datagram Congestion Control Protocol (DCCP)",
RFC 4336, March 2006.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006.
Welzl & Eddy Expires January 2, 2007 [Page 23]
Internet-Draft Congestion Control RFCs July 2006
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
March 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, September 2006.
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006.
[Riz00] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast
Congestion Control Scheme", Proceedings of ACM
SIGCOMM 2000, August 2000.
Authors' Addresses
Michael Welzl
University of Innsbruck
Technikerstr 21a
A-6020 Innsbruck, Austria
Phone: +43 (512) 507-6110
Email: michael.welzl@uibk.ac.at
Wesley M. Eddy
Verizon Federal Network Systems
NASA Glenn Research Center
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: (216) 433-6682
Email: weddy@grc.nasa.gov
Welzl & Eddy Expires January 2, 2007 [Page 24]
Internet-Draft Congestion Control RFCs July 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Welzl & Eddy Expires January 2, 2007 [Page 25]
