jiebi/TextFlow huggingface dataset:
Original text:
include complex subnetworks where the minimum delay changes over various time scales, resulting in a non- stationary minimum delay. <del> This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes.  A node might then have to buffer data until an assigned transmission opportunity or until the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation). Variation also arises when traffic with a higher priority DSCP 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.  This variation in the delay over short timescales (jitter) might not be distinguishable from jitter that results from other effects. </del>  A proposed congestion control algorithm SHOULD be evaluated to ensure its operation is robust when there is a significant change in the

Reviewer comments:
Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).

Revised text:
include complex subnetworks where the minimum delay changes over various time scales, resulting in a non- stationary minimum delay.  <ins> Varying delay occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes.  A node might then have to buffer data until an assigned transmission opportunity or until the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation).  Variation also arises when traffic with a higher priority DSCP 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.  This variation in the delay over short timescales (jitter) might not be distinguishable from jitter that results from other effects. </ins> A proposed congestion control algorithm SHOULD be evaluated to ensure its operation is robust when there is a significant change in the
Original text:
The IETF specifies standard Internet congestion control algorithms in the RFC-series.  These congestion control algorithms can suffer <del> performance challenges when used in various environments (e.g., high- speed networks, cellular and WiFi wireless technologies, and long distance satellite links), and also when flows carry specific </del>  workloads (Voice over IP (VoIP), gaming, and videoconferencing). When RFC5033 was published in 2007, TCP RFC9293 was the dominant

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
The IETF specifies standard Internet congestion control algorithms in the RFC-series.  These congestion control algorithms can suffer  <ins> performance challenges when used in differing environments (e.g., high-speed networks, cellular and WiFi wireless technologies, and long distance satellite links), and also when flows carry specific </ins> workloads (Voice over IP (VoIP), gaming, and videoconferencing). When RFC5033 was published in 2007, TCP RFC9293 was the dominant
Original text:
documented in any request for the working group to publish the specification.  3.2. This document applies to proposals for congestion control algorithms

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
documented in any request for the working group to publish the specification. <ins> Publication might occur without multiple implementations if a single implementation is widely used, open source, and shown to have positive impact on the Internet, particularly if the target status is Experimental. </ins> 3.2. This document applies to proposals for congestion control algorithms
Original text:
for both the answers and the degree of certainty of those answers. Congestion control algorithms without empirical evidence of Internet- <del> scale deployment SHOULD seek Experimental status. </del>  Congestion control algorithms with a record of measured Internet- scale deployment MAY directly seek the Standards Track if there is

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
for both the answers and the degree of certainty of those answers. Congestion control algorithms without empirical evidence of Internet-  <ins> scale deployment MUST seek Experimental status, unless they are not targeted at general use. Specifications published as Experimental ought to explain the reason for the status and what further information would be required to progress to standards track.  For example, section 12 of RFC6928 provides "Usage and Deployment Recommendations" that describe the experiments expected by the TCPM working group.  Section 4 of RFC4614 provides other examples of extensions that were considered experimental when the specification was published. Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being actively measured, and where it is possible to deactivate them if there are signs of pathological behavior. </ins> Congestion control algorithms with a record of measured Internet- scale deployment MAY directly seek the Standards Track if there is
Original text:
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 actively measured, and where it is possible to deactivate them 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 consensus that the proposed congestion control algorithm is

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
of this data does not waive the other considerations in this document.  Each published congestion control algorithm is REQUIRED to include a statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is
Original text:
the Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating that the mechanism is only being proposed for use in controlled environments.  The abstract specifies <del> environments where the Quick- Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment is not recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start.  The Quick- Start method is discussed as an example in RFC9049. </del>  Strictly speaking, Informational RFCs in the IETF stream need not meet all of the criteria in this document, as they do not carry a

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
the Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating that the mechanism is only being proposed for use in controlled environments.  The abstract specifies  <ins> environments where the Quick-Start request could give false positives (and therefore would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment is not recommended because it could lead to unnecessary 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
Original text:
5. <del> 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.  The following guidelines are designed to help authors and the IETF community.  Concerns that fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered an all-encompassing check-list. </del>  When considering a proposed congestion control algorithm, the community MUST consider the following criteria.  These criteria will

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
5.  <ins> Authors are expected to evaluate the congestion control algorithms that they bring to the IETF.  The working group is expecteed to complete a well-rounded evaluation of the pros and cons of an algorithm before it submits the specification for publication by the IETF. The following guidelines are designed to help authors and the IETF community.  Concerns that fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered an all-encompassing check-list. </ins> When considering a proposed congestion control algorithm, the community MUST consider the following criteria.  These criteria will
Original text:
most Internet flows. Furthermore, many IoT applications do not a have a human in the loop, <del> and therefore can have weaker latency constraints because they do not relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. </del>  7.5.

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
most Internet flows. Furthermore, many IoT applications do not a have a human in the loop,  <ins> and therefore might have weaker latency constraints because they do not relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. </ins> 7.5.
Original text:
state of each path, and demonstrate independent congestion control for each path being used.  Authors of a proposed multipath congestion control algorithm that implements path fail-over MUST evaluate the <del> harm resulting from a change in the path, and show that this does not result in flow starvation.  Synchronisation of failover (e.g., where multiple flows change their path on similar timeframes) can also contribute to harm and/or reduce fairness.  These effects also ought to be evaluated. </del>  Another example use is concurrent multipath, where the transport protocol simultaneously schedules a flow to aggregate the capacity

Reviewer comments:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Revised text:
state of each path, and demonstrate independent congestion control for each path being used.  Authors of a proposed multipath congestion control algorithm that implements path fail-over MUST evaluate the  <ins> harm to performance resulting from a change in the path, and show that this does not result in flow starvation.  Synchronisation of failover (e.g., where multiple flows change their path on similar timeframes) can also contribute to harm and/or reduce fairness. These effects also ought to be evaluated. </ins> Another example use is concurrent multipath, where the transport protocol simultaneously schedules a flow to aggregate the capacity
Original text:
general, these algorithms are expected to be less mature than ones that follow the procedures in this document.  Authors documenting deployed congestion control algorithms that cannot be changed by IETF <del> or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). </del>  4.

Reviewer comments:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Revised text:
general, these algorithms are expected to be less mature than ones that follow the procedures in this document.  Authors documenting deployed congestion control algorithms that cannot be changed by IETF  <ins> or IRTF review are invited to seek publication as an Informational RFC via the Independent Stream Editor (ISE). </ins> 4.
Original text:
Algorithms that rely on specific functions or configurations in the network need to provide a reference or specification for these <del> 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. </del>  In evaluating a new proposal for use in a controlled environment, the IETF needs to understand the usage, e.g., how the usage is scoped to

Reviewer comments:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Revised text:
Algorithms that rely on specific functions or configurations in the network need to provide a reference or specification for these  <ins> functions (an RFC or another stable specification).  For publication to proceed, the IETF will need to assess whether a working group exists that can properly assess the network-layer aspects and their interaction with the congestion control. </ins> In evaluating a new proposal for use in a controlled environment, the IETF needs to understand the usage, e.g., how the usage is scoped to
Original text:
community MUST consider the following criteria.  These criteria will be evaluated in various domains (see general-use and special-cases).  5.1. The criteria in this section evaluate the congestion control

Reviewer comments:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Revised text:
community MUST consider the following criteria.  These criteria will be evaluated in various domains (see general-use and special-cases). <ins> Some of the sections below will list criteria that SHOULD be met.  It could happen that these criteria are not in fact met by the proposal. In such cases, the community MUST document whether not meeting the criteria is acceptable, for example because there are practical limitations on carrying out an evaluation of the criteria. The requirement that the community consider a criterion does not imply that the result needs to be described in a resulting RFC. There is no formal requirement to document the results, although normal IETF policies for archiving proceedings will provide a record. This document, except where otherwise noted, does not provide normative guidance on the acceptable thresholds for any of these criteria.  Instead, the community will use these evaluations as an input when considering whether to progress the proposed algorithm. </ins> 5.1. The criteria in this section evaluate the congestion control
Original text:
5.2.1. <del> A proposed congestion control algorithm SHOULD be evaluated when competing using standard IETF congestion controls, e.g.  RFC5681, </del>  RFC9002, RFC9438.  A proposed congestion control algorithm that has a significantly negative impact on flows using standard congestion control might be suspect, and this aspect should be part of the

Reviewer comments:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Revised text:
5.2.1.  <ins> A proposed congestion control algorithm MUST be evaluated when competing against standard IETF congestion controls, e.g.  RFC5681, </ins> RFC9002, RFC9438.  A proposed congestion control algorithm that has a significantly negative impact on flows using standard congestion control might be suspect, and this aspect should be part of the
Original text:
5.3.1. <del> A proposed congestion control algorithm SHOULD include a clear explanation of any deviations from RFC2914 and RFC7141. </del>  5.3.2.

Reviewer comments:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Revised text:
5.3.1.  <ins> A proposed congestion control algorithm MUST clearly explain any deviations from RFC2914 and RFC7141. </ins> 5.3.2.
Original text:
The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control <del> 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. </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:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Revised text:
The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control  <ins> specification explicitly forbids use on the public Internet, there MUST be IETF 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:
current congestion control algorithms do have security implications (e.g., as outlined in RFC5681). <del> 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. </del>  9.

Reviewer comments:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Revised text:
current congestion control algorithms do have security implications (e.g., as outlined in RFC5681).  <ins> Proposed congestion control algorithms MUST examine any potential security or privacy issues that may arise from their design. </ins> 9.
Original text:
statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is considered safe for use on the Internet.  Each published algorithm is <del> also required to include a statement in the abstract describing </del>  environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorithm is deemed safe for use, but it is still is not recommended for use

Reviewer comments:
required -> REQUIRED
I agree with this change. The use of REQUIRED/RECOMMENDED for process rather than SHOULD/MUST for protocol, is not entirely consistent, but I think it is fine and unambiguous. Please do merge

Revised text:
statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is considered safe for use on the Internet.  Each published algorithm is  <ins> also REQUIRED to include a statement in the abstract describing </ins> environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorithm is deemed safe for use, but it is still is not recommended for use
Original text:
environments is discussed in Section 12 of RFC3649 (HighSpeed TCP) and Section 9.7 of RFC4782 (Quick-Start). <del> Protection Against Congestion Collaps </del>  The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714,

Reviewer comments:
Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)

Revised text:
environments is discussed in Section 12 of RFC3649 (HighSpeed TCP) and Section 9.7 of RFC4782 (Quick-Start).  <ins> Protection Against Congestion Collapse </ins> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714,
Original text:
mechanisms that would give flows with different round- trip times comparable bandwidth during backoff.  Fairness within the Alternate Congestion Control Algorithm. In environments with multiple competing flows all using the same

Reviewer comments:
Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)

Revised text:
mechanisms that would give flows with different round- trip times comparable bandwidth during backoff. <ins> Protection Against Bufferbloat The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases. Exactly how the algorithm reduces its sending rate is algorithm specific. Bufferbloat Bufferbloat refers to the building of long queues in the network.  Many network routers are configured with very large buffers.  If congestion starts happening, classic TCP congestion control algorithms RFC5681 will continue sending at a high rate until the buffer fills up completely and packet losses occur. Every connection going through that bottleneck will experience high latency.  This is particularly bad for highly interactive applications like games, but it also affects routine web browsing and video playing. This problem became apparent in the last decade and was not discussed in the Congestion Control Principles published in September 2002 RFC2914.  The classic congestion control algorithm RFC5681 and the widely deployed Cubic algorithm RFC9438 do not address it, but newly designed congestion control algorithms have the opportunity to improve the state of the art. </ins> Fairness within the Alternate Congestion Control Algorithm. In environments with multiple competing flows all using the same