jiebi/CodeConvo huggingface dataset:
Code change:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Related discussion:
text: most Internet flows. Furthermore, many IoT applications do not a have a human in the loop, <del> and therefore can have weaker latency constraints because they do not relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. </del> <ins> and therefore might have weaker latency constraints because they do not relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. </ins> 7.5.
Code change:
Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.

Related discussion:
text: state of each path, and demonstrate independent congestion control for each path being used.  Authors of a proposed multipath congestion control algorithm that implements path fail-over MUST evaluate the <del> harm resulting from a change in the path, and show that this does not result in flow starvation.  Synchronisation of failover (e.g., where multiple flows change their path on similar timeframes) can also contribute to harm and/or reduce fairness.  These effects also ought to be evaluated. </del> <ins> harm to performance resulting from a change in the path, and show that this does not result in flow starvation.  Synchronisation of failover (e.g., where multiple flows change their path on similar timeframes) can also contribute to harm and/or reduce fairness. These effects also ought to be evaluated. </ins> Another example use is concurrent multipath, where the transport protocol simultaneously schedules a flow to aggregate the capacity
Code change:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Related discussion:
text: general, these algorithms are expected to be less mature than ones that follow the procedures in this document.  Authors documenting deployed congestion control algorithms that cannot be changed by IETF <del> or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). </del> <ins> or IRTF review are invited to seek publication as an Informational RFC via the Independent Stream Editor (ISE). </ins> 4.
Code change:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Related discussion:
text: Algorithms that rely on specific functions or configurations in the network need to provide a reference or specification for these <del> functions (an RFC or another stable specification).  The IETF will need to assess whether the relevant working group is able to review the proposed new algorithm and whether there is sufficient experience to understand any dependent functions. </del> <ins> functions (an RFC or another stable specification).  For publication to proceed, the IETF will need to assess whether a working group exists that can properly assess the network-layer aspects and their interaction with the congestion control. </ins> In evaluating a new proposal for use in a controlled environment, the IETF needs to understand the usage, e.g., how the usage is scoped to
Code change:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Related discussion:
text: community MUST consider the following criteria.  These criteria will be evaluated in various domains (see general-use and special-cases). <ins> Some of the sections below will list criteria that SHOULD be met.  It could happen that these criteria are not in fact met by the proposal. In such cases, the community MUST document whether not meeting the criteria is acceptable, for example because there are practical limitations on carrying out an evaluation of the criteria. The requirement that the community consider a criterion does not imply that the result needs to be described in a resulting RFC. There is no formal requirement to document the results, although normal IETF policies for archiving proceedings will provide a record. This document, except where otherwise noted, does not provide normative guidance on the acceptable thresholds for any of these criteria.  Instead, the community will use these evaluations as an input when considering whether to progress the proposed algorithm. </ins> 5.1. The criteria in this section evaluate the congestion control
Code change:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Related discussion:
text: 5.2.1. <del> A proposed congestion control algorithm SHOULD be evaluated when competing using standard IETF congestion controls, e.g.  RFC5681, </del> <ins> A proposed congestion control algorithm MUST be evaluated when competing against standard IETF congestion controls, e.g.  RFC5681, </ins> RFC9002, RFC9438.  A proposed congestion control algorithm that has a significantly negative impact on flows using standard congestion control might be suspect, and this aspect should be part of the
Code change:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Related discussion:
text: 5.3.1. <del> A proposed congestion control algorithm SHOULD include a clear explanation of any deviations from RFC2914 and RFC7141. </del> <ins> A proposed congestion control algorithm MUST clearly explain any deviations from RFC2914 and RFC7141. </ins> 5.3.2.
Code change:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Related discussion:
text: The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control <del> specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </del> <ins> specification explicitly forbids use on the public Internet, there MUST be IETF consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </ins> The evaluation in each scenario SHOULD occur over a representative range of bandwidths, delays, and queue depths.  Of course, the set of
Code change:
A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!

Related discussion:
text: current congestion control algorithms do have security implications (e.g., as outlined in RFC5681). <del> The IETF process that results in publication needs to ensure that these security implications are considered.  Proposed congestion control algorithms therefore ought to be mindful of pitfalls, and SHOULD examine any potential security issues that may arise. </del> <ins> Proposed congestion control algorithms MUST examine any potential security or privacy issues that may arise from their design. </ins> 9.
Code change:
required -> REQUIRED
I agree with this change. The use of REQUIRED/RECOMMENDED for process rather than SHOULD/MUST for protocol, is not entirely consistent, but I think it is fine and unambiguous. Please do merge

Related discussion:
text: statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is considered safe for use on the Internet.  Each published algorithm is <del> also required to include a statement in the abstract describing </del> <ins> also REQUIRED to include a statement in the abstract describing </ins> environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorithm is deemed safe for use, but it is still is not recommended for use
Code change:
Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)

Related discussion:
text: environments is discussed in Section 12 of RFC3649 (HighSpeed TCP) and Section 9.7 of RFC4782 (Quick-Start). <del> Protection Against Congestion Collaps </del> <ins> Protection Against Congestion Collapse </ins> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714,
Code change:
Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)

Related discussion:
text: mechanisms that would give flows with different round- trip times comparable bandwidth during backoff. <ins> Protection Against Bufferbloat The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases. Exactly how the algorithm reduces its sending rate is algorithm specific. Bufferbloat Bufferbloat refers to the building of long queues in the network.  Many network routers are configured with very large buffers.  If congestion starts happening, classic TCP congestion control algorithms RFC5681 will continue sending at a high rate until the buffer fills up completely and packet losses occur. Every connection going through that bottleneck will experience high latency.  This is particularly bad for highly interactive applications like games, but it also affects routine web browsing and video playing. This problem became apparent in the last decade and was not discussed in the Congestion Control Principles published in September 2002 RFC2914.  The classic congestion control algorithm RFC5681 and the widely deployed Cubic algorithm RFC9438 do not address it, but newly designed congestion control algorithms have the opportunity to improve the state of the art. </ins> Fairness within the Alternate Congestion Control Algorithm. In environments with multiple competing flows all using the same
Code change:
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.

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

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

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

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

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

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