jiebi/CodeConvo huggingface dataset:
Code change:
Added the missing 'd' - thanks Neal.
I'm separating AQM from ECN, although ECN relies on AQM design and deployment - ECN can be a force for good when detecting bottlenecks and latency - aka RFC 8087.
Well, yes. ECN, by itself, is one of the signals that can be used by CC algorithms, together with packet loss, delay variation, and packet acks (input to bandwidth measurement). Makes sense to separate it. However, the L4S folks have introduced a tight coupling between a very specific use of ECN in the L4S AQM, and a fine grain mandate of the expected behavior of the CCA. And I cringe each time I read their dual queue formula based on the asymptotic limit of Reno -- but not Cubic. I wish we could walk that back, or describe it in more neutral terms. With L4S, ECT(1) is a signal from the sending host to the network that CE marks should be apply at incipient congestion, instead of waiting for actual loss-generating queue buildup as in RFC 3168. Maybe that should be true even for algorithms that are not described in L4S. Of course, we have to deal with what we have. Maybe we should just quote all the relevant RFCs, and denote the difference between ECT(1)/EC and ECT(0)/EC. Senders using ECT(1) should consider that the rate of CE marking signals the intensity of the congestion, while senders using ECT(0) should consider individual CE marks as denoting actual congestion.
I think the ECN text ought to approach with something very generic like setting ECT can provide nice properties [RFC8087], but comes with requirements for reacting to ECN-CE marking. This reaction to ECN-CE marks needs to be evaluated to ensure this conforms with the style of ECN being used. I'll make a PR.
see Neal's comment

Related discussion:
text: 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
Code change:
Adding a scope that excludes multicast.
Uh, is a PR addressing the same issue -- you were supposed to review it?
Would if this variant is merged
Discussed at IETF-118. At least we can mention Sect 4 of Multicast UDP Usage Guidelines in RFC8085.
IETF 118: Possibility that we could rule this out of scope Also some interest in this as a separate document that comes after the -bis
So just to provide the background for my question. The Reliable Multicast Transport WG (RMT) did produce two expermential congestion control specifications for multicast: So these specifications exists. Most mulitcast deployments are done in controlled environments however, with [Automatic Multicast Tunneling] (URL) multicast traffic these days have more probability to occur across links where this traffic would share bottlenecks with other unicast traffic. However, this amount of traffic is still normally bit-rate bound so it might be considered just in-elastic and consuming the bit-rate it does. I also want to state that I am fine with declaring multicast out of scope, but maybe some information about that there exist algorithms should be includeded in the draft. So an explicit out of scope with some background section/appendix.
We will put it out of scope and point to RFC 8085
Sorry, just reading through these changes now -- Why does a PR on multipath close an issue on multicast? Am I missing something here?
Whoops, that does not seem correct, re-opened this issue.
To answer NAME more directly, I don't think this draft is in the business of listing algorithms unless it requires new proposals to be measured against them, and not even that if the topic is out of scope. 5033bis is not a congestion control tutorial.
NAME I think it is a question of how one resolve this and if one declares it out of scope. Are we explicitly stating something like this: Multicast congestion control algorithms is out scope, and the rules and requirements within this specification has not been evaluated on their applicability for multicast congestion control. Future work on multicast congesiton control to specify new algorithms or update existing [webrc][TFMCC] will have to evaluate what is applicable and if additional requirements are necessary.
Add a changelog item (as in ) and it LGTM.

Related discussion:
text: 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.
Code change:
If merged this
Our abstract starts: "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." ... is it just me, or does "inadequate" and "at conflict" seem an odd BCP statement from the IETF itself.
Agreed. How about something closer to: "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 interactive traffic workloads (VoIP, gaming, and videoconferencing)." cc: NAME NAME

Related discussion:
text: 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.
Code change:
If merged this
Our abstract starts: "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." ... is it just me, or does "inadequate" and "at conflict" seem an odd BCP statement from the IETF itself.
Agreed. How about something closer to: "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 interactive traffic workloads (VoIP, gaming, and videoconferencing)." cc: NAME NAME

Related discussion:
text: 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).
Code change:
Suggested AQM text to address issue, when merge will
This section is listed as a special case, which it is (kind of), but it seems rather out of place in that section - I think we might wish to move it to the previous section. Since the original BCP, AQM is more common and really ought to be considered in any new design - even if the design does not wish to optimise for this.
Previously discussed in
Editors 1/16/24: Just add a sentence that AQMs are hard to detect, and therefore must be thought about -- cannot just ban use of a CC with AQM. But this falls thematically in with the special cases.
AQ are only a problem if they introduce unexpected behavior. The classic example is rate limiting, for which BB had to introduce special code.
Although packet scheduling and policing are useful complimentary functions, I don't think they are AQM.

Related discussion:
text: 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
Code change:
eliminate some awkward/unnecessary phrases. Include brief rationale for a bis.
done
OK, how about now?

Related discussion:
text: 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.
Code change:
Sec 2 leans heavy on the dated example of Highspeed TCP and drives pretty much everything to Experimental "until such time that the community better understands the solution space." It says that experimental RFCs can either be those judged to be safe on the internet, or those intended for testbeds. At this point, we probably understand enough to allow proposals to go for Proposed Standard. The safe/testbed distinction also doesn't make sense -- we might want to standardize CCs for controlled environments, like DCTCP. This needs a complete rewrite. It wouldn't hurt for that rewrite to also note that the IRTF is another venue, non-normatively.
I think a rewrite would help, but I'm think that could be too radical - we still do have proposals that ought ton be EXP either until deployment experience; or until we can agree they are "safe" for more general use. That doesn't seem to be a problem to me, but we ought to allow PS also. I agree we ought to mention IRTF.

Related discussion:
text: 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.
Code change:
Also eliminated obsolete/redundant discussion of AQM.
We missed a TODO in "Wired Networks"
Approved. Is "As" really "Because" ?

Related discussion:
text: 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.
Code change:
Minor proposal: the leading sentence in the second paragraph of the section "Mixed algorithm" could be made a bit easier to read.
I think we can merge

Related discussion:
text: 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.
Code change:
This PR adds a definition for a timeline track format, along with details about how to identify timeline tracks in the catalog and how to update timeline tracks. and
I like it! Regarding "The publisher MUST publish a complete timeline in the first MOQT Object of each MOQT Group." it means that the first object of the group strictly inflates with time. For an open range track (for example a 24/7 video channel), it may become excessively long. We may allow summarization of old times in the timeline csv.
A special ‘timeline’ track is produced which describes the availability of groups and objects with respect to media time and wallclock time. May also carry media time events which can be used by the player in constructing a UI, for example “Goal”, “Penalty”. This track can be used by the player for seeking to request specific portions of a DVR window in a live stream, or to any portion of a VOD asset. This may be used for advertising insertion at a later date. In the proposed structure below, the metadata field may be empty. If present, it must be enclosed inside double quotes and may hold any string data. In this example, JSON and XML metadata entires are shown.
I like the idea. Note that some have advocated for KLV as the support for timed metadata for live video. Here is a Demuxed talk about it a couple of years ago URL

Related discussion:
text: be interpreted by receivers to mean that the publish session is complete. <del> 7. </del> <ins> 8. </ins> ToDo <del> 8. </del> <ins> 9. </ins> This document creates a new entry in the "MoQ Streaming Format" Registry (see MoQTransport Sect 8).  The type value is 0x001, the
Code change:
The current version of WARP only references CMAF packaging and does not make it clear that WARP is also intended to support LOC (Low Overhaded Container) packaging. LOC is defined by URL Currently the LOC spec defines both a streaming format and a packaging format. Reference for packaging will therefore need to be made to specific subsections of that draft. In the future if LOC packaging is separated from LOC streaming format, then the WARP references can be updated.

Related discussion:
text: 1. WARP Streaming Format (WARP) is a media format designed to deliver <del> CMAF CMAF compliant media content over Media Over QUIC Transport (MOQT) MoQTransport.  WARP works by fragmenting the bitstream into objects that can be independently transmitted.  WARP leverages a simple prioritization strategy of assigning newer content a higher delivery order, allowing intermediaries to drop older data, and video over audio, in the face of congestion.  Either complete Groups of Pictures (GOPS) ISOBMFF or individual frames are mapped to MoQTransport Objects.  WARP is targeted at interactive levels of live latency. </del> <ins> CMAF CMAF and LOC LOC compliant media content over Media Over QUIC Transport (MOQT) MoQTransport.  WARP works by fragmenting the bitstream into objects that can be independently transmitted.  WARP leverages the Common Catalog Format COMMON-CATALOG-FORMAT to describe the output of the original publisher.  WARP specifies how content should be packaged and signaled, defines how the catalog communicates the content, specifies prioritization strategies for real-time and workflows for beginning and terminating broadcasts.  WARP also details how end-subscribers may perform adaptive bitrate switching. WARP is targeted at real-time and interactive levels of live latency. </ins> This document describes version 1 of the streaming format.
Code change:
The current version of WARP only references CMAF packaging and does not make it clear that WARP is also intended to support LOC (Low Overhaded Container) packaging. LOC is defined by URL Currently the LOC spec defines both a streaming format and a packaging format. Reference for packaging will therefore need to be made to specific subsections of that draft. In the future if LOC packaging is separated from LOC streaming format, then the WARP references can be updated.

Related discussion:
text: 3. <del> WARP delivers CMAF-packaged media bitstreams.  This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. 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. </del> <ins> WARP delivers CMAF CMAF and LOC LOC packaged media bitstreams. Either format may be used in a broadcast, or they may be intermixed between tracks.  The packaging format of a track, once declared, MUST remain constant. </ins> 3.1. <del> The packaging mode value is defined by Table 2. </del> <ins> This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. Both CMAF Object mappings CMAFpackaging Section 4 are supported and a content producer may use either.  To identify to clients which object mapping mode is being used for a given Track, the catalog "packaging" field MUST use one of the values defined in Table 1.  The values are case-sensitive. Table 1 provides values for the catalog "packaging" field with CMAF packaging. </ins> 3.2. <ins> This specification references Low Overhead Container (LOC) LOC to define how audio and video content is packaged.  With this packaging mode, each EncodedAudioChunk or EncodedVideoChunk sample is placed in a separate MOQT Object.  Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. Table 2 provides values for the catalog "packaging" field with LOC packaging. 3.3. </ins> WARP Tracks MAY be time-aligned.  Those that are, are subject to the following requirements:
Code change:
The current version of WARP only references CMAF packaging and does not make it clear that WARP is also intended to support LOC (Low Overhaded Container) packaging. LOC is defined by URL Currently the LOC spec defines both a streaming format and a packaging format. Reference for packaging will therefore need to be made to specific subsections of that draft. In the future if LOC packaging is separated from LOC streaming format, then the WARP references can be updated.

Related discussion:
text: able to cleanly switch between time-aligned media tracks at group boundaries. <del> 3.3. </del> <ins> 3.4. </ins> The catalog and media object payloads MAY be encrypted.  Common Encryption CENC with 'cbcs' mode (AES CBC with pattern encryption) is <del> the RECOMMENDED encryption method. </del> <ins> the RECOMMENDED encryption method for CMAF packaged content. </ins> 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> ToDo - content protection for LOC-packaged content. </ins> 4. WARP uses the Common Catalog Format {[COMMON-CATALOG-FORMAT}} to