Change:
NAME - is this roughly what you were expecting to see, on Issue 22? Please advise :-)
I'm having a conversation with NAME about URL, but the short summary here is that I need to tighten up some of the language about what we are saying about strangely HTTPish UDP traffic, from an observer's perspective, and to do so without starting to say things that either duplicate (bad) or contradict (worse) the QUIC manageability draft on this point. You'll note that the QUIC issue is still under discussion, so probably need to revisit this after they close their Issue. Fortunately, I bet NAME will make sure I behave ... and I appreciate that.
Is it worth also saying about the expectations networks allows streaming traffic over TCP and QUIC to flow freely? I think this could just be a short paragraph that highlights that when other variables are isolated, fairness/contention between TCP and QUIC is most likely a function of the congestion controllers at play.
I THINK the current text in this draft (as of 10 May) is consistent with the QUIC manageability draft, but it will be GREAT for us to do a final check after QUIC finishes working on their draft.
NAME - thank you for this suggestion. See what you think of the current text.
And, like magic, this just popped up on the QUIC mailing list 15 minutes ago. I swear, I could write this script! "The SNI extraction and Appendix A sections of manageability provide guidance that won't work with Chrome. I opened issues 357 and 358 about this. They should be easy to resolve. I apologize for the late notice (I haven't been keeping track of these documents closely) but I do think these do need to be addressed before publication."
The text LGTM. I'll leave it to you editors to decide and battle out where/if to land it.
NAME I'm going to do a commit that moves this text to an actual reasonable place in the draft (I'll be looking at your suggestion to put it near ABR, and I'll try to Do The Right Thing). Probably best not to merge this PR until I commit that, OK?
NAME and NAME I think this PR is ready to merge. Do either of you agree?
Since the intro says relate to quality of experience in internet video delivery. I'm a little surprised to not see anything about the effects on video QoE caused by contention in the network, or the role that fairness between other flows and/or protocols plays on video and other applications. Finally, its been interesting to see how large content providers have reduced streaming bitrates in response to large-scale contention during the COVID pandemic, whether voluntarily or via external pressures. This is especially curious when content is distributed via ABR technologies which should accommodate switching to lower bitrates. (I've heard anecdotal reasoning that the detection of contention is too slow, but unsure if that is really true).
One of the more logical explanations of the situation I have I read: URL EU asking Netflix to drop the bitrates was a total BS IMO.
It is worth noting that some protocols rely on the transport layer bwe/cc (the ones that are TCP based) while others have to implement their own mechanisms (udp based like QUIC or RTP). In that regard, I would differentiate the loss based bwe/cc algorithms (TCP, new Reno, bbr) vs the delay based ones (copa).
I'm planning to focus a PR for this issue on fairness and contention, but defer to the "Extremely Unpredictable Usage Profiles" section, which we've recently merged into Master, for anything about CoViD-19-related impacts on network performance for streaming media. Please let me know if that's not a good plan.
OK, I'm about 10 commits (it seemed like more) into the PR for this issue, and am now thinking that I should divide what is now the "Evolution of Transport Protocols and Transport Protocol Behaviors" section into a UDP/TCP section that comes before the ABR section, because those are the protocols that people use with ABR today, and a QUIC section (that is actually "evolution") that remains after the ABR section. NAME and NAME do you have any thoughts about that? I'm pretty sure it would allow us to tighten up the discussion of interaction between ABR and transport protocol behavior in the ABR section.
Sounds reasonable to me, I think.
I'll make that split (and see if I can do that without conflicts - I think I'm only moving text in , so should be easy.
The content here is pretty good, but I think maybe goes a little out of scope for what I thought this doc should do. I'd be in favor of more depth on the effects of congestion on video QoE. I'm agnostic on whether to drop some of the depth here on congestion control in general (it's good stuff, but reading it I feel like this is for an iccrg informational topic instead of a mops one.) Also the section location seems to be the first one after the intro. Should this move into the ABR section, maybe with a note about congestion response being the primary driver for ABR bitrate selection?

Discussion:
Abstract This document provides an overview of operational networking issues <del> that pertain to quality of experience in delivery of video and other </del> <ins> that pertain to quality of experience in streaming of video and other </ins> high-bitrate media over the internet. 1.

compound annual growth rate continuing at 34% (from Appendix D of CVNI). <ins> A substantial part of this growth is due to increased use of streaming video, although the amount of video traffic in real-time communications (for example, online videoconferencing) has also grown significantly.  While both streaming video and videoconferencing have real-time delivery and latency requirements, these requirements vary from one application to another.  For example, videoconferencing demands an end-to-end (one-way) latency of a few hundreds of milliseconds whereas live streaming can tolerate latencies of several seconds. This document specifically focuses on the streaming applications and defines streaming as follows: Streaming is transmission of a continuous media from a server to a client and its simultaneous consumption by the client.  Here, continous media refers to media and associated streams such as video, audio, metadata, etc.  In this definition, the critical term is "simultaneous", as it is not considered streaming if one downloads a video file and plays it after the download is completed, which would be called download-and-play. This has two implications.  First, server's transmission rate must (loosely or tightly) match to client's consumption rate for an uninterrupted playback.  That is, the client must not run out of data (buffer underrun) or take more than it can keep (buffer overrun) as any excess media is simply discarded.  Second, client's consumption rate is limited by not only bandwidth availability but also the real- time constraints.  That is, the client cannot fetch media that is not available yet. </ins> In many contexts, video traffic can be handled transparently as generic application-level traffic.  However, as the volume of video traffic continues to grow, it's becoming increasingly important to

further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily <del> require a bitrate of 30 Mbps or higher.  Refer to PCC for more details. </del> <ins> require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for more details. </ins> 2.2.

3.1. Adaptive BitRate (ABR) is a sort of application-level response <del> strategy in which the receiving media player attempts to detect the available bandwidth of the network path by experiment or by observing the successful application-layer download speed, then chooses a video bitrate (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur in the player (such as available memory, CPU, display size, etc.). </del> <ins> strategy in which the streaming client attempts to detect the available bandwidth of the network path by observing the successful application-layer download speed, then chooses a bitrate for each of the video, audio, subtitles and metadata (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur during the playback (such as available memory, CPU, display size, etc.). </ins> The choice of bitrate occurs within the context of optimizing for <del> some metric monitored by the video player, such as highest achievable video quality, or lowest rate of expected rebuffering events. </del> <ins> some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering (playback stall). </ins> 3.2. <del> ABR playback is commonly implemented by video players using HLS </del> <ins> ABR playback is commonly implemented by streaming clients using HLS </ins> RFC8216 or DASH DASH to perform a reliable segmented delivery of <del> video data over HTTP.  Different player implementations and receiving devices use different strategies, often proprietary algorithms (called rate adaptation or bitrate selection algorithms), to perform available bandwidth estimation/prediction and the bitrate selection. Most players only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </del> <ins> media over HTTP.  Different implementations use different strategies ABRSurvey, often proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  Most clients only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </ins> This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices.

4. <del> This document requires no actions from IANA. </del> <ins> **Note to Reviewers^^ - this section includes some material that may be tutorial for some readers.  We can decide how to say that, if the tutorial material is worth keeping.  Spencer thought it was worth including, because it provides a contrast to the material on QUIC, which is significantly less tutorial, unless you participated in the QUIC working group. Because networking resources are shared between users, a good place to start our discussion is how contention between users, and mechanisms to resolve that contention in ways that are "fair" between users, impact streaming media users.  These topics are closely tied to transport protocol behaviors. As noted in sec-abr, Adaptive Bitrate response strategies such as HLS RFC8216 or DASH DASH are attempting to respond to changing path characteristics, and underlying transport protocols are also attempting to respond to changing path characteristics. For most of the history of the Internet, these transport protocols, described in udp-behavior and tcp-behavior, have had relatively consistent behaviors that have changed slowly, if at all, over time. Newly standardized transport protocols like QUIC I-D.ietf-quic- transport can behave differently from existing transport protocols, and these behaviors may evolve over time more rapidly than currently- used transport protocols. For this reason, we have included a description of how the path characteristics that streaming media providers may see are likely to evolve over time. 4.1. 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 DNS 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). 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 applications have delegated to TCP - what to send, how much to send, and when to send it.  So, the way some UDP-based applications interact with other users has changed. It's also worth pointing out that because UDP has no transport-layer feedback mechanisms, UDP-based applications that send and receive substantial amounts of information are expected to provide their own feedback mechanisms.  This expectation is most recently codified in Best Current Practice RFC8085. RTP relies on RTCP Sender and Receiver Reports RFC3550 as its own feedback mechanism, and even includes Circuit Breakers for Unicast RTP Sessions RFC8083 for situations when normal RTP congestion control has not been able to react sufficiently to RTP flows sending at rates that result in sustained packet loss. The notion of "Circuit Breakers" has also been applied to other UDP applications in RFC8084, such as tunneling packets over UDP that are potentially not congestion-controlled (for example, "Encapsulating MPLS in UDP", as described in RFC7510).  If streaming media is carried in tunnels encapsulated in UDP, these media streams may encounter "tripped circuit breakers", with resulting user-visible impacts. 4.2. For most of the history of the Internet, we have trusted the TCP protocol 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 acknowledgments 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 COPA 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 protocol behavior has changed over time, the common practice of 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-user systems, streaming media providers could have a reasonable expectation that they could understand TCP transport protocol behaviors, and that those behaviors would remain relatively stable in the short term. 4.3. The QUIC protocol, developed from a proprietary protocol into an IETF standards-track protocol I-D.ietf-quic-transport, turns many of the statements made in udp-behavior and tcp-behavior on their heads. Although QUIC provides an alternative to the TCP and UDP transport protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in this document, the QUIC protocol encrypts almost all of its transport parameters, and all of its payload, so any intermediaries that network operators may be using to troubleshoot HTTP streaming media performance issues, perform analytics, or even intercept exchanges in current applications will not work for QUIC-based applications without making changes to their networks. While QUIC is designed as a general-purpose transport protocol, and can carry different application-layer protocols, the current standardized mapping is for HTTP/3 I-D.ietf-quic-http, which describes how QUIC transport features are used for HTTP.  The convention is for HTTP/3 to run over UDP port 443 Port443 but this is not a strict requirement. When HTTP/3 is encapsulated in QUIC, which is then encapsulated in UDP, streaming operators (and network operators) might see UDP traffic patterns that are similar to HTTP(S) over TCP.  Since earlier versions of HTTP(S) rely on TCP, UDP ports may be blocked for any port numbers that are not commonly used, such as UDP 53 for DNS. Even when UDP ports are not blocked and HTTP/3 can flow, streaming operators (and network operators) may severely rate-limit this traffic because they do not expect to see legitimate high-bandwidth traffic such as streaming media over the UDP ports that HTTP/3 is using. As noted in tcp-behavior, there is increasing interest in transport protocol behaviors that responds to delay measurements, instead of responding to packet loss.  These behaviors may deliver improved user experience, but in some cases have not responded to sustained packet loss, which exhausts available buffers along the end-to-end path that may affect other users sharing that path.  The QUIC protocol provides a set of congestion control hooks that can be use for algorithm agility, and I-D.ietf-quic-recovery defines a basic algorithm with transport behavior that is roughly similar to TCP NewReno RFC6582. However, QUIC senders can and do unilaterally chose to use different algorithms such as loss-based CUBIC RFC8312, delay-based COPA or BBR, or even something completely different We do have experience with deploying new congestion controllers without melting the Internet (CUBIC is one example), but the point mentioned in tcp-behavior about TCP being implemented in operating system kernels is also different with QUIC.  Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features", and to meet this expectation, many implementers have chosen to implement QUIC in user space, outside the operating system kernel, and to even distribute QUIC with applications. The decision to deploy a new version of QUIC is relatively uncontrolled, compared to other widely used transport protocols, and this can include new transport behaviors that appear without much notice except to the QUIC endpoints.  At IETF 105, Christian Huitema and Brian Trammell presented a talk on "Congestion Defense in Depth" CDiD, that explored potential concerns about new QUIC congestion controllers being broadly deployed without the testing and instrumentation that current major content providers routinely include.  The sense of the room at IETF 105 was that the current major content providers understood what is at stake when they deploy new congestion controllers, but this presentation, and the related discussion in TSVAREA minutes from IETF 105 (tsvarea-105, are still worth a look for new and rapidly growing content providers. It is worth considering that if TCP-based HTTP traffic and UDP-based HTTP/3 traffic are allowed to enter operator networks on roughly equal terms, questions of fairness and contention will be heavily dependent on interactions between the congestion controllers in use for TCP-base HTTP traffic and UDP-based HTTP/3 traffic. More broadly, I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It discusses what network operators can consider in some detail. </ins> 5. <ins> "Encrypted Media" has at least three meanings: Media encrypted at the application layer, typically using some sort of Digital Rights Management (DRM) system, and typically retaining this encryption "at rest", when it is stored at senders and receivers, Media encrypted by the sender at the transport layer, and remaining encrypted until it reaches the ultimate media consumer (in this document, referred to as "end-to-end media encryption"), and Media encrypted by the sender at the transport layer, and remaining encrypted until it reaches some intermediary that is _not_ the ultimate media consumer, but has credentials allowing descryption of the media content.  This intermediary may examine and even transform the media content in some way, before forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption") Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. Each of these encryption strategies is intended to achieve a 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 may be used to prevent media steam manipulation or to protect manifests.  This document does not take a position on whether those goals are "valid" (whatever that might mean). In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end". Both "End-to-End" and "Hop-by-Hop" media encryption have implications for streaming operators. 5.1. The use of strong encryption does provide confidentiality for encrypted streaming media, from the sender to either an intermediary or the ultimate media consumer, and this does prevent Deep Packet Inspection by any intermediary that does not possess credentials allowing decryption.  However, even encrypted content streams may be vulnerable to traffic analysis.  An intermediary that can identify an encrypted media stream without decrypting it, may be able to "fingerprint" the encrypted media stream of known content, and then match the targeted media stream against the fingerprints of known content.  This protection can be lessened if a media provider is repeatedly encrypting the same content. codaspy is an example of what is possible when identifying HTTPS-protected videos over TCP transport, based either on the length of entire resources being transferred, or on characteristic packet patterns at the beginning of a resource being transferred. If traffic analysis is successful at identifying encrypted content and associating it with specific users, this breaks privacy as certainly as examining decrypted traffic. Because HTTPS has historically layered HTTP on top of TLS, which is in turn layered on top of TCP, intermediaries do have access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol I-D.ietf-quic-transport as its transport layer.  QUIC relies only on the TLS 1.3 initial handshake for key exchange I-D.ietf-quic-tls, and encrypts almost all transport parameters, with the exception of a few invariant fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the destination connection ID I-D.ietf-quic-invariants.  For these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2. 5.2. Although the IETF has put considerable emphasis on end-to-end streaming media encryption, there are still important use cases that require the insertion of intermediaries. There are a variety of ways to involve intermediaries, and some are much more intrusive than others. From a content provider's perspective, a number of considerations are in play.  The first question is likely whether the content provider intends that intermediaries are explicitly addressed from endpoints, or whether the content provider is willing to allow intermediaries to "intercept" streaming content transparently, with no awareness or permission from either endpoint. If a content provider does not actively work to avoid interception by intermediaries, the effect will be indistinguishable from "impersonation attacks", and endpoints cannot be assumed of any level of privacy. Assuming that a content provider does intend to allow intermediaries to participate in content streaming, and does intend to provide some level of privacy for endpoints, there are a number of possible tools, either already available or still being specified.  These include Server And Network assisted DASH DASH-SAND - this specification introduces explicit messaging between DASH clients and network elements or between various network elements for the purpose of improving the efficiency of streaming sessions by providing information about real-time operational characteristics of networks, servers, proxies, caches, CDNs, as well as DASH client's performance and status. "Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)" RFC8723 - this specification provides a cryptographic transform for the Secure Real-time Transport Protocol that provides both hop-by-hop and end-to-end security guarantees. Secure Media Frames SFRAME - RFC8723 is closely tied to SRTP, and this close association impeded widespread deployment, because it could not be used for the most common media content delivery mechanisms.  A more recent proposal, Secure Media Frames SFRAME, also provides both hop-by-hop and end-to-end security guarantees, but can be used with other transport protocols beyond SRTP. 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- manageability (for HTTP/3 and QUIC). 5.3. "End-to-end" media encryption offers the potential of providing privacy for streaming media consumers, with the idea being that if an unauthorized intermediary can't decrypt streaming media, the intermediary can't use Deep Packet Inspection (DPI) to examine HTTP request and response headers and identify the media content being streamed. "End-to-end" media encryption became much more widespread in the years since RFC7258 was issued, which identified pervasive monitoring as a much greater threat than previously appreciated.  After the Snowden disclosures, many content providers made the decision to use HTTPS protection - HTTP over TLS - for most or all content being delivered as a routine practice, rather than in exceptional cases for content that was considered "sensitive". 6. This document requires no actions from IANA. 7. </ins> This document introduces no new security issues. <ins> 8. Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, and Mike English for their very helpful reviews and comments. </ins>