Network Working Group S. Floyd
Internet-Draft M. Allman
Expires: December 2006 ICIR / ICSI
October 2006
Specifying New Congestion Control Algorithms
draft-floyd-cc-alt-00.txt
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The IETF's standard congestion control schemes have been widely
shown to be inadequate for various environments (e.g., high-speed or
wireless networks). Recent research has yielded many alternate
congestion control schemes. Using these new congestion control
schemes in the global Internet has possible ramifications to both
the network 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.
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
Expires: April 2007 [Page 1]
draft-floyd-cc-alt-00.txt October 2006
authors proposing alternate congestion control and for the IETF
community when evaluating whether a proposal is appropriate for
publication in the RFC series.
This document does not give hard-and-fast rules for what makes 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. Status
Following the lead of HighSpeed TCP, 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 is algorithms that are
judged to be safe to deploy in the global Internet and further
investigated in that environment. The second class is algorithms
that, while promising, are not deemed safe enough for deployment on
the Internet, but are being specified to facilitate investigations
via simulation and testbeds.
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 even though it may not be unsafe
for use.
As examples of such statements, [RFC3649] specifying HighSpeed TCP
includes a statement in the abstract stating that the proposal is
Experimental, but may be deployed in the current Internet. In
contrast, the Quick-Start document [QuickStart] includes a paragraph
in the abstract stating the the mechanism is only being proposed for
controlled environments. The abstract specifies environments where
the Quick-Start request would give false positives (and therefore
would be unsafe to deploy). The abstract also specifies
environments where packets containing the Quick-Start request could
be dropped in the network; in such an environment, Quick-Start would
not be unsafe to deploy, but deployment would still not be
recommended because it could cause unnecessary delays for the
connections attempting to use Quick-Start.
Expires: April 2007 [Page 2]
draft-floyd-cc-alt-00.txt October 2006
3. Guidelines
As noted above, authors are expected to do a well-rounded
evaluations of the pros and cons of proposals brought to the IETF.
The following are guidelines to help authors and the IETF community.
Concerns that fall outside the scope of these guidelines are
certainly possible and these guidelines should not be used as a
check-list.
(1) Fairness to Standard TCP, SCTP, and DCCP.
In environments where standard congestion control is able to
make reasonable use of the available bandwidth the proposed
change should not significantly change this state.
For instance, in a situation where each of N flows uses 1/N of
the network capacity, a new congestion control scheme should not
significantly deviate from this state. For instance, a flow
using an alternate congestion controller that took half the
capacity and left each of the remaining N flows with 1/2N of the
capacity would be suspect.
(2) Using Spare Capacity.
Similar to point (1), alternate congestion control algorithms
may take up spare capacity in the network, but may not steal
significant amounts of capacity from flows using currently
standardized congestion control.
For instance, consider the case where N flows cannot naturally
use all the capacity and equally share one-third of the capacity
(with each flow using 1/3N of the capacity). A single flow
using an alternate congestion control scheme could use the
unused two-thirds of capacity. However, the flow using
alternate congestion control should not steal significant
amounts of additional capacity from the N standard flows.
(3) Difficult Environments.
An assessment of proposed algorithms in difficult environments
such as paths containing wireless links and paths with
reverse-path congestion. In addition, proposed algorithms
should be evaluated in situations where the bottleneck has high
and low levels of statistical multiplexing.
(4) Investigating a Range of Environments.
Similar to the last criteria, proposed alternate congestion
controllers should be assessed in a range of environments. For
instance, proposals should be investigated across a range of
bandwidths and round-trip times. A particularly important
aspect of evaluating a proposal for standardization is in
understanding where the algorithm breaks down. Therefore,
particular attention should be paid to extending the
Expires: April 2007 [Page 3]
draft-floyd-cc-alt-00.txt October 2006
investigation into areas where the proposal does not perform
well.
(5) Full Backoff.
All alternate congestion control algorithms ultimately should
include some notion of "full backoff". That is, at some point
the algorithm should reduce the sending rate to one packet per
round-trip time and then exponentially backoff the time between
single packet transmissions if congestion persists. Exactly
when this "full backoff" comes into play will be
algorithm-specific. However, this requirement is crucial to
protect the network in times of extreme congestion.
(6) Fairness within the Alternate Congestion Control Algorithm.
In environments with multiple competing flows using the
alternate congestion control algorithm, the proposal should
explore how bandwidth is shared among the competing flows.
(7) Performance with Misbehaving Nodes and Outside Attackers.
The proposal should explore how the alternate congestion control
mechanism performs with misbehaving senders, receivers, or
routers. In addition, the proposal should explore how the
alternate congestion control mechanism performs with outside
attackers. This can be particularly important for congestion
control mechanisms that involve explicit feedback from routers
along the path.
4. Security Considerations
This document does not represent a change to any aspect of the
TCP/IP protocol suite and therefore does not directly impact
Internet security. The implementation of various facets of the
Internet's current congestion control algorithms do have security
implications (e.g., as outlined in [RFC2581]). Alternate congestion
control schemes should be mindful of such pitfalls, as well.
5. IANA Considerations
This document does not require any IANA action.
Acknowledgments
Discussions with Lars Eggert and Aaron Falk seeded this document.
This document also draws from [Metrics].
Normative References
Informative References
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, Proposed Standard, April 1999.
Expires: April 2007 [Page 4]
draft-floyd-cc-alt-00.txt October 2006
[RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best
Current Practice, September 2000.
[Metrics] S. Floyd, Metrics for the Evaluation of Congestion
Control Mechanisms. Internet-draft draft-irtf-tmrg-metrics-04,
work in progress, August 2006.
[QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti,
Quick-Start for TCP and IP. Internet-draft
draft-ietf-tsvwg-quickstart-07.txt, work in progress, October
2006. Approved for Experimental.
Authors' Addresses
Sally Floyd
Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research)
Email: floyd@icir.org
URL: http://www.icir.org/floyd/
Mark Allman
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 235-1792
Email: mallman@icir.org
URL: http://www.icir.org/mallman/
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
Expires: April 2007 [Page 5]
draft-floyd-cc-alt-00.txt October 2006
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.
Expires: April 2007 [Page 6]
