jiebi/CodeConvo huggingface dataset:
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.4. </del> <ins> 3.1.3. </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.5. </del> <ins> 3.1.4. </ins> (TODO: Discuss short and long flows)
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. <ins> 4.3. Congestion control performance is affected by the queue discipline applied at the bottleneck link.  The default queue discipline that MUST be evaluated is drop-tail, First In First Out (FIFO).  See aqm for evaluation of other queue disciplines. </ins> 5. The criteria in evaluation-criteria will be evaluated in the
5.1. <del> (TODO: Write this section) </del> <ins> Proposals SHOULD be evaluated under a variety of bottleneck queue disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this document.  RFC7567 describes design considerations for AQMs. Among the AQM techniques that might have an impact on a congestion control algorithm are FQ-CoDel RFC8290; Proportional Integral Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. </ins> 5.2. <ins> (TODO: Write this section) 5.3. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.3. </del> <ins> 5.4. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del> <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as
to concretely understand and investigate the wealth of proposals in this space. <ins> This document is meant to reduce the barriers to entry for new congestion control work.  As such, proponents should not interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the rest of this document. </ins> 2. Following the lead of HighSpeed TCP RFC3649, alternate congestion
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.4. </del> <ins> 3.1.3. </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.5. </del> <ins> 3.1.4. A great deal of congestion control analysis concerns the steady-state behavior of long flows.  However, many internet flows are relatively short-lived.  If they never experience a packet loss, they remain in the "slow start" mode of operation RFC5681 that features exponential congestion window growth. </ins> <del> (TODO: Discuss short and long flows) </del> <ins> Proposals will consider how new and short-lived flows affect long- lived flows, and vice versa. </ins> 3.2.
5.1. <del> (TODO: Write this section) </del> <ins> Proposals SHOULD be evaluated under a variety of bottleneck queue disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this document.  RFC7567 describes design considerations for AQMs. Among the AQM techniques that might have an impact on a congestion control algorithm are FQ-CoDel RFC8290; Proportional Integral Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. </ins> 5.2. <ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics. IoT nodes might be more constrained in power, CPU, or other parameters than conventional Internet hosts.  This might place limits on the complexity of any given algorithm.  These power and radio constraints might make the volume of control packets in a given algorithm a key evaluation metric. Furthermore, many IoT applications do not a have a human in the loop, and therefore have weaker latency constraints because they do not relate to a user experience. Extremely low-power links can lead to very low throughput and a low bandwidth- delay product, well below the standard operating range of most Internet flows. 5.3. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.3. </del> <ins> 5.4. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.
3.2.2. <del> (TODO: Clarify that real time congestion controls are included, with allowances for the poor documentation / open source availability of these) </del> <ins> General-purpose protocols coexist in the Internet with real-time congestion control protocols, which in general have finite throughput requirements (i.e.  they do not seek to utilize all available capacity) and more strict latency bounds. RFC8868 provides suggestions for real-time congestion control design and RFC8867 suggests test cases.  RFC9392 describes some considerations for the RTP Control Protocol (RTCP).  This document does not change the informational status of those RFCs. New proposals SHOULD consider coexistence with widely deployed real- time congestion controls.  Regrettably, at the time of writing, many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion controls have incomplete public specifications. To the extent that behavior of widely deployed algorithms is understood, proposals can analyze and simulate the their interaction with those algorithms.  To the extent they are not, experiments can be conducted where possible. Note that in many deployments, real-time traffic is directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which substantially reduces the interplay with other traffic.  However, proposals cannot assume that this is always the case. </ins> 3.2.3.
5.2. <del> (TODO: Write this section) </del> <ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics. IoT nodes might be more constrained in power, CPU, or other parameters than conventional Internet hosts.  This might place limits on the complexity of any given algorithm.  These power and radio constraints might make the volume of control packets in a given algorithm a key evaluation metric. Furthermore, many IoT applications do not a have a human in the loop, and therefore have weaker latency constraints because they do not relate to a user experience. Extremely low-power links can lead to very low throughput and a low bandwidth- delay product, well below the standard operating range of most Internet flows. </ins> 5.3.
Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. <ins> Congestion control algorithms that set one of the two Explicit Congestion Transport (ECT) codepoints in the IP header can gain the benefits of receiving Explicit Congestion Notifictaion (ECN) Congestion Experienced (CE) signals from an on-path AQM RFC8087.  Use of ECN ?RFC3168,RFC9332 results in requirements for the congestion control algorithm to react when it receives a packet with an ECN-CE marking.  This reaction needs to be evaluated to confirm that the algorithm conforms with the requirements of the ECT codepoint that was used. </ins> 5.2. The "Internet of Things" (IoT) is a broad concept, but for congestion
community has gained much more experience with indications of congestion beyond packet loss. <ins> Multicast congestion controls are a considerably less mature field of study and are not in scope for this document.  However, Section 4 of the UDP Usage Guidelines RFC8085 provide additional guidelines for multicast and broadcast usage of UDP. </ins> 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.
5.2. <ins> An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering.  This cannot be assumed.  An internet Path can also include complex subnetworks where the minimum delay changes over various time scales, resulting in a non-stationary minimum delay. 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 and where a node 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 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. Proposals SHOULD be evaluated to ensure their operation is robust when there is a significant change in the minimum delay. 5.3. </ins> The "Internet of Things" (IoT) is a broad concept, but for congestion control purposes it is often associated with unique characteristics.
bandwidth- delay product, well below the standard operating range of most Internet flows. <del> 5.3. </del> <ins> 5.4. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.4. </del> <ins> 5.5. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.5. </del> <ins> 5.6. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.6. </del> <ins> 5.7. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.7. </del> <ins> 5.8. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as
Abstract <del> The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks, wireless technologies such as 3GPP and WiFi, long distance satellite links) and also in conflict with the needed, more isochronous, behaviors of VoIP, gaming, and videoconferencing traffic.  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. </del> <ins> There have been proposals to extend or update the standard IETF congestion control schemes.  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles.  Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. </ins> 1.
in 2007 as a Best Current Practice to evaluate new congestion control algorithms as Experimental or Proposed Standard RFCs. <ins> The IETF's standard congestion control schemes have been shown to have performance challenges in various environments (e.g., high-speed networks, cellular and WiFi wireless technologies, long distance satellite links) and also for specific traffic workloads (VoIP, gaming, and videoconferencing). </ins> 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).
5.1. Proposals SHOULD be evaluated under a variety of bottleneck queue <del> disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. </del> <ins> disciplines.  The effect of an AQM discipline can be hard to detect by Internet evaluation.  At a minimum, a proposal should reason about an algorithm's response to various AQM disciplines.  Simulation or empirical results are, of course, valuable. </ins> Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this
Abstract <del> There have been proposals to extend or update the standard IETF congestion control schemes.  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles.  Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. </del> <ins> Introducing new or modified congestion controllers in the global Internet have possible ramifications to both the traffic using the new congestion controller and to traffic using a standardized congestion controller.  Therefore, the IETF must proceed with caution when evaluating alternate congestion control proposals.  The goal of this document is to provide guidance for considering standardization of alternate congestion controllers at the IETF.  It replaces RFC5033 to reflect changes in the congestion control landscape. </ins> 1.
attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049. <del> For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for standardization (either as Experimental or as Proposed Standard), one 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 ensure algorithm specifications are widely disseminated to facilitate further research.  Such an internet-draft could also be considered for publication 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. Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent Submissions via the RFC-Editor).  However, we would hope the guidelines in this document inform the IESG as they consider whether to add a note to such documents. </del> <ins> Though out of scope of this document, congestion controller proponents may also seek publication of an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In general, these proposals are expected to be less mature than ones that follow the procedures in this document.  Documentation of deployed congestion controllers that cannot be changed by IETF or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). </ins> 3.
4.1. <del> (TODO: Describe properties of wired networks.) Proposals should be investigated for robust performance with different queueing mechanisms in the routers, especially Random Early Detection (RED) FJ03 and Drop-Tail.  This evaluation is often not included in the internet-draft itself, but in related papers cited in the draft. </del> <ins> Wired networks are characterized by extremely low rates of packet loss except for those due to queue drops.  They tend to have stable aggregate bandwidth, usually higher than other types of links, and low non-queueing delay.  Because the properties are relatively simple, wired links are typically used as a "baseline" case even if they are not always the bottleneck link in the modern Internet. </ins> 4.2.
widely deploying a congestion control algorithm over the Internet, but the examples of Cubic and BBR teach us that deployment of new algorithms is not in fact gated by publication of the algorithm as an <del> RFC.  Nevertheless, guidelines are important, if only to remind potential inventors and developers of the multiple facets of the congestion control problem. </del> <ins> RFC. Nevertheless, specifying congestion control algorithms has a number of advantages: A specification can help implementers, operators, and other interested parties to develop a shared understanding of how the algorithm works and how it is expected to behave in various different scenarios or configurations. A specification can help potential contributors understand the algorithm, which can make it easier for them to suggest improvements and/or identify limitations.  Further, the specification can help multiple contributors align on a consensus change to the algorithm. A specification that is accessible to anyone circumvents the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. Beyond helping develop specific algorithm proposals, guidelines can also serve as a reminder to potential inventors and developers of the multiple facets of the congestion control problem. </ins> The evaluation guidelines in this document are intended to be consistent with the congestion control principles from RFC2914 of
deployed congestion control algorithms. In contexts where differing congestion control algorithms are used, <del> it is important to understand whether a proposal can induce more harm to flows sharing a bottleneck than for the 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.  An 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. </del> <ins> it is important to understand whether a proposal could result in more harm than previously defined algorithms to flows sharing a common bottleneck.  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.  An 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. </ins> 3.2.1.
3. <del> Each codec bitstream MUST be packaged in to a sequence of Objects within a separate track. </del> <ins> WARP delivers CMAF-packaged media bitstreams.  This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. </ins> <del> Media tracks SHOULD be media-time aligned.  CMAF CMAF Aligned Switching Sets meet this requirement.  A receiver SHOULD be able to cleanly switch between media tracks at group boundaries. </del> <ins> Both CMAF Object mappings CMAFpackaging Section 4 are supported and a content producer may use either.  To identify to consumers which object mapping mode is being used for a given Track, a new track field is defined as per table 1. </ins> <del> Each group MUST be independently decodeable.  Assigning a new group ID to each CMAF Fragment (see CMAF Sect 6.6.1) meets this requirement. </del> <ins> 3.1. The packaging mode value is defined by Table 2. 3.2. WARP Tracks MAY be time-aligned.  Those that are, are subject to the following requirements: Time-aligned tracks MUST be advertised in the catalog as belonging to a common render group. The presentation time of the first media sample contained within the first MOQT Object of each equally numbered MOQT Group MUST be identical. A consequence of this restriction is that a WARP receiver SHOULD be able to cleanly switch between time-aligned media tracks at group boundaries. 3.3. The catalog and media object payloads MAY be encrypted.  Common Encryption CENC with 'cbcs' mode (AES CBC with pattern encryption) is the RECOMMENDED encryption method. ToDo - details of how keys are exchanged and license servers signaled.  May be best to extend catalog spec to allow the specification of content protection schema, along with any pssh or protection initialization data. </ins> 4.