jiebi/TextFlow huggingface dataset:
Original text:
to concretely understand and investigate the wealth of proposals in this space.  2. Following the lead of HighSpeed TCP RFC3649, alternate congestion

Reviewer comments:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

Revised text:
to concretely understand and investigate the wealth of proposals in this space. <ins> This document is meant to reduce the barriers to entry for new congestion control work.  As such, proponents should not 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 rest of this document. </ins> 2. Following the lead of HighSpeed TCP RFC3649, alternate congestion
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:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

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:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

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>  <del> (TODO: Discuss short and long flows) </del>  3.2.

Reviewer comments:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

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. A great deal of congestion control analysis concerns the steady-state behavior of long flows.  However, many internet flows are relatively short-lived.  If they never experience a packet loss, they remain in the "slow start" mode of operation RFC5681 that features exponential congestion window growth. </ins>  <ins> Proposals will consider how new and short-lived flows affect long- lived flows, and vice versa. </ins> 3.2.
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:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

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:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

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:
5.1. <del> (TODO: Write this section) </del>  5.2.  Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.3. </del>  The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.

Reviewer comments:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

Revised text:
5.1.  <ins> Proposals SHOULD be evaluated under a variety of bottleneck queue disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this document.  RFC7567 describes design considerations for AQMs. Among the AQM techniques that might have an impact on a congestion control algorithm are FQ-CoDel RFC8290; Proportional Integral Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. </ins> 5.2. <ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics. IoT nodes might be more constrained in power, CPU, or other parameters than conventional Internet hosts.  This might place limits on the complexity of any given algorithm.  These power and radio constraints might make the volume of control packets in a given algorithm a key evaluation metric. Furthermore, many IoT applications do not a have a human in the loop, and therefore have weaker latency constraints because they do not relate to a user experience. Extremely low-power links can lead to very low throughput and a low bandwidth- delay product, well below the standard operating range of most Internet flows. 5.3. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649.  <ins> 5.4. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.
Original text:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del>  When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del>  RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del>  The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Reviewer comments:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

Revised text:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth.  <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered.  <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering.  <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as
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:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

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:
Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.

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
Original text:
5.2. <del> (TODO: Write this section) </del>  5.3.

Reviewer comments:
I am not an IoT guy but I took a stab at it.
NAME do you have suggested text, or should I submit this is as a start and you can open a new issue?
Section 5.1 is just a TODO to write about this.
OK, that's a start. But there are two possible angles: could resource constrained devices use this spec? And, how would this spec coexist with IoT specific transports, such as "single buffer" implementations?Looks like a start (I fixed a typo). We don't speak about scale ... in that although the sending rate is often low (or short flows), the number of endpoints can be high.

Revised text:
5.2.  <ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics. IoT nodes might be more constrained in power, CPU, or other parameters than conventional Internet hosts.  This might place limits on the complexity of any given algorithm.  These power and radio constraints might make the volume of control packets in a given algorithm a key evaluation metric. Furthermore, many IoT applications do not a have a human in the loop, and therefore have weaker latency constraints because they do not relate to a user experience. Extremely low-power links can lead to very low throughput and a low bandwidth- delay product, well below the standard operating range of most Internet flows. </ins> 5.3.
Original text:
to concretely understand and investigate the wealth of proposals in this space.  2. Following the lead of HighSpeed TCP RFC3649, alternate congestion

Reviewer comments:
Add some text to indicate that proponents don't need a complete report on all the criteria before coming to IETF. They can arrive having thought about these problems a little and have a willingness to do the work implied in this draft.
We need to be nice, but not too nice. This phrase is targeting folks like researchers or PhD candidates. They should be aware that this topic is not going to be a walk in the park. But showing why the problem is hard could also be an encouragement -- you don't get a PhD for solving again a problem that 100s have already solved...

Revised text:
to concretely understand and investigate the wealth of proposals in this space. <ins> This document is meant to reduce the barriers to entry for new congestion control work.  As such, proponents should not 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 rest of this document. </ins> 2. Following the lead of HighSpeed TCP RFC3649, alternate congestion
Original text:
Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332.  5.2. The "Internet of Things" (IoT) is a broad concept, but for congestion

Reviewer comments:
Added the missing 'd' - thanks Neal.
I'm separating AQM from ECN, although ECN relies on AQM design and deployment - ECN can be a force for good when detecting bottlenecks and latency - aka RFC 8087.
Well, yes. ECN, by itself, is one of the signals that can be used by CC algorithms, together with packet loss, delay variation, and packet acks (input to bandwidth measurement). Makes sense to separate it. However, the L4S folks have introduced a tight coupling between a very specific use of ECN in the L4S AQM, and a fine grain mandate of the expected behavior of the CCA. And I cringe each time I read their dual queue formula based on the asymptotic limit of Reno -- but not Cubic. I wish we could walk that back, or describe it in more neutral terms. With L4S, ECT(1) is a signal from the sending host to the network that CE marks should be apply at incipient congestion, instead of waiting for actual loss-generating queue buildup as in RFC 3168. Maybe that should be true even for algorithms that are not described in L4S. Of course, we have to deal with what we have. Maybe we should just quote all the relevant RFCs, and denote the difference between ECT(1)/EC and ECT(0)/EC. Senders using ECT(1) should consider that the rate of CE marking signals the intensity of the congestion, while senders using ECT(0) should consider individual CE marks as denoting actual congestion.
I think the ECN text ought to approach with something very generic like setting ECT can provide nice properties [RFC8087], but comes with requirements for reacting to ECN-CE marking. This reaction to ECN-CE marks needs to be evaluated to ensure this conforms with the style of ECN being used. I'll make a PR.
see Neal's comment

Revised text:
Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. <ins> Congestion control algorithms that set one of the two Explicit Congestion Transport (ECT) codepoints in the IP header can gain the benefits of receiving Explicit Congestion Notifictaion (ECN) Congestion Experienced (CE) signals from an on-path AQM RFC8087.  Use of ECN ?RFC3168,RFC9332 results in requirements for the congestion control algorithm to react when it receives a packet with an ECN-CE marking.  This reaction needs to be evaluated to confirm that the algorithm conforms with the requirements of the ECT codepoint that was used. </ins> 5.2. The "Internet of Things" (IoT) is a broad concept, but for congestion
Original text:
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.

Reviewer comments:
Adding a scope that excludes multicast.
Uh, is a PR addressing the same issue -- you were supposed to review it?
Would if this variant is merged
Discussed at IETF-118. At least we can mention Sect 4 of Multicast UDP Usage Guidelines in RFC8085.
IETF 118: Possibility that we could rule this out of scope Also some interest in this as a separate document that comes after the -bis
So just to provide the background for my question. The Reliable Multicast Transport WG (RMT) did produce two expermential congestion control specifications for multicast: So these specifications exists. Most mulitcast deployments are done in controlled environments however, with [Automatic Multicast Tunneling] (URL) multicast traffic these days have more probability to occur across links where this traffic would share bottlenecks with other unicast traffic. However, this amount of traffic is still normally bit-rate bound so it might be considered just in-elastic and consuming the bit-rate it does. I also want to state that I am fine with declaring multicast out of scope, but maybe some information about that there exist algorithms should be includeded in the draft. So an explicit out of scope with some background section/appendix.
We will put it out of scope and point to RFC 8085
Sorry, just reading through these changes now -- Why does a PR on multipath close an issue on multicast? Am I missing something here?
Whoops, that does not seem correct, re-opened this issue.
To answer NAME more directly, I don't think this draft is in the business of listing algorithms unless it requires new proposals to be measured against them, and not even that if the topic is out of scope. 5033bis is not a congestion control tutorial.
NAME I think it is a question of how one resolve this and if one declares it out of scope. Are we explicitly stating something like this: Multicast congestion control algorithms is out scope, and the rules and requirements within this specification has not been evaluated on their applicability for multicast congestion control. Future work on multicast congesiton control to specify new algorithms or update existing [webrc][TFMCC] will have to evaluate what is applicable and if additional requirements are necessary.
Add a changelog item (as in ) and it LGTM.

Revised text:
community has gained much more experience with indications of congestion beyond packet loss. <ins> Multicast congestion controls are a considerably less mature field of study and are not in scope for this document.  However, Section 4 of the UDP Usage Guidelines RFC8085 provide additional guidelines for multicast and broadcast usage of UDP. </ins> 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.