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:
at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.

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:
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments.  For instance, proposals should be investigated across a range of <del> bandwidths, round-trip times, levels of traffic on the reverse </del>  path, and levels of statistical multiplexing at the congested link.  Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers,

Reviewer comments:
at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.

Revised text:
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments.  For instance, proposals should be investigated across a range of  <ins> capacities, round-trip times, levels of traffic on the reverse </ins> path, and levels of statistical multiplexing at the congested link.  Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers,
Original text:
full backoff mechanism must be identical to that of TCP RFC2988. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times <del> comparable bandwidth during backoff. </del>  Protection Against Bufferbloat

Reviewer comments:
at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.

Revised text:
full backoff mechanism must be identical to that of TCP RFC2988. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times  <ins> comparable caapcity during backoff. </ins> Protection Against Bufferbloat
Original text:
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should <del> explore how bandwidth is shared among the competing flows. </del>  Performance with Misbehaving Nodes and Outside Attackers.

Reviewer comments:
at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.

Revised text:
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should  <ins> explore how the capacity is shared among the competing flows. </ins> Performance with Misbehaving Nodes and Outside Attackers.
Original text:
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1) <del> assessing the impact on standard congestion control, (3) investigation of the proposed mechanism in a range of environments, (4) protection against congestion collapse, and (8) discussing whether the mechanism allows for incremental deployment. For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </del>  5.

Reviewer comments:
at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.

Revised text:
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1)  <ins> assessing the impact on standard congestion control, (2) performance in wireless environments, (4) investigation of the proposed mechanism in a range of environments, (5) protection against congestion collapse, and (10) discussing whether the mechanism allows for incremental deployment. For other guidelines, the author must perform the suggested evaluations and provide recommended analysis.  Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </ins> 5.
Original text:
protocol suite and therefore does not directly impact Internet security.  The implementation of various facets of the Internet's current congestion control algorithms do have security implications <del> (e.g., as outlined in RFC2581).  Alternate congestion control schemes </del>  should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise.

Reviewer comments:
at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.

Revised text:
protocol suite and therefore does not directly impact Internet security.  The implementation of various facets of the Internet's current congestion control algorithms do have security implications  <ins> (e.g., as outlined in RFC5681).  Alternate congestion control schemes </ins> should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise.
Original text:
Impact on Standard TCP, SCTP RFC2960, and DCCP RFC4340. <del> Proposed congestion control mechanisms should be evaluated when competing with standard IETF congestion control RFC2581, RFC2960, RFC4340.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism. </del>  We note that this bullet is not a requirement for strict TCP- friendliness as a prerequisite for an alternate congestion control

Reviewer comments:
The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.

Revised text:
Impact on Standard TCP, SCTP RFC2960, and DCCP RFC4340.  <ins> Evaluation of proposed congestion control mechanisms should include test cases competing with standard IETF congestion control RFC2581, RFC2960, RFC4340.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism. </ins> We note that this bullet is not a requirement for strict TCP- friendliness as a prerequisite for an alternate congestion control
Original text:
using spare capacity is discussed in Sections 6, 11.1, and 12 of RFC3649.  Difficult Environments. The proposed algorithms should be assessed in difficult <del> environments such as paths containing wireless links. Characteristics of wireless environments are discussed in RFC3819 and in Section 16 of Tools.  Other difficult environments can include those with multipath routing within a connection.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </del>  While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with

Reviewer comments:
The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.

Revised text:
using spare capacity is discussed in Sections 6, 11.1, and 12 of RFC3649. <ins> Wireless links While the early Internet was dominated by wired links, the properties of wireless links have become extremely important to Internet performance.  In particular, congestion controllers should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. </ins> Difficult Environments. The proposed algorithms should be assessed in difficult  <ins> environments.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </ins> While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with
Original text:
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments.  For instance, proposals should be investigated across a range of <del> bandwidths, round-trip times, levels of traffic on the reverse </del>  path, and levels of statistical multiplexing at the congested link.  Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers,

Reviewer comments:
The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.

Revised text:
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments.  For instance, proposals should be investigated across a range of  <ins> capacities, round-trip times, levels of traffic on the reverse </ins> path, and levels of statistical multiplexing at the congested link.  Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers,
Original text:
full backoff mechanism must be identical to that of TCP RFC2988. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times <del> comparable bandwidth during backoff. </del>  Protection Against Bufferbloat

Reviewer comments:
The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.

Revised text:
full backoff mechanism must be identical to that of TCP RFC2988. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round- trip times  <ins> comparable caapcity during backoff. </ins> Protection Against Bufferbloat
Original text:
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should <del> explore how bandwidth is shared among the competing flows. </del>  Performance with Misbehaving Nodes and Outside Attackers.

Reviewer comments:
The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.

Revised text:
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should  <ins> explore how the capacity is shared among the competing flows. </ins> Performance with Misbehaving Nodes and Outside Attackers.
Original text:
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1) <del> assessing the impact on standard congestion control, (3) investigation of the proposed mechanism in a range of environments, (4) protection against congestion collapse, and (8) discussing whether the mechanism allows for incremental deployment. For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </del>  5.

Reviewer comments:
The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.

Revised text:
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1)  <ins> assessing the impact on standard congestion control, (2) performance in wireless environments, (4) investigation of the proposed mechanism in a range of environments, (5) protection against congestion collapse, and (10) discussing whether the mechanism allows for incremental deployment. For other guidelines, the author must perform the suggested evaluations and provide recommended analysis.  Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. </ins> 5.