jiebi/TextFlow huggingface dataset:
Original text:
deployment in the Internet. This document updates the similarly titled RFC5033 that was published <del> in 2007.  Since then, multiple congestion control algorithms were developed outside of the IETF, including at least two that saw large scale deployment: Cubic HRX08 and BBR BBR-draft. </del>  Cubic was documented in a research publication in 2007 HRX08, and then adopted as the default congestion control algorithm for the TCP

Reviewer comments:
This takes the initial part of that charter and adds to the introduction as a starting point for the new document.
Let's add text to the Introduction with our motivation and intention for revising RFC 5033, i.e., why and what do we want to update. The goal is to improve our alignment early on. This text could draw from the CCWG charter and prior discussions.

Revised text:
deployment in the Internet. This document updates the similarly titled RFC5033 that was published  <ins> in 2007 as a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. In 2007, TCP was the dominant consumer of this work, and proposals were typically discussed in research groups, for example the Internet Congestion Control Research Group (ICCRG). Since RFC 5033 was published, many conditions have changed.  The set of protocols using these algorithms has spread beyond TCP and SCTP to include DCCP, QUIC, and beyond.  Some congestion control algorithm proponents now have the opportunity to test and deploy at scale without IETF review.  There is more interest in specialized use cases such as data centers and real-time protocols.  Finally, the community has gained much more experience with indications of congestion beyond packet loss. Multiple congestion control algorithms have been developed outside of the IETF, including at least two that saw large scale deployment: Cubic HRX08 and BBR BBR-draft. </ins> Cubic was documented in a research publication in 2007 HRX08, and then adopted as the default congestion control algorithm for the TCP
Original text:
the abstract stating the mechanism is only being proposed for controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore <del> would be unsafe to deploy).  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 would still not be recommended because it could cause unnecessary delays for the connections attempting to use Quick-Start. </del>  For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for

Reviewer comments:
Update the QS text and various editorial suggestions. if merged.
I'll propose a PR with some editorial updates to the first part of the ID.

Revised text:
the abstract stating the mechanism is only being proposed for controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore  <ins> 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 would not be 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> For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for
Original text:
possibility would be to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities.  This is particularly encouraged in order to <del> get algorithm specifications widely disseminated to facilitate further research.  Such an internet-draft could be submitted to be considered as an Informational RFC, as a first step in the process towards standardization.  Such a document would also be expected to carry an explicit warning against using the scheme in the global Internet. </del>  Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent

Reviewer comments:
Update the QS text and various editorial suggestions. if merged.
I'll propose a PR with some editorial updates to the first part of the ID.

Revised text:
possibility would be to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities.  This is particularly encouraged in order to  <ins> ensure algorithm specifications are widely disseminated to facilitate further research.  Such an internet-draft could also be considered as an Informational RFC, as a first step in the process towards standardization.  Such a document would be expected to carry an explicit warning against using the scheme in the global Internet. </ins> Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent
Original text:
3.1.1.  The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some

Reviewer comments:
Define congestion collapse in terms of excess overhead. Rename the prior congestion collapse section "Implement full backoff" Closes issue
Editors: This metric is very interesting, but wonder if it's really a requirement for loss recovery, not congestion control (granted, these two are often intertwined). This would put it out of scope. Our proposal would be to revert this, though perhaps we are misunderstanding the intent.
Define congestion collapse in terms of excess overhead under adverse conditions. This is how it was defined circa 1987. Rename the current "congestion collapse" section.
NAME would you like to take a crack at finding some text that would be in scope to address the intent behind this issue?
Closing this issue, as it's through IETF Last Call.

Revised text:
3.1.1. <ins> The alternate congestion control mechanism should not cause increased overhead under adverse network conditions. This criteria can be evaluated by counting the total bytes (data and headers) arriving at the receiver when delivering a fixed workload over varying network conditions.  The total delivered bytes should remain constant, independent of network conditions over the entire operating range for the protocol.  For general transport protocols such as TCP this means over any path in the Internet. There are known exceptions to this guideline, for example spurious Retransmission Timeouts RFC7765 and TCP loss Probe RFC8985.  These algorithms can substantially improve application performance in certain environments at the cost of additional network overhead due to spurious retransmissions. Alternate congestion control mechanisms should be carefully evaluated for exceptions.  That evaluation should appropriately reflect on any the inherent trade-offs. This criteria can also be applied protocol layers above transport. 3.1.2. </ins> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some
Original text:
mechanisms that would give flows with different round- trip times comparable capacity during backoff. <del> 3.1.2. </del>  The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly

Reviewer comments:
Define congestion collapse in terms of excess overhead. Rename the prior congestion collapse section "Implement full backoff" Closes issue
Editors: This metric is very interesting, but wonder if it's really a requirement for loss recovery, not congestion control (granted, these two are often intertwined). This would put it out of scope. Our proposal would be to revert this, though perhaps we are misunderstanding the intent.
Define congestion collapse in terms of excess overhead under adverse conditions. This is how it was defined circa 1987. Rename the current "congestion collapse" section.
NAME would you like to take a crack at finding some text that would be in scope to address the intent behind this issue?
Closing this issue, as it's through IETF Last Call.

Revised text:
mechanisms that would give flows with different round- trip times comparable capacity during backoff.  <ins> 3.1.3. </ins> The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly
Original text:
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.3. </del>  When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. <del> 3.1.4. </del>  (TODO: Discuss short and long flows)

Reviewer comments:
Define congestion collapse in terms of excess overhead. Rename the prior congestion collapse section "Implement full backoff" Closes issue
Editors: This metric is very interesting, but wonder if it's really a requirement for loss recovery, not congestion control (granted, these two are often intertwined). This would put it out of scope. Our proposal would be to revert this, though perhaps we are misunderstanding the intent.
Define congestion collapse in terms of excess overhead under adverse conditions. This is how it was defined circa 1987. Rename the current "congestion collapse" section.
NAME would you like to take a crack at finding some text that would be in scope to address the intent behind this issue?
Closing this issue, as it's through IETF Last Call.

Revised text:
designed congestion control algorithms have the opportunity to improve the state of the art.  <ins> 3.1.4. </ins> When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows.  <ins> 3.1.5. </ins> (TODO: Discuss short and long flows)
Original text:
3.1.1. <del> The alternate congestion control mechanism should not cause increased overhead under adverse network conditions. This criteria can be evaluated by counting the total bytes (data and headers) arriving at the receiver when delivering a fixed workload over varying network conditions.  The total delivered bytes should remain constant, independent of network conditions over the entire operating range for the protocol.  For general transport protocols such as TCP this means over any path in the Internet. There are known exceptions to this guideline, for example spurious Retransmission Timeouts RFC7765 and TCP loss Probe RFC8985.  These algorithms can substantially improve application performance in certain environments at the cost of additional network overhead due to spurious retransmissions. Alternate congestion control mechanisms should be carefully evaluated for exceptions.  That evaluation should appropriately reflect on any the inherent trade-offs. This criteria can also be applied protocol layers above transport. 3.1.2. </del> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some

Reviewer comments:
Reverts ietf-wg-ccwg/rfc5033bis. This was accidentally submitted without review. The conclusion of the editors is that this is out of scope for the document.

Revised text:
3.1.1.  The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some
Original text:
mechanisms that would give flows with different round- trip times comparable capacity during backoff. <del> 3.1.3. </del>  The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly

Reviewer comments:
Reverts ietf-wg-ccwg/rfc5033bis. This was accidentally submitted without review. The conclusion of the editors is that this is out of scope for the document.

Revised text:
mechanisms that would give flows with different round- trip times comparable capacity during backoff.  <ins> 3.1.2. </ins> The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly
Original text:
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.4. </del>  When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. <del> 3.1.5. </del>  (TODO: Discuss short and long flows)

Reviewer comments:
Reverts ietf-wg-ccwg/rfc5033bis. This was accidentally submitted without review. The conclusion of the editors is that this is out of scope for the document.

Revised text:
designed congestion control algorithms have the opportunity to improve the state of the art.  <ins> 3.1.3. </ins> When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows.  <ins> 3.1.4. </ins> (TODO: Discuss short and long flows)
Original text:
3.3.1. Proposed congestion control mechanisms SHOULD include a clear <del> explanation of the deviations from RFC2914. </del>  3.3.2.

Reviewer comments:
rfc7141 partially updates rfc5033; include relevant sections in the -bis document
7141 does not mention 5033, so can you be more specific?
Oct 12: Pinged NAME to follow up
IIRC, it was due to rfc7141 updating rfc2914; rfc2914 is mentioned and referenced at numerous points throughout the 5033 document. 5033bis should heed the advice from 7141 around marking probabiliy taking into consideration packet sizes rather than only the packets themselves. At least this train of thought is the most likely one, which was had in my mind at the time.
Editors: we suspect that this question is orthogonal to the purpose of this document; will look more carefully at the reference.
It turns out that 7141 does have recommendations on response to congestion signals from the network, not just AQM recommendations (See Sec 2.3 and 2.4 for a good summary).

Revised text:
3.3.1. Proposed congestion control mechanisms SHOULD include a clear  <ins> explanation of the deviations from RFC2914 and RFC7141. </ins> 3.3.2.
Original text:
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties.  5. The criteria in evaluation-criteria will be evaluated in the

Reviewer comments:
Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also. ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.

Revised text:
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. <ins> 4.3. Congestion control performance is affected by the queue discipline applied at the bottleneck link.  The default queue discipline that MUST be evaluated is drop-tail, First In First Out (FIFO).  See aqm for evaluation of other queue disciplines. </ins> 5. The criteria in evaluation-criteria will be evaluated in the
Original text:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.6.1. </del>  An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also

Reviewer comments:
Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also. ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.

Revised text:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start).  <ins> 5.7.1. </ins> An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also
Original text:
properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del>  Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

Reviewer comments:
Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also. ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.

Revised text:
properties of that path can vary, with similar impacts on congestion control  <ins> 5.8. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A