jiebi/TextFlow huggingface dataset:
Original text:
also provides both hop-by-hop and end-to-end security guarantees, but can be used with other transport protocols beyond SRTP. <del> If a content provider chooses not to involve intermediaries, this choice should be carefully considered.  As an example, if media manifests are encrypted end-to-end, network providers who had been able to lower offered quality and reduce on their networks will no longer be able to do that.  Some resources that might inform this consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic- </del>  manageability (for HTTP/3 and QUIC). 7.3.

Reviewer comments:
…seemed more well covered in 8824 than in 8825.)
IGTM!
From NAME Last paragraph, while I understand why some mobile providers wants "to lower quality" it would be easier for the reader to understand if the text said "in order to reduce the bandwidth on expensive links, some operators want to lower the quality".
Describe how editing manifests lowers the bandwidth requirements.

Revised text:
also provides both hop-by-hop and end-to-end security guarantees, but can be used with other transport protocols beyond SRTP.  <ins> The choice of whether to involve intermediaries sometimes requires careful consideration.  As an example, when ABR manifests were commonly sent unencrypted some networks would modify manifests during peak hours by removing high-bitrate renditions in order to prevent players from choosing those renditions, thus reducing the overall bandwidth consumed for delivering these media streams and thereby improving the network load and the user experience for their customers.  Now that ubiquitous encryption typically prevents this kind of modification, in order to maintain the same level of network health and user experience across networks whose users would have benefitted from this intervention a media streaming operator sometimes needs to choose between adding intermediaries who are authorized to change the manifests or adding significant extra complexity to their service. Some resources that might inform other similar considerations are further discussed in RFC8824 (for WebRTC) and I-D.ietf-quic- </ins> manageability (for HTTP/3 and QUIC). 7.3.
Original text:
HTTP includes state of the art standardized security mechanisms, and <del> HTTP can make use of already-deployed caching infrastructure. </del>  Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport

Reviewer comments:
…astructure
Looks good to me. I've been through the doc looking at occurrences of "cach", "prox", and "CDN", and they all looked fine to me.

Revised text:
HTTP includes state of the art standardized security mechanisms, and  <ins> HTTP can make use of already-deployed caching infrastructure such as CDNs (Content Delivery Networks), local proxies, and browser caches. </ins> Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport
Original text:
entertainment applications as people watched videos or played games. <del> At the IXP-level, it was observed that port utilization increased. This phenomenon could probably be explained by a higher level of uncacheable traffic such as videoconferencing and VPNs from residential users as they stopped commuting and switched to work- at-home. </del>  4.

Reviewer comments:
LGTM - and my comment is the same length as the change itself, so I'm merging now ...

Revised text:
entertainment applications as people watched videos or played games.  <ins> At the IXP level, it was observed that physical link utilization increased.  This phenomenon could probably be explained by a higher level of uncacheable traffic such as videoconferencing and VPNs from residential users as they stopped commuting and switched to work-at-home. </ins> 4.
Original text:
3.2.1. There are many reasons why path characteristics might change <del> suddenly, for example, "cross traffic" that traverses part of the path, especially if this traffic is "inelastic", and does not, itself, respond to </del>  indications of path congestion. <del> routing changes, which can happen in normal operation, especially if the new path now includes path segments that are more heavily loaded, offer lower total bandwidth, or simply cover more distance. </del> In order to recognize that a path carrying streaming media is "not behaving the way it normally does", having an expected baseline that describes "the way it normally does" is fundamental.  Analytics that

Reviewer comments:
From NAME Section 3.2.1 says, "There are many reasons why path characteristics might change suddenly...". It may be good to mention MTU changes as part of the path changes, since changes in the maximum packet sizes supported by paths can be disruptive to traffic (requiring new PMTUD, etc).
FWIW, I agree with this. I may try to think of others that we should also add.

Revised text:
3.2.1. There are many reasons why path characteristics might change  <ins> suddenly, but we can divide these reasons into two categories: If the path topology changes.  For example, routing changes, which can happen in normal operation, may result in traffic being carried over a new path topology that that is partially or entirely disjoint from the previous path, especially if the new path topology includes one or more path segments that are more heavily loaded, offer lower total bandwidth, change the overall Path MTU size, or simply cover more distance between the path endpoints. If "cross traffic" that also traverses part or all of the same path topology increases or decreases, especially if this new "cross traffic" is "inelastic", and does not, itself, respond to </ins> indications of path congestion.  In order to recognize that a path carrying streaming media is "not behaving the way it normally does", having an expected baseline that describes "the way it normally does" is fundamental.  Analytics that
Original text:
approximately matches the bandwidth requirement estimates from several video providers is given in MSOD: <del> Height and width are in pixels, and frame rate is in frames per second.  The actual bitrate required for a specific video will also depend on the codec used, fidelity desired and some other characteristics of the video itself, such as the amount and frequency of high-detail motion, which may influence the compressability of the content, but this equation provides a rough estimate. </del>  Here are a few common resolutions used for video content, with their <del> typical per-user bandwidth requirements according to this formula: </del>  2.1.2. bandwidth requirements for a router on the delivery path with that number of users downstream.  For example, at a node with 10,000 downstream users simultaneously consuming video streams, <del> approximately up to 80 Gbps would be necessary in order for all of them to get 1080p resolution at 60 fps. </del>  However, when there is some overlap in the feeds being consumed by end users, it is sometimes possible to reduce the bandwidth

Reviewer comments:
This is my attempt at the changes we discussed in URL to include both the high-end and the typical bitrate needs.
Changes look good to me.

Revised text:
approximately matches the bandwidth requirement estimates from several video providers is given in MSOD:  <ins> Height and width are in pixels, frame rate is in frames per second, and the motion factor is a value that ranges from 20 for a low-motion talking heads video to 7 for sports, and content with a lot of screen changes. The motion factor captures the variability in bitrate due to the amount and frequency of high-detail motion, which generally influences the compressability of the content. The exact bitrate required for a particular video also depends on a number of specifics about the codec used and how the codec-specific tuning parameters are matched to the content, but this equation provides a rough estimate that approximates the usual bitrate characteristics using the most common codecs and settings for production traffic. </ins> Here are a few common resolutions used for video content, with their  <ins> typical and peak per-user bandwidth requirements for 60 frames per second (FPS): </ins> 2.1.2. bandwidth requirements for a router on the delivery path with that number of users downstream.  For example, at a node with 10,000 downstream users simultaneously consuming video streams,  <ins> approximately 80 Gbps would be necessary in order for all of them to get typical content at 1080p resolution at 60 fps, or up to 180 Gbps to get sustained high-motion content such as sports, while maintaining the same resolution. </ins> However, when there is some overlap in the feeds being consumed by end users, it is sometimes possible to reduce the bandwidth
Original text:
1.1. <del> A full review of all streaming media considerations is too wide a </del>  topic to cover comprehensively in a single document. This document focuses chiefly on large-scale delivery of streaming purposes of this document they're considered network path properties  1.2. Note to RFC Editor: Please remove this section and its subsections content bitrate.  The size of the buffer is also commonly a fixed size.  The fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant <del> complexity when things like personalization or ad workflows are introduced. </del>  The challenges in filling the buffer in a timely way fall into two broad categories: 1. content selection and 2. content variation.

Reviewer comments:
Check against new main version for duplication on scope.
Discussion from editor's conference call: find a better place to put description of WebRTC (now that we have a good scope section).
From NAME
NAME - please see what you think of the new location for the mention of WebRTC.
Sure, this seems fine.

Revised text:
1.1.  <ins> A full review of all streaming media considerations is too broad a </ins> topic to cover comprehensively in a single document. This document focuses chiefly on large-scale delivery of streaming purposes of this document they're considered network path properties <ins> It is worth pointing out explicitly, because questions about "Web Real-Time Communication", or "WebRTC", come up often, that some WebRTC protocols (RFC8834, RFC8835) are mentioned in this document, including RTP, WebRTC's principal media transport protocol.  However, (as noted in sd) it is difficult to give general guidance for unreliable media transport protocols, even in the specific case of WebRTC. </ins> 1.2. Note to RFC Editor: Please remove this section and its subsections content bitrate.  The size of the buffer is also commonly a fixed size.  The fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant  <ins> complexity when things like personalization or advertising insertion workflows are introduced. </ins> The challenges in filling the buffer in a timely way fall into two broad categories: 1. content selection and 2. content variation.
Original text:
caches. Various HTTP versions have been used for media delivery.  HTTP/1.0, <del> HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport behavior is described in reliable-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </del>  Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, unreliable-behavior, and hop-by-hop- RTP RFC3550, which can notice packetloss and repair some limited reordering, <del> SCTP RFC4960, which can use partial reliability RFC3758 to recover </del>  from some loss, but can abandon recovery to limit head-of-line blocking, and

Reviewer comments:
lgtm
From NAME
Done, except that 4960bis has now popped out as RFC9260. For these next two comments - our responses to reviews from NAME and NAME especially in dropping a lot of the archeology text about TCP, focusing on transport services, and working to make sure we are comparing apples to apples (2022 TCP to 2022 QUIC), have significantly improved the document throughout Section 6. The new discussion of "typically implemented in a kernel, although it doesn't have to be" and "typically implemented in userspace, although it doesn't have to be" is also intended to be more even-handed than the original text. I'm still following up on a couple of things with NAME and NAME but -11 will be significantly better, thanks to the review teams.

Revised text:
caches. Various HTTP versions have been used for media delivery.  HTTP/1.0,  <ins> HTTP/1.1 and HTTP/2 are carried over TCP I-D.ietf-tcpm-rfc793bis, and TCP's transport behavior is described in reliable-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </ins> Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, unreliable-behavior, and hop-by-hop- RTP RFC3550, which can notice packetloss and repair some limited reordering,  <ins> SCTP RFC9260, which can use partial reliability RFC3758 to recover </ins> from some loss, but can abandon recovery to limit head-of-line blocking, and
Original text:
Even when the bandwidth requirements for video streams along a path are well understood, additional analysis is required to understand <del> the constraints on bandwidth at various points in the network.  This analysis is necessary because media servers may react to bandwidth constraints using two independent feedback loops: </del>  Media servers often respond to application-level feedback from the media player that indicates a bottleneck somewhere along the path In one example, if a media server overestimates the available bandwidth to the media player, <del> the transport protocol detects loss due to congestion and reduces its sending window size per round trip, </del>  the media server adapts to application-level feedback from the media player and reduces its own sending rate, probing. To avoid these types of situations, which can potentially affect all <del> the users whose streaming media segments traverse a bottleneck, there are several possible mitigations that streaming operators can use. However, the first step toward mitigating a problem is knowing that a problem is occurring. </del>  3.2.1.

Reviewer comments:
From NAME -
NAME - after thinking about this comment, I think two things need to happen - your observation about bottlenecks at different nodes/hops/layers of the protocol stack belongs at the beginning of this section, because we're drilling down on ONE layer of the protocol stack in the rest of section 3.2, and as you say, the reference to "link" is not helpful here. Please let me know if URL is responsive to this comment.

Revised text:
Even when the bandwidth requirements for video streams along a path are well understood, additional analysis is required to understand  <ins> the constraints on bandwidth at various points along the path between media servers and media players.  Video streams can encounter bottlenecks at many points along a path, whether the bottleneck happens at a node or at a path segment along the path, and these bottlenecks may involve a lack of processing power, buffering capacity, link speed, or any other exhaustible resource. Media servers may react to bandwidth constraints using two independent feedback loops: </ins> Media servers often respond to application-level feedback from the media player that indicates a bottleneck somewhere along the path In one example, if a media server overestimates the available bandwidth to the media player,  <ins> the transport protocol may detect loss due to congestion and reduce its sending window size per round trip, </ins> the media server adapts to application-level feedback from the media player and reduces its own sending rate, probing. To avoid these types of situations, which can potentially affect all  <ins> the users whose streaming media segments traverse a bottleneck path segment, there are several possible mitigations that streaming operators can use.  However, the first step toward mitigating a problem is knowing that a problem is occurring. </ins> 3.2.1.
Original text:
to-glass delay target under 10 seconds. This level of latency is targeted to have a user experience similar <del> to traditional broadcast TV delivery.  A frequently cited problem with failing to achieve this level of latency for live sporting events is the user experience failure from having crowds within earshot of one another who react audibly to an important play, or from users who learn of an event in the match via some other channel, for example, social media, before it has happened on the screen showing the sporting event. </del>  Applications requiring low-latency live media delivery are generally feasible at scale with some restrictions.  This typically requires 4.3. <del> Non-low-latency live delivery of media is defined here as a live stream that does not have a latency target shorter than 10 seconds. </del>  This level of latency is the historically common case for segmented video delivery using HLS RFC8216 and DASH MPEG-DASH.  This level of

Reviewer comments:
From NAME
NAME - thank you for this review. You caught a lot more things than I was hoping were still in there. :grinning:
PR should address these issues (and more).
Agree with NAME that this fixed lots of stuff. I'd like to leave it open so we can run this tool again after addressing more issues.

Revised text:
to-glass delay target under 10 seconds. This level of latency is targeted to have a user experience similar  <ins> to broadcast TV delivery.  A frequently cited problem with failing to achieve this level of latency for live sporting events is the user experience failure from having crowds within earshot of one another who react audibly to an important play, or from users who learn of an event in the match via some other channel, for example, social media, before it has happened on the screen showing the sporting event. </ins> Applications requiring low-latency live media delivery are generally feasible at scale with some restrictions.  This typically requires 4.3.  <ins> Non-low-latency live delivery of media is defined here as a livestream that does not have a latency target shorter than 10 seconds. </ins> This level of latency is the historically common case for segmented video delivery using HLS RFC8216 and DASH MPEG-DASH.  This level of
Original text:
IETF 106 meeting: https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s  2. 2.1.

Reviewer comments:
I assume this is uncontroversial and am therefore just merging it, hearing no objections.

Revised text:
IETF 106 meeting: https://www.youtube.com/watch?v=4_k340xT2jM&t=7m23s <ins> MOPS Interim Meeting 2020-04-15: https://www.youtube.com/watch?v=QExiajdC0IY&t=10m25s IETF 108 meeting: https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s </ins> 2. 2.1.
Original text:
5. <del> *Note to Reviewers* This section includes some material on UDP and TCP that may be tutorial for some readers.  We can decide how to explain that, if the working group feels that this tutorial material is worth keeping. Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless the reader participated in the QUIC working group. </del> Because networking resources are shared between users, a good place to start our discussion is how contention between users, and mechanisms to resolve that contention in ways that are "fair" between

Reviewer comments:
Remove this material from Sec 5: This section includes some material on UDP and TCP that may be tutorial for some readers. We can decide how to explain that, if the working group feels that this tutorial material is worth keeping. Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless the reader participated in the QUIC working group.

Revised text:
5.  Because networking resources are shared between users, a good place to start our discussion is how contention between users, and mechanisms to resolve that contention in ways that are "fair" between
Original text:
jump over the years due to increased consumption of entertainment as well as conversational video. <del> TBD: insert charts showing historical relative data usage patterns with error bars by time of day in consumer networks? TBD: Cross-ref vs. video quality by time of day in practice for some case study?  Not sure if there's a good way to capture a generalized insight here, but it seems worth making the point that demand projections can be used to help with e.g. power consumption with routing architectures that provide for modular scalability. </del> 2.5. Although TCP/IP has been used with a number of widely used

Reviewer comments:
I don't remember where this suggestion came from, but it was on the list in the 107 interim slides, so I figured it should be tracked: URL
Maybe refer to Cisco VNI? URL
Cisco VNI link is already a 404, so ... Checking with RFC Editor to see whether they can handle SVG yet.
The point of this is trying to show internet scale growth of video traffic over time, both by proportion and by gross volume, not really about including pictures. This maybe is already covered by our intro paragraph: "Estimates put the total share of internet video traffic at 75% in 2019, expected to grow to 82% by 2022. This estimate projects the gross volume of video traffic will more than double during this time, based on a compound annual growth rate continuing at 34% (from Appendix D of [CVNI])." We should consider just closing this issue.
Related point (perhaps a new issue?): this info may stop being available--prior reports often came from DPI at IXPs or similar to monitor traffic, but since the dawn of ubiquitous encryption this info will stop being available, and we'll (probably?) only have reports from servers.
We're thinking this is Won't Fix - at a minimum, this isn't information we can update in the future.
Pulled these out of the text of the draft as part of this issue, from the bottom of section "2.4 Predictable Usage Profiles": TBD: insert charts showing historical relative data usage patterns with error bars by time of day in consumer networks? TBD: Cross-ref vs. video quality by time of day in practice for some case study? Not sure if there's a good way to capture a generalized insight here, but it seems worth making the point that demand projections can be used to help with e.g. power consumption with routing architectures that provide for modular scalability.

Revised text:
jump over the years due to increased consumption of entertainment as well as conversational video.  2.5. Although TCP/IP has been used with a number of widely used
Original text:
4.2.3. <del> Each PAUploadReq carries a list of extensions that clients may use to </del>  convey additional, authenticated information in the report.  Each extension is a tag-length encoded value of the following form:

Reviewer comments:
NAME I'm struggling with Github here and can't figure out what change you want.
Thanks.
Disregard, I found it and pushed myself.

Revised text:
4.2.3.  <ins> Each UploadReq carries a list of extensions that clients may use to </ins> convey additional, authenticated information in the report.  Each extension is a tag-length encoded value of the following form: