jiebi/CodeConvo huggingface dataset:
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
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
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
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
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.
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
also required to include a statement in the abstract describing environments where the protocol is not recommended for deployment. There can be environments where the congestion control algorith is <del> deemed _safe_ for use, but it is still is not _recommended_ for use because it does not perform well for the user. </del> <ins> deemed _safe_ for use, but it is still is _not recommended_ for use because it does not perform well for the user RFC8890. </ins> As examples of such statements, RFC3649 specifying HighSpeed TCP includes a statement in the abstract stating that the proposed congestion control algorithm is Experimental, but may be deployed in <del> the current Internet.  In contrast, the Quick-Start document RFC4782 includes a paragraph in the abstract stating the mechanism is only being proposed for use in controlled environments.  The abstract specifies 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 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. Alhough out of the scope of this document, a proponent of a new </del> <ins> 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 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 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. Alhough out of the scope of this document, proponents of a new </ins> algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In general, these algorithms are expected to be less mature than ones
2. <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. 3. </ins> This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations
or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). <del> 3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 4. Algorithms can be designed for general Internet deployment or for use
General-purpose protocols need to coexist in the Internet with real- time congestion control algorithms, which, in general, have finite throughput requirements (i.e., do not seek to utilize all available <del> capacity) and more strict latency bounds. </del> <ins> capacity) and more strict latency bounds.  See RFC8836 for a description of the characteristics of this use case and the resulting requirements. </ins> RFC8868 provides suggestions for real-time congestion control design and RFC8867 suggests test cases.  RFC9392 describes some
3. <ins> 3.1. This document does not specify specific evaluation methods, short of internet-scale deployment and measurement, to test the criteria described below.  There are multiple possible approaches to evaluation.  Each has a role, and the most appropriate approach depends on the criteria being evaluated and the maturity of the specification. For many algorithms, an initial evaluation will consider individual protocol mechanisms in a simulator to analyse their stability and safety across a wide range of conditions, including overload.  For example, RFC8869 describes evaluation test cases for interactive real-time media over wireless networks.  Such results could also be published or discussed in IRTF research groups, such as ICCRG and MAPRG. Before a proposed congestion control algorithm is published as an Experimental or Standards Track RFC, the community SHOULD gain practical experience with implementation and experience using the algorithm.  Where there is implementation by independent teams, this can help provide assurance that a specification has avoided assumptions or ambiguity.  An independent evaluation by multiple teams helps provide assurance that the design meets the evaluation criteria, and can assess typical interactions with other traffic. This evaluation could use an emulated laboratory environment or a controlled experiment (within a limited domain or at Internet-scale). Evidence of results is normally considered by the working group in deciding if a specification is ready for publication and ought to be documented in any request for the working group to publish the specification. 3.2. </ins> This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations
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 formal recommendation from the community.  Instead, the community judges the publication of Informational RFCs based on the value of their addition to the RFC series. </ins> Although out of the scope of this document, proponents of a new algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In
requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and <del> a half BDP.  This was unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </del> <ins> a half times the Bandwidth Delay Product (BDP).  This was unsatisfactory, and indeed further versions have fixed 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
5.3.2. <del> The proposed congestion control algorithm ought to discuss whether it </del> <ins> A congestion control algorithm proposal MUST discuss whether it </ins> allows for incremental deployment in the targeted environment.  For a <del> mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </del> <ins> mechanism targeted for deployment in the current Internet, the proposal SHOULD discuss what is known (if anything) about the correct operation of the mechanisms with some of the equipment in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like. </ins> Similarly, if the proposed congestion control algorithm is intended only for specific environments (and not the global Internet), the
The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control specification explicitly forbids use on the public Internet, the <del> community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </del> <ins> community MUST reach 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
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
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
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.
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
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
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
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
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
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