8. <del> Editor's note: This section is to be kept in a living document where future references, links and/or updates to the existing references will be reflected.  That living document is likely to be an IETF- owned Wiki: https://tinyurl.com/streaming-opcons-reading </del>  <del> 8.1. </del>  <del> SVA Glossary: https://glossary.streamingvideoalliance.org/ Datazoom Video Player Data Dictionary: https://help.datazoom.io/hc/en-us/articles/360031323311 Datazoom Video Metrics Encyclopedia: https://help.datazoom.io/hc/ en-us/articles/360046177191 8.2. 8.2.1. The following papers describe how video is encoded, different video encoding standards and tradeoffs in selecting encoding parameters. Overview of the Versatile Video Coding (VVC) Standard and its Applications (https://ieeexplore.ieee.org/document/9503377) Video Compression - From Concepts to the H.264/AVC Standard (https://ieeexplore.ieee.org/document/1369695) Developments in International Video Coding Standardization After AVC, With an Overview of Versatile Video Coding (VVC) (https://ieeexplore.ieee.org/document/9328514) A Technical Overview of AV1 (https://ieeexplore.ieee.org/ document/9363937) CTU Depth Decision Algorithms for HEVC: A Survey (https://arxiv.org/abs/2104.08328) 8.2.2. The following papers summarize the methods for selecting packaging configurations such as the resolution-bitrate pairs, segment durations, use of constant vs. variable-duration segments, etc. Deep Reinforced Bitrate Ladders for Adaptive Video Streaming (https://dl.acm.org/doi/10.1145/3458306.3458873) Comparing Fixed and Variable Segment Durations for Adaptive Video Streaming: a Holistic Analysis (https://dl.acm.org/ doi/10.1145/3339825.3391858) 8.2.3. The following links describe some of the issues and solutions regarding the interconnecting of the content delivery networks. Open Caching: Open standards for Caching in ISP Networks: https://www.streamingvideoalliance.org/working-group/open-caching/ Netflix Open Connect: https://openconnect.netflix.com 8.2.4. The two surveys describe and compare different rate-adaptation algorithms in terms of different metrics like achieved bitrate/ quality, stall rate/duration, bitrate switching frequency, fairness, network utilization, etc. A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP (https://ieeexplore.ieee.org/document/8424813) A Survey of Rate Adaptation Techniques for Dynamic Adaptive Streaming Over HTTP (https://ieeexplore.ieee.org/document/7884970) 8.2.5. The following papers describe the peculiarities of adaptive streaming in low-latency live streaming scenarios. Catching the Moment with LoL+ in Twitch-like Low-latency Live Streaming Platforms (https://ieeexplore.ieee.org/document/9429986) Data-driven Bandwidth Prediction Models and Automated Model Selection for Low Latency (https://ieeexplore.ieee.org/ document/9154522) Performance Analysis of ACTE: A Bandwidth Prediction Method for Low-latency Chunked Streaming (https://dl.acm.org/ doi/10.1145/3387921) Online Learning for Low-latency Adaptive Streaming (https://dl.acm.org/doi/10.1145/3339825.3397042) Tightrope Walking in Low-latency Live Streaming: Optimal Joint Adaptation of Video Rate and Playback Speed (https://dl.acm.org/ doi/10.1145/3458305.3463382) Content-aware Playback Speed Control for Low-latency Live Streaming of Sports (https://dl.acm.org/ doi/10.1145/3458305.3478437) 8.2.6. The following papers explain the benefits of server and network assistance in client-driven streaming systems.  There is also a good reference about how congestion affects video quality and how rate control works in streaming applications. Manus Manum Lavat: Media Clients and Servers Cooperating with Common Media Client/Server Data (https://dl.acm.org/ doi/10.1145/3472305.3472886) Common media client data (CMCD): initial findings (https://dl.acm.org/doi/10.1145/3458306.3461444) SDNDASH: Improving QoE of HTTP Adaptive Streaming Using Software Defined Networking (https://dl.acm.org/ doi/10.1145/2964284.2964332) Caching in HTTP Adaptive Streaming: Friend or Foe? (https://dl.acm.org/doi/10.1145/2578260.2578270) A Survey on Multi-Access Edge Computing Applied to Video Streaming: Some Research Issues and Challenges (https://ieeexplore.ieee.org/document/9374553) The Ultimate Guide to Internet Congestion Control (https://www.compiralabs.com/ultimate-guide-congestion-control) 8.2.7. The following papers describe various QoE metrics one can use in streaming applications. QoE Management of Multimedia Streaming Services in Future Networks: a Tutorial and Survey (https://ieeexplore.ieee.org/ document/8930519) A Survey on Quality of Experience of HTTP Adaptive Streaming (https://ieeexplore.ieee.org/document/6913491) QoE Modeling for HTTP Adaptive Video Streaming-A Survey and Open Challenges (https://ieeexplore.ieee.org/document/8666971) 8.2.8. The following papers explain the latest developments in the immersive media domain (for video and audio) and the developing standards for such media. A Survey on Adaptive 360o Video Streaming: Solutions, Challenges and Opportunities (https://ieeexplore.ieee.org/document/9133103) MPEG Immersive Video Coding Standard (https://ieeexplore.ieee.org/ document/9374648) Emerging MPEG Standards for Point Cloud Compression (https://ieeexplore.ieee.org/document/8571288) Compression of Sparse and Dense Dynamic Point Clouds--Methods and Standards (https://ieeexplore.ieee.org/document/9457097) MPEG Standards for Compressed Representation of Immersive Audio (https://ieeexplore.ieee.org/document/9444109) An Overview of Omnidirectional MediA Format (OMAF) (https://ieeexplore.ieee.org/document/9380215) From Capturing to Rendering: Volumetric Media Delivery with Six Degrees of Freedom (https://ieeexplore.ieee.org/document/9247522) 8.3. 5G-MA: https://www.5g-mag.com/reference-tools dash.js: http://reference.dashif.org/dash.js/latest/samples/ DASH-IF Conformance: https://conformance.dashif.org ExoPlayer: https://github.com/google/ExoPlayer FFmpeg: https://www.ffmpeg.org/ GPAC: https://gpac.wp.imt.fr/ hls.js: https://github.com/video-dev/hls.js OBS Studio: https://obsproject.com/ Shaka Player: https://github.com/google/shaka-player Shaka Packager: https://github.com/google/shaka-packager Traffic Control CDN: https://trafficcontrol.apache.org/ VideoLAN: https://www.videolan.org/projects/ video.js: https://github.com/videojs/video.js 8.4. ACM Mile High Video (MHV): https://mile-high.video/ ACM Multimedia Systems (MMSys): https://acmmmsys.org ACM Multimedia (MM): https://acmmm.org ACM NOSSDAV: https://www.nossdav.org/ ACM Packet Video: https://packet.video/ Demuxed and meetups: https://demuxed.com/ and https://demuxed.com/ events/ DVB World: https://www.dvbworld.org EBU BroadThinking: https://tech.ebu.ch/events/broadthinking2021 IBC Conference: https://show.ibc.org/conference/ibc-conference IEEE Int. Conf. on Multimedia and Expo (ICME) Media Web Symposium: https://www.fokus.fraunhofer.de/de/go/mws Live Video Stack: https://sh2021.livevideostack.com Picture Coding Symp.  (PCS) SCTE Expo: https://expo.scte.org/ 8.5. 3GPP SA4: https://www.3gpp.org/specifications-groups/sa-plenary/ sa4-codec 5G-MAG: https://www.5g-mag.com/ AOM: http://aomedia.org/ ATSC: https://www.atsc.org/ CTA WAVE: https://cta.tech/Resources/Standards/WAVE-Project DASH Industry Forum: https://dashif.org/ DVB: https://dvb.org/ HbbTV: https://www.hbbtv.org/ HESP Alliance: https://www.hespalliance.org/ IAB: https://www.iab.com/ MPEG: https://www.mpegstandards.org/ Streaming Video Alliance: https://www.streamingvideoalliance.org/ SCTE: https://www.scte.org/ SMPTE: https://www.smpte.org/ SRT Alliance: https://www.srtalliance.org/ Video Services Forum: https://vsf.tv/ VQEG: https://www.its.bldrdoc.gov/vqeg/vqeg-home.aspx W3C: https://www.w3.org/ 8.6. 8.6.1. 5G new radio and systems technologies provide new functionalities for video distribution. 5G targets not only smartphones, but also new devices such as augmented reality glasses or automotive receivers. Higher bandwidth, lower latencies, edge and cloud computing functionalities, service-based architectures, low power consumption, broadcast/multicast functionalities and other network functions come hand in hand with new media formats and processing capabilities promising better and more consistent quality for traditional video streaming services as well as enabling new experiences such as immersive media and augmented realities. 5G Multimedia Standardization (https://www.riverpublishers.com/ journal_read_html_article.php?j=JICTS/6/1/8) 8.6.2. Ads can be inserted at different stages in the streaming workflow, on the server side or client side.  The DASH-IF guidelines detail server-side ad-insertion with period replacements based on manipulating the manifest.  HLS interstitials provide a similar approach.  The idea is that the manifest can be changed and point to a sub-playlist of segments, possibly located on a different location. This approach results in efficient resource usage in the network, as duplicate caching is avoided, but some intelligence at the player is needed to deal with content transitions (e.g., codec changes, timeline gaps, etc.).  Player support for such content is gradually maturing.  Other important technologies for ad insertion include signalling of ads and breaks that is still typically based on SCTE-35 for HLS and SCTE-214 for DASH.  Such signals provide useful information for scheduling the ads and contacting ad servers.  The usage of SCTE-35 for ad insertion is popular in the broadcast industry, while the exact usage in the OTT space is still being discussed in SCTE.  Another important technology is identification of ads, such as based on ad-id or other commercial entities that provide such services.  The identification of the ad in a manifest or stream is usually standardized by SMPTE.  Other key technologies for ad insertion include tracking of viewer impressions, usually based on Video Ad Serving Template (VAST) defined by IAB. DASH-IF Ad Insertion Guidelines: https://dashif.org/docs/CR-Ad- Insertion-r7.pdf SCTE-214-1: https://www.scte.org/standards-development/library/ standards-catalog/ansiscte-214-1-2016/ RP 2092-1:2015 - SMPTE Recommended Practice - Advertising Digital Identifier (Ad-ID) Representations: https://ieeexplore.ieee.org/ document/7291518 IAB Tech Lab Digital Video Studio: https://iabtechlab.com/audio- video/tech-lab-digital-video-suite/ 8.6.3. There are different contribution and ingest specifications dealing with different use cases.  A common case is contribution that previously happened over satellite to a broadcast or streaming headend.  RIST and SRT are examples of such contribution protocols. Within a streaming headend the encoder and packager/CDN may have an ingest/contribution interface as well.  This is specified by the DASH-IF Ingest. DASH-IF Ingest: https://github.com/Dash-Industry-Forum/Ingest RIST: https://www.rist.tv/ SRT: https://github.com/Haivision/srt 8.6.4. Practical streaming headends need redundant encoders and packagers to operate without glitches and blackouts.  The redundant operation requires synchronization between two or more encoders and also between two or more packagers that possibly handle different inputs and outputs, generating compatible inter-changeable output representations.  This problem is important for anyone developing a streaming headend at scale, and the synchronization problem is currently under discussion in the wider community.  Follow the developments at: https://sites.google.com/view/encodersyncworkshop/ home 8.6.5. WebRTC is increasingly being used for streaming of time-sensitive content such as live sporting events.  Innovations in cloud computing allow implementers to efficiently scale delivery of content using WebRTC.  Support for WebRTC communication is available on all modern web browsers and is available on native clients for all major platforms. DASH-IF WebRTC Discussions: https://dashif.org/webRTC/ Overview of WebRTC: https://webrtc.org/ </del>  9. 11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, <del> Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del>  12.  References [2] https://www.ietf.org/mailman/listinfo/mops [3] https://mailarchive.ietf.org/arch/browse/mops/

I made one change to the links, because this gets a 404: URL But a web search for "SCTE-214-1" found this instead, which seems to be a new location for the same thing: URL Additionally, There were 3 more links that failed check-URL URL URL URL All of these get something with chrome, but fail with curl. The datazoom links get a 403 and the iabtechlab gets a 406. (Changing the UA header to match chrome's made curl succeed with iabtechlab, but not the datazoom links. Didn't dig deeper yet.) I haven't put in automation for this, but I figure it's useful to have something at least to do a quick scan.
This works. These work just fine for me on chrome no 403 or 406, plain 200.
They work for me in chrome also, but they don't work in curl or wget so the script complains about them.
Looks good to me, modulo a Github Action error that we don't understand. Will merge now, so we can move forward.
Just make the change for ACM Mile-High Video Conference.

8.  <ins> The Media Operations community maintains a list of references and resources for further reading at this location: </ins>  <ins> https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [4] </ins>  <ins> Editor's note: The link above might or might not be changed during IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf- mops-streaming-opcons/issues/114 [5] for updates. </ins> 9. 11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,  <ins> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References [2] https://www.ietf.org/mailman/listinfo/mops [3] https://mailarchive.ietf.org/arch/browse/mops/ <ins> [4] https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [5] https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/ issues/114 </ins>


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.

…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.

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.


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

…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.

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


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.

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

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.


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

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.

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


by implementing adaptive playout methods, refer to RFC4733 and RFC6843. <del> Applications with further-specialized latency requirements are out of scope for this document. </del>  4.2.

…cope (issue ) Replaces Max's pull request from here: URL
Maybe "Interactive Latencies" would be a better name? "Near real-time" sounds too ambitious, something for even lower latencies, e.g. tens of microseconds.
This is also fine, though nobody infers microseconds when we are talking about rea-time media, that is everybody knows about certain built-in delays due to capturing and framing and encoding and so on.
For example, see: URL URL It might be worth thinking a bit about whether there's any worthwhile improvements we can make here before it's too late. As much as I don't want to chase a moving target, I also don't want to ship something that lacks consensus.
I think chances for a consensus are more likely if we keep it simple, see my suggested text .
I'll integrate ali's comments, turn this into a new pr, and pull it: URL
One more thing we should perhaps integrate to help with this is to clarify that "Ultra Low Latency" is an industry term of art in segmented streaming video delivery, and that's basically where this category's name came from. ( .)
PS: Came up again from NAME 's review (URL) Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming.
closed via URL Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section

by implementing adaptive playout methods, refer to RFC4733 and RFC6843.  <ins> 4.1.1. Some internet applications that incorporate media streaming have specific interactivity or control-feedback requirements that drive much lower glass to glass media latency targets than one second. These include videoconferencing or voice calls, remote video game play, remote control of hardware platforms like drones, vehicles, or surgical robots, and many other envisioned or deployed interactive applications. Applications with latency targets in these regimes are out of scope for this document. </ins> 4.2.


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>  5.

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.

proposals to use in describing how new technologies address or avoid these existing observed problems.  2. 2.1. 4.  <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.


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

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.

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


constraints using two independent feedback loops: Media servers often respond to application-level feedback from the <del> media player that indicates a bottleneck link somewhere along the path, by adjusting the amount of media that the media server will send to the media player in a given timeframe.  This is described in greater detail in sec-abr. </del>  <del> Media servers also typically implement transport protocols with </del>  capacity-seeking congestion controllers that probe for bandwidth, and adjust the sending rate based on transport mechanisms.  This is described in greater detail in sec-trans. other, and this can result in QOE for users that is significantly lower than what could have been achieved.  In one example, if a media server overestimates the available bandwidth to the media player, sending at a higher rate. In order to avoid these types of situations, which can potentially <del> affect all the users whose streaming media traverses a bottleneck link, there are several possible mitigations that streaming operators can use, but the first step toward mitigating a problem is knowing when that problem occurs. </del>  3.2.1. Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a <del> link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. </del>  Some receiver-side ABR algorithms such as ELASTIC are designed to try to avoid this effect. https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [4] <del> Editor's note: The link above might or might not be changed during </del>  IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf- mops-streaming-opcons/issues/114 [5] for updates. 11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, <del> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del>  12.  References

Also add Linda to ACKs and add stream: IETF (this is now an XML2RFCv3 thing)
From NAME
responding to the application-level feedback that indicates a bottleneck link somewhere along the path. We agree that "link" is ambiguous. In this section, we're talking about a bottleneck, so we don't need to to say "link", BUT we will clean up other occurrences of "link" in the document - one is actually a URL. implementing some forms of congestion control that probe for bandwidth. The conclusion says that the QoE is poorer when the two methods don't coordinate. Question 2: Both methods are implemented on the Media server, they should coordinate by nature, aren't they? You might think so, but they don't, for various reasons (transport protocols being implemented by OS vendors, and media servers and players are implemented by completely different people. We say that in 3.2, but we describe media servers as "implementing transport protocols". That should have been "rely on". This might change, with transport protocols being implemented in user space and packaged as libraries that are shipped media servers, but that's the case today.

constraints using two independent feedback loops: Media servers often respond to application-level feedback from the  <ins> media player that indicates a bottleneck somewhere along the path, by adjusting the amount of media that the media server will send to the media player in a given timeframe.  This is described in greater detail in sec-abr. </ins>  <ins> Media servers also typically rely on transport protocols with </ins> capacity-seeking congestion controllers that probe for bandwidth, and adjust the sending rate based on transport mechanisms.  This is described in greater detail in sec-trans. other, and this can result in QOE for users that is significantly lower than what could have been achieved. <ins> One might wonder why media servers and transport protocols are each blissfully ignorant of what the other is doing, and there are multiple reasons for that, but one reason is that media servers may be implemented to run under a general-purpose operating system which typically has its transport protocols implemented in the operating system kernel, making decisions that the media server never knows about. </ins> In one example, if a media server overestimates the available bandwidth to the media player, sending at a higher rate. In order to avoid these types of situations, which can potentially  <ins> affect all the users whose streaming media traverses a bottleneck, there are several possible mitigations that streaming operators can use, but the first step toward mitigating a problem is knowing when that problem occurs. </ins> 3.2.1. Mobile flow-bandwidth spectrum and timing mapping can be impacted by idle time in some networks.  The carrier capacity assigned to a  <ins> physical or virtual link can vary with activity.  Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a steadier transmission in the same network. </ins> Some receiver-side ABR algorithms such as ELASTIC are designed to try to avoid this effect. https://github.com/ietf-wg-mops/draft-ietf-mops-streaming- opcons/blob/main/living-doc-mops-streaming-opcons.md [4]  <ins> Editor's note: The URL above might or might not be changed during </ins> IESG Evaluation.  See https://github.com/ietf-wg-mops/draft-ietf- mops-streaming-opcons/issues/114 [5] for updates. 11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,  <ins> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References


The bitrate requirements in scaling are per end-user actively consuming a media feed, so in the worst case, the bitrate demands can be multiplied by the number of simultaneous users to find the <del> 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, approximately 80 Gbps might be necessary in order for all of them to get typical content at 1080p resolution. </del>  However, when there is some overlap in the feeds being consumed by end users, it is sometimes possible to reduce the bandwidth Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, <del> Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del>  12.  References

Also add Michael Scharf to acks section
From NAME (URL) (In Section 3.3 Path Requirements) The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path".
LGTM Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section

The bitrate requirements in scaling are per end-user actively consuming a media feed, so in the worst case, the bitrate demands can be multiplied by the number of simultaneous users to find the  <ins> bandwidth requirements for a delivery path with that number of users downstream.  For example, at a node with 10,000 downstream users simultaneously consuming video streams, approximately 80 Gbps might be necessary in order for all of them to get typical content at 1080p resolution. </ins> However, when there is some overlap in the feeds being consumed by end users, it is sometimes possible to reduce the bandwidth Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,  <ins> Lucas Pardue, Mark Nottingham, Matt Stock, Michael Scharf, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References


6.2. <del> For most of the history of the Internet, we have trusted UDP-based applications to limit their impact on other users.  One of the strategies used was to use UDP for simple query-response application protocols, such as DNS, which is often used to send a single-packet request to look up the IP address for a domain name, and return a single-packet response containing the IP address.  Although it is possible to saturate a path between a DNS client and DNS server with DNS requests, in practice, that was rare enough that DNS included few mechanisms to resolve contention between DNS users and other users (whether they are also using DNS, or using other application protocols that share the same pathways). In recent times, the usage of UDP-based applications that were not simple query-response protocols has grown substantially, and since UDP does not provide any feedback mechanism to senders to help limit impacts on other users, application-level protocols such as RTP RFC3550 have been responsible for the decisions that TCP-based </del>  applications have delegated to TCP - what to send, how much to send, and when to send it.  Because UDP itself has no transport-layer feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own <del> feedback mechanisms and respond to the feedback the application </del>  receives.  This expectation is most recently codified in Best Current Practice RFC8085. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, <del> Lucas Pardue, Mark Nottingham, Matt Stock, Michael Scharf, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del>  12.  References

Also adding Tommy's name in Acks section.
LGTM, too and ready to merge.
From NAME In Section 6.1 (on UDP), DNS queries are described as follows: "DNS, which is often used to send a single-packet request to look up the IP address for a DNS name, and return a single-packet response containing the IP address." I'm not sure how valuable this example is for explaining UDP, but if it is kept, please say that multiple packets are sent to get multiple addresses. With IPv6 and IPv4, clients query for both A and AAAA records, and handle multiple addresses, especially for IPv6.
FWIW, I understand why you're saying this. My point (and I wrote this) was to explain why it we've used DNS over UDP for decades without worrying about congestive collapse, but we've used other protocols over TCP because we were worried. I can certainly explain that more correctly, as you propose. And thanks for pushing back.
Hi, NAME especially after NAME suggesting in his TSVART review that I don't need to talk about history, removing this text completely was a perfectly reasonable resolution for your issue!
Sounds good
LGTM

6.2.  <ins> Because UDP does not provide any feedback mechanism to senders to help limit impacts on other users, UDP-based application-level protocols have been responsible for the decisions that TCP-based </ins> applications have delegated to TCP - what to send, how much to send, and when to send it.  Because UDP itself has no transport-layer feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own  <ins> feedback mechanisms, and to respond to the feedback the application </ins> receives.  This expectation is most recently codified in Best Current Practice RFC8085. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,  <ins> Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, Tommy Pauly, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References


6.3. <del> For most of the history of the Internet, we have trusted TCP to limit the impact of applications that sent a significant number of packets, in either or both directions, on other users.  Although early versions of TCP were not particularly good at limiting this impact RFC0793, the addition of Slow Start and Congestion Avoidance, as described in RFC2001, were critical in allowing TCP-based applications to use as much bandwidth as possible, but to avoid using more bandwidth than was possible.  Although dozens of RFCs have been written refining TCP decisions about what to send, how much to send, and when to send it, since 1988 Jacobson-Karels the signals available for TCP senders remained unchanged - end-to-end acknowledgements for packets that were successfully sent and received, and packet timeouts for packets that were not. The success of the largely TCP-based Internet is evidence that the mechanisms TCP used to achieve equilibrium quickly, at a point where TCP senders do not interfere with other TCP senders for sustained periods of time, have been largely successful.  The Internet continued to work even when the specific mechanisms used to reach equilibrium changed over time.  Because TCP provides a common tool to avoid contention, as some TCP-based applications like FTP were largely replaced by other TCP-based applications like HTTP, the transport behavior remained consistent. In recent times, the TCP goal of probing for available bandwidth and "backing off" when a network path is saturated has been supplanted by the goal of avoiding growing queues along network paths, which prevent TCP senders from reacting quickly when a network path is saturated.  Congestion control mechanisms such as COPA COPA18 and BBR I-D.cardwell-iccrg-bbr-congestion-control make these decisions based on measured path delays, assuming that if the measured path delay is increasing, the sender is injecting packets onto the network path faster than the receiver can accept them, so the sender should adjust its sending rate accordingly. Although TCP behavior has changed over time, the common practice of </del>  implementing TCP as part of an operating system kernel has acted to limit how quickly TCP behavior can change.  Even with the widespread use of automated operating system update installation on many end-

Looks good, ready to merge.
Merging based on Ali's review (thanks!).
from NAME 's review (URL) (in Section 6.2. TCP and Its Behavior) Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.
NAME - thank you for these suggestions - they should have all occurred to me when typing this section, but they did not.
from NAME 's review (URL) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section

6.3.  <ins> The past success of the largely TCP-based Internet is evidence that the mechanisms TCP used to achieve equilibrium quickly, at a point where TCP senders do not interfere with other TCP senders for sustained periods of time (RFC5681), have been largely successful. The Internet has continued to work even when the specific TCP mechanisms used to reach equilibrium changed over time (RFC7414). Because TCP provides a common tool to avoid contention, even when significant TCP-based applications like FTP were largely replaced by other significant TCP-based applications like HTTP, the transport behavior remained safe for the Internet. Modern TCP implementations (I-D.ietf-tcpm-rfc793bis) continue to probe for available bandwidth, and "back off" when a network path is saturated, but may also work to avoid growing queues along network paths, which prevent TCP senders from detecting quickly when a network path becoming saturated.  Congestion control mechanisms such as COPA COPA18 and BBR I-D.cardwell-iccrg-bbr-congestion-control make these decisions based on measured path delays, assuming that if the measured path delay is increasing, the sender is injecting packets onto the network path faster than the network can forward them (or the receiver can accept them) so the sender should adjust its sending rate accordingly. Although common TCP behavior has changed significantly since the days of Jacobson-Karels and RFC2001, even adding new congestion controllers such as CUBIC RFC8312, the common practice of </ins> implementing TCP as part of an operating system kernel has acted to limit how quickly TCP behavior can change.  Even with the widespread use of automated operating system update installation on many end-


different base volume level than the main video, which can make for a jarring user experience. <del> Additionally, this market historically has had incidents of ad fraud (misreporting of ad delivery to end users for financial gain).  As a mitigation for concerns driven by those incidents, some SSPs have required the use of players with features like reporting of ad delivery, or providing information that can be used for user tracking.  Some of these and other measures have raised privacy concerns for end users. </del>  In general, this is a rapidly developing space with many considerations, and media streaming operators engaged in advertising

One note about this edit: My local build failed with this (from a fresh clone): In line 255 of the xml, it has the xref here: Thus the issue in my local build went away when I made the above change. I'm not sure why this passed build in the repo, it looks to me like it's expected to fail? But anyway, that's why I have that part, and I'm not sure we wanted a reference in the title anyway. Probably should be in a different PR, but I'm rushing out the door and wanted the reviews, but also wanted to make it build first...
NAME - My apologies for driving you a little bit nuttier. I tend to add cross-ref targets on pretty much everything, but (of course) that one should have been
I tried that, but it also failed since IABcovid was already a named reference in the reference section, and the one place it was used seemed to be referring to that. So I thought it better to remove the tag.
Maybe, but on my reading of 7258, making the collection overt instead of covert and requiring consent is one of the mitigations, but does not change the notion of the pervasive monitoring behavior matching the technical definition of the attack as they describe it. I landed on this text after looking for something softer but then considering a few quotes like these from 7258: I'm happy to take suggestions but it seemed to me that if there are broad segments of people who do not realize that agreeing to cookie use means agreeing to expose much of their browsing history to multiple parties, then the best description based on existing terms is to call it a PM attack. Yeah, good point. Maybe this? URL Yes, that's better. Thanks. That'll be in the rev...
A couple of things here: I agree with your reading of RFC 7258 (and, looking back at URL, I actually balloted on it - 2014 was a long time ago, so I'd forgotten). I think it's consistent with RFC 7258 to say "This provides a strong incentive for advertisers to gain access to the data necessary to perform behavioral targeting, leading some to engage in what is indistinguishable from a pervasive monitoring attack ({{RFC7258}}) based on user tracking in order to collect the relevant data," I understand you to say that since everyone accepts cookies, whether they should do so or not, so that doesn't count as informed consent, and the use of cookies to indicate consent doesn't change the characterization of what advertisers are doing - it's still indistinguishable from an attack, Is that right? If I'm tracking you correctly, perhaps that's a point worth making (not in those words, perhaps). But let's wait and see what NAME says - he is, after all, the Discuss holder . That's EXACTLY what I was hoping for!
NAME - thanks for pushing back and making me think about my suggestion on RFC 7258. I reviewed your changes and they look fine.
NAME - have you had a chance to look at this PR?
From NAME
We think the points to make are: media operators, your media is part of an arms race aiming to track users for more effective advertisers There are some efforts, such as , to get the ecosystem to reduce its reliance on individual tracking while still achieving targeted ads, which are worth a lot of money (pick out a reference or 2 from e.g. [1] https://www2012.universite-URL ) As an initial idea, we're thinking perhaps to add a paragraph after the first mention of targeting, and we're wondering if this is in the right direction, and whether you can suggest any specific improvements?: URL Traditionally, targeted ads have relied on user tracking, which involves a relatively large privacy exposure for end users. At the time of this writing some proposals such as have been made in an effort to reduce that exposure without losing the effects of targeting (ref from [1] that measures a high impact). We found a few references touching on the risks, like: URL URL But maybe someone knows a better reference?
Just wondering when we could expect some PR to address Roman's DISCUSS.
Hi, NAME Jake had asked NAME for guidance , the Wednesday before this document was on the telechat. I haven't seen a response yet. The authors are meeting later today to coordinate our continued comment resolution, so we may be smarter after that.
While this is true, as of last week I stopped waiting and am working on a PR to address this, basically trying to tighten up the rough proposed direction I outlined in the request for guidance in hopes that direction is close to right. That timing came with a number of other outside distractions, which is the reason I'm not done yet. Most of the time on this topic so far has gone toward looking for good references, and a bit toward angst on whether and how to add something about pervasive monitoring to the original sketch of the proposed text. So maybe within the next day or so, if I can land on something I'm happy with.
URL is my first attempt to address this, please let me know what you think NAME and NAME
NAME - this PR looks plausible to me, but we'll see what NAME says - he is, after all, the Discuss holder :stuckouttonguewinkingeye:. I do have a couple of nits. In this text, Is "what amounts to" the right phrase? It seems quite direct. Perhaps "can be considered"? it might be worth mentioning explicitly that collecting this information without user consent is the problem. So, insert "without user consent" at the appropriate place? In this text (which existed before the PR), is there a decent reference that could be added? In this text, I'd suggest Hi Roman, We discussed this in an author's chat, and we're trying to pin down some good text that would cover your DISCUSS. (We're separately considering your other excellent comments as well, but wanted to focus on this first.) We think the points to make are: media operators, your media is part of an arms race aiming to track users for more effective advertisers There are some efforts, such as Topics, to get the ecosystem to reduce its reliance on individual tracking while still achieving targeted ads, which are worth a lot of money (pick out a reference or 2 from e.g. [1] https://www2012.universite-URL ) As an initial idea, we're thinking perhaps to add a paragraph after the first mention of targeting, and we're wondering if this is in the right direction, and whether you can suggest any specific improvements?: URL : Traditionally, targeted ads have relied on user tracking, which involves a relatively large privacy exposure for end users. At the time of this writing some proposals such as Topics have been made in an effort to reduce that exposure without losing the effects of targeting (ref from [1] that measures a high impact). We found a few references touching on the risks, like: URL URL But maybe you know a better reference? Thanks and regards, Jake (and Spencer and Ali)

different base volume level than the main video, which can make for a jarring user experience.  <ins> Another major source of competing objectives comes from user privacy considerations vs. the advertiser's incentives to target ads to user segments based on behavioral data.  Multiple studies, for example BEHAVE and BEHAVE2, have reported large improvements in ad effectiveness when using behaviorally targeted ads, relative to untargeted ads.  This provides a strong incentive for advertisers to gain access to the data necessary to perform behavioral targeting, leading some to engage in what is indistinguishable from a pervasive monitoring attack (RFC7258) based on user tracking in order to collect the relevant data, A more complete review of issues in this space is available in BALANCING. On top of these competing objectives, this market historically has had incidents of ad fraud (misreporting of ad delivery to end users for financial gain) ADFRAUD.  As a mitigation for concerns driven by those incidents, some SSPs have required the use of specific media players that include features like reporting of ad delivery, or providing additional user information that can be used for tracking. </ins> In general, this is a rapidly developing space with many considerations, and media streaming operators engaged in advertising


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>  a client and its simultaneous consumption by the client. <del> Here, "continuous media" refers to media and associated streams </del>  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>  manifests. This document does not take a position on whether those goals are

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

This document specifically focuses on streaming applications and defines streaming as follows:  <ins> Streaming is the continuous transmission of media from a server to </ins> a client and its simultaneous consumption by the client.  <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  <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


Several pointers for further reading on this rapidly changing subject (further). <del> Making specific recommendations on operational practices to mitigate the issues described in this document is out of scope, though some existing mitigations are mentioned in passing.  The intent is to provide a point of reference for future solution proposals to describe how new technologies address or avoid existing problems. </del> 1.1.  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. <del> 1.1.1. </del>  This document is in the GitHub repository at:

tries to address:
We want a paragraph to say something about scope along the lines of: This document is for endpoints delivering streaming media traffic. This can include intermediaries like CDNs as well as content owners and end users, plus their device and player providers. We think this can help address a few issues from last call/iesg review, including: (more to be linked as we notice them)
Consider adding a subsection in the introduction about things that are out of scope, and (for extra credit), why they are out of scope.
From NAME (URL) Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section (Seems closely related to URL )
The purpose of such tunneling is to circumvent geoblocks and access content from other regions - not to protect the media content. Encrypting the content is done by the content owner for its protection.
So, looking at , I'm seeing this text: I think this means that the effect is that the "transport-level information is opaque to intermediaries" effect described in the document applies, with the additional consideration that intermediaries can't see the IP addresses used inside the tunnel, either. I think the same applies to any IPsec-encrypted tunnel. Do we need to say that? And, if so - can we describe this without using product names and descriptions which may age badly in an RFC?
isn't as easy to read, but I think this is also the rough equivalent of IPsec, from a media operator perspective - all of the transport information and the IP addresses used inside the tunnel are obscured.
Just for the record, definitely worth checking as it is related to this discussion: URL
From NAME 's review (URL) (in Section 6.2. TCP and Its Behavior) Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers?
This might be a scoping matter. I think this section was meant to be talking about delivery to end users, but maybe some discussion of datacenters is right to at least briefly mention somewhere? If so, maybe that gets a small section somewhere that mostly says the topic is out of scope as its own too-broad topic. Not sure if DCTCP/ECN needs a mention as it usually it wouldn't be required until you get below ultra low latency, but it can (presumably? I don't have ready measurements...) help with datacenter efficiency and reliability on your delay targets and maybe has some worthwhile references. Note: we dropped a bit of explanation about ECN (URL), and although we didn't really capture why in our notes IIRC the decision came from the low occurrence of marking in end user delivery.
From NAME (URL) (in Section 3.2.1. Recognizing Changes from an Expected Baseline) The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors).
Up-leveling for this point - we need to include a scoping for this document. When we started this document, the scope was largely for content providers. If content providers have control of any middleboxes on the path or stats from middleboxes, that would be in scope. If CDNs own middleboxes like video transcoders, that would also be in scope. We want to exclude "middlebox" devices like ISP routers and tunnel endpoints. We'll revisit this comment when we have proposed text for scoping. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section

Several pointers for further reading on this rapidly changing subject (further).  1.1. <ins> A full review of all streaming media considerations is too wide a topic to cover comprehensively in a single document. This document focuses chiefly on large-scale delivery of streaming media to end users and related issues.  It is primarily intended for those controlling endpoints involved in delivering streaming media traffic.  This can include origin servers publishing content, intermediaries like content delivery networks (CDNs), and providers for client devices and media players. Topics outside this scope include: in-depth examination of real-time interactive media, such as video conferencing; although we touch lightly on topics in this space, the intent is to let readers know that for more in-depth coverage they'll need to look to other documents, since the techniques and issues for interactive real-time media differ so dramatically from those in large-scale one-way delivery of streaming media. specific recommendations on operational practices to mitigate issues described in this document; although some known mitigations are mentioned in passing, the primary intent is to provide a point of reference for future solution proposals to describe how new technologies address or avoid existing problems. generalized network performance techniques; while things like datacenter design and transit network design can be crucial dependencies for a performant streaming media service, these are considered independent topics better addressed by other documents. transparent tunnels; while tunnels can have an impact on streaming media via issues like the round trip time and the maximum transmission unit (MTU) of packets carried over tunnels, for the purposes of this document they're considered network path properties 1.2. </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.  <ins> 1.2.1. </ins> This document is in the GitHub repository at:


As the Internet has grown, an increasingly large share of the traffic delivered to end users has become video.  The most recent available estimates found that 75% of the total traffic to end users was video <del> in 2019.  At that time, the share of video traffic had been growing for years and was projected to continue growing (Appendix D of CVNI). </del>  A substantial part of this growth is due to the increased use of streaming video.  However, video traffic in real-time communications

issue
From NAME There are places that could benefit from more citations. For example, Section says, "Historical data shows that users consume more videos and at a higher bit rate than they did in the past..." but does not explain what data this is.
There are many results on a google search, for example, see: URL Most if not all of such reports will be marketing reports, I am not sure how appropriate they are for us to cite, though (reports do not necessarily agree with each other). If it is going to be better, we can reword the sentence as: s/ Historical data shows that users consume more videos and at a higher bit rate than they did in the past on their connected devices. / Users consume more videos (also likely at a higher bit rate) than they did in the past on their connected devices. And maybe even add the following to the end of the sentence above: "evident from the growth of the streaming media providers and increased monthly CDN traffic and consumptions on broadband connections." This argument probably requires some sort of citation as well (although no one will dispute), but those references might be easier to come up with. Maybe NAME might provide some numbers from Akamai.
I think Akamai numbers for the last few years may have a systematic failure to capture a significant amount of growth from some of the streaming services that make for an important quantity of video. I happened across a report that claims this on page 12: "Our data show in the first half of 2021 bandwidth traffic was dominated by streaming video, accounting for 53.72% of overall traffic, with YouTube, Netflix, and Facebook video in the top three." URL That's down as a share of traffic from the 2018 estimates from cisco. Unfortunately these things don't really show their methodology very well...
One reason for that is probably because services use multiple CDNs at the same time. But then I would weigh the actual numbers more than the predictions from 3-4 years earlier. As we all know covid has caused significant changes in broadband consumption.
I think we talked about this when we were removing an outdated forecast for 2022 ("but that forecast was from 2017, and it's 2022 now?!?"). When we couldn't find a forecast for streaming video that was dated later than 2017 or 2018, I suggested that one possible explanation was continued use of encryption ("if I don't know anything about what was encrypted, what's my strategy for knowing whether it's streaming video?") What I suggested at that time, was observing that the numbers from 2017 said about 75 percent of traffic, was streaming video, so if total traffic grew by (say) 20 percent over some period, it's likely that streaming video also grew by something like 20 percent over the same period. It's a guess, but I'm assuming that the percentage of total traffic that's streaming video in 2022 isn't like half of what it was in 2017 - and if it's not, what grew and took the place of streaming video in 2022? If making that assumption isn't a good plan, I think we'd need to know a lot more about methodologies behind the numbers we cite than we've been able to find. But we'll talk (soon).
(Adding reference from section 2 here as well...)
closed by pr

As the Internet has grown, an increasingly large share of the traffic delivered to end users has become video.  The most recent available estimates found that 75% of the total traffic to end users was video  <ins> in 2019 (as described in RFC8404, such traffic surveys have since become impossible to conduct due to ubiquitous encryption).  At that time, the share of video traffic had been growing for years and was projected to continue growing (Appendix D of CVNI). </ins> A substantial part of this growth is due to the increased use of streaming video.  However, video traffic in real-time communications


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.

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.

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.