jiebi/CodeConvo huggingface dataset:
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: The criteria in this section evaluate the congestion control algorithm when one or more flows using that algorithm share a <del> bottleneck link (i.e. with no flows using a differing congestion </del> <ins> bottleneck link (i.e., with no flows using a differing congestion </ins> control algorithm). 4.1.1.
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: 4.2. <del> These criteria evaluate the interaction of the proposed congestion control algorithm with commonly deployed congestion control algorithms. </del> <ins> Mixed algorithm behavior criteria evaluate the interaction of the proposed congestion control algorithm with commonly deployed congestion control algorithms. </ins> In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: a proposal targeting general Internet use can not assume this is always the case. <ins> circuit-breakers describes the impact of network transport circuit breaker algorithms.  RFC8083 also defines a minimal set of RTP circuit breakers that operate across a path.  This identifies conditions under which a sender needs to stop transmitting media data to protect the network from excessive congestion.  It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. </ins> 4.2.3. The effect on short-lived and long-lived flows using other common
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: 4.3.1. <del> Proposed congestion control algorithms SHOULD include a clear </del> <ins> A proposed congestion control algorithm SHOULD include a clear </ins> explanation of any deviations from RFC2914 and RFC7141. 4.3.2.
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: on a specific proposed congestion control algorithm - is out of scope of this document.  RFC7567 describes design considerations for AQMs. <ins> 6.1.1. Some equipment in the network use an automatic mechanism to continuously monitor the use of resources by a flow or aggregate set of flows RFC8084.  Such a network transport circuit breaker can automatically detect excessive congestion, and when detected, it can terminate (or significantly reduce the rate of) the flow(s).  A well- designed congestion control algorithm ought to react before the flow uses excessive resources and therefore will operate within the envelope set by network transport circuit breaker algorithms. </ins> 6.2. An Internet Path can include simple links, where the minimum delay is
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: might then have to buffer data until an assigned transmission opportunity or when the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of <del> operation).  Variation also arises when a higher priority diffserv traffic classic prompts the transmission by a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </del> <ins> operation).  Variation also arises when traffic with a higher priority diffserv class pre-empts transmission of traffic with a lower class.  In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.  The jitter from variation over short timescales might not be distinguishable similar from other effects. </ins> A proposed congestion control algorithm SHOULD be evaluated to ensure their operation is robust when there is a significant change in the
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: operating congestion controls. For these reasons, data center congestion controls are often distinct <del> from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </del> <ins> from those running elsewhere on the Interenet (see controlled- environments).  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 7.
Code change:
Proposed text to add MP-TCP RFCs.
From NAME review: Section 5.8: What is the verdict on RFC 6356? Is it not worth bringing this up in relation to concurrent usage? RFC 8041 do bring up additional experience with also other algorithms for MP-TCP that have been tried. I would at least claim “At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet.” that this sentence is factual wrong as RFC 6356 is an IETF experimental specification. I do think this section brings up important aspects to consider. However, it also point to some interesting challenges in reasoning and responsibility between functionalities when managing different paths. Looking at the text I think we have scheduler application data, path availability checks as well as congestion control all impacting what is happening. What is truly congestion control here?

Related discussion:
text: Another example use is concurrent multipath, where the transport protocol simultaneously schedules flows to aggregate the capacity <del> across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows.  Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </del> <ins> across multiple paths. The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: A proposed congestion control algorithm MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an overall capacity limit), and SHOULD consider the potential for harm to other flows. Synchronisation of congestion control mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated. At the time of writing, there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MP-TCP). </ins> 6.9.
Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: proceed with caution when evaluating proposals for alternate congestion control.  The goal of this document is to provide guidance for considering standardization of a proposed congestion control <del> algorithm at the IETF.  It replaces RFC5033 to reflect changes in the congestion control landscape. </del> <ins> algorithm at the IETF.  It obsoletes RFC5033 to reflect changes in the congestion control landscape. </ins> 1.
Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: then adopted as the default congestion control algorithm for the TCP implementation in Linux.  It was already used in a significant fraction of TCP connections over the Internet before being documented <del> in an Informational Internet Draft in 2015, published as an </del> <ins> in an Informational Internet-Draft in 2015, published as an </ins> Informational RFC in 2017 RFC8312 and then as a Proposed Standard in 2023 RFC9438. BBR is developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It <del> was described in an IRTF draft in 2018, and that draft is regularly updated to document the evolving versions of the algorithm BBR-draft. BBR is widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </del> <ins> was described in an IRTF Internet-Draft in 2018, and that Internet- Draft is regularly updated to document the evolving versions of the algorithm BBR-draft.  BBR is widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </ins> We cannot say now whether the original authors of RFC5033 expected that developers would be somehow waiting for IETF review before
Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: A specification can help potential contributors understand the algorithm, which can make it easier for them to suggest <del> improvements and/or identify limitations.  Further, the </del> <ins> improvements and/or identify limitations.  Furthermore, the </ins> specification can help multiple contributors align on a consensus change to the algorithm.
Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: the developers of alternative algorithms and by the IETF in the context of each proposal. <del> The high-order criterion for advancing any proposal is a serious scientific study of the pros and cons that occur when the proposal is considered for publication by the IETF or before it is deployed at large scale. </del> <ins> The high-order criterion for advancing any proposal within the IETF is a serious scientific study of the pros and cons that occur when the proposal is considered for publication by the IETF or before it is deployed at large scale. </ins> <del> After initial studies, we encourage authors to write a specification of their proposal for publication in the RFC series.  This allows others to concretely understand and investigate the wealth of </del> <ins> After initial studies, authors are encouraged to write a specification of their proposal for publication in the RFC series. This allows others to understand and investigate the wealth of </ins> proposals in this space. This document is meant to reduce the barriers to entry for new
Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: consider other non-standard congestion control algorithms that are known to be widely deployed. <del> We note that this guideline is not a requirement for strict Reno- or </del> <ins> Note that this guideline is not a requirement for strict Reno- or </ins> Cubic- friendliness as a prerequisite for a proposed congestion control mechanism to advance to Experimental or Standards Track status.  As an example, HighSpeed TCP is a congestion control
Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: A proposed congestion control algorithm SHOULD consider coexistence with widely deployed real-time congestion control algorithms. <del> Regrettably, at the time of writing, many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications.  It is hoped this situation will change. </del> <ins> Regrettably, at the time of writing (2024), many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications.  It is hoped this situation will change. </ins> To the extent that behavior of widely deployed algorithms is understood, a proposed congestion control algorithm can analyze and
Code change:
Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.

Related discussion:
text: contribute to harm and/or reduce fairness, these effects also ought to be evaluated. <del> At the time of writing, there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MP-TCP). </del> <ins> At the time of writing (2024), there are currently no Standards Track RFCs, but there is an Experimental RFC RFC6356 that specifies a concurrent multipath congestion control algorithm for TCP (MPTCP RFC8684). </ins> 6.9.
Code change:
Make it clear this is about guidelines for authors, not status of this document avoid redundant guidance avoid "subjective" guidance such as "believes"
thanks

Related discussion:
text: 2. <del> This document applies to proposed congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations for both the answers and the degree of certainty of the answers. Congestion control algorithms without experience of Internet-scale deployment SHOULD seek Experimental status until real-world data is able to answer the questions in general-use.  Congestion control </del> <ins> This document applies to proposed congestion control algorithms proposals that seek Experimental or Standards Track status. Evaluation of both cases involves the same questions, but with different expectations for both the answers and the degree of certainty of the answers. Congestion control algorithms without empirical evidence of Internet- scale deployment SHOULD seek Experimental status.  Congestion control </ins> algorithms with a record of measured Internet-scale deployment MAY <del> directly seek the Standards Track if the community believes it is safe, and the design is stable, guided by the considerations in general-use.  The existence of this data does not waive the other considerations in this document. </del> <ins> directly seek the Standards Track if there is solid data that reflects that it is safe, and the design is stable, guided by the considerations in general-use.  However, the existence of this data does not waive the other considerations in this document. </ins> Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being <del> actively measured, and where it is possible to deactivate if there are signs of pathological behavior. </del> <ins> actively measured, and where it is possible to deactivate them if there are signs of pathological behavior. </ins> Each published congestion control algorithm is REQUIRED to include a statement in the abstract indicating whether or not there is IETF