jiebi/CodeConvo huggingface dataset:
Change:
…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.

Discussion:
HTTP includes state of the art standardized security mechanisms, and <del> HTTP can make use of already-deployed caching infrastructure. </del> <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
Change:
LGTM - and my comment is the same length as the change itself, so I'm merging now ...

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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. <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
Change:
consolidated venue and history sections, moved TBDs to issues list and removed from draft, added a few links to help reviewers Any changes anyone would like to see, or does this work? I propose that any of us other than the pull-requester should feel free to merge it if they're happy with it and nobody has objected in a reasonably short time, or of course to suggest improvements.

Discussion:
proposals to use in describing how new technologies address or avoid these existing observed problems. <del> 1.1. Note to RFC Editor: Please remove this section before publication (To the editor: check this repository URL after the draft is adopted. The working group may create its own repository) This document is in the Github repository at https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are welcome to open issues and send pull requests for this document. Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org). </del> 2. 2.1.

4. <del> Note to RFC Editor: Please remove this section before publication TBD: suggestion from mic at IETF 106 (Mark Nottingham): dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) https://www.youtube.com/watch?v=4_k340xT2jM&t=13m TBD: suggestion from mic at IETF 106 (Dave Oran + Glenn Deen responding): pre-placement for many use cases is useful-distinguish between live vs.  cacheable.  "People assume high-demand == live, but not always true" with popular netflix example. (Glenn): something about latency requirements for cached vs. streaming on live vs.  pre-recorded content, and breaking requirements into 2 separate charts.  also: "Standardized ladder" for adaptive bit rate rates suggested, declined as out of scope. https://www.youtube.com/watch?v=4_k340xT2jM&t=14m15s TBD: suggestion at the mic from IETF 106 (Aaron Falk): include industry standard metrics from citations, some standard scoping metrics may be already defined.  https://www.youtube.com/ watch?v=4_k340xT2jM&t=19m15s </del> <ins> Note to RFC Editor: Please remove this section and its subsections before publication. This section is to provide references to make it easier to review the development and discussion on the draft so far. 4.1. (To the editor: check this repository URL after the draft is adopted. The working group may create its own repository) This document is in the Github repository at https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are welcome to open issues and send pull requests for this document. Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org). 4.2. Presentations: IETF 105 BOF: https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s IETF 106 Mops meeting: https://www.youtube.com/ watch?v=4_k340xT2jM&t=7m23s List archive search for doc mentions: https://mailarchive.ietf.org/arch/browse/mops/?q=draft-ietf-mops- streaming-opcons </ins> 5.
Change:
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.

Discussion:
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> <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 <del> typical per-user bandwidth requirements according to this formula: </del> <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, <del> approximately up to 80 Gbps would be necessary in order for all of them to get 1080p resolution at 60 fps. </del> <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
Change:
NAME and NAME - note that John's last comment hasn't been addressed in this PR yet.
Added a single comment for the subsequent sentence where you made a change.
NAME and NAME - Most of John's comments are nits and easy to resolve, but there are two that need thought. First, this comment So, let's think about this. We're looking at two, related statements, I'm wondering if it is correct to say Streaming is continuous transmission of media from a server to a client and its simultaneous consumption by the client. I'll make that change, and see if anyone objects. Second, this comment (followed by some excellent guesses about recourse) I read this text as saying that your streaming service is less complex if you have an intermediary that is modifying manifests during peak hours, than if you add that functionality to media servers that are already complex, especially if intermediaries are making a few well-understood changes to the manifests that only need to work for media players downstream on a given path, while a media server would have to maintain multiple versions of the manifests that that, in total, cover every possible modification that any intermediary would have done, and then figure out how to send each media player the appropriate version of the manifest for that media player. If that's what other people think, we can say that. If it's not what other people think, we need to talk.
The first one works for me ("Streaming is a continuous transmission of media"). For the second, yes, that was my intent. It is possible to deliver different manifests to different clients. Doing so based on some kind of aggregated estimate of the path load (possibly including peak hours/time of day, etc.) can do roughly the same job of reducing network load that was previously done with on-path edits to unencrypted manifests, but it adds a lot of complexity to the media service, which was previously instead taken on by (some of) the networks with a problem.
lgtm

Discussion:
This document specifically focuses on streaming applications and defines streaming as follows: <del> Streaming is the transmission of continuous media from a server to </del> <ins> Streaming is the continuous transmission of media from a server to </ins> a client and its simultaneous consumption by the client. <del> Here, "continuous media" refers to media and associated streams </del> <ins> Here, "media" refers to any type of media and associated streams </ins> such as video, audio, metadata, etc.  In this definition, the critical term is "simultaneous," as it is not considered streaming if one downloads a media file and plays it after the download is

different goal.  For instance, application-level encryption may be used for business purposes, such as avoiding piracy or enforcing geographic restrictions on playback, while transport-layer encryption <del> may be used to prevent media steam manipulation or to protect </del> <ins> may be used to prevent media stream manipulation or to protect </ins> manifests. This document does not take a position on whether those goals are
Change:
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.

Discussion:
1.1. <del> A full review of all streaming media considerations is too wide a </del> <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 <del> complexity when things like personalization or ad workflows are introduced. </del> <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.
Change:
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.

Discussion:
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> <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, <del> SCTP RFC4960, which can use partial reliability RFC3758 to recover </del> <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
Change:
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.

Discussion:
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> <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, <del> the transport protocol detects loss due to congestion and reduces its sending window size per round trip, </del> <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 <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> <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.
Change:
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.

Discussion:
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> <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. <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> <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
Change:
I assume this is uncontroversial and am therefore just merging it, hearing no objections.

Discussion:
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.
Change:
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.

Discussion:
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
Change:
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.

Discussion:
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