Specifying New Congestion Control Algorithms
draft-ietf-ccwg-rfc5033bis-08

[Ballot comment]
Thanks to Sean Turner for his ARTART Review.

I support Roman's DISCUSS position.  Generally I find the addition of BCP 14 language (compared to the document being replaced) to be awkward.  There are 17 SHOULDs; if I were to deviate from or disregard all of them, would I still have something this process ought to be accepting?  And I don't know how it is one is supposed to enforce a SHOULD against "the community" (Section 3.1).  In Section 5 in several places, the SHOULD applies to the proposed algorithm itself, not the proposal (i.e., the document describing it).

[Ballot comment]
Thanks for this document. It is a very helpful document, even for the non-initiated, who are encouraged to read this before unleashing things at scale on the internet :)

[Ballot comment]
Firstly, thank you for writing this -- I'm not really a transport person, and so was not really looking forward to reading this - but it turned out to be a very approachable, friendly and well written document.
Secondly, I'd like to thank Jürgen Schönwälder for the OpsDir review - https://datatracker.ietf.org/doc/review-ietf-ccwg-rfc5033bis-06-opsdir-lc-schoenwaelder-2024-07-06/ . I agree with Jürgen's comments and think that these changes would further improve the document.


I have only a few minor nits and comments to add (these really are just nits - feel free to ignore them / no reply needed):
1: "These congestion control algorithms can suffer performance challenges when used in various environments (e.g. ..." - I wonder if "different" or "differing" might be better than "various". Various sounds like there are specific environments, but instead of a list of what all these are, we only get some examples.

2: Why are you specifically listing these in "This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status." - if someone were to write an Informational congestion control algorithm (e.g documenting how they do congestion control between mesh nodes attached to reindeer in Lapland) should they not also consider many of the same things?
If not, perhaps just adding a sentence along the lines of "Informational documents are encouraged to consider the advice in this document and provide similar documentation" or something? Ah, never mind, I found the Informational text further down -- I suspect it would be polite to the reader to move this section up, but this is just, like, my opinion....
I'm not super-enthused by the amount of IETF process lawyering in "Strictly speaking, Informational RFCs in the IETF stream need not meet all of the criteria in this document, as they do not carry a formal recommendation from the community.  Instead, the community judges the publication of Informational RFCs based on the value of their addition to the RFC series." - if / when IETF process changes we don't want to discover that process notes are lying around in other places and need to be updated -- I'd suggest removing this bit, or replacing it with something like I suggested above...

3: Nit: s/where the Quick- Start request/where the Quick-Start request/

4: I'll just bite my tongue on section 4.

5: "5.  Evaluation Criteria

  As noted above, authors are expected to do a well-rounded evaluation of the pros and cons of congestion control algorithms that are brought to the IETF.  " -- I don't actually see where this is really "noted above". In addition, I'm somewhat confused / bemused by the sentence. Does this mean that: A: the authors are supposed to clearly list the pros and cons of algorithms that they are bringing (which is what I'm assuming you mean), or B: that they are supposed to have evaluated and understood the existing algorithms which their shiny new proposed algorithm will be competing with? Or C: that *participants* are intended to do a good evaluation before approving a new alg?

6: I may be violating my own rant in comment #2, but perhaps this document should note that if a new congestion control algorithm is aiming for Experimental status is should clearly document what the actual experiment is / how success will be judged?

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-ccwg-rfc5033bis-07

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================
## The document is well written and pleasant to read

## The introduction section 1 is a nice historic overview and justification of this draft existence

## My comments are of editorial nature intended to improve the story flow


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

13   Introducing new or modified congestion control algorithms in the
14   global Internet has possible ramifications to both the flows using
15   the proposed congestion control algorithms and to flows using a
16   standardized congestion control algorithm.  Therefore, the IETF must
17   proceed with caution when evaluating proposals for alternate
18   congestion control.  The goal of this document is to provide guidance
19   for considering standardization of a proposed congestion control
20   algorithm at the IETF.  It obsoletes RFC5033 to reflect changes in
21   the congestion control landscape.

[minor]
Would the following be a possible alternate abstract that covers the document intent?

"
This document revises and updates RFC 5033, which discusses the principles and guidelines for designing and evaluating new congestion control algorithms. The aim is to ensure that proposed congestion control algorithms operate fairly and efficiently alongside standardized 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 and interoperability across diverse network environments.
"

140   This document obsoletes [RFC5033], which was published in 2007 as a
141   Best Current Practice to evaluate proposed congestion control
142   algorithms as Experimental or Proposed Standard RFCs.

[minor]
re-edit proposal from readability perspective

"
This document obsoletes RFC 5033, which was published in 2007 as a Best Current Practice for evaluating proposed congestion control algorithms as Experimental or Proposed Standard RFCs.
"

151   When [RFC5033] was published in 2007, TCP [RFC9293] was the dominant
152   consumer of IETF congestion control work, and proposals were
153   typically discussed in the Internet Congestion Control Research Group
154   (ICCRG).  Around the same time, the Datagram Congestion Control
155   Protocol (DCCP) [RFC4340] was developed as a method for defining new
156   congestion control algorithms for datagram traffic.  The Stream
157   Control Transmission Protocol (SCTP) [RFC9260] re-used TCP congestion
158   control algorithms.

160   Since then, many conditions have changed.  The set of protocols using
161   congestion control algorithms has grown to include QUIC [RFC9000],
162   RTP Media Congestion Avoidance Techniques (RMCAT) (e.g., [RFC8836])
163   and beyond.  Some proponents of alternative congestion control
164   algorithms now have the opportunity to test and deploy at scale
165   without IETF review.  There is more interest in specialized use
166   cases, such as data centers (e.g., [RFC8257]), and in support for a
167   variety of upper layer protocols/applications, e.g., real-time
168   protocols.  Finally, the community has gained much more experience
169   with indications of congestion beyond packet loss.

[minor]
proposed alternate textblob for easier to consume flow

"
When [RFC5033] was published in 2007, TCP [RFC9293] was the primary focus of IETF congestion control efforts, with proposals typically discussed within the Internet Congestion Control Research Group (ICCRG). Concurrently, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was developed to define new congestion control algorithms for datagram traffic, while the Stream Control Transmission Protocol (SCTP) [RFC9260] reused TCP congestion control algorithms.

Since then, several changes have occurred. The range of protocols utilizing congestion control algorithms has expanded to include QUIC [RFC9000] and RTP Media Congestion Avoidance Techniques (RMCAT) (e.g., [RFC8836]. Additionally, some alternative congestion control algorithms can now be tested and deployed at scale without IETF review. There is increased interest in specialized use cases, such as data centers (e.g., [RFC8257], and in supporting a variety of upper layer protocols and applications, such as real-time protocols. Moreover, the community has gained significant experience with congestion indications beyond packet loss.
"

392   As noted above, authors are expected to do a well-rounded evaluation
393   of the pros and cons of congestion control algorithms that are
394   brought to the IETF.  The following guidelines are designed to help
395   authors and the IETF community.  Concerns that fall outside the scope
396   of these guidelines are certainly possible; these guidelines should
397   not be considered an all-encompassing check-list.

[minor]
proposed alternate textblob

"
As previously noted, authors are expected to conduct a comprehensive evaluation of the advantages and disadvantages of congestion control algorithms presented to the IETF. The following guidelines are intended to assist authors and the IETF community in this endeavor. While these guidelines provide a helpful framework, they should not be regarded as an exhaustive checklist, as concerns beyond the scope of these guidelines may also arise.
"

[Ballot comment]
# Internet AD comments for draft-ietf-ccwg-rfc5033bis-07
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.2

* "Each published algorithm is also required to include" ->
  "Each published algorithm is also REQUIRED to include"?

### S5.3.2

* Does "Incremental Deployment" include testing using the CC ALG on only
  one side of the connection (i.e. client-only or server-only)?

  Perhaps that's covered by other text in other sections, though.

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-ccwg-rfc5033bis-07
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ccwg-rfc5033bis-07.txt&submitcheck=True

Thanks to Sean Turner for the ART ART Review.

I support Roman's discuss.

## Comments

### Normative guidance in BCPs

I agree with Sean's comments regarding RFC6962-like language.

```
284   Before a proposed congestion control algorithm is published as an
285   Experimental or Standards Track RFC, the community SHOULD gain
286   practical experience with implementation and experience using the
287   algorithm.  Where there is implementation by independent teams, this
```

In the context of a BCP, I find this SHOULD a bit confusing.

My intuition is that it is common sense that communities MUST obtain some experience from implementation and experimentation in order to be following the "best current practice".

Are there cases that are relevant to this BCP where it is NOT RECOMMENDED to do this?

```
306   Congestion control algorithms without empirical evidence of Internet-
307   scale deployment SHOULD seek Experimental status.
```

When is this a MUST, and when (in the context of IETFs view of "Best Current Practice" per Section 5 RFC2026 ) can it be ignored?

### Strengthen Security Considerations

```
886   The IETF process that results in publication needs to ensure that
887   these security implications are considered.  Proposed congestion
888   control algorithms therefore ought to be mindful of pitfalls, and
889   SHOULD examine any potential security issues that may arise.
```

It seems a small red flag to have only a single SHOULD under security considerations for a BCP.

When in the context of a BCP, is it ok to ignore potential security issues that may arise?

7.10 has several instances of the word "harm" which I am not sure are security or performance issues.

Is it considered BCP to run experiments in order to gather empirical evidence to support upgrading an Experimental status document to Standards Track?

Is there a security risk of having "too many experiments" running at once? or are these questions out of scope for this document?

[Ballot comment]
Thanks for the work done in this document, it is easy to read even for a non-transport person.

Some comments (feel free to ignore):

- should there be a reference for DSCP ?

- thanks for taking care of multipath/multihoming

My biggest concern is about section 7.4 `many IoT applications do not a have a human in the loop, and therefore can have weaker latency constraints because they do not relate to a user experience`. I do not think that it is really true for manufacturings/nuclear plants, robots, ... IoT covers a lot of different use cases. Perhaps use "constrained networks" rather than "IoT" ?

[Ballot discuss]
** Section 5

(a) Section 5.0 says “When considering a proposed congestion control algorithm, the community MUST consider the following criteria”, where there are subsequent 5.* sections which provide normative language.

(b) Section 5.1.5 says “A proposed congestion control algorithm MUST consider how new and short-lived flows affect long-lived flows, and vice versa.”

(c) Section 5.2.1 says “A proposed congestion control algorithm SHOULD be evaluated when competing using standard IETF congestion controls”

(d) Section 5.2.2 says the “… proposed congestion control algorithm SHOULD consider coexistence    with widely deployed real-time congestion
control algorithms.”

(e) Section 5.3.1 says “A proposed congestion control algorithm SHOULD include a clear …”

(f) Section 6 says “… the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress.”

-- Per (a), what does it mean to for a specification to be required to “MUST consider”?  Does that consideration have to be manifest if the new document?  (b) uses a similar construct.

-- Per (a) combined with (c), (d) or (e): what does is mean for a specification to “MUST consider” (a) combined with “SHOULD … evaluate” (in (c)), “SHOULD consider” (in (d)) or “SHOULD include” (in (e))?

** Section 6.  The following appears to be underspecified.
  The criteria in Section 5 will be evaluated in the following
  scenarios.  Unless a proposed congestion control specification
  explicitly forbids use on the public Internet, the community MUST
  reach consensus that it meets the criteria in these scenarios for the
  proposed congestion control algorithm to progress.

The text above seems to imply a mandatory evaluation process which is the cross product of the criteria in Section 5.* and the scenarios described in Section 6.*.

Let’s take an example of Sections 5.2.3 + 6.1.
  5.2.3.  Short and Long Flows

  The effect on short-lived and long-lived flows using other common
  congestion control algorithms MUST be evaluated, as in Section 5.1.5.

  6.1.  Paths with Tail-drop Queues

  The performance of a congestion control algorithm is affected by the
  queue discipline applied at the bottleneck link.  The drop-tail queue
  discipline (using a FIFO buffer) MUST be evaluated.  See Section 7.1
  for evaluation of other queue disciplines.

What would it mean for an algorithm to “meet the criteria in these scenarios” (Section 6.0) for short/long terms flows on paths with trail-drop queues.  The guiding text on both 5.2.3 and 6.1 only says that properties should be “evaluated”.  How can this be repeatably applied?

[Ballot comment]
Thank you to Joel Halpern for the GENART review.

** Section 3.2               
    Authors documenting
    deployed congestion control algorithms that cannot be changed by IETF
    or IRTF review are invited to publish as an Informational RFC via the
    Independent Stream Editor (ISE).

The ISE may choose not to publish the document.  Should s/are invited to publish/can seek publication/.  This is the same language used for the IRTF.

** Section 4
    Algorithms that rely on specific functions or configurations in the
    network need to provide a reference or specification for these
    functions (an RFC or another stable specification).  The IETF will
    need to assess whether the relevant working group is able to review
    the proposed new algorithm and whether there is sufficient experience
    to understand any dependent functions.

Is the second sentence describing a procedure that is any different that the standing approach for all normative references – the WG needs to evaluate if it can get to that reference?  If it isn’t novel, why is it needed?

** Section 6.
    ... the community MUST
    reach consensus that it meets the criteria in these scenarios for the
    proposed congestion control algorithm to progress.

Who is the community in this normative guidance?  Is that the IETF standards process? 

** Section 8

  The IETF process that results in publication needs to ensure that
  these security implications are considered.  Proposed congestion
  control algorithms therefore ought to be mindful of pitfalls, and
  SHOULD examine any potential security issues that may arise.

-- What is the “IETF process that results in publication”?  How is that different than the process for producing any other document?

-- Why is the requirement for coverage security considerations in future specification stated as optional (SHOULD).  Under what circumstances should potential security issues NOT be discussed.  I would recommend using a lower case should.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ccwg-rfc5033bis-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-07-08):

From: The IESG
To: IETF-Announce
CC: ccwg-chairs@ietf.org, ccwg@ietf.org, draft-ietf-ccwg-rfc5033bis@ietf.org, ietf@tenghardt.net, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Specifying New Congestion Control Algorithms) to Best Current Practice


The IESG has received a request from the Congestion Control Working Group WG
(ccwg) to consider the following document: - 'Specifying New Congestion
Control Algorithms'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-07-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Introducing new or modified congestion control algorithms in the
  global Internet has possible ramifications to both the flows using
  the proposed congestion control algorithms and to flows using a
  standardized congestion control algorithm.  Therefore, the IETF must
  proceed with caution when evaluating proposals for alternate
  congestion control.  The goal of this document is to provide guidance
  for considering standardization of a proposed congestion control
  algorithm at the IETF.  It obsoletes RFC5033 to reflect changes in
  the congestion control landscape.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccwg-rfc5033bis/



No IPR declarations have been submitted directly on this I-D.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached broad agreement in the Working Group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No, and nobody raised any concerns about publication.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The question does not apply. This document is a BCP, not a protocol specification.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This draft has benefited from broad TSV and WIT area review within the WG itself. There were a number of detailed reviews across the entire document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The question does not apply.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The question does not apply.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The question does not apply.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document does not describe a protocol, so considerations regarding port registration do not apply.
The document is protocol-agnostic, so considerations regarding TCP, UDP, SCTP, or QUIC specifically do not apply, but the document mentions that congestion controllers are used by different protocols.
The document discusses ECN under Section 6.1 and mentions considerations around (misbehaving) middleboxes in Section 6.5.
The document discusses tunneling and nested congestion control interactions in Section 5.2 and specifies that new congestion control proposals that rely on explicit signals from the path MUST consider tunneling.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document obsoletes RFC 5033, which is BCP 133.
As a Best Current Practice, the document standardizes practices of how the IETF considers congestion control proposals, specifically new algorithms.
The document represents the results of community deliberations within CCWG on the evaluation criteria and scenarios that ought to be considered.
The "Intended RFC status" Datatracker attribute reflects this intention.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; no IPR issues are known.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is 1 instance of lines with non-ascii characters in the document. This appears to be an outdated warning per RFC 7997.
All outdated references are intentional and refer to different versions of a congestion control algorithm being discussed as examples for how congestion controllers evolve.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not have any normative references that are not freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document obsoletes RFC 5033, and RFC 5033 is discussed on the title page, in the abstract, and in the introduction.
I am not aware of any Datatracker metadata that would need to be set now. Other documents show "Updates" or "Obsoletes" under "Type" but I cannot edit this field as a WG chair, and I presume it'll be updated once this document is approved.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions, which is appropriate.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The question does not apply.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached broad agreement in the Working Group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No, and nobody raised any concerns about publication.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The question does not apply. This document is a BCP, not a protocol specification.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This draft has benefited from broad TSV and WIT area review within the WG itself. There were a number of detailed reviews across the entire document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The question does not apply.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The question does not apply.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The question does not apply.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document does not describe a protocol, so considerations regarding port registration do not apply.
The document is protocol-agnostic, so considerations regarding TCP, UDP, SCTP, or QUIC specifically do not apply, but the document mentions that congestion controllers are used by different protocols.
The document discusses ECN under Section 6.1 and mentions considerations around (misbehaving) middleboxes in Section 6.5.
The document discusses tunneling in Section 5.2 and specifies that new congestion control proposals that rely on explicit signals from the path MUST consider tunneling.
It does not currently discuss nested congestion control interactions.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document obsoletes RFC 5033, which is BCP 133.
As a Best Current Practice, the document standardizes practices of how the IETF considers congestion control proposals, specifically new algorithms.
The document represents the results of community deliberations within CCWG on the evaluation criteria and scenarios that ought to be considered.
The "Intended RFC status" Datatracker attribute reflects this intention.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; no IPR issues are known.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is 1 instance of lines with non-ascii characters in the document. This appears to be an outdated warning per RFC 7997.

The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords.

Outdated references:

  == Outdated reference: A later version (-02) exists of
    draft-cardwell-iccrg-bbr-congestion-control-00

  -- Duplicate reference: draft-cardwell-iccrg-bbr-congestion-control,
    mentioned in 'BBRv1-draft', was also mentioned in 'BBR-draft'.

The two references to BBR intentionally refer to different revisions of the draft, as this document discusses the history of BBR.

  -- Obsolete informational reference (is this intentional?): RFC 2988
    (Obsoleted by RFC 6298)

  -- Obsolete informational reference (is this intentional?): RFC 8312
    (Obsoleted by RFC 9438)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not have any normative references that are not freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document obsoletes RFC 5033, and RFC 5033 is discussed on the title page, in the abstract, and in the introduction.
I am not aware of any Datatracker metadata that would need to be set now. Other documents show "Updates" or "Obsoletes" under "Type" but I cannot edit this field as a WG chair, and I presume it'll be updated once this document is approved.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions, which is appropriate.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The question does not apply.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached broad agreement in the Working Group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No, and nobody raised any concerns about publication.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The question does not apply. This document is a BCP, not a protocol specification.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This draft has benefited from broad TSV and WIT area review within the WG itself. There were a number of detailed reviews across the entire document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The question does not apply.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The question does not apply.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The question does not apply.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document does not describe a protocol, so considerations regarding port registration do not apply.
The document is protocol-agnostic, so considerations regarding TCP, UDP, SCTP, or QUIC specifically do not apply, but the document mentions that congestion controllers are used by different protocols.
The document discusses ECN under Section 6.1 and mentions considerations around (misbehaving) middleboxes in Section 6.5.
The document discusses tunneling in Section 5.2 and specifies that new congestion control proposals that rely on explicit signals from the path MUST consider tunneling.
It does not currently discuss nested congestion control interactions.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document obsoletes RFC 5033, which is BCP 133.
As a Best Current Practice, the document standardizes practices of how the IETF considers congestion control proposals, specifically new algorithms.
The document represents the results of community deliberations within CCWG on the evaluation criteria and scenarios that ought to be considered.
The "Intended RFC status" Datatracker attribute reflects this intention.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; no IPR issues are known.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is 1 instance of lines with non-ascii characters in the document. This appears to be an outdated warning per RFC 7997.

The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords.

Outdated references:

  == Outdated reference: A later version (-02) exists of
    draft-cardwell-iccrg-bbr-congestion-control-00

  -- Duplicate reference: draft-cardwell-iccrg-bbr-congestion-control,
    mentioned in 'BBRv1-draft', was also mentioned in 'BBR-draft'.

The two references to BBR intentionally refer to different revisions of the draft, as this document discusses the history of BBR.

  -- Obsolete informational reference (is this intentional?): RFC 2988
    (Obsoleted by RFC 6298)

  -- Obsolete informational reference (is this intentional?): RFC 8312
    (Obsoleted by RFC 9438)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not have any normative references that are not freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document obsoletes RFC 5033, and RFC 5033 is discussed on the title page, in the abstract, and in the introduction.
I am not aware of any Datatracker metadata that would need to be set now. Other documents show "Updates" or "Obsoletes" under "Type" but I cannot edit this field as a WG chair, and I presume it'll be updated once this document is approved.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions, which is appropriate.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The question does not apply.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached broad agreement in the Working Group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The question does not apply. This document is a BCP, not a protocol specification.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This draft has benefited from broad TSV and WIT area review within the WG itself.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The question does not apply.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The question does not apply.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The question does not apply.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document does not describe a protocol, so considerations regarding port registration do not apply.
The document is protocol-agnostic, so considerations regarding TCP, UDP, SCTP, or QUIC specifically do not apply, but the document mentions that congestion controllers are used by different protocols.
The document discusses ECN under Section 6.1 and mentions considerations around (misbehaving) middleboxes in Section 6.5.
The document discusses tunneling in Section 5.2 and specifies that new congestion control proposals that rely on explicit signals from the path MUST consider tunneling.
It does not currently discuss nested congestion control interactions.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document obsoletes RFC 5033, which is BCP 133.
As a Best Current Practice, the document standardizes practices of how the IETF considers congestion control proposals, specifically new algorithms.
The document represents the results of community deliberations within CCWG on the evaluation criteria and scenarios that ought to be considered.
The "Intended RFC status" Datatracker attribute reflects this intention.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes; no IPR issues are known.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is 1 instance of lines with non-ascii characters in the document. This appears to be an outdated warning per RFC 7997.

The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords.

Outdated references:

  == Outdated reference: A later version (-02) exists of
    draft-cardwell-iccrg-bbr-congestion-control-00

  -- Duplicate reference: draft-cardwell-iccrg-bbr-congestion-control,
    mentioned in 'BBRv1-draft', was also mentioned in 'BBR-draft'.

The two references to BBR intentionally refer to different revisions of the draft, as this document discusses the history of BBR.

  -- Obsolete informational reference (is this intentional?): RFC 2988
    (Obsoleted by RFC 6298)

  -- Obsolete informational reference (is this intentional?): RFC 8312
    (Obsoleted by RFC 9438)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The document does not have any normative references that are not freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document obsoletes RFC 5033, and RFC 5033 is discussed on the title page, in the abstract, and in the introduction.
I am not aware of any Datatracker metadata that would need to be set now. Other documents show "Updates" or "Obsoletes" under "Type" but I cannot edit this field as a WG chair, and I presume it'll be updated once this document is approved.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document has no IANA actions, which is appropriate.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The question does not apply.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

The document obsoletes RFC 5033, which is BCP 133.
As a BCP, the document standardizes practices of how the IETF considers congestion control proposals, specifically new algorithms.
The document represents the results of community deliberations within CCWG on the evaluation criteria and scenarios that ought to be considered.