Authors and *AD,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!--[rfced] *ADs - As this document obsoletes RFC 5033, should it be
added to BCP 133? We have updated as such; please let us know
any objections. -->
2) <!--[rfced] While we understand RFC 5033 was published
with some of the text we are questioning below, the questions and
edits are aimed at making the text as correct and useful to the reader
as possible. Please review carefully.
In addition, this document is in the current RFC format (a major change
was made in 2019), so various updates have been made in the source file.
Details are here: https://www.rfc-editor.org/pubprocess/how-we-update.
-->
3) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
4) <!--[rfced] Might this update to the Abstract be of interest? It
attempts to reduce redundancy and reorganize the sentences
slightly.
Original:
This document replaces RFC 5033, which discusses the principles and
guidelines for standardizing new congestion control algorithms. It
seeks to ensure that proposed congestion control algorithms operate
without harm and efficiently alongside other algorithms in the global
Internet. It emphasizes the need for comprehensive testing and
validation to prevent adverse interactions with existing flows. This
document provides a framework for the development and assessment of
congestion control mechanisms, promoting stability across diverse
network environments. It obsoletes RFC5033 to reflect changes in
the congestion control landscape.
Perhaps:
RFC 5033 discusses the principles and guidelines for standardizing
new congestion control algorithms. This document obsoletes RFC
5033 to reflect changes in the congestion control landscape by
providing a framework for the development and assessment of
congestion control mechanisms, promoting stability across diverse
work environments. This document aims to describe ways that
proposed congestion control algorithms can operate both without
harm and efficiently alongside other algorithms in the global
Internet. It emphasizes the need for comprehensive testing and
validation to prevent adverse interactions with existing flows.
-->
5) <!-- [rfced] We note that [HRX08] states it was published in 2008. May
we update the text below accordingly?
Original:
CUBIC was documented in a research publication in 2007 [HRX08], and
was then adopted as the default congestion control algorithm for
the TCP implementation in Linux.
Perhaps:
CUBIC was documented in a research publication in 2008 [HRX08], and
was then adopted as the default congestion control algorithm for
the TCP implementation in Linux.
-->
6) <!--[rfced] Would one of the following suggestions be agreeable in
order to clarify this document's journey?
Original:
It was already used in a significant fraction of TCP connections over
the Internet before being documented in an Informational
Internet-Draft in 2015, published as an Informational RFC in 2017 as
[RFC8312] and then as a Proposed Standard in 2023 [RFC9438].
Perhaps A:
It was already used in a significant
fraction of TCP connections over the Internet before being published as an
Informational RFC in 2017 as [RFC8312] and then as a Proposed
Standard in 2023 [RFC9438].
Perhaps B:
It was already used in a significant fraction of TCP connections over
the Internet before being documented in an Internet-Draft with the
intended status of Informational in 2015, published as an
Informational RFC in 2017 as [RFC8312], and then published as a
Proposed Standard in 2023 [RFC9438].
-->
7) <!--[rfced] Note that we have removed "IRTF" from the following text.
It doesn't appear to us that an IRTF RG adopted this draft (we
see the first two versions as individual submissions and the last
as an IETF document). Please review.
Original:
It was described in an IRTF Internet-Draft in 2018, and that
Internet-Draft is regularly updated to document the
evolving versions of the algorithm [BBR-draft].
Current:
It was described in an Internet-Draft in 2018, which has been
regularly updated to document the evolving versions of the algorithm
[BBR].
-->
8) <!-- [rfced] May we update the third bullet below for consistency with
the other bulleted items?
Original:
Nevertheless, a specification for a congestion control algorithm
provides a number of advantages:
* It can help implementers, operators, and other interested parties
develop a shared understanding of how the algorithm works and how
it is expected to behave in various scenarios and configurations.
* It can help potential contributors understand the algorithm, which
can make it easier for them to suggest improvements and/or
identify limitations. Furthermore, the specification can help
multiple contributors align on a consensus change to the
algorithm.
* A specification that is accessible to anyone can circumvent the
issue that some implementers may be unable to read open source
reference implementations due to the constraints of some open
source licenses.
Perhaps:
Nevertheless, a specification for a congestion control algorithm
provides a number of advantages:
...
* It can help (by being accessible to anyone) to circumvent the issue that
some implementers may be unable to read open-source reference
implementations due to the constraints of some open-source licenses.
-->
9) <!--[rfced] Might this update reduce redundancy?
Original:
Evidence of results is normally considered by the working group in
deciding if a specification is ready for publication and ought to be
documented in any request for the working group to publish the
specification.
Perhaps:
Any request for a working group to consider a specification for
publication ought to document evidence of results.
-->
10) <!--[rfced] May we make this update for accuracy/clarity?
Original:
Publication might occur without multiple implementations if a single
implementation is widely used, open source, and shown to have
positive impact on the Internet, particularly if the target status is
Experimental.
Perhaps:
A congestion control algorithm without multiple implementations
might still be published as an RFC if a single implementation is
widely used, open source, and shown to have a positive impact on
the Internet, particularly if the target status is Experimental.
-->
11) <!--[rfced] Please carefully review our updates to Section 3.2. As
much of this section is about RFCs themselves and the publication
process, we have made a number of changes to attempt to improve
clarity and to align the style of terminology with past RFCs and
in-house guidance on such topics. Please let us know any
objections or further updates to be made. -->
12) <!--[rfced] This text left us wondering what happens to algorithms
that are not targeted at general use? What status can they seek?
Perhaps further info would be helpful to the reader?
Original:
Congestion control algorithms without empirical evidence of
Internet-scale deployment MUST seek Experimental status, unless they
are not targeted at general use.
-->
13) <!--[rfced] In the following, we assume that RFC 4614 should remain as
the cited document even though it has been obsoleted.
Please note that we have added mention of the obsoleting document
as well as an Informative References entry for the ease of the
reader.
Original:
Section 4 of [RFC4614] provides other examples of extensions that were
considered experimental when the specification was
published.
Current:
Section 4 of [RFC4614] provides other examples of extensions that were
considered experimental when the specification was
published (note that [RFC4614] has since been obsoleted by
[RFC7414]).
-->
14) <!-- [rfced] For readability, may we update this sentence as follows?
Original:
In evaluating a new proposal for use in a controlled environment,
the IETF needs to understand the usage, e.g., how the usage is
scoped to the controlled environment, whether the algorithm will
share resources with Internet traffic, and consider what could
happen if used in a protocol that is bridged across an Internet
path.
Perhaps:
In evaluating a new proposal for use in a controlled environment,
the IETF community needs to understand the usage (e.g., how the usage is
scoped to the controlled environment), whether the algorithm will
share resources with Internet traffic, and what could
happen if used in a protocol that is bridged across an Internet
path.
-->
15) <!--[rfced] Does the suggested text capture your intended meaning?
Original:
Instead, the community will use these evaluations as an input when
considering whether to progress the proposed algorithm.
Perhaps:
Instead, the community will use these evaluations as an input when
considering whether to progress the proposed algorithm specification
in the publication process.
-->
16) <!-- [rfced] We were unable to find "Reno" explicitly mentioned in RFC
5681 as seen in the text below:
Original:
The standards-track Reno [RFC5681] and CUBIC [RFC9438]
congestion control algorithms send at progressively higher rates
until a First-In First-Out (FIFO) buffer completely fills...
However, it does appear in RFCs 5681 and 6582 in the reference
below. Should the reference to RFC 5681 be adjusted to [FF96]? [FF96]
is now available at this URL:
https://dl.acm.org/doi/10.1145/235160.235162
>From RFC 5681:
[FF96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
Tahoe, Reno and SACK TCP", Computer Communication Review,
July 1996, ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
>From RFC 6582:
"For the typical implementation of the TCP fast recovery algorithm
described in [RFC5681] (first implemented in the 1990 BSD Reno
release, and referred to as the "Reno algorithm" in [FF96])..."
-->
17) <!-- [rfced] FYI - We have reworked the text below into a bulleted
list for ease of the reader and updated to use didactic
caps. Please review and let us know any objections.
Original:
Among the AQM techniques that might have an impact on a proposed
congestion control algorithm are Flow Queue CoDel (FQ-CoDel)
[RFC8290]; Proportional Integral Controller Enhanced (PIE) [RFC8033];
and Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].
Current:
Some of the AQM techniques that might have an impact on a proposed
congestion control algorithm include:
* Flow Queue CoDel (FQ-CoDel) [RFC8290];
* Proportional Integral controller Enhanced (PIE) [RFC8033]; and
* Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332].
-->
18) <!-- [rfced] We note that ECT is most often expanded to "ECN-Capable
Transport (ECT)" (as was done in normative reference RFC 9902).
Would you like to update this expansion to match the usage in
RFC 9902?
Original:
A proposed congestion control algorithm that sets one of the two
Explicit Congestion Transport (ECT) codepoints in the IP header can
gain the benefits of receiving Explicit Congestion Notification (ECN)
Congestion Experienced (CE) signals from an on-path AQM [RFC8087].
Perhaps:
A proposed congestion control algorithm that sets one of the two
ECN-Capable Transport (ECT) codepoints in the IP header can gain the
benefits of receiving Explicit Congestion Notification-Congestion
Experienced (ECN-CE) signals from an on-path AQM [RFC8087].
-->
19) <!-- [rfced] FYI - For readability, we have reformatted the text below to
read as a bulleted list. Please review and let us know any objections.
Original:
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]. 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.
Current:
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]. 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.
-->
20) <!-- [rfced] We had the following additional questions related to
references and citations in the document:
a.) [BUFFERBLOAT] Would you like to use the following URL for this
reference (as this URL has a DOI and an open access PDF)?
https://dl.acm.org/doi/10.1145/2063166.2071893
b.) FYI - We have added the following RFCs to the Informative
References section, as they are included in the text but were not
cited as references.
RFC 9293
RFC 4340
RFC 9260
RFC 9000
RFC 8257
-->
21) <!--[rfced] Note that we have cut the "Evolution of RFC5033bis"
section. Generally, change logs only exist in published RFCs in
obsoleting documents as a "Changes Since RFC ####" section, which
highlights the substantive changes that took place between the
last published RFC and this one (i.e., mentions errata addressed or
a security consideration that has changed, etc.). If the section
should be kept, may we suggest something like:
Perhaps:
Changes Since RFC 5033
* Harmonized the "proposed congestion control algorithm"
* Examined BCP 14 keywords and consistency with other RFCs
* Added text on constrained environments/limited domains and circuit
breakers and aligned with other RFCs
* Added discussion of real-time protocols, short flows, AQM response,
multipath transports
* Listed properties of wired networks
* Added sections addressing IoT and Multicast (noting this is out of scope)
* Rewrote the "Document Status" section
* Added improved first sentence of Abstract and Introduction
* Reorganized central sections of the document
* Added QUIC, other congestion control standards
* Added wireless environments
* Aligned motivation for this work with the CCWG charter
* Refined discussion of Quick-Start
* Included updated text suggested by Dave Taht
* Added criterion for bufferbloat
* Mentioned CUBIC and BBR as motivation
-->
22) <!--[rfced] We note that there are a number of instances in which an
algorithm or a proposed algorithm takes on human abilities.
Please review the text with this in mind and let us know if any
updates should be made. Some examples below (not exhaustive):
Original:
A proposed congestion control algorithm SHOULD explore...
Perhaps:
A proposal for a congestion control algorithm SHOULD explore...
Original:
A proposed congestion control algorithm ought not to presume...
Perhaps:
Authors of a proposed congestion control algorithm ought not to presume...
Original:
A proposed congestion control algorithm MUST clearly explain any
deviations from [RFC2914] and [RFC7141].
Perhaps:
A proposal for a congestion control algorithm MUST clearly explain any
deviations from [RFC2914] and [RFC7141].
-->
23) <!-- [rfced] FYI - We have added expansions for abbreviations upon
first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
review each expansion in the document carefully to ensure
correctness.
Explicit Congestion Notification (ECN)
Multipath TCP (MPTCP)
-->
24) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
Thank you.
RFC Editor/kf/mf
*****IMPORTANT*****
Updated 2025/02/26
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9743.xml
https://www.rfc-editor.org/authors/rfc9743.html
https://www.rfc-editor.org/authors/rfc9743.pdf
https://www.rfc-editor.org/authors/rfc9743.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9743-diff.html
https://www.rfc-editor.org/authors/rfc9743-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9743-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9743
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9743 (draft-ietf-ccwg-rfc5033bis-08)
Title : Specifying New Congestion Control Algorithms
Author(s) : M. Duke, G. Fairhurst
WG Chair(s) : Eric Kinnear, Reese Enghardt
Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
