On Mar 1, 2025, at 2:42 AM, Gorry Fairhurst<go...@erg.abdn.ac.uk> wrote:
Thanks for doing this - It is good to get this precise as a BCP, and we have
replies to your questions (see below), and also a few extra requests.
Martin and I have coordinated, but he'll chime-in if there any additional
requests.
Best wishes,
Gorry
---
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. -->
GF> I think it ought to be added to it.
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 onhttps://www.rfc-editor.org/search.
-->
GF> I suggest adding: Transport, CC.
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.
-->
GF> I think this doesn't precisely capture what was intended, would this be
acceptable:
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
network paths.
The document seeks to ensure that proposed congestion control algorithms operate
efficiently and without harm when used 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.
-->
GF> OK: Please do align with the reference.
---
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 in 2015,
and published as an Informational RFC in 2017 as [RFC8312]
and then as a Proposed Standard in 2023 [RFC9438].
-->
GF> Option B (above) seems correct.
---
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].
-->
GF> I think this doesn't precisely capture what was intended, would this be
acceptable:
BBR was described in an Internet-Draft in 2018 and was first presented
in the IRTF internet congestion control research group.
It has since 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.
-->
GF> OK
---
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.
-->
GF> That doesn't capture it, we suggest:
When a working group is seeking to decide if a proposed
specification is ready for publication, it will normaly consider
evidence of results. This ought to be
documented in any request from the working group to publish the
specification.
---
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.
-->
GF> OK.
---
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.
-->
GF> Your update looks good to me.
---
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.
-->
GF> Please add this after the original text:
NEW:
Algorithms not targeted at general use do not require internet-scale data.
---
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]).
-->
GF> We suggest replacing the current text by
NEW:
Section 4 of [RFC7414] provides other examples of extensions that were
considered experimental when the specification was
published.
---
14) <!-- [rfced]
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.
-->
GF> OK.
---
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.
-->
GF> OK.
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])..."
-->
GF> Please don't change the reference. I believe the method specified in RFC5681 is
widely known in the community as "Reno". We ought to refer to it as such.
---
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].
-->
GF> OK, thanks.
---
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].
-->
GF> OK.
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.
-->
GF> The porposed change is OK.
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
GF> Yes, please use this.
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
-->
GF> Thanks, OK.
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
-->
GF> Thanks, I think this ought to be reduced.
I suggest a shortened key changes section, as below
NEW:
Key Changes Since RFC 5033
* Examined BCP 14 keywords and consistency with other RFCs
* Rewrote the "Document Status" section
* Added QUIC, other more recent congestion control standards
* Aligned motivation for this work with the CCWG charter
* Refined discussion of Quick-Start
* Added criterion for bufferbloat
* 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 and wireless networks
* Added sections addressing IoT and Multicast (noting this is out of scope)
---
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].
-->
GF> All of these changes are OK.
---
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)
-->
GF> Thanks, OK.
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. -->
GF> OK.
Thank you.
RFC Editor/kf/mf
---
Additional issues
** Note: in 5.1.4: This change seems wrong. The proposer to the IETF needs to
describe evaluation to advance a proposal. However, the specification when
completed does NOT need to specify/document this, but might refer to a document
that does this.
ORIGINAL:
the proposal should explore how the capacity is
PROPOSED by RFC-ED:
the specification should explore how the capacity
GF> Please modify
NEW:
the evaluation should explore how the capacity
----
** /on/of/.
PROPOSED by RFC-ED:
Specifications on congestion control algorithms
NEW:
Specifications of congestion control algorithms
GF> Is this new text acceptable?
---
** /Sec 3.1
GF> "the Internet scale" sounds wrong to my ears. I don't care about the hyphen, but
please lose the "the".
OLD
(within a limited domain or at Internet-scale)
NEW
(within a limited domain or at the Internet scale)
---
** Sec 5.1.2
GF> We prefer we avoid lower case should:
OLD
A congestion control algorithm should try to avoid maintaining excessive
queues in the network.
NEW
A congestion control algorithm ought to try to avoid maintaining excessive
queues in the network.
---
** Sec 5.1.2
GF> The grammar is now broken in a new sentence. I suggest this change
OLD
The Standards Track RFCs [RFC5681] and [RFC9438] describing the Reno and CUBIC
congestion control algorithms (respectively) send at progressively higher rates
until a First In, First Out (FIFO) buffer completely fills; then packet losses
occur.
NEW
The Standards Track RFCs [RFC5681] and [RFC9438] describe the Reno and CUBIC
congestion control algorithms (respectively), which send at progressively
higher rates until a First In, First Out (FIFO) buffer completely fills; then
packet losses occur.
---
** Sec 7.4
GF> Avoid lower-case "may"
OLD
Congestion control algorithms still may need to share the path with other flows
with different constraints.
NEW
Congestion control algorithms still might need to share the path with other
flows with different constraints.
---
** Sec 7.8
GF> The 'algorithm' doesn't need to consider anything, the designer does:
OLD
A proposed congestion control algorithm SHOULD consider how it would perform in
the presence of transient events such as a sudden onset of congestion, a
routing change, or a mobility event.
NEW
A proposal for a congestion control algorithm SHOULD consider how it would
perform in the presence of transient events such as a sudden onset of
congestion, a routing change, or a mobility event.
---
END.
*****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
