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

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

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

Related discussion:
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> <ins> comparable caapcity during backoff. </ins> Protection Against Bufferbloat
Code change:
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.

Related discussion:
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> <ins> explore how the capacity is shared among the competing flows. </ins> Performance with Misbehaving Nodes and Outside Attackers.
Code change:
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.

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

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

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

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

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

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

Related discussion:
text: designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.3. </del> <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. <del> 3.1.4. </del> <ins> 3.1.5. </ins> (TODO: Discuss short and long flows)
Code change:
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.

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:
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.

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:
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.

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. </ins> (TODO: Discuss short and long flows)
Code change:
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).

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