Internet DRAFT - draft-scheffenegger-congress-rfc5033bis
draft-scheffenegger-congress-rfc5033bis
TODO Working Group R. Scheffenegger, Ed.
Internet-Draft NetApp, Inc.
Obsoletes: 5033 (if approved) S. Floyd
Intended status: Best Current Practice M. Allman
Expires: 21 August 2023 ICIR / ICSI
17 February 2023
Specifying New Congestion Control Algorithms
draft-scheffenegger-congress-rfc5033bis-00
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.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/rscheff/drafts.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 21 August 2023.
Scheffenegger, et al. Expires 21 August 2023 [Page 1]
Internet-Draft New CC Algorithms February 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Status . . . . . . . . . . . . . . . . . . . . . . . 3
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Minimum Requirements . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
Scheffenegger, et al. Expires 21 August 2023 [Page 2]
Internet-Draft New CC Algorithms February 2023
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.
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_
for use because it does not perform well for the user.
Scheffenegger, et al. Expires 21 August 2023 [Page 3]
Internet-Draft New CC Algorithms February 2023
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 [RFC4782] includes a paragraph in
the abstract stating the mechanism is only being proposed for
controlled environments. The abstract specifies environments where
the Quick-Start request could 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.
For authors of alternate congestion control schemes who are not ready
to bring their congestion control mechanisms to the IETF for
standardization (either as Experimental or as Proposed Standard), one
possibility would be to submit an internet-draft that documents the
alternate congestion control mechanism for the benefit of the IETF
and IRTF communities. This is particularly encouraged in order to
get algorithm specifications widely disseminated to facilitate
further research. Such an internet-draft could be submitted to be
considered as an Informational RFC, as a first step in the process
towards standardization. Such a document would also be expected to
carry an explicit warning against using the scheme in the global
Internet.
Note: we are not changing the RFC publication process for non-IETF
produced documents (e.g., those from the IRTF or Independent
Submissions via the RFC-Editor). However, we would hope the
guidelines in this document inform the IESG as they consider whether
to add a note to such documents.
3. Guidelines
As noted above, authors are expected to do a well-rounded evaluation
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;
these guidelines should not be considered as an all-encompassing
check-list.
(0) Differences with Congestion Control Principles [RFC2914]
Proposed congestion control mechanisms should include a clear
explanation of the deviations from [RFC2914].
(1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].
Scheffenegger, et al. Expires 21 August 2023 [Page 4]
Internet-Draft New CC Algorithms February 2023
Proposed congestion control mechanisms should be evaluated when
competing with standard IETF congestion control [RFC2581],
[RFC2960], [RFC4340]. Alternate congestion controllers that have
a significantly negative impact on traffic using standard
congestion control may be suspect and this aspect should be part
of the community's decision making with regards to the suitability
of the alternate congestion control mechanism.
We note that this bullet is not a requirement for strict TCP-
friendliness as a prerequisite for an alternate congestion control
mechanism to advance to Experimental. As an example, HighSpeed
TCP is a congestion control mechanism that is Experimental, but
that is not TCP-friendly in all environments. We also note that
this guideline does not constrain the fairness offered for non-
best-effort traffic.
As an example from an Experimental RFC, fairness with standard TCP
is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed TCP) and
using spare capacity is discussed in Sections 6, 11.1, and 12 of
[RFC3649].
(2) Difficult Environments.
The proposed algorithms should be assessed in difficult
environments such as paths containing wireless links.
Characteristics of wireless environments are discussed in
[RFC3819] and in Section 16 of [Tools]. Other difficult
environments can include those with multipath routing within a
connection. We note that there is still much to be desired in
terms of the performance of TCP in some of these difficult
environments. For congestion control mechanisms with explicit
feedback from routers, difficult environments can include paths
with non-IP queues at layer-two, IP tunnels, and the like. A
minimum goal for experimental mechanisms proposed for widespread
deployment in the Internet should be that they do not perform
significantly worse than TCP in these environments.
While it is impossible to enumerate all the possible "difficult
environments", we note that the IETF has previously grappled with
paths with long delays [RFC2488], high delay bandwidth products
[RFC3649], high packet corruption rates [RFC3155], packet
reordering [RFC4653], and significantly slow links [RFC3150].
Aspects of alternate congestion control that impact networks with
these characteristics should be detailed.
As an example from an Experimental RFC, performance in difficult
environments is discussed in Sections 6, 9.2, and 10.2 of
[RFC4782] (Quick-Start).
Scheffenegger, et al. Expires 21 August 2023 [Page 5]
Internet-Draft New CC Algorithms February 2023
(3) 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, round-trip times, levels of traffic on the reverse
path, and levels of statistical multiplexing at the congested
link. Similarly, proposals should be investigated for robust
performance with different queueing mechanisms in the routers,
especially Random Early Detection (RED) [FJ03] and Drop-Tail.
This evaluation is often not included in the internet-draft
itself, but in related papers cited in the draft.
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
characterizing the areas where the proposed mechanism does not
perform well.
As an example from an Experimental RFC, performance in a range of
environments is discussed in Section 12 of [RFC3649] (HighSpeed
TCP) and Section 9.7 of [RFC4782] (Quick-Start).
(4) Protection Against Congestion Collaps
The alternate congestion control mechanism should either stop
sending when the packet drop rate exceeds some threshold
[RFC3714], or should include some notion of "full backoff". For
"full backoff", at some point the algorithm would 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 either "full backoff" or a
pause in sending comes into play will be algorithm-specific.
However, as discussed in [RFC2914], this requirement is crucial to
protect the network in times of extreme congestion.
If "full backoff" is used, this bullet does not require that the
full backoff mechanism must be identical to that of TCP [RFC2988].
As an example, this bullet does not preclude full backoff
mechanisms that would give flows with different round- trip times
comparable bandwidth during backoff.
(5) Fairness within the Alternate Congestion Control Algorithm.
In environments with multiple competing flows all using the same
alternate congestion control algorithm, the proposal should
explore how bandwidth is shared among the competing flows.
Scheffenegger, et al. Expires 21 August 2023 [Page 6]
Internet-Draft New CC Algorithms February 2023
(6) 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.
As an example from an Experimental RFC, performance with
misbehaving nodes and outside attackers is discussed in Sections
9.4, 9.5, and 9.6 of [RFC4782] (Quick-Start). This includes
discussion of misbehaving senders and receivers; collusion between
misbehaving routers; misbehaving middleboxes; and the potential
use of Quick-Start to attack routers or to tie up available Quick-
Start bandwidth.
(7) Responses to Sudden or Transient Events.
The proposal should consider how the alternate congestion control
mechanism would perform in the presence of transient events such
as sudden congestion, a routing change, or a mobility event.
Routing changes, link disconnections, intermittent link
connectivity, and mobility are discussed in more detail in
Section 17 of [Tools].
As an example from an Experimental RFC, response to transient
events is discussed in Section 9.2 of [RFC4782] (Quick-Start).
(8) Incremental Deployment.
The proposal should discuss whether the alternate congestion
control mechanism allows for incremental deployment in the
targeted environment. For a mechanism targeted for deployment in
the current Internet, it would be helpful for the proposal to
discuss what is known (if anything) about the correct operation of
the mechanism with some of the equipment installed in the current
Internet, e.g., routers, transparent proxies, WAN optimizers,
intrusion detection systems, home routers, and the like.
As a similar concern, if the alternate congestion control
Scheffenegger, et al. Expires 21 August 2023 [Page 7]
Internet-Draft New CC Algorithms February 2023
mechanism is intended only for specific environments (and not the
global Internet), the proposal should consider how this intention
is to be carried out. The community will have to address the
question of whether the scope can be enforced by simply stating
the restrictions or whether additional protocol mechanisms are
required to enforce the scoping. The answer will necessarily
depend on the change being proposed.
As an example from an Experimental RFC, deployment issues are
discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start).
4. Minimum Requirements
This section suggests minimum requirements for a document to be
approved as Experimental with approval for widespread deployment in
the global Internet.
The minimum requirements for approval for widespread deployment in
the global Internet include the following guidelines on: (1)
assessing the impact on standard congestion control, (3)
investigation of the proposed mechanism in a range of environments,
(4) protection against congestion collapse, and (8) discussing
whether the mechanism allows for incremental deployment.
For other guidelines, i.e., (2), (5), (6), and (7), the author must
perform the suggested evaluations and provide recommended analysis.
Evidence that the proposed mechanism has significantly more problems
than those of TCP should be a cause for concern in approval for
widespread deployment in the global Internet.
5. 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, and should
examine any potential security issues that may arise.
6. IANA Considerations
This document has no IANA actions.
7. References
7.1. Normative References
Scheffenegger, et al. Expires 21 August 2023 [Page 8]
Internet-Draft New CC Algorithms February 2023
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, DOI 10.17487/RFC2581, April 1999,
<https://www.rfc-editor.org/rfc/rfc2581>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/rfc/rfc2914>.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000,
<https://www.rfc-editor.org/rfc/rfc2960>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/rfc/rfc4340>.
7.2. Informative References
[FJ03] Floyd, S. and V. Jacobson, "Random Early Detection
Gateways for Congestion Avoidance", IEEE/ACM Transactions
on Networking, V.1 N.4 , August 1993.
[Metrics] Floyd, S., "Metrics for the Evaluation of Congestion
Control Mechanisms", Work in Progress , July 2007.
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms",
BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999,
<https://www.rfc-editor.org/rfc/rfc2488>.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, DOI 10.17487/RFC2988, November 2000,
<https://www.rfc-editor.org/rfc/rfc2988>.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
"End-to-end Performance Implications of Slow Links",
BCP 48, RFC 3150, DOI 10.17487/RFC3150, July 2001,
<https://www.rfc-editor.org/rfc/rfc3150>.
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
Vaidya, "End-to-end Performance Implications of Links with
Errors", BCP 50, RFC 3155, DOI 10.17487/RFC3155, August
2001, <https://www.rfc-editor.org/rfc/rfc3155>.
Scheffenegger, et al. Expires 21 August 2023 [Page 9]
Internet-Draft New CC Algorithms February 2023
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, DOI 10.17487/RFC3649, December 2003,
<https://www.rfc-editor.org/rfc/rfc3649>.
[RFC3714] Floyd, S., Ed. and J. Kempf, Ed., "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet",
RFC 3714, DOI 10.17487/RFC3714, March 2004,
<https://www.rfc-editor.org/rfc/rfc3714>.
[RFC3819] Karn, P., Ed., 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, DOI 10.17487/RFC3819, July 2004,
<https://www.rfc-editor.org/rfc/rfc3819>.
[RFC4653] Bhandarkar, S., Reddy, A. L. N., Allman, M., and E.
Blanton, "Improving the Robustness of TCP to Non-
Congestion Events", RFC 4653, DOI 10.17487/RFC4653, August
2006, <https://www.rfc-editor.org/rfc/rfc4653>.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
January 2007, <https://www.rfc-editor.org/rfc/rfc4782>.
[Tools] Floyd, S. and E. Kohler, "Tools for the Evaluation of
Simulation and Testbed Scenarios", Work in Progress , July
2007.
Acknowledgments
Discussions with Lars Eggert and Aaron Falk seeded this document.
Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye,
Colin Perkins, Pekka Savola, members of TSVWG, and participants at
the TCP Workshop at Microsoft Research for feedback and
contributions. This document also draws from [Metrics].
Authors' Addresses
Richard Scheffenegger (editor)
NetApp, Inc.
Email: srichard@netapp.com
Sally Floyd
ICSI Center for Internet Research
Email: floyd@icir.org
URI: http://www.icir.org/floyd
Scheffenegger, et al. Expires 21 August 2023 [Page 10]
Internet-Draft New CC Algorithms February 2023
Mark Allman
ICSI Center for Internet Research
Email: mallman@icir.org
URI: http://www.icir.org/mallman
Scheffenegger, et al. Expires 21 August 2023 [Page 11]
