jiebi/TextFlow huggingface dataset:
Original text:
consider other non-standard congestion control algorithms that are known to be widely deployed. <del> We note that this guideline is not a requirement for strict Reno- or </del>  Cubic- friendliness as a prerequisite for a proposed congestion control mechanism to advance to Experimental or Standards Track status.  As an example, HighSpeed TCP is a congestion control

Reviewer comments:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Revised text:
consider other non-standard congestion control algorithms that are known to be widely deployed.  <ins> Note that this guideline is not a requirement for strict Reno- or </ins> Cubic- friendliness as a prerequisite for a proposed congestion control mechanism to advance to Experimental or Standards Track status.  As an example, HighSpeed TCP is a congestion control
Original text:
A proposed congestion control algorithm SHOULD consider coexistence with widely deployed real-time congestion control algorithms. <del> Regrettably, at the time of writing, many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications.  It is hoped this situation will change. </del>  To the extent that behavior of widely deployed algorithms is understood, a proposed congestion control algorithm can analyze and

Reviewer comments:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Revised text:
A proposed congestion control algorithm SHOULD consider coexistence with widely deployed real-time congestion control algorithms.  <ins> Regrettably, at the time of writing (2024), many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications.  It is hoped this situation will change. </ins> To the extent that behavior of widely deployed algorithms is understood, a proposed congestion control algorithm can analyze and
Original text:
contribute to harm and/or reduce fairness, these effects also ought to be evaluated. <del> At the time of writing, there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MP-TCP). </del>  6.9.

Reviewer comments:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Revised text:
contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  <ins> At the time of writing (2024), there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MPTCP RFC8684). </ins> 6.9.
Original text:
2. <del> This document applies to proposed congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations for both the answers and the degree of certainty of the answers. Congestion control algorithms without experience of Internet-scale deployment SHOULD seek Experimental status until real-world data is able to answer the questions in general-use.  Congestion control </del>  algorithms with a record of measured Internet-scale deployment MAY <del> directly seek the Standards Track if the community believes it is safe, and the design is stable, guided by the considerations in general-use.  The existence of this data does not waive the other considerations in this document. </del>  Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being <del> actively measured, and where it is possible to deactivate if there are signs of pathological behavior. </del>  Each published congestion control algorithm is REQUIRED to include a statement in the abstract indicating whether or not there is IETF

Reviewer comments:
Make it clear this is about guidelines for authors, not status of this document avoid redundant guidance avoid "subjective" guidance such as "believes"
thanks

Revised text:
2.  <ins> This document applies to proposed congestion control algorithms proposals that seek Experimental or Standards Track status. Evaluation of both cases involves the same questions, but with different expectations for both the answers and the degree of certainty of the answers. Congestion control algorithms without empirical evidence of Internet- scale deployment SHOULD seek Experimental status.  Congestion control </ins> algorithms with a record of measured Internet-scale deployment MAY  <ins> directly seek the Standards Track if there is solid data that reflects that it is safe, and the design is stable, guided by the considerations in general-use.  However, the existence of this data does not waive the other considerations in this document. </ins> Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being  <ins> actively measured, and where it is possible to deactivate them if there are signs of pathological behavior. </ins> Each published congestion control algorithm is REQUIRED to include a statement in the abstract indicating whether or not there is IETF
Original text:
2.  This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations

Reviewer comments:
I suggest that we swap the section 3 and 2 in the sequence of sections so that the readers understand the interpretation of normative text before they read about it. URL

Revised text:
2. <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. 3. </ins> This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations
Original text:
or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). <del> 3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 4. Algorithms can be designed for general Internet deployment or for use

Reviewer comments:
I suggest that we swap the section 3 and 2 in the sequence of sections so that the readers understand the interpretation of normative text before they read about it. URL

Revised text:
or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE).  4. Algorithms can be designed for general Internet deployment or for use
Original text:
5.2.2. <del> General-purpose protocols need to coexist in the Internet with real- </del>  time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available capacity) and more strict latency bounds.  See RFC8836 for a

Reviewer comments:
The title of section 5.2.1 mentions general-purpose transports but the content really about comparing against standard congestion control algorithms, I suggest to reflect that in the section title. URL
Hmmm: This was originally conceived as General-Purpose v Real-Time (next section). If we change this to "standard general-purpose congestion control algorithms" , does it then make "real-time look non-standard - so ought that now be "standard real-time congestion control algorithms"? Would that help?
It was not that clear that it was supposed to convey "general-purpose" VS "real-time". But my main point was that if this is all about congestion control for general purpose transport then lets say that. Competing with general purpose congestion control Competing with real-time congestion control

Revised text:
5.2.2.  <ins> General-purpose algorithms need to coexist in the Internet with real- </ins> time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available capacity) and more strict latency bounds.  See RFC8836 for a
Original text:
General-purpose protocols need to coexist in the Internet with real- time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available <del> capacity) and more strict latency bounds. </del>  RFC8868 provides suggestions for real-time congestion control design and RFC8867 suggests test cases.  RFC9392 describes some

Reviewer comments:
This paragraph is a good summery of what is available related to congestion control when it comes to real-time traffic in the context of this specification. However, all of those referenced resources were developed following the requirements set out by URL , also RFC8836 describes the aspects of real-time conversational media that helps the scope of being real-time. hence, I suggest we add a reference to RFC8836. URL

Revised text:
General-purpose protocols need to coexist in the Internet with real- time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available  <ins> capacity) and more strict latency bounds.  See RFC8836 for a description of the characteristics of this use case and the resulting requirements. </ins> RFC8868 provides suggestions for real-time congestion control design and RFC8867 suggests test cases.  RFC9392 describes some
Original text:
delays for the connections attempting to use Quick-Start.  The Quick- Start method is discussed as an example in RFC9049.  Although out of the scope of this document, proponents of a new algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In

Reviewer comments:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: 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. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Revised text:
delays for the connections attempting to use Quick-Start.  The Quick- Start method is discussed as an example in RFC9049. <ins> 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. </ins> Although out of the scope of this document, proponents of a new algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In
Original text:
requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and <del> a half BDP.  This was unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </del>  This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track

Reviewer comments:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: 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. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Revised text:
requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and  <ins> a half times the Bandwidth Delay Product (BDP).  This was unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </ins> This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track
Original text:
5.3.2. <del> The proposed congestion control algorithm ought to discuss whether it </del>  allows for incremental deployment in the targeted environment.  For a <del> mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </del>  Similarly, if the proposed congestion control algorithm is intended only for specific environments (and not the global Internet), the

Reviewer comments:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: 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. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Revised text:
5.3.2.  <ins> A congestion control algorithm proposal MUST discuss whether it </ins> allows for incremental deployment in the targeted environment.  For a  <ins> mechanism targeted for deployment in the current Internet, the proposal SHOULD discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </ins> Similarly, if the proposed congestion control algorithm is intended only for specific environments (and not the global Internet), the
Original text:
The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control specification explicitly forbids use on the public Internet, the <del> community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </del>  The evaluation in each scenario SHOULD occur over a representative range of bandwidths, delays, and queue depths.  Of course, the set of

Reviewer comments:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: 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. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Revised text:
The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control specification explicitly forbids use on the public Internet, the  <ins> community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </ins> The evaluation in each scenario SHOULD occur over a representative range of bandwidths, delays, and queue depths.  Of course, the set of
Original text:
For these reasons, data center congestion controls are often distinct from those running elsewhere on the Internet (see controlled- <del> environments.  A proposed congestion control need not coexist well </del>  with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it.

Reviewer comments:
All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: 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. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.

Revised text:
For these reasons, data center congestion controls are often distinct from those running elsewhere on the Internet (see controlled-  <ins> environments).  A proposed congestion control need not coexist well </ins> with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it.
Original text:
on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs. <del> 7.1.1. </del>  Some equipment in the network uses an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set

Reviewer comments:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Revised text:
on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs.  <ins> 7.2. </ins> Some equipment in the network uses an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set