doc: Add RFC documents

1 files changed, 2127 insertions, 0 deletions

diff --git a/doc/rfc/rfc9317.txt b/doc/rfc/rfc9317.txt
new file mode 100644
index 0000000..dce5151
--- /dev/null
+++ b/doc/rfc/rfc9317.txt
@@ -0,0 +1,2127 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Holland
+Request for Comments: 9317                     Akamai Technologies, Inc.
+Category: Informational                                         A. Begen
+ISSN: 2070-1721                                          Networked Media
+                                                              S. Dawkins
+                                                     Tencent America LLC
+                                                            October 2022
+
+
+             Operational Considerations for Streaming Media
+
+Abstract
+
+   This document provides an overview of operational networking and
+   transport protocol issues that pertain to the quality of experience
+   (QoE) when streaming video and other high-bitrate media over the
+   Internet.
+
+   This document explains the characteristics of streaming media
+   delivery that have surprised network designers or transport experts
+   who lack specific media expertise, since streaming media highlights
+   key differences between common assumptions in existing networking
+   practices and observations of media delivery issues encountered when
+   streaming media over those existing networks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9317.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Key Definitions
+     1.2.  Document Scope
+   2.  Our Focus on Streaming Video
+   3.  Bandwidth Provisioning
+     3.1.  Scaling Requirements for Media Delivery
+       3.1.1.  Video Bitrates
+       3.1.2.  Virtual Reality Bitrates
+     3.2.  Path Bottlenecks and Constraints
+       3.2.1.  Recognizing Changes from a Baseline
+     3.3.  Path Requirements
+     3.4.  Caching Systems
+     3.5.  Predictable Usage Profiles
+     3.6.  Unpredictable Usage Profiles
+       3.6.1.  Peer-to-Peer Applications
+       3.6.2.  Impact of Global Pandemic
+   4.  Latency Considerations
+     4.1.  Ultra-Low-Latency
+       4.1.1.  Near-Real-Time Latency
+     4.2.  Low-Latency Live
+     4.3.  Non-Low-Latency Live
+     4.4.  On-Demand
+   5.  Adaptive Encoding, Adaptive Delivery, and Measurement
+           Collection
+     5.1.  Overview
+     5.2.  Adaptive Encoding
+     5.3.  Adaptive Segmented Delivery
+     5.4.  Advertising
+     5.5.  Bitrate Detection Challenges
+       5.5.1.  Idle Time between Segments
+       5.5.2.  Noisy Measurements
+       5.5.3.  Wide and Rapid Variation in Path Capacity
+     5.6.  Measurement Collection
+   6.  Transport Protocol Behaviors and Their Implications for Media
+           Transport Protocols
+     6.1.  Media Transport over Reliable Transport Protocols
+     6.2.  Media Transport over Unreliable Transport Protocols
+     6.3.  QUIC and Changing Transport Protocol Behavior
+   7.  Streaming Encrypted Media
+     7.1.  General Considerations for Streaming Media Encryption
+     7.2.  Considerations for Hop-by-Hop Media Encryption
+     7.3.  Considerations for End-to-End Media Encryption
+   8.  Additional Resources for Streaming Media
+   9.  IANA Considerations
+   10. Security Considerations
+   11. Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   This document provides an overview of operational networking and
+   transport protocol issues that pertain to the quality of experience
+   (QoE) when streaming video and other high-bitrate media over the
+   Internet.
+
+   This document is intended to explain the characteristics of streaming
+   media delivery that have surprised network designers or transport
+   experts who lack specific media expertise, since streaming media
+   highlights key differences between common assumptions in existing
+   networking practices and observations of media delivery issues
+   encountered when streaming media over those existing networks.
+
+1.1.  Key Definitions
+
+   This document defines "high-bitrate streaming media over the
+   Internet" as follows:
+
+   *  "High-bitrate" is a context-sensitive term broadly intended to
+      capture rates that can be sustained over some but not all of the
+      target audience's network connections.  A snapshot of values
+      commonly qualifying as high-bitrate on today's Internet is given
+      by the higher-value entries in Section 3.1.1.
+
+   *  "Streaming" means the continuous transmission of media segments
+      from a server to a client and its simultaneous consumption by the
+      client.
+
+      -  The term "simultaneous" is critical, as media segment
+         transmission is not considered "streaming" if one downloads a
+         media file and plays it after the download is completed.
+         Instead, this would be called "download and play".
+
+      -  This has two implications.  First, the sending rate for media
+         segments must match the client's consumption rate (whether
+         loosely or tightly) to provide uninterrupted playback.  That
+         is, the client must not run out of media segments (buffer
+         underrun) and must not accept more media segments than it can
+         buffer before playback (buffer overrun).
+
+      -  Second, the client's media segment consumption rate is limited
+         not only by the path's available bandwidth but also by media
+         segment availability.  The client cannot fetch media segments
+         that a media server cannot provide (yet).
+
+   *  "Media" refers to any type of media and associated streams, such
+      as video, audio, metadata, etc.
+
+   *  "Over the Internet" means that a single operator does not have
+      control of the entire path between media servers and media
+      clients, so it is not a "walled garden".
+
+   This document uses these terms to describe the streaming media
+   ecosystem:
+
+   Streaming Media Operator:  an entity that provides streaming media
+      servers
+
+   Media Server:  a server that provides streaming media to a media
+      player, which is also referred to as a streaming media server, or
+      simply a server
+
+   Intermediary:  an entity that is on-path, between the streaming media
+      operator and the ultimate media consumer, and that is media aware
+
+      When the streaming media is encrypted, an intermediary must have
+      credentials that allow the intermediary to decrypt the media in
+      order to be media aware.
+
+      An intermediary can be one of many specialized subtypes that meet
+      this definition.
+
+   Media Player:  an endpoint that requests streaming media from a media
+      server for an ultimate media consumer, which is also referred to
+      as a streaming media client, or simply a client
+
+   Ultimate Media Consumer:  a human or machine using a media player
+
+1.2.  Document Scope
+
+   A full review of all streaming media considerations for all types of
+   media over all types of network paths is too broad a topic to cover
+   comprehensively in a single document.
+
+   This document focuses chiefly on the large-scale delivery of
+   streaming high-bitrate media to end users.  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.
+
+   Most of the considerations covered in this document apply to both
+   "live media" (created and streamed as an event is in progress) and
+   "media on demand" (previously recorded media that is streamed from
+   storage), except where noted.
+
+   Most of the considerations covered in this document apply to both
+   media that is consumed by a media player, for viewing by a human, and
+   media that is consumed by a machine, such as a media recorder that is
+   executing an adaptive bitrate (ABR) streaming algorithm, except where
+   noted.
+
+   This document contains
+
+   *  a short description of streaming video characteristics in
+      Section 2 to set the stage for the rest of the document,
+
+   *  general guidance on bandwidth provisioning (Section 3) and latency
+      considerations (Section 4) for streaming media delivery,
+
+   *  a description of adaptive encoding and adaptive delivery
+      techniques in common use for streaming video, along with a
+      description of the challenges media senders face in detecting the
+      bitrate available between the media sender and media receiver, and
+      a collection of measurements by a third party for use in analytics
+      (Section 5),
+
+   *  a description of existing transport protocols used for media
+      streaming and the issues encountered when using those protocols,
+      along with a description of the QUIC transport protocol [RFC9000]
+      more recently used for streaming media (Section 6),
+
+   *  a description of implications when streaming encrypted media
+      (Section 7), and
+
+   *  a pointer to additional resources for further reading on this
+      rapidly changing subject (Section 8).
+
+   Topics outside this scope include the following:
+
+   *  an in-depth examination of real-time, two-way interactive media,
+      such as videoconferencing; although this document touches lightly
+      on topics related to this space, the intent is to let readers know
+      that for more in-depth coverage they should look to other
+      documents, since the techniques and issues for interactive real-
+      time, two-way 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 considerations,
+      such as data center design, transit network design, and "walled
+      garden" optimizations, can be crucial components of a performant
+      streaming media service, these are considered independent topics
+      that are 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, these issues are considered as part of
+      the set of network path properties.
+
+   Questions about whether this document also covers "Web Real-Time
+   Communication (WebRTC)" have come up often.  It does not.  WebRTC's
+   principal media transport protocol [RFC8834] [RFC8835], the Real-time
+   Transport Protocol (RTP), is mentioned in this document.  However, as
+   noted in Section 2, it is difficult to give general guidance for
+   unreliable media transport protocols used to carry interactive real-
+   time media.
+
+2.  Our Focus on Streaming Video
+
+   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
+   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]).
+
+   A substantial part of this growth is due to the increased use of
+   streaming video.  However, 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 additional discussion of latency
+   requirements, see Section 4.
+
+   In many contexts, media traffic can be handled transparently as
+   generic application-level traffic.  However, as the volume of media
+   traffic continues to grow, it is becoming increasingly important to
+   consider the effects of network design decisions on application-level
+   performance, with considerations for the impact on media delivery.
+
+   Much of the focus of this document is on media streaming over HTTP.
+   HTTP is widely used for media streaming because
+
+   *  support for HTTP is widely available in a wide range of operating
+      systems,
+
+   *  HTTP is also used in a wide variety of other applications,
+
+   *  HTTP has been demonstrated to provide acceptable performance over
+      the open Internet,
+
+   *  HTTP includes state-of-the-art standardized security mechanisms,
+      and
+
+   *  HTTP can use already-deployed caching infrastructure, such as
+      CDNs, local proxies, and browser caches.
+
+   Various HTTP versions have been used for media delivery.  HTTP/1.0,
+   HTTP/1.1, and HTTP/2 are carried over TCP [RFC9293], and TCP's
+   transport behavior is described in Section 6.1.  HTTP/3 is carried
+   over QUIC, and QUIC's transport behavior is described in Section 6.3.
+
+   Unreliable media delivery using RTP and other UDP-based protocols is
+   also discussed in Sections 4.1, 6.2, and 7.2, but it is difficult to
+   give general guidance for these applications.  For instance, when
+   packet loss occurs, the most appropriate response may depend on the
+   type of codec being used.
+
+3.  Bandwidth Provisioning
+
+3.1.  Scaling Requirements for Media Delivery
+
+3.1.1.  Video Bitrates
+
+   Video bitrate selection depends on many variables including the
+   resolution (height and width), frame rate, color depth, codec,
+   encoding parameters, scene complexity, and amount of motion.
+   Generally speaking, as the resolution, frame rate, color depth, scene
+   complexity, and amount of motion increase, the encoding bitrate
+   increases.  As newer codecs with better compression tools are used,
+   the encoding bitrate decreases.  Similarly, a multi-pass encoding
+   generally produces better quality output compared to single-pass
+   encoding at the same bitrate or delivers the same quality at a lower
+   bitrate.
+
+   Here are a few common resolutions used for video content, with
+   typical ranges of bitrates for the two most popular video codecs
+   [Encodings].
+
+         +============+================+============+============+
+         | Name       | Width x Height | H.264      | H.265      |
+         +============+================+============+============+
+         | DVD        | 720 x 480      | 1.0 Mbps   | 0.5 Mbps   |
+         +------------+----------------+------------+------------+
+         | 720p (1K)  | 1280 x 720     | 3-4.5 Mbps | 2-4 Mbps   |
+         +------------+----------------+------------+------------+
+         | 1080p (2K) | 1920 x 1080    | 6-8 Mbps   | 4.5-7 Mbps |
+         +------------+----------------+------------+------------+
+         | 2160p (4k) | 3840 x 2160    | N/A        | 10-20 Mbps |
+         +------------+----------------+------------+------------+
+
+            Table 1: Typical Resolutions and Bitrate Ranges Used
+                             for Video Encoding
+
+   *  Note that these codecs do not take the actual "available
+      bandwidth" between media servers and media players into account
+      when encoding because the codec does not have any idea what
+      network paths and network path conditions will carry the encoded
+      video at some point in the future.  It is common for codecs to
+      offer a small number of resource variants, differing only in the
+      bandwidth each variant targets.
+
+   *  Note that media players attempting to receive encoded video across
+      a network path with insufficient available path bandwidth might
+      request the media server to provide video encoded for lower
+      bitrates, at the cost of lower video quality, as described in
+      Section 5.3.
+
+   *  In order to provide multiple encodings for video resources, the
+      codec must produce multiple variants (also called renditions) of
+      the video resource encoded at various bitrates, as described in
+      Section 5.2.
+
+3.1.2.  Virtual Reality Bitrates
+
+   The bitrates given in Section 3.1.1 describe video streams that
+   provide the user with a single, fixed point of view -- therefore, the
+   user has no "degrees of freedom", and the user sees all of the video
+   image that is available.
+
+   Even basic virtual reality (360-degree) videos that allow users to
+   look around freely (referred to as "three degrees of freedom" or
+   3DoF) require substantially larger bitrates when they are captured
+   and encoded, as such videos require multiple fields of view of the
+   scene.  Yet, due to smart delivery methods, such as viewport-based or
+   tile-based streaming, there is no need to send the whole scene to the
+   user.  Instead, the user needs only the portion corresponding to its
+   viewpoint at any given time [Survey360].
+
+   In more immersive applications, where limited user movement ("three
+   degrees of freedom plus" or 3DoF+) or full user movement ("six
+   degrees of freedom" or 6DoF) is allowed, the required bitrate grows
+   even further.  In this case, 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
+   require a bitrate of 30 Mbps or higher.  Refer to [MPEGI] and [PCC]
+   for more details.
+
+3.2.  Path Bottlenecks and Constraints
+
+   Even when the bandwidth requirements for media streams along a path
+   are well understood, additional analysis is required to understand
+   the constraints on bandwidth at various points along the path between
+   media servers and media players.  Media streams can encounter
+   bottlenecks at many points along a path, whether the bottleneck
+   happens at a node or at a path segment along the path, and these
+   bottlenecks may involve a lack of processing power, buffering
+   capacity, link speed, or any other exhaustible resource.
+
+   Media servers may react to bandwidth constraints using two
+   independent feedback loops:
+
+   *  Media servers often respond to application-level feedback from the
+      media player that indicates a bottleneck somewhere along the path
+      by sending a different media bitrate.  This is described in
+      greater detail in Section 5.
+
+   *  Media servers also typically rely on transport protocols with
+      capacity-seeking congestion controllers that probe for available
+      path bandwidth and adjust the media sending rate based on
+      transport mechanisms.  This is described in greater detail in
+      Section 6.
+
+   The result is that these two (potentially competing) "helpful"
+   mechanisms each respond to the same bottleneck with no coordination
+   between themselves, so that each is unaware of actions taken by the
+   other, and this can result in QoE for users that is significantly
+   lower than what could have been achieved.
+
+   One might wonder why media servers and transport protocols are each
+   unaware of what the other is doing, and there are multiple reasons
+   for that.  One reason is that media servers are often implemented as
+   applications executing in user space, relying on a general-purpose
+   operating system that typically has its transport protocols
+   implemented in the operating system kernel, making decisions that the
+   media server never knows about.
+
+   As one example, if a media server overestimates the available
+   bandwidth to the media player,
+
+   *  the transport protocol may detect loss due to congestion and
+      reduce its sending window size per round trip,
+
+   *  the media server adapts to application-level feedback from the
+      media player and reduces its own sending rate, and/or
+
+   *  the transport protocol sends media at the new, lower rate and
+      confirms that this new, lower rate is "safe" because no transport-
+      level loss is occurring.
+
+   However, because the media server continues to send at the new, lower
+   rate, the transport protocol's maximum sending rate is now limited by
+   the amount of information the media server queues for transmission.
+   Therefore, the transport protocol cannot probe for available path
+   bandwidth by sending at a higher rate until the media player requests
+   segments that buffer enough data for the transport to perform the
+   probing.
+
+   To avoid these types of situations, which can potentially affect all
+   the users whose streaming media segments traverse a bottleneck path
+   segment, there are several possible mitigations that streaming
+   operators can use.  However, the first step toward mitigating a
+   problem is knowing that a problem is occurring.
+
+3.2.1.  Recognizing Changes from a Baseline
+
+   There are many reasons why path characteristics might change in
+   normal operation.  For example:
+
+   *  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 is partially or entirely
+      disjointed 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 respond to indications of path
+      congestion.
+
+   *  Wireless links (Wi-Fi, 5G, LTE, etc.) may see rapid changes to
+      capacity from changes in radio interference and signal strength as
+      endpoints move.
+
+   To recognize that a path carrying streaming media has experienced a
+   change, maintaining a baseline that captures its prior properties is
+   fundamental.  Analytics that aid in that recognition can be more or
+   less sophisticated and can usefully operate on several different time
+   scales, from milliseconds to hours or days.
+
+   Useful properties to monitor for changes can include the following:
+
+   *  round-trip times
+
+   *  loss rate (and explicit congestion notification (ECN) [RFC3168]
+      when in use)
+
+   *  out-of-order packet rate
+
+   *  packet and byte receive rate
+
+   *  application-level goodput
+
+   *  properties of other connections carrying competing traffic, in
+      addition to the connections carrying the streaming media
+
+   *  externally provided measurements, for example, from network cards
+      or metrics collected by the operating system
+
+3.3.  Path Requirements
+
+   The bitrate requirements in Section 3.1 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
+   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 for all of them to get typical content at 1080p
+   resolution.
+
+   However, when there is some overlap in the feeds being consumed by
+   end users, it is sometimes possible to reduce the bandwidth
+   provisioning requirements for the network by performing some kind of
+   replication within the network.  This can be achieved via object
+   caching with the delivery of replicated objects over individual
+   connections and/or by packet-level replication using multicast.
+
+   To the extent that replication of popular content can be performed,
+   bandwidth requirements at peering or ingest points can be reduced to
+   as low as a per-feed requirement instead of a per-user requirement.
+
+3.4.  Caching Systems
+
+   When demand for content is relatively predictable, and especially
+   when that content is relatively static, caching content close to
+   requesters and preloading caches to respond quickly to initial
+   requests are often useful (for example, HTTP/1.1 caching is described
+   in [RFC9111]).  This is subject to the usual considerations for
+   caching -- for example, how much data must be cached to make a
+   significant difference to the requester and how the benefit of
+   caching and preloading cache balances against the costs of tracking
+   stale content in caches and refreshing that content.
+
+   It is worth noting that not all high-demand content is "live"
+   content.  One relevant example is when popular streaming content can
+   be staged close to a significant number of requesters, as can happen
+   when a new episode of a popular show is released.  This content may
+   be largely stable and is therefore low-cost to maintain in multiple
+   places throughout the Internet.  This can reduce demands for high
+   end-to-end bandwidth without having to use mechanisms like multicast.
+
+   Caching and preloading can also reduce exposure to peering point
+   congestion, since less traffic crosses the peering point exchanges if
+   the caches are placed in peer networks.  This is especially true when
+   the content can be preloaded during off-peak hours and if the
+   transfer can make use of "A Lower-Effort Per-Hop Behavior (LE PHB)
+   for Differentiated Services" [RFC8622], "Low Extra Delay Background
+   Transport (LEDBAT)" [RFC6817], or similar mechanisms.
+
+   All of this depends, of course, on the ability of a streaming media
+   operator to predict usage and provision bandwidth, caching, and other
+   mechanisms to meet the needs of users.  In some cases (Section 3.5),
+   this is relatively routine, but in other cases, it is more difficult
+   (Section 3.6).
+
+   With the emergence of ultra-low-latency streaming, responses have to
+   start streaming to the end user while still being transmitted to the
+   cache and while the cache does not yet know the size of the object.
+   Some of the popular caching systems were designed around a cache
+   footprint and had deeply ingrained assumptions about knowing the size
+   of objects that are being stored, so the change in design
+   requirements in long-established systems caused some errors in
+   production.  Incidents occurred where a transmission error in the
+   connection from the upstream source to the cache could result in the
+   cache holding a truncated segment and transmitting it to the end
+   user's device.  In this case, players rendering the stream often had
+   a playback freeze until the player was reset.  In some cases, the
+   truncated object was even cached that way and served later to other
+   players as well, causing continued stalls at the same spot in the
+   media for all players playing the segment delivered from that cache
+   node.
+
+3.5.  Predictable Usage Profiles
+
+   Historical data shows that users consume more videos, and these
+   videos are encoded at a bitrate higher than they were in the past.
+   Improvements in the codecs that help reduce the encoding bitrates
+   with better compression algorithms have not offset the increase in
+   the demand for the higher quality video (higher resolution, higher
+   frame rate, better color gamut, better dynamic range, etc.).  In
+   particular, mobile data usage in cellular access networks has shown a
+   large jump over the years due to increased consumption of
+   entertainment and conversational video.
+
+3.6.  Unpredictable Usage Profiles
+
+   It is also possible for usage profiles to change significantly and
+   suddenly.  These changes are more difficult to plan for, but at a
+   minimum, recognizing that sudden changes are happening is critical.
+
+   The two examples that follow are instructive.
+
+3.6.1.  Peer-to-Peer Applications
+
+   In the first example, described in "Report from the IETF Workshop on
+   Peer-to-Peer (P2P) Infrastructure, May 28, 2008" [RFC5594], when the
+   BitTorrent file sharing application came into widespread use in 2005,
+   sudden and unexpected growth in peer-to-peer traffic led to
+   complaints from ISP customers about the performance of delay-
+   sensitive traffic (Voice over IP (VoIP) and gaming).  These
+   performance issues resulted from at least two causes:
+
+   *  Many access networks for end users used underlying technologies
+      that are inherently asymmetric, favoring downstream bandwidth
+      (e.g., ADSL, cellular technologies, and most IEEE 802.11
+      variants), assuming that most users will need more downstream
+      bandwidth than upstream bandwidth.  This is a good assumption for
+      client-server applications, such as streaming media or software
+      downloads, but BitTorrent rewarded peers that uploaded as much as
+      they downloaded, so BitTorrent users had much more symmetric usage
+      profiles, which interacted badly with these asymmetric access
+      network technologies.
+
+   *  Some P2P systems also used distributed hash tables to organize
+      peers into a ring topology, where each peer knew its "next peer"
+      and "previous peer".  There was no connection between the
+      application-level ring topology and the lower-level network
+      topology, so a peer's "next peer" might be anywhere on the
+      reachable Internet.  Traffic models that expected most
+      communication to take place with a relatively small number of
+      servers were unable to cope with peer-to-peer traffic that was
+      much less predictable.
+
+   Especially as end users increase the use of video-based social
+   networking applications, it will be helpful for access network
+   providers to watch for increasing numbers of end users uploading
+   significant amounts of content.
+
+3.6.2.  Impact of Global Pandemic
+
+   Early in 2020, the COVID-19 pandemic and resulting quarantines and
+   shutdowns led to significant changes in traffic patterns due to a
+   large number of people who suddenly started working and attending
+   school remotely and using more interactive applications (e.g.,
+   videoconferencing and streaming media).  Subsequently, the Internet
+   Architecture Board (IAB) held a COVID-19 Network Impacts Workshop
+   [RFC9075] in November 2020.  The following observations from the
+   workshop report are worth considering.
+
+   *  Participants describing different types of networks reported
+      different kinds of impacts, but all types of networks saw impacts.
+
+   *  Mobile networks saw traffic reductions, and residential networks
+      saw significant increases.
+
+   *  Reported traffic increases from ISPs and Internet Exchange Points
+      (IXPs) over just a few weeks were as big as the traffic growth
+      over the course of a typical year, representing a 15-20% surge in
+      growth to land at a new normal that was much higher than
+      anticipated.
+
+   *  At Deutscher Commercial Internet Exchange (DE-CIX) Frankfurt, the
+      world's largest IXP in terms of data throughput, the year 2020 has
+      seen the largest increase in peak traffic within a single year
+      since the IXP was founded in 1995.
+
+   *  The usage pattern changed significantly as work-from-home and
+      videoconferencing usage peaked during normal work hours, which
+      would have typically been off-peak hours with adults at work and
+      children at school.  One might expect that the peak would have had
+      more impact on networks if it had happened during typical evening
+      peak hours for streaming applications.
+
+   *  The increase in daytime bandwidth consumption reflected both
+      significant increases in essential applications, such as
+      videoconferencing and virtual private networks (VPNs), and
+      entertainment applications as people watched videos or played
+      games.
+
+   *  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 working at home.
+
+   Again, it will be helpful for streaming operators to monitor traffic
+   as described in Section 5.6, watching for sudden changes in
+   performance.
+
+4.  Latency Considerations
+
+   Streaming media latency refers to the "glass-to-glass" time duration,
+   which is the delay between the real-life occurrence of an event and
+   the streamed media being appropriately played on an end user's
+   device.  Note that this is different from the network latency
+   (defined as the time for a packet to cross a network from one end to
+   another end) because it includes media encoding/decoding and
+   buffering time and, for most cases, also the ingest to an
+   intermediate service, such as a CDN or other media distribution
+   service, rather than a direct connection to an end user.
+
+   The team working on this document found these rough categories to be
+   useful when considering a streaming media application's latency
+   requirements:
+
+   *  ultra-low-latency (less than 1 second)
+
+   *  low-latency live (less than 10 seconds)
+
+   *  non-low-latency live (10 seconds to a few minutes)
+
+   *  on-demand (hours or more)
+
+4.1.  Ultra-Low-Latency
+
+   Ultra-low-latency delivery of media is defined here as having a
+   glass-to-glass delay target under 1 second.
+
+   Some media content providers aim to achieve this level of latency for
+   live media events.  This introduces new challenges when compared to
+   the other latency categories described in Section 4, because ultra-
+   low-latency is on the same scale as commonly observed end-to-end
+   network latency variation, often due to bufferbloat [CoDel], Wi-Fi
+   error correction, or packet reordering.  These effects can make it
+   difficult to achieve ultra-low-latency for many users and may require
+   accepting relatively frequent user-visible media artifacts.  However,
+   for controlled environments that provide mitigations against such
+   effects, ultra-low-latency is potentially achievable with the right
+   provisioning and the right media transport technologies.
+
+   Most applications operating over IP networks and requiring latency
+   this low use the Real-time Transport Protocol (RTP) [RFC3550] or
+   WebRTC [RFC8825], which uses RTP as its media transport protocol,
+   along with several other protocols necessary for safe operation in
+   browsers.
+
+   It is worth noting that many applications for ultra-low-latency
+   delivery do not need to scale to as many users as applications for
+   low-latency and non-low-latency live delivery, which simplifies many
+   delivery considerations.
+
+   Recommended reading for applications adopting an RTP-based approach
+   also includes [RFC7656].  For increasing the robustness of the
+   playback by implementing adaptive playout methods, refer to [RFC4733]
+   and [RFC6843].
+
+4.1.1.  Near-Real-Time Latency
+
+   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 1 second.  These
+   include videoconferencing or voice calls; remote video gameplay;
+   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.
+
+4.2.  Low-Latency Live
+
+   Low-latency live delivery of media is defined here as having a glass-
+   to-glass delay target under 10 seconds.
+
+   This level of latency is targeted to have a user experience similar
+   to broadcast TV delivery.  A frequently cited problem with failing to
+   achieve this level of latency for live sporting events is the user
+   experience failure from having crowds within earshot of one another
+   who react audibly to an important play or from users who learn of an
+   event in the match via some other channel, for example, social media,
+   before it has happened on the screen showing the sporting event.
+
+   Applications requiring low-latency live media delivery are generally
+   feasible at scale with some restrictions.  This typically requires
+   the use of a premium service dedicated to the delivery of live media,
+   and some trade-offs may be necessary relative to what is feasible in
+   a higher-latency service.  The trade-offs may include higher costs,
+   delivering a lower quality media, reduced flexibility for adaptive
+   bitrates, or reduced flexibility for available resolutions so that
+   fewer devices can receive an encoding tuned for their display.  Low-
+   latency live delivery is also more susceptible to user-visible
+   disruptions due to transient network conditions than higher-latency
+   services.
+
+   Implementation of a low-latency live media service can be achieved
+   with the use of HTTP Live Streaming (HLS) [RFC8216] by using its low-
+   latency extension (called LL-HLS) [HLS-RFC8216BIS] or with Dynamic
+   Adaptive Streaming over HTTP (DASH) [MPEG-DASH] by using its low-
+   latency extension (called LL-DASH) [LL-DASH].  These extensions use
+   the Common Media Application Format (CMAF) standard [MPEG-CMAF] that
+   allows the media to be packaged into and transmitted in units smaller
+   than segments, which are called "chunks" in CMAF language.  This way,
+   the latency can be decoupled from the duration of the media segments.
+   Without a CMAF-like packaging, lower latencies can only be achieved
+   by using very short segment durations.  However, using shorter
+   segments means using more frequent intra-coded frames, and that is
+   detrimental to video encoding quality.  The CMAF standard allows us
+   to still use longer segments (improving encoding quality) without
+   penalizing latency.
+
+   While an LL-HLS client retrieves each chunk with a separate HTTP GET
+   request, an LL-DASH client uses the chunked transfer encoding feature
+   of the HTTP [CMAF-CTE], which allows the LL-DASH client to fetch all
+   the chunks belonging to a segment with a single GET request.  An HTTP
+   server can transmit the CMAF chunks to the LL-DASH client as they
+   arrive from the encoder/packager.  A detailed comparison of LL-HLS
+   and LL-DASH is given in [MMSP20].
+
+4.3.  Non-Low-Latency Live
+
+   Non-low-latency live delivery of media is defined here as a live
+   stream that does not have a latency target shorter than 10 seconds.
+
+   This level of latency is the historically common case for segmented
+   media delivery using HLS and DASH.  This level of latency is often
+   considered adequate for content like news.  This level of latency is
+   also sometimes achieved as a fallback state when some part of the
+   delivery system or the client-side players do not support low-latency
+   live streaming.
+
+   This level of latency can typically be achieved at scale with
+   commodity CDN services for HTTP(s) delivery, and in some cases, the
+   increased time window can allow for the production of a wider range
+   of encoding options relative to the requirements for a lower-latency
+   service without the need for increasing the hardware footprint, which
+   can allow for wider device interoperability.
+
+4.4.  On-Demand
+
+   On-demand media streaming refers to the playback of pre-recorded
+   media based on a user's action.  In some cases, on-demand media is
+   produced as a by-product of a live media production, using the same
+   segments as the live event but freezing the manifest that describes
+   the media available from the media server after the live event has
+   finished.  In other cases, on-demand media is constructed out of pre-
+   recorded assets with no streaming necessarily involved during the
+   production of the on-demand content.
+
+   On-demand media generally is not subject to latency concerns, but
+   other timing-related considerations can still be as important or even
+   more important to the user experience than the same considerations
+   with live events.  These considerations include the startup time, the
+   stability of the media stream's playback quality, and avoidance of
+   stalls and other media artifacts during the playback under all but
+   the most severe network conditions.
+
+   In some applications, optimizations are available to on-demand media
+   but are not always available to live events, such as preloading the
+   first segment for a startup time that does not have to wait for a
+   network download to begin.
+
+5.  Adaptive Encoding, Adaptive Delivery, and Measurement Collection
+
+   This section describes one of the best-known ways to provide a good
+   user experience over a given network path, but one thing to keep in
+   mind is that application-level mechanisms cannot provide a better
+   experience than the underlying network path can support.
+
+5.1.  Overview
+
+   A simple model of media playback can be described as a media stream
+   consumer, a buffer, and a transport mechanism that fills the buffer.
+   The consumption rate is fairly static and is represented by the
+   content bitrate.  The size of the buffer is also commonly a fixed
+   size.  The buffer fill process needs to be at least fast enough to
+   ensure that the buffer is never empty; however, it also can have
+   significant complexity when things like personalization or
+   advertising insertion workflows are introduced.
+
+   The challenges in filling the buffer in a timely way fall into two
+   broad categories:
+
+   *  Content variation (also sometimes called a "bitrate ladder") is
+      the set of content renditions that are available at any given
+      selection point.
+
+   *  Content selection comprises all of the steps a client uses to
+      determine which content rendition to play.
+
+   The mechanism used to select the bitrate is part of the content
+   selection, and the content variation is all of the different bitrate
+   renditions.
+
+   Adaptive bitrate streaming ("ABR streaming" or simply "ABR") is a
+   commonly used technique for dynamically adjusting the media quality
+   of a stream to match bandwidth availability.  When this goal is
+   achieved, the media server will tend to send enough media that the
+   media player does not "stall", without sending so much media that the
+   media player cannot accept it.
+
+   ABR uses an application-level response strategy in which the
+   streaming client attempts to detect the available bandwidth of the
+   network path by first observing the successful application-layer
+   download speed; then, given the available bandwidth, the client
+   chooses a bitrate for each of the video, audio, subtitles, and
+   metadata (among a limited number of available options for each type
+   of media) 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.).
+
+5.2.  Adaptive Encoding
+
+   Media servers can provide media streams at various bitrates because
+   the media has been encoded at various bitrates.  This is a so-called
+   "ladder" of bitrates that can be offered to media players as part of
+   the manifest so that the media player can select among the available
+   bitrate choices.
+
+   The media server may also choose to alter which bitrates are made
+   available to players by adding or removing bitrate options from the
+   ladder delivered to the player in subsequent manifests built and sent
+   to the player.  This way, both the player, through its selection of
+   bitrate to request from the manifest, and the server, through its
+   construction of the bitrates offered in the manifest, are able to
+   affect network utilization.
+
+5.3.  Adaptive Segmented Delivery
+
+   Adaptive segmented delivery attempts to optimize its own use of the
+   path between a media server and a media client.  ABR playback is
+   commonly implemented by streaming clients using HLS [RFC8216] or DASH
+   [MPEG-DASH] to perform a reliable segmented delivery of media over
+   HTTP.  Different implementations use different strategies
+   [ABRSurvey], often relying on proprietary algorithms (called rate
+   adaptation or bitrate selection algorithms) to perform available
+   bandwidth estimation/prediction and the bitrate selection.
+
+   Many systems will do an initial probe or a very simple throughput
+   speed test at the start of media playback.  This is done to get a
+   rough sense of the highest (total) media bitrate that the network
+   between the server and player will likely be able to provide under
+   initial network conditions.  After the initial testing, clients tend
+   to rely upon passive network observations and will make use of
+   player-side statistics, such as buffer fill rates, to monitor and
+   respond to changing network conditions.
+
+   The choice of bitrate occurs within the context of optimizing for one
+   or more metrics monitored by the client, such as the highest
+   achievable audiovisual quality or the lowest chances for a
+   rebuffering event (playback stall).
+
+5.4.  Advertising
+
+   The inclusion of advertising alongside or interspersed with streaming
+   media content is common in today's media landscape.
+
+   Some commonly used forms of advertising can introduce potential user
+   experience issues for a media stream.  This section provides a very
+   brief overview of a complex and rapidly evolving space.
+
+   The same techniques used to allow a media player to switch between
+   renditions of different bitrates at segment boundaries can also be
+   used to enable the dynamic insertion of advertisements (hereafter
+   referred to as "ads"), but this does not mean that the insertion of
+   ads has no effect on the user's quality of experience.
+
+   Ads may be inserted with either Client-side Ad Insertion (CSAI) or
+   Server-side Ad Insertion (SSAI).  In CSAI, the ABR manifest will
+   generally include links to an external ad server for some segments of
+   the media stream, while in SSAI, the server will remain the same
+   during ads but will include media segments that contain the
+   advertising.  In SSAI, the media segments may or may not be sourced
+   from an external ad server like with CSAI.
+
+   In general, the more targeted the ad request is, the more requests
+   the ad service needs to be able to handle concurrently.  If
+   connectivity is poor to the ad service, this can cause rebuffering
+   even if the underlying media assets (both content and ads) can be
+   accessed quickly.  The less targeted the ad request is, the more
+   likely that ad requests can be consolidated and that ads can be
+   cached similarly to the media content.
+
+   In some cases, especially with SSAI, advertising space in a stream is
+   reserved for a specific advertiser and can be integrated with the
+   video so that the segments share the same encoding properties, such
+   as bitrate, dynamic range, and resolution.  However, in many cases,
+   ad servers integrate with a Supply Side Platform (SSP) that offers
+   advertising space in real-time auctions via an Ad Exchange, with bids
+   for the advertising space coming from Demand Side Platforms (DSPs)
+   that collect money from advertisers for delivering the ads.  Most
+   such Ad Exchanges use application-level protocol specifications
+   published by the Interactive Advertising Bureau [IAB-ADS], an
+   industry trade organization.
+
+   This ecosystem balances several competing objectives, and integrating
+   with it naively can produce surprising user experience results.  For
+   example, ad server provisioning and/or the bitrate of the ad segments
+   might be different from that of the main content, and either of these
+   differences can result in playback stalls.  For another example,
+   since the inserted ads are often produced independently, they might
+   have a different base volume level than the main content, which can
+   make for a jarring user experience.
+
+   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 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.
+
+   In general, this is a rapidly developing space with many
+   considerations, and media streaming operators engaged in advertising
+   may need to research these and other concerns to find solutions that
+   meet their user experience, user privacy, and financial goals.  For
+   further reading on mitigations, [BAP] has published some standards
+   and best practices based on user experience research.
+
+5.5.  Bitrate Detection Challenges
+
+   This kind of bandwidth-measurement system can experience various
+   troubles that are affected by networking and transport protocol
+   issues.  Because adaptive application-level response strategies are
+   often using rates as observed by the application layer, there are
+   sometimes inscrutable transport-level protocol behaviors that can
+   produce surprising measurement values when the application-level
+   feedback loop is interacting with a transport-level feedback loop.
+
+   A few specific examples of surprising phenomena that affect bitrate
+   detection measurements are described in the following subsections.
+   As these examples will demonstrate, it is common to encounter cases
+   that can deliver application-level measurements that are too low, too
+   high, and (possibly) correct but that vary more quickly than a lab-
+   tested selection algorithm might expect.
+
+   These effects and others that cause transport behavior to diverge
+   from lab modeling can sometimes have a significant impact on bitrate
+   selection and on user QoE, especially where players use naive
+   measurement strategies and selection algorithms that do not account
+   for the likelihood of bandwidth measurements that diverge from the
+   true path capacity.
+
+5.5.1.  Idle Time between Segments
+
+   When the bitrate selection is chosen substantially below the
+   available capacity of the network path, the response to a segment
+   request will typically complete in much less absolute time than the
+   duration of the requested segment, leaving significant idle time
+   between segment downloads.  This can have a few surprising
+   consequences:
+
+   *  TCP slow-start, when restarting after idle, requires multiple RTTs
+      to re-establish a throughput at the network's available capacity.
+      When the active transmission time for segments is substantially
+      shorter than the time between segments, leaving an idle gap
+      between segments that triggers a restart of TCP slow-start, the
+      estimate of the successful download speed coming from the
+      application-visible receive rate on the socket can thus end up
+      much lower than the actual available network capacity.  This, in
+      turn, can prevent a shift to the most appropriate bitrate.
+      [RFC7661] provides some mitigations for this effect at the TCP
+      transport layer for senders who anticipate a high incidence of
+      this problem.
+
+   *  Mobile flow-bandwidth spectrum and timing mapping can be impacted
+      by idle time in some networks.  The carrier capacity assigned to a
+      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.
+
+   Some receiver-side ABR algorithms, such as [ELASTIC], are designed to
+   try to avoid this effect.
+
+   Another way to mitigate this effect is by the help of two
+   simultaneous TCP connections, as explained in [MMSys11] for Microsoft
+   Smooth Streaming.  In some cases, the system-level TCP slow-start
+   restart can also be disabled, for example, as described in
+   [OReilly-HPBN].
+
+5.5.2.  Noisy Measurements
+
+   In addition to smoothing over an appropriate time scale to handle
+   network jitter (see [RFC5481]), ABR systems relying on measurements
+   at the application layer also have to account for noise from the in-
+   order data transmission at the transport layer.
+
+   For instance, in the event of a lost packet on a TCP connection with
+   SACK support (a common case for segmented delivery in practice), loss
+   of a packet can provide a confusing bandwidth signal to the receiving
+   application.  Because of the sliding window in TCP, many packets may
+   be accepted by the receiver without being available to the
+   application until the missing packet arrives.  Upon the arrival of
+   the one missing packet after retransmit, the receiver will suddenly
+   get access to a lot of data at the same time.
+
+   To a receiver measuring bytes received per unit time at the
+   application layer and interpreting it as an estimate of the available
+   network bandwidth, this appears as a high jitter in the goodput
+   measurement, presenting as a stall followed by a sudden leap that can
+   far exceed the actual capacity of the transport path from the server
+   when the hole in the received data is filled by a later
+   retransmission.
+
+5.5.3.  Wide and Rapid Variation in Path Capacity
+
+   As many end devices have moved to wireless connections for the final
+   hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth
+   detection have emerged.
+
+   In most real-world operating environments, wireless links can often
+   experience sudden changes in capacity as the end user device moves
+   from place to place or encounters new sources of interference.
+   Microwave ovens, for example, can cause a throughput degradation in
+   Wi-Fi of more than a factor of 2 while active [Micro].
+
+   These swings in actual transport capacity can result in user
+   experience issues when interacting with ABR algorithms that are not
+   tuned to handle the capacity variation gracefully.
+
+5.6.  Measurement Collection
+
+   Media players use measurements to guide their segment-by-segment
+   adaptive streaming requests but may also provide measurements to
+   streaming media providers.
+
+   In turn, media providers may base analytics on these measurements to
+   guide decisions, such as whether adaptive encoding bitrates in use
+   are the best ones to provide to media players or whether current
+   media content caching is providing the best experience for viewers.
+
+   To that effect, the Consumer Technology Association (CTA), who owns
+   the Web Application Video Ecosystem (WAVE) project, has published two
+   important specifications.
+
+   *  CTA-2066: Streaming Quality of Experience Events, Properties and
+      Metrics
+
+   [CTA-2066] specifies a set of media player events, properties, QoE
+   metrics, and associated terminology for representing streaming media
+   QoE across systems, media players, and analytics vendors.  While all
+   these events, properties, metrics, and associated terminology are
+   used across a number of proprietary analytics and measurement
+   solutions, they were used in slightly (or vastly) different ways that
+   led to interoperability issues.  CTA-2066 attempts to address this
+   issue by defining common terminology and how each metric should be
+   computed for consistent reporting.
+
+   *  CTA-5004: Web Application Video Ecosystem - Common Media Client
+      Data (CMCD)
+
+   Many assume that the CDNs have a holistic view of the health and
+   performance of the streaming clients.  However, this is not the case.
+   The CDNs produce millions of log lines per second across hundreds of
+   thousands of clients, and they have no concept of a "session" as a
+   client would have, so CDNs are decoupled from the metrics the clients
+   generate and report.  A CDN cannot tell which request belongs to
+   which playback session, the duration of any media object, the
+   bitrate, or whether any of the clients have stalled and are
+   rebuffering or are about to stall and will rebuffer.  The consequence
+   of this decoupling is that a CDN cannot prioritize delivery for when
+   the client needs it most, prefetch content, or trigger alerts when
+   the network itself may be underperforming.  One approach to couple
+   the CDN to the playback sessions is for the clients to communicate
+   standardized media-relevant information to the CDNs while they are
+   fetching data.  [CTA-5004] was developed exactly for this purpose.
+
+6.  Transport Protocol Behaviors and Their Implications for Media
+    Transport Protocols
+
+   Within this document, the term "media transport protocol" is used to
+   describe any protocol that carries media metadata and media segments
+   in its payload, and the term "transport protocol" describes any
+   protocol that carries a media transport protocol, or another
+   transport protocol, in its payload.  This is easier to understand if
+   the reader assumes a protocol stack that looks something like this:
+
+             Media Segments
+       ---------------------------
+              Media Format
+       ---------------------------
+         Media Transport Protocol
+       ---------------------------
+          Transport Protocol(s)
+
+   where
+
+   *  "Media segments" would be something like the output of a codec or
+      some other source of media segments, such as closed-captioning,
+
+   *  "Media format" would be something like an RTP payload format
+      [RFC2736] or an ISO base media file format (ISOBMFF) profile
+      [ISOBMFF],
+
+   *  "Media transport protocol" would be something like RTP [RFC3550]
+      or DASH [MPEG-DASH], and
+
+   *  "Transport protocol" would be a protocol that provides appropriate
+      transport services, as described in Section 5 of [RFC8095].
+
+   Not all possible streaming media applications follow this model, but
+   for the ones that do, it seems useful to distinguish between the
+   protocol layer that is aware it is transporting media segments and
+   underlying protocol layers that are not aware.
+
+   As described in the abstract of [RFC8095], the IETF has standardized
+   a number of protocols that provide transport services.  Although
+   these protocols, taken in total, provide a wide variety of transport
+   services, Section 6 will distinguish between two extremes:
+
+   *  transport protocols used to provide reliable, in-order media
+      delivery to an endpoint, typically providing flow control and
+      congestion control (Section 6.1), and
+
+   *  transport protocols used to provide unreliable, unordered media
+      delivery to an endpoint, without flow control or congestion
+      control (Section 6.2).
+
+   Because newly standardized transport protocols, such as QUIC
+   [RFC9000], that are typically implemented in user space can evolve
+   their transport behavior more rapidly than currently used transport
+   protocols that are typically implemented in operating system kernel
+   space, this document includes a description of how the path
+   characteristics that streaming media providers may see are likely to
+   evolve; see Section 6.3.
+
+   It is worth noting explicitly that the transport protocol layer might
+   include more than one protocol.  For example, a specific media
+   transport protocol might run over HTTP, or over WebTransport, which
+   in turn runs over HTTP.
+
+   It is worth noting explicitly that more complex network protocol
+   stacks are certainly possible -- for instance, when packets with this
+   protocol stack are carried in a tunnel or in a VPN, the entire packet
+   would likely appear in the payload of other protocols.  If these
+   environments are present, streaming media operators may need to
+   analyze their effects on applications as well.
+
+6.1.  Media Transport over Reliable Transport Protocols
+
+   The HLS [RFC8216] and DASH [MPEG-DASH] media transport protocols are
+   typically carried over HTTP, and HTTP has used TCP as its only
+   standardized transport protocol until HTTP/3 [RFC9114].  These media
+   transport protocols use ABR response strategies as described in
+   Section 5 to respond to changing path characteristics, and underlying
+   transport protocols are also attempting to respond to changing path
+   characteristics.
+
+   The past success of the largely TCP-based Internet is evidence that
+   the various flow control and congestion control mechanisms that TCP
+   has 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 provided 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 [RFC9293] 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 can
+   prevent older TCP senders from quickly detecting when a network path
+   is becoming saturated.  Congestion control mechanisms, such as Copa
+   [COPA18] and Bottleneck Bandwidth and Round-trip propagation time
+   (BBR) [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 with adding new congestion
+   controllers such as CUBIC [RFC8312], 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.
+
+6.2.  Media Transport over Unreliable Transport Protocols
+
+   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
+   applications have delegated to TCP, i.e., 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
+   feedback mechanisms and to respond to the feedback the application
+   receives.  This expectation is most recently codified as a Best
+   Current Practice [RFC8085].
+
+   In contrast to adaptive segmented delivery over a reliable transport
+   as described in Section 5.3, some applications deliver streaming
+   media segments using an unreliable transport and rely on a variety of
+   approaches, including:
+
+   *  media encapsulated in a raw MPEG Transport Stream (MPEG-TS)
+      [MPEG-TS] over UDP, which makes no attempt to account for
+      reordering or loss in the transport,
+
+   *  RTP [RFC3550], which can notice packet loss and repair some
+      limited reordering,
+
+   *  the Stream Control Transmission Protocol (SCTP) [RFC9260], which
+      can use partial reliability [RFC3758] to recover from some loss
+      but can abandon recovery to limit head-of-line blocking, and
+
+   *  the Secure Reliable Transport (SRT) [SRT], which can use forward
+      error correction and time-bound retransmission to recover from
+      loss within certain limits but can abandon recovery to limit head-
+      of-line blocking.
+
+   Under congestion and loss, approaches like the above generally
+   experience transient media artifacts more often and delay of playback
+   effects less often, as compared with reliable segment transport.
+   Often, one of the key goals of using a UDP-based transport that
+   allows some unreliability is to reduce latency and better support
+   applications like videoconferencing or other live-action video with
+   interactive components, such as some sporting events.
+
+   Congestion avoidance strategies for deployments using unreliable
+   transport protocols vary widely in practice, ranging from being
+   entirely unresponsive to responding by using strategies, including:
+
+   *  feedback signaling to change encoder settings (as in [RFC5762]),
+
+   *  fewer enhancement layers (as in [RFC6190]), and
+
+   *  proprietary methods to detect QoE issues and turn off video to
+      allow less bandwidth-intensive media, such as audio, to be
+      delivered.
+
+   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 segments are carried in tunnels encapsulated in UDP,
+   these media streams may encounter "tripped circuit breakers", with
+   resulting user-visible impacts.
+
+6.3.  QUIC and Changing Transport Protocol Behavior
+
+   The QUIC protocol, developed from a proprietary protocol into an IETF
+   Standards Track protocol [RFC9000], behaves differently than the
+   transport protocols characterized in Sections 6.1 and 6.2.
+
+   Although QUIC provides an alternative to the TCP and UDP transport
+   protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in
+   Section 7.1, 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.  Section 7 describes the
+   implications of media encryption in more detail.
+
+   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 [RFC9114], which describes how
+   QUIC transport services 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.  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 QUIC packets
+   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 Section 5.5.2, because TCP provides a reliable, in-order
+   delivery service for applications, any packet loss for a TCP
+   connection causes head-of-line blocking so that no TCP segments
+   arriving after a packet is lost will be delivered to the receiving
+   application until retransmission of the lost packet has been
+   received, allowing in-order delivery to the application to continue.
+   As described in [RFC9000], QUIC connections can carry multiple
+   streams, and when packet losses do occur, only the streams carried in
+   the lost packet are delayed.
+
+   A QUIC extension currently being specified [RFC9221] adds the
+   capability for "unreliable" delivery, similar to the service provided
+   by UDP, but these datagrams are still subject to the QUIC
+   connection's congestion controller, providing some transport-level
+   congestion avoidance measures, which UDP does not.
+
+   As noted in Section 6.1, there is an increasing interest in
+   congestion control algorithms that respond to delay measurements
+   instead of responding to packet loss.  These algorithms may deliver
+   an improved user experience, but in some cases, they 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 used for algorithm agility, and [RFC9002] defines a basic
+   congestion control algorithm that is roughly similar to TCP NewReno
+   [RFC6582].  However, QUIC senders can and do unilaterally choose to
+   use different algorithms, such as loss-based CUBIC [RFC8312], delay-
+   based Copa or BBR, or even something completely different.
+
+   The Internet community does have experience with deploying new
+   congestion controllers without causing congestion collapse on the
+   Internet.  As noted in [RFC8312], both the CUBIC congestion
+   controller and its predecessor BIC have significantly different
+   behavior from Reno-style congestion controllers, such as TCP NewReno
+   [RFC6582]; both were added to the Linux kernel to allow
+   experimentation and analysis, both were then selected as the default
+   TCP congestion controllers in Linux, and both were deployed globally.
+
+   The point mentioned in Section 6.1 about TCP congestion controllers
+   being implemented in operating system kernels is 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";
+   to meet this expectation, many implementers have chosen to implement
+   QUIC in user space, outside the operating system kernel, and to even
+   distribute QUIC libraries with their own applications.  It is worth
+   noting that streaming operators using HTTP/3, carried over QUIC, can
+   expect more frequent deployment of new congestion controller behavior
+   than has been the case with HTTP/1 and HTTP/2, carried over TCP.
+
+   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-based HTTP traffic and UDP-based HTTP/3 traffic.
+
+7.  Streaming Encrypted Media
+
+   "Encrypted Media" has at least three meanings:
+
+   *  Media encrypted at the application layer, typically using some
+      sort of Digital Rights Management (DRM) system or other object
+      encryption/security mechanism and typically remaining encrypted at
+      rest when senders and receivers store it.
+
+   *  Media encrypted by the sender at the transport layer and remaining
+      encrypted until it reaches the ultimate media consumer (in this
+      document, it is referred to as end-to-end media encryption).
+
+   *  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 decryption 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, it is referred to as
+      hop-by-hop media encryption).
+
+   This document focuses on media encrypted at the transport layer,
+   whether encryption is performed hop by hop or end to end.  Because
+   media encrypted at the application layer will only be processed by
+   application-level entities, this encryption does not have transport-
+   layer implications.  Of course, 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 stream manipulation or to protect
+   manifests.
+
+   This document does not take a position on whether those goals are
+   valid.
+
+   Both end-to-end and hop-by-hop media encryption have specific
+   implications for streaming operators.  These are described in
+   Sections 7.2 and 7.3.
+
+7.1.  General Considerations for Streaming Media Encryption
+
+   The use of strong encryption does provide confidentiality for
+   encrypted streaming media, from the sender to either the ultimate
+   media consumer or to an intermediary that possesses credentials
+   allowing decryption.  This does prevent deep packet inspection (DPI)
+   by any on-path intermediary that does not possess credentials
+   allowing decryption.  However, even encrypted content streams may be
+   vulnerable to traffic analysis.  An on-path observer that can
+   identify that encrypted traffic contains a media stream could
+   "fingerprint" this encrypted media stream and then compare it against
+   "fingerprints" of known content.  The protection provided by strong
+   encryption can be further lessened if a streaming media operator is
+   repeatedly encrypting the same content.  "Identifying HTTPS-Protected
+   Netflix Videos in Real-Time" [CODASPY17] 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 tells
+   an on-path observer what resource is being streamed, and by who,
+   almost 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 have historically had
+   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 [RFC9114], uses the QUIC
+   protocol [RFC9000] as its transport layer.  QUIC relies on the TLS
+   1.3 initial handshake [RFC8446] only for key exchange [RFC9001] and
+   encrypts almost all transport parameters itself, except for a few
+   invariant header fields.  In the QUIC short header, the only
+   transport-level parameter that is sent "in the clear" is the
+   Destination Connection ID [RFC8999], and even in the QUIC long
+   header, the only transport-level parameters sent "in the clear" are
+   the version, Destination Connection ID, and Source Connection ID.
+   For these reasons, HTTP/3 is significantly more "opaque" than HTTPS
+   with HTTP/1 or HTTP/2.
+
+   [RFC9312] discusses the manageability of the QUIC transport protocol
+   that is used to encapsulate HTTP/3, 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.
+
+   More broadly, "Considerations around Transport Header
+   Confidentiality, Network Operations, and the Evolution of Internet
+   Transport Protocols" [RFC9065] describes the impact of increased
+   encryption of transport headers in general terms.
+
+   It is also worth noting that considerations for heavily encrypted
+   transport protocols also come into play when streaming media is
+   carried over IP-level VPNs and tunnels, with the additional
+   consideration that an intermediary that does not possess credentials
+   allowing decryption will not have visibility to the source and
+   destination IP addresses of the packets being carried inside the
+   tunnel.
+
+7.2.  Considerations for Hop-by-Hop Media Encryption
+
+   Hop-by-hop media encryption offers the benefits described in
+   Section 7.1 between the streaming media operator and authorized
+   intermediaries, among authorized intermediaries, and between
+   authorized intermediaries and the ultimate media consumer; however,
+   it does not provide these benefits end to end.  The streaming media
+   operator and ultimate media consumer must trust the authorized
+   intermediaries, and if these intermediaries cannot be trusted, the
+   benefits of encryption are lost.
+
+   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 streaming media operator's perspective, a number of
+   considerations are in play.  The first question is likely whether the
+   streaming media operator intends that intermediaries are explicitly
+   addressed from endpoints or whether the streaming media operator is
+   willing to allow intermediaries to "intercept" streaming content
+   transparently, with no awareness or permission from either endpoint.
+
+   If a streaming media operator does not actively work to avoid
+   interception by on-path intermediaries, the effect will be
+   indistinguishable from "impersonation attacks", and endpoints cannot
+   be assured of any level of confidentiality and cannot trust that the
+   content received came from the expected sender.
+
+   Assuming that a streaming media operator 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 the following:
+
+   Server and Network Assisted DASH [MPEG-DASH-SAND]:
+      This specification introduces explicit messaging between DASH
+      clients and DASH-aware network elements or among various DASH-
+      aware 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 a 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 SRTP
+      that provides both hop-by-hop and end-to-end security guarantees.
+
+   Secure 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 Frames [SFRAME], also provides both hop-by-hop
+      and end-to-end security guarantees but can be used with other
+      media transport protocols beyond SRTP.
+
+   A streaming media operator's choice of whether to involve
+   intermediaries requires careful consideration.  As an example, when
+   ABR manifests were commonly sent unencrypted, some access network
+   operators would modify manifests during peak hours by removing high-
+   bitrate renditions to prevent players from choosing those renditions,
+   thus reducing the overall bandwidth consumed for delivering these
+   media streams and thereby reducing the network load and improving the
+   average user experience for their customers.  Now that ubiquitous
+   encryption typically prevents this kind of modification, a streaming
+   media operator who used intermediaries in the past, and who now
+   wishes to maintain the same level of network health and user
+   experience, must choose between adding intermediaries who are
+   authorized to change the manifests or adding some other form of
+   complexity to their service.
+
+   Some resources that might inform other similar considerations are
+   further discussed in [RFC8824] (for WebRTC) and [RFC9312] (for HTTP/3
+   and QUIC).
+
+7.3.  Considerations for End-to-End Media Encryption
+
+   End-to-end media encryption offers the benefits described in
+   Section 7.1 from the streaming media operator to the ultimate media
+   consumer.
+
+   End-to-end media encryption has become much more widespread in the
+   years since the IETF issued "Pervasive Monitoring Is an Attack"
+   [RFC7258] as a Best Current Practice, describing 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.
+
+   However, as noted in [RFC7258], there is no way to prevent pervasive
+   monitoring by an attacker while allowing monitoring by a more benign
+   entity who only wants to use DPI to examine HTTP requests and
+   responses to provide a better user experience.  If a modern encrypted
+   transport protocol is used for end-to-end media encryption,
+   unauthorized on-path intermediaries are unable to examine transport
+   and application protocol behavior.  As described in Section 7.2, only
+   an intermediary explicitly authorized by the streaming media operator
+   who is to examine packet payloads, rather than intercepting packets
+   and examining them without authorization, can continue these
+   practices.
+
+   [RFC7258] states that "[t]he IETF will strive to produce
+   specifications that mitigate pervasive monitoring attacks", so
+   streaming operators should expect the IETF's direction toward
+   preventing unauthorized monitoring of IETF protocols to continue for
+   the foreseeable future.
+
+8.  Additional Resources for Streaming Media
+
+   The Media Operations (MOPS) community maintains a list of references
+   and resources; for further reading, see [MOPS-RESOURCES].
+
+9.  IANA Considerations
+
+   This document has no IANA actions.
+
+10.  Security Considerations
+
+   Security is an important matter for streaming media applications, and
+   the topic of media encryption was explained in Section 7.  This
+   document itself introduces no new security issues.
+
+11.  Informative References
+
+   [ABRSurvey]
+              Bentaleb, A., Taani, B., Begen, A. C., Timmerer, C., and
+              R. Zimmermann, "A survey on bitrate adaptation schemes for
+              streaming media over HTTP", IEEE Communications Surveys &
+              Tutorials, vol. 21/1, pp. 562-585, Firstquarter 2019,
+              DOI 10.1109/COMST.2018.2862938,
+              <https://doi.org/10.1109/COMST.2018.2862938>.
+
+   [ADFRAUD]  Sadeghpour, S. and N. Vlajic, "Ads and Fraud: A
+              Comprehensive Survey of Fraud in Online Advertising",
+              Journal of Cybersecurity and Privacy 1, no. 4, pp.
+              804-832, DOI 10.3390/jcp1040039, December 2021,
+              <https://doi.org/10.3390/jcp1040039>.
+
+   [BALANCING]
+              Berger, D., "Balancing Consumer Privacy with Behavioral
+              Targeting", Santa Clara High Technology Law Journal, Vol.
+              27, Issue 1, Article 2, 2010,
+              <https://digitalcommons.law.scu.edu/chtlj/vol27/iss1/2/>.
+
+   [BAP]      Coalition for Better Ads, "Making Online Ads Better for
+              Everyone", <https://www.betterads.org/>.
+
+   [BBR-CONGESTION-CONTROL]
+              Cardwell, N., Cheng, Y., Yeganeh, S. H., Swett, I., and V.
+              Jacobson, "BBR Congestion Control", Work in Progress,
+              Internet-Draft, draft-cardwell-iccrg-bbr-congestion-
+              control-02, 7 March 2022,
+              <https://datatracker.ietf.org/doc/html/draft-cardwell-
+              iccrg-bbr-congestion-control-02>.
+
+   [BEHAVE]   Yan, J., Liu, N., Wang, G., Zhang, W., Jiang, Y., and Z.
+              Chen, "How much can behavioral targeting help online
+              advertising?", WWW '09: Proceedings of the 18th
+              international conference on World wide web, pp. 261-270,
+              DOI 10.1145/1526709.1526745, April 2009,
+              <https://dl.acm.org/doi/abs/10.1145/1526709.1526745>.
+
+   [BEHAVE2]  Goldfarb, A. and C. E. Tucker, "Online advertising,
+              behavioral targeting, and privacy", Communications of the
+              ACM, Volume 54, Issue 5, pp. 25-27,
+              DOI 10.1145/1941487.1941498, May 2011,
+              <https://dl.acm.org/doi/abs/10.1145/1941487.1941498>.
+
+   [CMAF-CTE] Bentaleb, A., Akcay, M., Lim, M., Begen, A., and R.
+              Zimmermann, "Catching the Moment With LoL+ in Twitch-Like
+              Low-Latency Live Streaming Platforms", IEEE Trans.
+              Multimedia, Vol. 24, pp. 2300-2314,
+              DOI 10.1109/TMM.2021.3079288, May 2021,
+              <https://doi.org/10.1109/TMM.2021.3079288>.
+
+   [CODASPY17]
+              Reed, A. and M. Kranch, "Identifying HTTPS-Protected
+              Netflix Videos in Real-Time", ACM CODASPY,
+              DOI 10.1145/3029806.3029821, March 2017,
+              <https://dl.acm.org/doi/10.1145/3029806.3029821>.
+
+   [CoDel]    Nichols, K. and V. Jacobson, "Controlling queue delay",
+              Communications of the ACM, Volume 55, Issue 7, pp. 42-50",
+              DOI 10.1145/2209249.2209264, July 2012,
+              <https://doi.org/10.1145/2209249.2209264>.
+
+   [COPA18]   Arun, V. and H. Balakrishnan, "Copa: Practical Delay-Based
+              Congestion Control for the Internet", USENIX NSDI, April
+              2018, <https://web.mit.edu/copa/>.
+
+   [CTA-2066] Consumer Technology Association, "Streaming Quality of
+              Experience Events, Properties and Metrics", CTA-2066,
+              March 2020, <https://shop.cta.tech/products/streaming-
+              quality-of-experience-events-properties-and-metrics>.
+
+   [CTA-5004] Consumer Technology Association, "Web Application Video
+              Ecosystem - Common Media Client Data", CTA-5004, September
+              2020, <https://shop.cta.tech/products/web-application-
+              video-ecosystem-common-media-client-data-cta-5004>.
+
+   [CVNI]     Cisco, "Cisco Visual Networking Index: Forecast and
+              Trends, 2017–2022", 2018.
+
+   [ELASTIC]  De Cicco, L., Caldaralo, V., Palmisano, V., and S.
+              Mascolo, "ELASTIC: A Client-Side Controller for Dynamic
+              Adaptive Streaming over HTTP (DASH)", Packet Video
+              Workshop, DOI 10.1109/PV.2013.6691442, December 2013,
+              <https://ieeexplore.ieee.org/document/6691442>.
+
+   [Encodings]
+              Apple Developer, "HTTP Live Streaming (HLS) Authoring
+              Specification for Apple Devices", June 2020,
+              <https://developer.apple.com/documentation/
+              http_live_streaming/
+              hls_authoring_specification_for_apple_devices>.
+
+   [HLS-RFC8216BIS]
+              Pantos, R., Ed., "HTTP Live Streaming 2nd Edition", Work
+              in Progress, Internet-Draft, draft-pantos-hls-rfc8216bis-
+              11, 11 May 2022, <https://www.ietf.org/archive/id/draft-
+              pantos-hls-rfc8216bis-11.txt>.
+
+   [IAB-ADS]  "IAB", <https://www.iab.com/>.
+
+   [ISOBMFF]  ISO, "Information technology - Coding of audio-visual
+              objects - Part 12: ISO base media file format", ISO/
+              IEC 14496-12:2022, January 2022,
+              <https://www.iso.org/standard/83102.html>.
+
+   [Jacobson-Karels]
+              Jacobson, V. and M. Karels, "Congestion Avoidance and
+              Control", November 1988,
+              <https://ee.lbl.gov/papers/congavoid.pdf>.
+
+   [LL-DASH]  DASH-IF, "Low-latency Modes for DASH", March 2020,
+              <https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf>.
+
+   [Micro]    Taher, T. M., Misurac, M. J., LoCicero, J. L., and D. R.
+              Ucci, "Microwave Oven Signal Interference Mitigation For
+              Wi-Fi Communication Systems", 2008 5th IEEE Consumer
+              Communications and Networking Conference, pp. 67-68,
+              DOI 10.1109/ccnc08.2007.21, January 2008,
+              <https://doi.org/10.1109/ccnc08.2007.21>.
+
+   [MMSP20]   Durak, K. et al., "Evaluating the Performance of Apple's
+              Low-Latency HLS", IEEE MMSP,
+              DOI 10.1109/MMSP48831.2020.9287117, September 2020,
+              <https://ieeexplore.ieee.org/document/9287117>.
+
+   [MMSys11]  Akhshabi, S., Begen, A. C., and C. Dovrolis, "An
+              experimental evaluation of rate-adaptation algorithms in
+              adaptive streaming over HTTP", ACM MMSys,
+              DOI 10.1145/1943552.1943574, February 2011,
+              <https://dl.acm.org/doi/10.1145/1943552.1943574>.
+
+   [MOPS-RESOURCES]
+              "rfc9317-additional-resources", September 2022,
+              <https://wiki.ietf.org/group/mops/rfc9317-additional-
+              resources>.
+
+   [MPEG-CMAF]
+              ISO, "Information technology - Multimedia application
+              format (MPEG-A) - Part 19: Common media application format
+              (CMAF) for segmented media", ISO/IEC 23000-19:2020, March
+              2020, <https://www.iso.org/standard/79106.html>.
+
+   [MPEG-DASH]
+              ISO, "Information technology - Dynamic adaptive streaming
+              over HTTP (DASH) - Part 1: Media presentation description
+              and segment formats", ISO/IEC 23009-1:2022, August 2022,
+              <https://www.iso.org/standard/83314.html>.
+
+   [MPEG-DASH-SAND]
+              ISO, "Information technology - Dynamic adaptive streaming
+              over HTTP (DASH) - Part 5: Server and network assisted
+              DASH (SAND)", ISO/IEC 23009-5:2017, February 2017,
+              <https://www.iso.org/standard/69079.html>.
+
+   [MPEG-TS]  ITU-T, "Information technology - Generic coding of moving
+              pictures and associated audio information: Systems", ITU-T
+              Recommendation H.222.0, June 2021,
+              <https://www.itu.int/rec/T-REC-H.222.0>.
+
+   [MPEGI]    Boyce, J. M. et al., "MPEG Immersive Video Coding
+              Standard", Proceedings of the IEEE, Vol. 109, Issue 9, pp.
+              1521-1536, DOI 10.1109/JPROC.2021.3062590,
+              <https://ieeexplore.ieee.org/document/9374648>.
+
+   [OReilly-HPBN]
+              Grigorik, I., "High Performance Browser Networking -
+              Chapter 2: Building Blocks of TCP", May 2021,
+              <https://hpbn.co/building-blocks-of-tcp/>.
+
+   [PCC]      Schwarz, S. et al., "Emerging MPEG Standards for Point
+              Cloud Compression", IEEE Journal on Emerging and Selected
+              Topics in Circuits and Systems,
+              DOI 10.1109/JETCAS.2018.2885981, March 2019,
+              <https://ieeexplore.ieee.org/document/8571288>.
+
+   [Port443]  IANA, "Service Name and Transport Protocol Port Number
+              Registry", <https://www.iana.org/assignments/service-
+              names-port-numbers>.
+
+   [RFC2001]  Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
+              Retransmit, and Fast Recovery Algorithms", RFC 2001,
+              DOI 10.17487/RFC2001, January 1997,
+              <https://www.rfc-editor.org/info/rfc2001>.
+
+   [RFC2736]  Handley, M. and C. Perkins, "Guidelines for Writers of RTP
+              Payload Format Specifications", BCP 36, RFC 2736,
+              DOI 10.17487/RFC2736, December 1999,
+              <https://www.rfc-editor.org/info/rfc2736>.
+
+   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
+              Shelby, "Performance Enhancing Proxies Intended to
+              Mitigate Link-Related Degradations", RFC 3135,
+              DOI 10.17487/RFC3135, June 2001,
+              <https://www.rfc-editor.org/info/rfc3135>.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, DOI 10.17487/RFC3168, September 2001,
+              <https://www.rfc-editor.org/info/rfc3168>.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+              July 2003, <https://www.rfc-editor.org/info/rfc3550>.
+
+   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+              Conrad, "Stream Control Transmission Protocol (SCTP)
+              Partial Reliability Extension", RFC 3758,
+              DOI 10.17487/RFC3758, May 2004,
+              <https://www.rfc-editor.org/info/rfc3758>.
+
+   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
+              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
+              DOI 10.17487/RFC4733, December 2006,
+              <https://www.rfc-editor.org/info/rfc4733>.
+
+   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
+              Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
+              March 2009, <https://www.rfc-editor.org/info/rfc5481>.
+
+   [RFC5594]  Peterson, J. and A. Cooper, "Report from the IETF Workshop
+              on Peer-to-Peer (P2P) Infrastructure, May 28, 2008",
+              RFC 5594, DOI 10.17487/RFC5594, July 2009,
+              <https://www.rfc-editor.org/info/rfc5594>.
+
+   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
+              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
+              <https://www.rfc-editor.org/info/rfc5681>.
+
+   [RFC5762]  Perkins, C., "RTP and the Datagram Congestion Control
+              Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April
+              2010, <https://www.rfc-editor.org/info/rfc5762>.
+
+   [RFC6190]  Wenger, S., Wang, Y.-K., Schierl, T., and A.
+              Eleftheriadis, "RTP Payload Format for Scalable Video
+              Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
+              <https://www.rfc-editor.org/info/rfc6190>.
+
+   [RFC6582]  Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
+              NewReno Modification to TCP's Fast Recovery Algorithm",
+              RFC 6582, DOI 10.17487/RFC6582, April 2012,
+              <https://www.rfc-editor.org/info/rfc6582>.
+
+   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
+              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
+              DOI 10.17487/RFC6817, December 2012,
+              <https://www.rfc-editor.org/info/rfc6817>.
+
+   [RFC6843]  Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
+              (RTCP) Extended Report (XR) Block for Delay Metric
+              Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
+              <https://www.rfc-editor.org/info/rfc6843>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+              2014, <https://www.rfc-editor.org/info/rfc7258>.
+
+   [RFC7414]  Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
+              Zimmermann, "A Roadmap for Transmission Control Protocol
+              (TCP) Specification Documents", RFC 7414,
+              DOI 10.17487/RFC7414, February 2015,
+              <https://www.rfc-editor.org/info/rfc7414>.
+
+   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
+              "Encapsulating MPLS in UDP", RFC 7510,
+              DOI 10.17487/RFC7510, April 2015,
+              <https://www.rfc-editor.org/info/rfc7510>.
+
+   [RFC7656]  Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
+              B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
+              for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
+              DOI 10.17487/RFC7656, November 2015,
+              <https://www.rfc-editor.org/info/rfc7656>.
+
+   [RFC7661]  Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
+              TCP to Support Rate-Limited Traffic", RFC 7661,
+              DOI 10.17487/RFC7661, October 2015,
+              <https://www.rfc-editor.org/info/rfc7661>.
+
+   [RFC8083]  Perkins, C. and V. Singh, "Multimedia Congestion Control:
+              Circuit Breakers for Unicast RTP Sessions", RFC 8083,
+              DOI 10.17487/RFC8083, March 2017,
+              <https://www.rfc-editor.org/info/rfc8083>.
+
+   [RFC8084]  Fairhurst, G., "Network Transport Circuit Breakers",
+              BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
+              <https://www.rfc-editor.org/info/rfc8084>.
+
+   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
+
+   [RFC8095]  Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
+              Ed., "Services Provided by IETF Transport Protocols and
+              Congestion Control Mechanisms", RFC 8095,
+              DOI 10.17487/RFC8095, March 2017,
+              <https://www.rfc-editor.org/info/rfc8095>.
+
+   [RFC8216]  Pantos, R., Ed. and W. May, "HTTP Live Streaming",
+              RFC 8216, DOI 10.17487/RFC8216, August 2017,
+              <https://www.rfc-editor.org/info/rfc8216>.
+
+   [RFC8312]  Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
+              R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
+              RFC 8312, DOI 10.17487/RFC8312, February 2018,
+              <https://www.rfc-editor.org/info/rfc8312>.
+
+   [RFC8404]  Moriarty, K., Ed. and A. Morton, Ed., "Effects of
+              Pervasive Encryption on Operators", RFC 8404,
+              DOI 10.17487/RFC8404, July 2018,
+              <https://www.rfc-editor.org/info/rfc8404>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8622]  Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
+              Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
+              June 2019, <https://www.rfc-editor.org/info/rfc8622>.
+
+   [RFC8723]  Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
+              "Double Encryption Procedures for the Secure Real-Time
+              Transport Protocol (SRTP)", RFC 8723,
+              DOI 10.17487/RFC8723, April 2020,
+              <https://www.rfc-editor.org/info/rfc8723>.
+
+   [RFC8824]  Minaburo, A., Toutain, L., and R. Andreasen, "Static
+              Context Header Compression (SCHC) for the Constrained
+              Application Protocol (CoAP)", RFC 8824,
+              DOI 10.17487/RFC8824, June 2021,
+              <https://www.rfc-editor.org/info/rfc8824>.
+
+   [RFC8825]  Alvestrand, H., "Overview: Real-Time Protocols for
+              Browser-Based Applications", RFC 8825,
+              DOI 10.17487/RFC8825, January 2021,
+              <https://www.rfc-editor.org/info/rfc8825>.
+
+   [RFC8834]  Perkins, C., Westerlund, M., and J. Ott, "Media Transport
+              and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
+              January 2021, <https://www.rfc-editor.org/info/rfc8834>.
+
+   [RFC8835]  Alvestrand, H., "Transports for WebRTC", RFC 8835,
+              DOI 10.17487/RFC8835, January 2021,
+              <https://www.rfc-editor.org/info/rfc8835>.
+
+   [RFC8999]  Thomson, M., "Version-Independent Properties of QUIC",
+              RFC 8999, DOI 10.17487/RFC8999, May 2021,
+              <https://www.rfc-editor.org/info/rfc8999>.
+
+   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", RFC 9000,
+              DOI 10.17487/RFC9000, May 2021,
+              <https://www.rfc-editor.org/info/rfc9000>.
+
+   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
+              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
+              <https://www.rfc-editor.org/info/rfc9001>.
+
+   [RFC9002]  Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
+              and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
+              May 2021, <https://www.rfc-editor.org/info/rfc9002>.
+
+   [RFC9065]  Fairhurst, G. and C. Perkins, "Considerations around
+              Transport Header Confidentiality, Network Operations, and
+              the Evolution of Internet Transport Protocols", RFC 9065,
+              DOI 10.17487/RFC9065, July 2021,
+              <https://www.rfc-editor.org/info/rfc9065>.
+
+   [RFC9075]  Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins,
+              "Report from the IAB COVID-19 Network Impacts Workshop
+              2020", RFC 9075, DOI 10.17487/RFC9075, July 2021,
+              <https://www.rfc-editor.org/info/rfc9075>.
+
+   [RFC9111]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Caching", STD 98, RFC 9111,
+              DOI 10.17487/RFC9111, June 2022,
+              <https://www.rfc-editor.org/info/rfc9111>.
+
+   [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
+              June 2022, <https://www.rfc-editor.org/info/rfc9114>.
+
+   [RFC9221]  Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
+              Datagram Extension to QUIC", RFC 9221,
+              DOI 10.17487/RFC9221, March 2022,
+              <https://www.rfc-editor.org/info/rfc9221>.
+
+   [RFC9260]  Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
+              Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
+              June 2022, <https://www.rfc-editor.org/info/rfc9260>.
+
+   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
+              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
+              <https://www.rfc-editor.org/info/rfc9293>.
+
+   [RFC9312]  Kühlewind, M. and B. Trammell, "Manageability of the QUIC
+              Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
+              September 2022, <https://www.rfc-editor.org/info/rfc9312>.
+
+   [SFRAME]   IETF, "Secure Frame (sframe)",
+              <https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/>.
+
+   [SRT]      Sharabayko, M., "SRT Protocol Overview", April 2020,
+              <https://datatracker.ietf.org/meeting/interim-2020-mops-
+              01/materials/slides-interim-2020-mops-01-sessa-srt-
+              protocol-overview-00>.
+
+   [Survey360]
+              Yaqoob, A., Bi, T., and G. Muntean, "A Survey on Adaptive
+              360° Video Streaming: Solutions, Challenges and
+              Opportunities", IEEE Communications Surveys & Tutorials,
+              Volume 22, Issue 4, DOI 10.1109/COMST.2020.3006999, July
+              2020, <https://ieeexplore.ieee.org/document/9133103>.
+
+Acknowledgments
+
+   Thanks to Nancy Cam-Winget, Leslie Daigle, Roman Danyliw, Glenn Deen,
+   Martin Duke, Linda Dunbar, Lars Eggert, Mike English, Roni Even,
+   Aaron Falk, Alexandre Gouaillard, Erik Kline, Renan Krishna, Warren
+   Kumari, Will Law, Chris Lemmons, Kiran Makhjani, Sanjay Mishra, Mark
+   Nottingham, Dave Oran, Lucas Pardue, Tommy Pauly, Kyle Rose, Zahed
+   Sarker, Michael Scharf, John Scudder, Valery Smyslov, Matt Stock,
+   Éric Vyncke, and Robert Wilton for very helpful suggestions, reviews,
+   and comments.
+
+Authors' Addresses
+
+   Jake Holland
+   Akamai Technologies, Inc.
+   150 Broadway
+   Cambridge, MA 02144
+   United States of America
+   Email: jakeholland.net@gmail.com
+
+
+   Ali Begen
+   Networked Media
+   Turkey
+   Email: ali.begen@networked.media
+
+
+   Spencer Dawkins
+   Tencent America LLC
+   United States of America
+   Email: spencerdawkins.ietf@gmail.com