jiebi/CodeConvo huggingface dataset:
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.
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
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.
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
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
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
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
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.
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
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
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
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,
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.
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.
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
using spare capacity is discussed in Sections 6, 11.1, and 12 of RFC3649. <ins> Wireless links While the early Internet was dominated by wired links, the properties of wireless links have become extremely important to Internet performance.  In particular, congestion controllers should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. </ins> Difficult Environments. The proposed algorithms should be assessed in difficult <del> environments such as paths containing wireless links. Characteristics of wireless environments are discussed in RFC3819 and in Section 16 of Tools.  Other difficult environments can include those with multipath routing within a connection.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </del> <ins> environments.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </ins> While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with
the abstract stating the mechanism is only being proposed for controlled environments.  The abstract specifies environments where the Quick-Start request could give false positives (and therefore <del> would be unsafe to deploy).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would still not be recommended because it could cause unnecessary delays for the connections attempting to use Quick-Start. </del> <ins> would be unsafe for incremental deployment where some routers forward, but do not process the option).  The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would not be recommended because it could lead to unnecessary delays for the connections attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049. </ins> For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for
possibility would be to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities.  This is particularly encouraged in order to <del> get algorithm specifications widely disseminated to facilitate further research.  Such an internet-draft could be submitted to be considered as an Informational RFC, as a first step in the process towards standardization.  Such a document would also be expected to carry an explicit warning against using the scheme in the global Internet. </del> <ins> ensure algorithm specifications are widely disseminated to facilitate further research.  Such an internet-draft could also be considered as an Informational RFC, as a first step in the process towards standardization.  Such a document would be expected to carry an explicit warning against using the scheme in the global Internet. </ins> Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent
3.1.1. <ins> The alternate congestion control mechanism should not cause increased overhead under adverse network conditions. This criteria can be evaluated by counting the total bytes (data and headers) arriving at the receiver when delivering a fixed workload over varying network conditions.  The total delivered bytes should remain constant, independent of network conditions over the entire operating range for the protocol.  For general transport protocols such as TCP this means over any path in the Internet. There are known exceptions to this guideline, for example spurious Retransmission Timeouts RFC7765 and TCP loss Probe RFC8985.  These algorithms can substantially improve application performance in certain environments at the cost of additional network overhead due to spurious retransmissions. Alternate congestion control mechanisms should be carefully evaluated for exceptions.  That evaluation should appropriately reflect on any the inherent trade-offs. This criteria can also be applied protocol layers above transport. 3.1.2. </ins> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.3. </del> <ins> 3.1.4. </ins> When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. <del> 3.1.4. </del> <ins> 3.1.5. </ins> (TODO: Discuss short and long flows)
differentiated and used by a single connection at the sender.  A multipath sender can schedule which packets travel on which of its active paths.  This enables a tradeoff in timeliness and reliability. <ins> There are various ways that multipath techniques can be used, </ins> <del> One use is to provide fail-over from one path to another when the original path is no longer viable or to switch the traffic from one path to another when this is expected to improve performance </del> <ins> One example use is to provide fail-over from one path to another when the original path is no longer viable or to switch the traffic from one path to another when this is expected to improve performance </ins> (latency, throughput, reliability, cost).  Designs need to independently track the congestion state of each path, and need to demonstrate independent congestion control for each path being used.
contribute to harm and/or reduce fairness, these effects also ought to be evaluated. <del> A concurrent multipath transport protocol simultaneously schedules flows to aggregate the capacity across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: New CCs 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 fairness with other flows.  Synchronisation of CC 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> Another example use is concurrent multipath, where the transport protocol simultaneously schedules flows to aggregate the capacity across multiple paths.  The Internet provides no guarantee that different paths (e.g., using different endpoint addresses) are disjoint.  This has additional implications: New CCs 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 fairness with other flows.  Synchronisation of CC 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. </ins> 6.
3.1.4. <del> When multiple competing flows all using the same alternate congestion </del> <ins> When multiple competing flows all use the same alternate congestion </ins> control algorithm, the proposal should explore how the capacity is <del> shared among the competing flows. </del> <ins> shared among the competing flows.  Capacity fairness can be important when a small number of similar flows compete to fill a bottleneck. It can however also not be useful: for example when comparing flows seek to send at different rates or when some of the flows do not last sufficiently long to approach asymptotic behavior. </ins> 3.1.5. <ins> In contexts where differing congestion control algorithms are used, it is important to understand whether an alternate congestion control algorithm can induce more harm to sharing flows than existing defined methods.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the latency introduced, or an increase in packet loss.  This evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. 3.1.6. </ins> (TODO: Discuss short and long flows) 3.2.
New CCs 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 <del> overall capacity limit), and SHOULD consider the fairness with other flows.  Synchronisation of CC 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> overall capacity limit), and SHOULD consider the potential for harm to other flows.  Synchronisation of CC 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. </ins> 6.
3.1.1. <del> The alternate congestion control mechanism should not cause increased overhead under adverse network conditions. This criteria can be evaluated by counting the total bytes (data and headers) arriving at the receiver when delivering a fixed workload over varying network conditions.  The total delivered bytes should remain constant, independent of network conditions over the entire operating range for the protocol.  For general transport protocols such as TCP this means over any path in the Internet. There are known exceptions to this guideline, for example spurious Retransmission Timeouts RFC7765 and TCP loss Probe RFC8985.  These algorithms can substantially improve application performance in certain environments at the cost of additional network overhead due to spurious retransmissions. Alternate congestion control mechanisms should be carefully evaluated for exceptions.  That evaluation should appropriately reflect on any the inherent trade-offs. This criteria can also be applied protocol layers above transport. 3.1.2. </del> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714, or should include some notion of "full backoff".  For "full backoff", at some