jiebi/TextFlow huggingface dataset:
Original 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>  1.

Reviewer comments:
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

Revised text:
Abstract  <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.
Original text:
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).

Reviewer comments:
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

Revised 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).
Original 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>  Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this

Reviewer comments:
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.

Revised text:
5.1. Proposals SHOULD be evaluated under a variety of bottleneck queue  <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
Original 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>  1.

Reviewer comments:
eliminate some awkward/unnecessary phrases. Include brief rationale for a bis.
done
OK, how about now?

Revised text:
Abstract  <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.
Original 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>  3.

Reviewer comments:
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.

Revised text:
attempting to use Quick-Start.  The Quick-Start method is discussed as an example in RFC9049.  <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.
Original 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>  4.2.

Reviewer comments:
Also eliminated obsolete/redundant discussion of AQM.
We missed a TODO in "Wired Networks"
Approved. Is "As" really "Because" ?

Revised text:
4.1.  <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.
Original 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>  3.2.1.

Reviewer comments:
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

Revised text:
deployed congestion control algorithms. In contexts where differing congestion control algorithms are used,  <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.
Original text:
be interpreted by receivers to mean that the publish session is complete. <del> 7. </del>  ToDo <del> 8. </del>  This document creates a new entry in the "MoQ Streaming Format" Registry (see MoQTransport Sect 8).  The type value is 0x001, the

Reviewer comments:
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

Revised text:
be interpreted by receivers to mean that the publish session is complete.  <ins> 8. </ins> ToDo  <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
Original 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>  This document describes version 1 of the streaming format.

Reviewer comments:
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.

Revised text:
1. WARP Streaming Format (WARP) is a media format designed to deliver  <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.
Original 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>  3.1. <del> The packaging mode value is defined by Table 2. </del>  3.2.  WARP Tracks MAY be time-aligned.  Those that are, are subject to the following requirements:

Reviewer comments:
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.

Revised text:
3.  <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.  <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:
Original text:
able to cleanly switch between time-aligned media tracks at group boundaries. <del> 3.3. </del>  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>  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.  4. WARP uses the Common Catalog Format {[COMMON-CATALOG-FORMAT}} to

Reviewer comments:
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.

Revised text:
able to cleanly switch between time-aligned media tracks at group boundaries.  <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  <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
Original text:
catalog object SHOULD only be published only when the availability of tracks changes. <del> Each catalog update MUST be mapped to a discreet moq-transport object. </del>  5. <del> The MOQT Groups and MOQT Objects need to be mapped to moq-transport Streams.  Irrespective of the packagingmode in place, each MOQT Object MUST be mapped to a new moq-transport Stream. </del>  6.

Reviewer comments:
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.

Revised text:
catalog object SHOULD only be published only when the availability of tracks changes.  <ins> Each catalog update MUST be mapped to a discreet MOQT Object. </ins> 5.  <ins> The MOQT Groups and MOQT Objects need to be mapped to MOQT Streams. Irrespective of the mediapackaging in place, each MOQT Object MUST be mapped to a new MOQT Stream. </ins> 6.
Original text:
a separate MOQT Object.  Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. <del> Table 2 provides values for the catalog "packaging" field with LOC packaging. </del>  3.2.

Reviewer comments:
Fixing table references and reformatting certain sections to 80 chars line width.
Table 2 is declared twice, as is Table 3.

Revised text:
a separate MOQT Object.  Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group.  <ins> When LOC packaging is used for a track, the catalog packaging attribute (packaging) MUST be present and it MUST be populated with a value of "loc". </ins> 3.2.
Original text:
publishers for advertising their output and for subscribers in consuming that output.  The payload of the Catalog object is opaque to Relays and can be end-to-end encrypted.  The Catalog provides the <del> names and namespaces of the tracks being produced, along with the relationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. </del>  The catalog track MUST have a case-sensitive Track Name of "catalog".

Reviewer comments:
Fixing table references and reformatting certain sections to 80 chars line width.
Table 2 is declared twice, as is Table 3.

Revised text:
publishers for advertising their output and for subscribers in consuming that output.  The payload of the Catalog object is opaque to Relays and can be end-to-end encrypted.  The Catalog provides the  <ins> names and namespaces of the tracks being produced, along with therelationship between tracks, properties of the tracks that consumers may use for selection and any relevant initialization data. </ins> The catalog track MUST have a case-sensitive Track Name of "catalog".