jiebi/CodeConvo huggingface dataset:
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. <del> 7.4. </del> <ins> 7.5. </ins> A proposed congestion control algorithm ought not to presume that all general Internet paths have a low delay.  Some paths include links
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: Paths can also present a variable delay as described in delay. <del> 7.5. </del> <ins> 7.6. </ins> A proposed congestion control algorithm SHOULD explore how the algorithm performs with non-compliant senders, receivers, or routers.
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 7.6. </del> <ins> 7.7. </ins> A proposed congestion control algorithm ought not to presume that all general Internet paths reliably deliver packets in order.  RFC4653 discusses the effect of extreme packet reordering. <del> 7.7. </del> <ins> 7.8. </ins> A proposed congestion control algorithm SHOULD consider how the proposed congestion control algorithm would perform in the presence
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782. <del> 7.7.1. </del> <ins> 7.9. </ins> An IETF transport is not tied to a specific Internet path or type of path.  The set of routers that form a path can and do change with
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: in path characteristics on the interval of common Internet re-routing intervals. <del> 7.8. </del> <ins> 7.10. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A
Code change:
From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.

Related discussion:
text: RFC6356 that specifies a concurrent multipath congestion control algorithm for MPTCP RFC8684. <del> 7.9. </del> <ins> 7.11. </ins> Data centers are characterized by very low latencies (< 2 ms).  Many workloads involve bursty traffic where many nodes complete a task at
Code change:
Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).

Related discussion:
text: caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and a half times the Bandwidth Delay Product (BDP).  This was <del> unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </del> <ins> unsatisfactory, and indeed further versions provided a fix for this aspect of BBR BBR-draft. </ins> This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track
Code change:
Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).

Related discussion:
text: 6.4. While the early Internet was dominated by wired links, the properties <del> of wireless links have become extremely important to Internet performance.  In particular, a proposed congestion control algorithm 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. </del> <ins> of wireless links have become important to Internet performance.  In particular, a proposed congestion control algorithm 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> 7.
Code change:
Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).

Related discussion:
text: include complex subnetworks where the minimum delay changes over various time scales, resulting in a non- stationary minimum delay. <del> This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes.  A node might then have to buffer data until an assigned transmission opportunity or until the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation). Variation also arises when traffic with a higher priority DSCP 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.  This variation in the delay over short timescales (jitter) might not be distinguishable from jitter that results from other effects. </del> <ins> Varying delay occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes.  A node might then have to buffer data until an assigned transmission opportunity or until the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation).  Variation also arises when traffic with a higher priority DSCP 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.  This variation in the delay over short timescales (jitter) might not be distinguishable from jitter that results from other effects. </ins> A proposed congestion control algorithm SHOULD be evaluated to ensure its operation is robust when there is a significant change in the
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: The IETF specifies standard Internet congestion control algorithms in the RFC-series.  These congestion control algorithms can suffer <del> performance challenges when used in various environments (e.g., high- speed networks, cellular and WiFi wireless technologies, and long distance satellite links), and also when flows carry specific </del> <ins> performance challenges when used in differing environments (e.g., high-speed networks, cellular and WiFi wireless technologies, and long distance satellite links), and also when flows carry specific </ins> workloads (Voice over IP (VoIP), gaming, and videoconferencing). When RFC5033 was published in 2007, TCP RFC9293 was the dominant
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: documented in any request for the working group to publish the specification. <ins> Publication might occur without multiple implementations if a single implementation is widely used, open source, and shown to have positive impact on the Internet, particularly if the target status is Experimental. </ins> 3.2. This document applies to proposals for congestion control algorithms
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: for both the answers and the degree of certainty of those answers. Congestion control algorithms without empirical evidence of Internet- <del> scale deployment SHOULD seek Experimental status. </del> <ins> scale deployment MUST seek Experimental status, unless they are not targeted at general use. Specifications published as Experimental ought to explain the reason for the status and what further information would be required to progress to standards track.  For example, section 12 of RFC6928 provides "Usage and Deployment Recommendations" that describe the experiments expected by the TCPM working group.  Section 4 of RFC4614 provides other examples of extensions that were considered experimental when the specification was published. Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being actively measured, and where it is possible to deactivate them if there are signs of pathological behavior. </ins> Congestion control algorithms with a record of measured Internet- scale deployment MAY directly seek the Standards Track if there is
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: of this data does not waive the other considerations in this document. <del> Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being actively measured, and where it is possible to deactivate them if there are signs of pathological behavior. </del> Each published congestion control algorithm is REQUIRED to include a statement in the abstract indicating whether or not there is IETF consensus that the proposed congestion control algorithm is
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: the Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating that the mechanism is only being proposed for use in controlled environments.  The abstract specifies <del> environments where the Quick- Start request could give false positives (and therefore 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 is not 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. </del> <ins> environments where the Quick-Start request could give false positives (and therefore 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 is not 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> Strictly speaking, Informational RFCs in the IETF stream need not meet all of the criteria in this document, as they do not carry a
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: 5. <del> As noted above, authors are expected to do a well-rounded evaluation of the pros and cons of congestion control algorithms that are brought to the IETF.  The following guidelines are designed to help authors and the IETF community.  Concerns that fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered an all-encompassing check-list. </del> <ins> Authors are expected to evaluate the congestion control algorithms that they bring to the IETF.  The working group is expecteed to complete a well-rounded evaluation of the pros and cons of an algorithm before it submits the specification for publication by the IETF. The following guidelines are designed to help authors and the IETF community.  Concerns that fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered an all-encompassing check-list. </ins> When considering a proposed congestion control algorithm, the community MUST consider the following criteria.  These criteria will