Network Working Group S. Floyd
Request for Comments: 5033 M. Allman
BCP: 133 ICIR / ICSI
Category: Best Current Practice August 2007
Specifying New Congestion Control Algorithms
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.
Abstract
The IETF's standard congestion control schemes have been widely shown
to be inadequate for various environments (e.g., high-speed
networks). Recent research has yielded many alternate congestion
control schemes that significantly differ from the IETF's congestion
control principles. Using these new congestion control schemes in
the global Internet has possible ramifications to both the traffic
using the new congestion control and to traffic using the currently
standardized congestion control. Therefore, the IETF must proceed
with caution when dealing with alternate congestion control
proposals. The goal of this document is to provide guidance for
considering alternate congestion control algorithms within the IETF.
Floyd & Allman Best Current Practice [Page 1]
RFC 5033 Specifying New Congestion Control Algorithms August 2007
1. Introduction
This document provides guidelines for the IETF to use when evaluating
suggested congestion control algorithms that significantly differ
from the general congestion control principles outlined in [RFC2914].
The guidance is intended to be useful to authors proposing alternate
congestion control and for the IETF community when evaluating whether
a proposal is appropriate for publication in the RFC series.
The guidelines in this document are intended to be consistent with
the congestion control principles from [RFC2914] of preventing
congestion collapse, considering fairness, and optimizing the flow's
own performance in terms of throughput, delay, and loss. [RFC2914]
also discusses the goal of avoiding a congestion control "arms race"
among competing transport protocols.
This document does not give hard-and-fast requirements for an
appropriate congestion control scheme. Rather, the document provides
a set of criteria that should be considered and weighed by the IETF
in the context of each proposal. The high-order criteria for any new
proposal is that a serious scientific study of the pros and cons of
the proposal needs to have been done such that the IETF has a well-
rounded set of information to consider.
After initial studies, we encourage authors to write a specification
of their proposals for publication in the RFC series to allow others
to concretely understand and investigate the wealth of proposals in
this space.
2. Document Status
Following the lead of HighSpeed TCP [RFC3649], alternate congestion
control algorithms are expected to be published as "Experimental"
RFCs until such time that the community better understands the
solution space. Traditionally, the meaning of "Experimental" status
has varied in its use and interpretation. As part of this document
we define two classes of congestion control proposals that can be
published with the "Experimental" status. The first class includes
algorithms that are judged to be safe to deploy for best-effort
traffic in the global Internet and further investigated in that
environment. The second class includes algorithms that, while
promising, are not deemed safe enough for widespread deployment as
best-effort traffic on the Internet, but are being specified to
facilitate investigations in simulation, testbeds, or controlled
environments. The second class can also include algorithms where the
IETF does not yet have sufficient understanding to decide if the
algorithm is or is not safe for deployment on the Internet.
Floyd & Allman Best Current Practice [Page 2]
RFC 5033 Specifying New Congestion Control Algorithms August 2007
Each alternate congestion control algorithm published is required to
include a statement in the abstract indicating whether or not the
proposal is considered safe for use on the Internet. Each alternate
congestion control algorithm published is also required to include a
statement in the abstract describing environments where the protocol
is not recommended for deployment. There may be environments where
the protocol is deemed *safe* for use, but still is not *recommended*
datatracker.ietf.org