jiebi/TextFlow huggingface dataset:
Original text:
specification can help multiple contributors align on a consensus change to the algorithm. <del> A specification that is accessible to anyone circumvents the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. </del>  Beyond helping develop specific algorithm proposals, guidelines can also serve as a reminder to potential inventors and developers of the

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
specification can help multiple contributors align on a consensus change to the algorithm.  <ins> A specification that is accessible to anyone can circumvent the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. </ins> Beyond helping develop specific algorithm proposals, guidelines can also serve as a reminder to potential inventors and developers of the
Original text:
proposals in this space. This document is meant to reduce the barriers to entry for new <del> congestion control work to the IETF.  As such, proponents ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </del>  2.

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
proposals in this space. This document is meant to reduce the barriers to entry for new  <ins> congestion control work to the IETF.  As such, proponents of new congestion control algorithms ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </ins> 2.
Original text:
The criteria in this section evaluate the congestion control algorithm when one or more flows using that algorithm share a <del> bottleneck link (i.e. with no flows using a differing congestion </del>  control algorithm). 4.1.1.

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
The criteria in this section evaluate the congestion control algorithm when one or more flows using that algorithm share a  <ins> bottleneck link (i.e., with no flows using a differing congestion </ins> control algorithm). 4.1.1.
Original text:
4.2. <del> These criteria evaluate the interaction of the proposed congestion control algorithm with commonly deployed congestion control algorithms. </del>  In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
4.2.  <ins> Mixed algorithm behavior criteria evaluate the interaction of the proposed congestion control algorithm with commonly deployed congestion control algorithms. </ins> In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control
Original text:
a proposal targeting general Internet use can not assume this is always the case.  4.2.3. The effect on short-lived and long-lived flows using other common

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
a proposal targeting general Internet use can not assume this is always the case. <ins> circuit-breakers describes the impact of network transport circuit breaker algorithms.  RFC8083 also defines a minimal set of RTP circuit breakers that operate across a path.  This identifies conditions under which a sender needs to stop transmitting media data to protect the network from excessive congestion.  It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. </ins> 4.2.3. The effect on short-lived and long-lived flows using other common
Original text:
4.3.1. <del> Proposed congestion control algorithms SHOULD include a clear </del>  explanation of any deviations from RFC2914 and RFC7141. 4.3.2.

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
4.3.1.  <ins> A proposed congestion control algorithm SHOULD include a clear </ins> explanation of any deviations from RFC2914 and RFC7141. 4.3.2.
Original text:
on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs.  6.2. An Internet Path can include simple links, where the minimum delay is

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs. <ins> 6.1.1. Some equipment in the network use an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set of flows RFC8084.  Such a network transport circuit breaker can automatically detect excessive congestion, and when detected, it can terminate (or significantly reduce the rate of) the flow(s).  A well- designed congestion control algorithm ought to react before the flow uses excessive resources and therefore will operate within the envelope set by network transport circuit breaker algorithms. </ins> 6.2. An Internet Path can include simple links, where the minimum delay is
Original text:
might then have to buffer data until an assigned transmission opportunity or when the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of <del> operation).  Variation also arises when a higher priority diffserv traffic classic prompts the transmission by a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </del>  A proposed congestion control algorithm SHOULD be evaluated to ensure their operation is robust when there is a significant change in the

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
might then have to buffer data until an assigned transmission opportunity or when the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of  <ins> operation).  Variation also arises when traffic with a higher priority diffserv class pre-empts transmission of traffic with a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </ins> A proposed congestion control algorithm SHOULD be evaluated to ensure their operation is robust when there is a significant change in the
Original text:
operating congestion controls. For these reasons, data center congestion controls are often distinct <del> from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </del>  7.

Reviewer comments:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Revised text:
operating congestion controls. For these reasons, data center congestion controls are often distinct  <ins> from those running elsewhere on the Interenet (see controlled- environments).  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 7.
Original text:
Another example use is concurrent multipath, where the transport protocol simultaneously schedules flows to aggregate the capacity <del> across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows.  Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </del>  6.9.

Reviewer comments:
Proposed text to add MP-TCP RFCs.
From NAME review: Section 5.8: What is the verdict on RFC 6356? Is it not worth bringing this up in relation to concurrent usage? RFC 8041 do bring up additional experience with also other algorithms for MP-TCP that have been tried. I would at least claim “At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet.” that this sentence is factual wrong as RFC 6356 is an IETF experimental specification. I do think this section brings up important aspects to consider. However, it also point to some interesting challenges in reasoning and responsibility between functionalities when managing different paths. Looking at the text I think we have scheduler application data, path availability checks as well as congestion control all impacting what is happening. What is truly congestion control here?

Revised text:
Another example use is concurrent multipath, where the transport protocol simultaneously schedules flows to aggregate the capacity  <ins> across multiple paths. The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows. Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated. 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). </ins> 6.9.
Original text:
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 <del> algorithm at the IETF.  It replaces RFC5033 to reflect changes in the congestion control landscape. </del>  1.

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:
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  <ins> algorithm at the IETF.  It obsoletes RFC5033 to reflect changes in the congestion control landscape. </ins> 1.
Original text:
then adopted as the default congestion control algorithm for the TCP implementation in Linux.  It was already used in a significant fraction of TCP connections over the Internet before being documented <del> in an Informational Internet Draft in 2015, published as an </del>  Informational RFC in 2017 RFC8312 and then as a Proposed Standard in 2023 RFC9438. BBR is developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It <del> was described in an IRTF draft in 2018, and that draft is regularly updated to document the evolving versions of the algorithm BBR-draft. BBR is widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </del>  We cannot say now whether the original authors of RFC5033 expected that developers would be somehow waiting for IETF review before

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:
then adopted as the default congestion control algorithm for the TCP implementation in Linux.  It was already used in a significant fraction of TCP connections over the Internet before being documented  <ins> in an Informational Internet-Draft in 2015, published as an </ins> Informational RFC in 2017 RFC8312 and then as a Proposed Standard in 2023 RFC9438. BBR is developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It  <ins> 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.  BBR is widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </ins> We cannot say now whether the original authors of RFC5033 expected that developers would be somehow waiting for IETF review before
Original text:
A specification can help potential contributors understand the algorithm, which can make it easier for them to suggest <del> improvements and/or identify limitations.  Further, the </del>  specification can help multiple contributors align on a consensus change to the algorithm.

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 specification can help potential contributors understand the algorithm, which can make it easier for them to suggest  <ins> improvements and/or identify limitations.  Furthermore, the </ins> specification can help multiple contributors align on a consensus change to the algorithm.
Original text:
the developers of alternative algorithms and by the IETF in the context of each proposal. <del> The high-order criterion for advancing any proposal is a serious scientific study of the pros and cons that occur when the proposal is considered for publication by the IETF or before it is deployed at large scale. </del>  <del> After initial studies, we encourage authors to write a specification of their proposal for publication in the RFC series.  This allows others to concretely understand and investigate the wealth of </del>  proposals in this space. This document is meant to reduce the barriers to entry for new

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:
the developers of alternative algorithms and by the IETF in the context of each proposal.  <ins> The high-order criterion for advancing any proposal within the IETF is a serious scientific study of the pros and cons that occur when the proposal is considered for publication by the IETF or before it is deployed at large scale. </ins>  <ins> After initial studies, authors are encouraged to write a specification of their proposal for publication in the RFC series. This allows others to understand and investigate the wealth of </ins> proposals in this space. This document is meant to reduce the barriers to entry for new