jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
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> <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. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
text: properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del> <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
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
text: mechanisms that would give flows with different round- trip times comparable capacity during backoff. <del> 3.1.3. </del> <ins> 3.1.2. </ins> The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly
Code change:
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.

Related discussion:
text: designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.4. </del> <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. <del> 3.1.5. </del> <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> <del> (TODO: Discuss short and long flows) </del> <ins> Proposals will consider how new and short-lived flows affect long- lived flows, and vice versa. </ins> 3.2.
Code change:
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.

Related discussion:
text: 3.3.1. Proposed congestion control mechanisms SHOULD include a clear <del> explanation of the deviations from RFC2914. </del> <ins> explanation of the deviations from RFC2914 and RFC7141. </ins> 3.3.2.
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
text: 5.1. <del> (TODO: Write this section) </del> <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. <del> 5.3. </del> <ins> 5.4. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.
Code change:
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.

Related discussion:
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> <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. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
text: properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del> <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
Code change:
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.

Related discussion:
text: 5.2. <del> (TODO: Write this section) </del> <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.
Code change:
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...

Related discussion:
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