RFC 9317

Operational Considerations for Streaming Media

📅 published October 2022, from ietf

🎀 RFC 9317: Operational Considerations for Streaming Media 🎀

Okay bestie, this one is a pure gem 💅✨. It's an Informational doc from the IETF (not a Standards Track spec, so it's giving "here's some super useful tea" vibes, not "you MUST do this" 🙈). It was published in October 2022 (RFC 9317, Category: Informational, ISSN: 2070-1721) by J. Holland of Akamai Technologies, Inc., A. Begen of Networked Media, and S. Dawkins of Tencent America LLC. 🌸 It doesn't obsolete or update any other RFCs, so it's a fresh start, no drama 🫶.

The whole point is QoE (quality of experience) when you're streaming video and other high-bitrate media over the Internet 📺💖. It's written for network designers and transport experts who aren't media people yet, to explain all the stuff that surprised them when streaming didn't behave the way their usual networking assumptions said it would 😭🔥.

Status of This Memo 🧚

This document is not an Internet Standards Track specification; it is published for informational purposes. 🌈 It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for an Internet Standard, though; see Section 2 of RFC 7841 for that. 💅

Info on the current status, errata, and how to give feedback lives 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the publication date. Please actually read those, because they spell out your rights and restrictions 🙈. Code components pulled out of this doc must include Revised BSD License text (see Section 4.e of the Trust Legal Provisions) and come without warranty, as the Revised BSD License describes ✨.

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 doc gives you the overview of operational networking and transport protocol issues that affect QoE when you stream video and other high-bitrate media over the Internet 📺🦋. It's meant for network designers and transport experts without media expertise, because streaming media shows up the gap between what networking folks usually assume and what actually happens when media runs over those same networks 😭.

1.1. Key Definitions 🎀

This doc defines "high-bitrate streaming media over the Internet" like this:

  • "High-bitrate" is a context-sensitive term. It's meant to capture rates that can be sustained over some but not all of the target audience's connections 💅. For a snapshot of what counts as high-bitrate on today's Internet, check the higher-value entries in Section 3.1.1.
  • "Streaming" means the continuous transmission of media segments from a server to a client, while the client consumes them at the same time 🌊. The word "simultaneous" is the key bit: if you download a whole media file and then play it, that's not streaming. That's "download and play" 🙈.
    • This has two implications. First, the sending rate has to match the client's consumption rate (loosely or tightly) so playback stays smooth ✨. The client must not run out of media segments (buffer underrun), and it must not accept more than it can buffer before playback (buffer overrun) 😭.
    • Second, the client's consumption rate is limited not just by the path's available bandwidth but also by segment availability. The client can't fetch segments the media server can't provide (yet) ⏳.
  • "Media" covers any type of media and its associated streams, like video, audio, metadata, and so on 🎶.
  • "Over the Internet" means no single operator controls the whole path between media servers and clients, so it's not a "walled garden" 🌐.

This doc 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. It's also called a streaming media server, or just a server 🖥️

Intermediary: an entity that sits 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 let it decrypt the media in order to be media aware. 🔐 That's a big deal, bestie!

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. It's also called a streaming media client, or simply a client 🎧

Ultimate Media Consumer: a human or machine using a media player 🍿

Part 1 of 10 is done, so more is coming! Stay tuned, besties 💜🌈

1.2. Document Scope 🧭

Okay so, a FULL review of every streaming media consideration, for every kind of media, over every kind of network path? Bestie, that's way too big for one doc 😭 It would be a whole library. So this one focuses mainly on large-scale delivery of streaming high-bitrate media to end users 🎬 It's mostly for people controlling the endpoints that deliver streaming traffic: origin servers publishing content, intermediaries like content delivery networks (CDNs), and providers for client devices and media players 💖

Most of the stuff here applies to both "live media" (created and streamed while an event is happening) and "media on demand" (already-recorded media streamed from storage), unless we say otherwise ✨

Most of it also applies to media a media player shows to a human, AND media a machine consumes, like a media recorder running an adaptive bitrate (ABR) streaming algorithm 🤖 Unless noted, obviously.

So what's actually in here? 👀

  • a quick vibe check on streaming video characteristics in Section 2 to set the stage 🎀
  • bandwidth provisioning (Section 3) and latency considerations (Section 4) for streaming media delivery 💸⏱️
  • adaptive encoding and adaptive delivery techniques in common use for streaming video (Section 5), plus the struggle media senders have detecting the bitrate available between sender and receiver, plus a collection of third-party measurements for analytics 📊
  • existing transport protocols used for media streaming and the issues people run into with them (Section 6), plus the QUIC transport protocol [RFC9000], which is more recently used for streaming 🚀
  • what happens when you stream encrypted media (Section 7) 🔐
  • a pointer to extra reading on this rapidly changing subject (Section 8) 📚

Now the stuff that's OUT of scope, tho 🙅‍♀️

  • an in-depth look at real-time, two-way interactive media, like videoconferencing. This doc touches on it lightly, but for real depth you should look elsewhere, because the techniques and issues for interactive real-time two-way media are sooo different from large-scale, one-way streaming 💅
  • specific operational practice recommendations for mitigating issues. Some known mitigations get mentioned in passing, but the main goal is a reference point for future solution proposals, showing how new technologies address or avoid existing problems 🧠
  • generalized network performance techniques. Things like data center design, transit network design, and "walled garden" optimizations can be crucial for a performant streaming service, but they're independent topics better addressed by other documents 🏗️
  • transparent tunnels. Tunnels can affect streaming through things like round-trip time and the maximum transmission unit (MTU) of packets carried over them, but for this doc those issues count as part of the set of network path properties 🚇

Okay, WebRTC 🎙️ People keep asking if this doc covers "Web Real-Time Communication (WebRTC)". It does not 🙅‍♀️ WebRTC's principal media transport protocol [RFC8834] [RFC8835], the Real-time Transport Protocol (RTP), is mentioned here. But as Section 2 explains, it's hard 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 keep growing (Appendix D of [CVNI]).

A big chunk of this growth comes from streaming video 🍿 But video traffic in real-time communications (for example, online videoconferencing) has also grown a lot 😭 Both streaming video and videoconferencing have real-time delivery and latency requirements, but those requirements vary from one application to another. For more on latency requirements, check Section 4 🫶

In lots of contexts, media traffic can be handled transparently as generic application-level traffic 🤷‍♀️ However, as the volume of media traffic keeps growing, it's becoming super important to think about how network design decisions affect application-level performance, including the impact on media delivery 💜

Much of this doc focuses on media streaming over HTTP 🌸 HTTP is widely used for streaming because:

  • support for HTTP is widely available across 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's hard 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 a LOT of variables, including resolution (height and width), frame rate, color depth, codec, encoding parameters, scene complexity, and amount of motion 🤯 Generally speaking, as resolution, frame rate, color depth, scene complexity, and amount of motion go up, the encoding bitrate goes up too 📈 As newer codecs with better compression tools get used, the encoding bitrate goes down 📉 Similarly, multi-pass encoding generally produces better quality output than 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 has no idea what network paths and network path conditions will carry the encoded video at some point in the future 🙈 It's 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 give the user a single, fixed point of view. So the user has no "degrees of freedom", and sees all of the video image that's available 👀

Even basic virtual reality (360-degree) videos that let users look around freely (called "three degrees of freedom" or 3DoF) need substantially bigger bitrates when captured and encoded, since these videos need multiple fields of view of the scene 😭 BUT, thanks to smart delivery methods like viewport-based or tile-based streaming, there's no need to send the whole scene to the user 🧠✨ Instead, the user only needs the portion that matches their 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 🚀 Here, immersive content is typically called volumetric media 🧊 One way to represent volumetric media is with 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

okay so even when we totally know how much bandwidth the media streams need 💖, we still have to dig into the constraints on bandwidth at different points along the path between media servers and media players 🛣️. Media streams can hit bottlenecks all over the place, whether the bottleneck sits at a node or on a path segment 🦋. And these bottlenecks can come from 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 zero coordination between themselves 💀. Each one is unaware of what the other is doing, 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 running in user space. They rely on a general-purpose operating system that typically has its transport protocols implemented in the operating system kernel, so the kernel makes decisions 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 keeps sending 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. So the transport protocol can't 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 do that 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 lots of reasons why path characteristics might change during 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 help with that recognition can be more or less sophisticated, and they 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, you multiply the bitrate demands by the number of simultaneous users to find the bandwidth requirements for a delivery path with that many users downstream 🧮. For example, at a node with 10,000 downstream users all streaming video at once, approximately 80 Gbps might be necessary for all of them to get typical content at 1080p resolution 😱.

However, when there's some overlap in the feeds end users are consuming, it's sometimes possible to reduce the bandwidth provisioning requirements for the network by doing 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 so they can 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 balances against the costs of tracking stale content in caches and refreshing that content 🧐.

It's 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 drops. This content may be largely stable, which makes it 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 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. In other cases, it's more difficult (Section 3.6) 😬.

With the emergence of ultra-low-latency streaming, responses have to start streaming to the end user while they're still being transmitted to the cache, and while the cache doesn't 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 the objects being stored. So the change in design requirements in these 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 higher bitrate than they were in the past 📈. Improvements in codecs that reduce encoding bitrates with better compression algorithms haven't offset the increase in demand for higher quality video. That includes higher resolution, higher frame rate, better color gamut, better dynamic range, and so on 🌟. In particular, mobile data usage in cellular access networks has jumped a lot over the years due to increased consumption of entertainment and conversational video 📲💜.

3.6. Unpredictable Usage Profiles

Usage profiles can also change significantly and suddenly 🌪️. These changes are harder 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 🌸

Okay so, bestie, this first example comes from "Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008" [RFC5594] 📚. When BitTorrent file sharing blew up in widespread use in 2005, there was sudden and unexpected growth in peer-to-peer traffic 📈. ISP customers started complaining that their delay-sensitive stuff was lagging, like Voice over IP (VoIP) and gaming 😭. Two things were causing this, and I'm obsessed with how they stack up 💅:

  • Lots of access networks for end users use technologies that are inherently asymmetric, favoring downstream bandwidth (e.g., ADSL, cellular technologies, and most IEEE 802.11 variants) 🙈. They were built on the assumption that most users need way more downstream than upstream bandwidth. That's a solid assumption for client-server apps like 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 🔄. Those symmetric profiles clashed hard with the asymmetric access networks 💀.
  • Some P2P systems 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 this application-level ring and the lower-level network topology, so a peer's "next peer" could be literally anywhere on the reachable Internet 🌍. Traffic models that expected most communication to happen with a relatively small number of servers simply couldn't cope with peer-to-peer traffic that was way less predictable 🤯.

Especially as end users keep increasing their use of video-based social networking apps, 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 the resulting quarantines and shutdowns totally changed traffic patterns 😩. A huge number of people suddenly started working and attending school remotely, and used more interactive applications (e.g., videoconferencing and streaming media) 💻🎓. The Internet Architecture Board (IAB) then held a COVID-19 Network Impacts Workshop [RFC9075] in November 2020 🧠. Here are some observations from the workshop report that are honestly worth knowing 🫶:

  • 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 😱. That's a 15-20% surge in growth that landed at a new normal way higher than anyone expected 🚀.
  • At Deutscher Commercial Internet Exchange (DE-CIX) Frankfurt, the world's largest IXP in terms of data throughput, the year 2020 saw the largest increase in peak traffic within a single year since the IXP was founded in 1995 🏆.
  • The usage pattern changed a lot 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 the peak would have hit networks harder if it had happened during typical evening peak hours for streaming apps 🍿.
  • 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, physical link utilization increased 📶. This could probably be explained by a higher level of uncacheable traffic, such as videoconferencing and VPNs, from residential users who 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 ⏱️

Okay, latency time, and this part is so important 🫶. Streaming media latency is the "glass-to-glass" time duration, which is the delay between a real-life event happening and the streamed media actually playing on an end user's device 📱✨. This is different from network latency (defined as the time for a packet to cross a network from one end to another end) 🚚, because it also includes media encoding/decoding and buffering time, and, for most cases, 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 useful when thinking about a streaming media app'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 for this level of latency for live media events 🎪. It introduces new challenges compared to the other latency categories 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 hard 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 these effects, ultra-low-latency is potentially achievable with the right provisioning and the right media transport technologies 💅✨.

Most applications operating over IP networks that need 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 needed for safe operation in browsers 🔐.

It's worth noting that many applications for ultra-low-latency delivery don't 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 making playback more robust 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 apps 💜.

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 aimed at a user experience similar to broadcast TV delivery 📡. A frequently cited problem with failing to hit this level of latency for live sporting events is the awful experience of having crowds within earshot of one another who react audibly to an important play 📣, or of users who learn about an event in the match through some other channel, for example social media, before it has happened on the screen showing the sporting event 😭📱.

Applications that need low-latency live media delivery are generally feasible at scale with some restrictions 🌟. This typically requires a premium service dedicated to live media delivery, and some trade-offs may be necessary compared to what's 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 🌧️.

A low-latency live media service can be built with 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], which lets the media be packaged into and transmitted in units smaller than segments, 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, shorter segments mean more frequent intra-coded frames, and that is detrimental to video encoding quality 📉. The CMAF standard lets us 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 HTTP [CMAF-CTE], which lets the LL-DASH client 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 📼. It's often considered adequate for content like news 🗞️. It's also sometimes achieved as a fallback state when some part of the delivery system or the client-side players don't support low-latency live streaming 🛟.

This level of latency can typically be achieved at scale with commodity CDN services for HTTP(s) delivery 🌍. In some cases, the increased time window can allow for producing a wider range of encoding options relative to the requirements for a lower-latency service, without increasing the hardware footprint, which can allow for wider device interoperability 🌈✨.

4.4. On-Demand 🎬

okay so on-demand media streaming is the playback of pre-recorded media that kicks off because a user did something, like hitting play 🫶. sometimes on-demand media is basically a by-product of a live production: it reuses the same segments as the live event, but the manifest describing what the media server has available gets frozen once the live event is over 🧊. other times, on-demand content gets built out of pre-recorded assets, and no streaming has to be involved while that content is being produced 💅.

on-demand isn't really worried about latency 🙅‍♀️, but other timing stuff can matter just as much (or even more!) to the user experience than it does for live events 😭. we're talking startup time, keeping the playback quality stable, and avoiding stalls and other media artifacts during playback under pretty much everything except the most severe network conditions 💀.

some optimizations are available for on-demand media that aren't always available for live events 🧚, like preloading the first segment, so the startup time doesn't have to wait for a network download to begin ✨.

5. Adaptive Encoding, Adaptive Delivery, and Measurement Collection 🦋

this section covers one of the most famous ways to give users a good experience over a given network path 👑. but keep in mind that application-level mechanisms cannot give you a better experience than the underlying network path can actually support 🫠.

5.1. Overview 🧃

picture a simple model of media playback: you've got a media stream consumer, a buffer, and a transport mechanism that fills that buffer 🪣. the consumption rate is pretty 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 make sure the buffer is never empty 😤. it can also get really complicated once things like personalization or advertising insertion workflows show up 🌀.

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. it's all about balance, bestie ⚖️.

ABR uses an application-level response strategy 💖. the streaming client tries 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 ✨. it typically adjusts as changes in available bandwidth occur in the network, or as changes in capabilities occur during 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 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 🔄. it does this 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 🤝. teamwork makes the dream work 🥹.

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] 🧪. they often rely 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. they'll make use of player-side statistics, such as buffer fill rates, to monitor and respond to changing network conditions 👁️✨.

the choice of bitrate happens within the context of optimizing for one or more metrics monitored by the client 🎯. think of things like 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 super common in today's media landscape 💅.

some commonly used forms of advertising can introduce potential user experience issues for a media stream 😬. this section gives a very brief overview of a complex and rapidly evolving space 🌪️.

the same techniques used to let a media player 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 that doesn't mean inserting 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. in SSAI, the server stays the same during ads, but it 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 it is 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. it can be integrated with the video so 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 🏷️. bids for the advertising space come 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. that can make for a jarring user experience 🔊😖.

another major source of competing objectives comes from user privacy considerations versus 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 gives advertisers a strong incentive to gain access to the data needed to perform behavioral targeting 🚨. it has led 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 has historically had incidents of misreporting 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. these players 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. 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 often use rates as observed by the application layer, there are sometimes inscrutable transport-level protocol behaviors. these can produce surprising measurement values when the application-level feedback loop interacts 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 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 🚩. this is especially true 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 ✨

Okay bestie, when the bitrate selection is picked substantially below the available capacity of the network path 🫶, the response to a segment request will typically finish in way less absolute time than the duration of the requested segment. That leaves a lot of idle time between segment downloads 💤. This can have a few surprising consequences 👀:

  • TCP slow-start, when restarting after idle, needs 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, and an idle gap between segments triggers a restart of TCP slow-start, the estimate of the successful download speed from the application-visible receive rate on the socket can 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 with 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 high jitter in the goodput measurement 📉. It presents 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 they may also provide measurements to streaming media providers 🎀.

In turn, media providers may base analytics on these measurements to guide decisions. For example, they can figure out whether the 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. Honestly, 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. 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 the 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], are typically implemented in user space. That means they can evolve their transport behavior more rapidly than currently used transport protocols, which are typically implemented in operating system kernel space 🚀. So 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. 🦋

okay so the past success of the largely TCP-based Internet is honestly proof that the flow control and congestion control mechanisms TCP uses to reach 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

Okay bestie, so UDP doesn't give senders any feedback to help limit impacts on other users 😭. That means UDP-based application-level protocols have been responsible for the decisions that TCP-based applications 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 ✨

okay bestie, "encrypted media" can mean like three different things 🫶

  • Application-layer encryption: the media is encrypted by a DRM system or some other object encryption/security mechanism, and it usually stays encrypted when senders and receivers store it 🔐
  • End-to-end media encryption: the sender encrypts at the transport layer, and it stays encrypted until it reaches the ultimate media consumer 💖
  • Hop-by-hop media encryption: the sender encrypts at the transport layer, and it stays encrypted until it reaches some intermediary that is _not_ the ultimate media consumer but does have the credentials to decrypt. That intermediary can poke at the media and even transform it, then forward it re-encrypted 🦋

This doc is all about media encrypted at the transport layer, whether that's hop by hop or end to end 🎀 Application-layer encryption only gets processed by application-level entities, so it doesn't have transport-layer implications. BUT both hop-by-hop and end-to-end transport can also carry media that's encrypted at the application layer too, so you can stack them 🌈

Each strategy is trying to do something different. Application-level encryption might be for business stuff, like stopping piracy or enforcing geographic restrictions on playback 🌍. Transport-layer encryption might be used to stop media stream manipulation or to protect manifests 🧚

This document does not take a position on whether those goals are valid. Not our call, bestie 💅

Both end-to-end and hop-by-hop media encryption have specific implications for streaming operators. Those are covered in Sections 7.2 and 7.3 ✨

7.1. General Considerations for Streaming Media Encryption

Strong encryption gives confidentiality for encrypted streaming media, from the sender to either the ultimate media consumer or to an intermediary that has decryption credentials 🔒 This stops deep packet inspection (DPI) by any on-path intermediary that doesn't have those credentials. ngl, that's a big deal 😭

BUT even encrypted streams can be vulnerable to traffic analysis 💀 An on-path observer that spots an encrypted media stream can "fingerprint" it and then compare that fingerprint against "fingerprints" of known content. And the protection gets weaker if a streaming media operator keeps encrypting the same content over and over 🙈

"Identifying HTTPS-Protected Netflix Videos in Real-Time" [CODASPY17] is a real example of what's possible with HTTPS-protected videos over TCP transport. It works based on either the length of entire resources being transferred, or on characteristic packet patterns at the very beginning of a resource being transferred 👀 If traffic analysis can identify the encrypted content and link it to specific users, then the on-path observer knows what resource is being streamed and by who, almost as well as if they'd looked at the decrypted traffic. Iconic for the attacker, not for us 😤

Here's some history. HTTPS used to layer HTTP on top of TLS, which sits on top of TCP. So intermediaries historically had access to unencrypted TCP-level transport information, like retransmissions, and some carriers used that info to try to improve transport-layer performance [RFC3135] 🛰️

The most recent standardized version of HTTPS is HTTP/3 [RFC9114], and it uses the QUIC protocol [RFC9000] as its transport layer 🚀 QUIC only relies on the TLS 1.3 initial handshake [RFC8446] for key exchange [RFC9001], and it encrypts almost all transport parameters itself. The exceptions are a few invariant header fields. In the QUIC short header, the only transport-level parameter sent "in the clear" is the Destination Connection ID [RFC8999]. 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. So yeah, HTTP/3 is way more "opaque" than HTTPS with HTTP/1 or HTTP/2 🧊

[RFC9312] talks about the manageability of the QUIC transport protocol that's used to encapsulate HTTP/3. It focuses on how QUIC's design and wire image affect network operations involving QUIC traffic, and it goes into some detail about what network operators can consider 🧐

Zooming out a bit, "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 🌸

Also worth knowing: the considerations for heavily encrypted transport protocols come into play when streaming media is carried over IP-level VPNs and tunnels too 🎀 The extra twist is that an intermediary without decryption credentials won't be able to see the source and destination IP addresses of the packets being carried inside the tunnel. Main character encryption energy 🦋

7.2. Considerations for Hop-by-Hop Media Encryption

Hop-by-hop media encryption gives you the benefits from Section 7.1 between the streaming media operator and the authorized intermediaries 🫶 It also works among authorized intermediaries, and between authorized intermediaries and the ultimate media consumer. BUT it does not give those benefits end to end. The streaming media operator and the ultimate media consumer have to trust the authorized intermediaries. If those intermediaries can't be trusted, the benefits of encryption are gone 💔

The IETF has put a lot of focus on end-to-end streaming media encryption. Still, there are important use cases that require inserting intermediaries 🧚

There are lots of ways to involve intermediaries, and some are way more intrusive than others 👀

From a streaming media operator's point of view, a bunch of things are in play. The first question is probably whether the operator wants intermediaries to be explicitly addressed by the endpoints. Or is the operator okay with intermediaries "intercepting" streaming content transparently, with zero awareness or permission from either endpoint? 🕵️‍♀️

If a streaming media operator doesn't actively work to avoid interception by on-path intermediaries, the effect looks the same as "impersonation attacks" 😱 Endpoints can't be assured of any level of confidentiality, and they can't trust that the content they got actually came from the expected sender.

Now, if the operator does plan to let intermediaries take part in content streaming, and does want to provide some level of privacy for endpoints, there are a few tools to look at 🌈 Some are already available, and some are still being specified. These include the following:

  • Server and Network Assisted DASH [MPEG-DASH-SAND]: This specification adds explicit messaging between DASH clients and DASH-aware network elements, or among various DASH-aware network elements. The goal is to make streaming sessions more efficient by sharing info about real-time operational characteristics of networks, servers, proxies, caches, CDNs, and 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 SRTP that gives both hop-by-hop and end-to-end security guarantees 🔥
  • Secure Frames [SFRAME]: [RFC8723] is closely tied to SRTP, and that close association held back widespread deployment, because it couldn't be used for the most common media content delivery mechanisms 😩 The newer proposal, Secure Frames [SFRAME], also gives both hop-by-hop and end-to-end security guarantees, but it can be used with other media transport protocols beyond SRTP 🎀

Choosing whether to involve intermediaries takes some careful thought 🧠 Here's a good example. When ABR manifests were commonly sent unencrypted, some access network operators would modify the manifests during peak hours. They removed high-bitrate renditions so players couldn't choose them. That cut the overall bandwidth used to deliver these streams, which reduced network load and improved the average user experience for their customers 📉 But now that ubiquitous encryption typically prevents that kind of modification, a streaming media operator who used intermediaries in the past and still wants the same level of network health and user experience has to pick one of two paths. They can add intermediaries who are authorized to change the manifests, or they can add some other form of complexity to their service 🤷‍♀️

Some resources that might inform similar considerations are discussed further 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 gives you the benefits from Section 7.1 from the streaming media operator all the way to the ultimate media consumer 💜

End-to-end media encryption has become way more widespread since the IETF published "Pervasive Monitoring Is an Attack" [RFC7258] as a Best Current Practice 🙌 That document described pervasive monitoring as a much bigger threat than people had previously realized. After the Snowden disclosures, a lot of content providers decided to use HTTPS protection (HTTP over TLS) for most or all content as a routine practice, instead of only for the stuff they considered sensitive 🌟

BUT, as [RFC7258] notes, there's no way to stop pervasive monitoring by an attacker while still allowing monitoring by a more benign entity that only wants to use DPI to examine HTTP requests and responses in order to provide a better user experience 😤 If a modern encrypted transport protocol is used for end-to-end media encryption, unauthorized on-path intermediaries can't examine the transport and application protocol behavior. As Section 7.2 described, only an intermediary that the streaming media operator has explicitly authorized can examine packet payloads. Unauthorized interception and examination doesn't get to keep happening 🙅‍♀️

[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 🔮 The IETF is not slowing down on this one, bestie ✨

8. Additional Resources for Streaming Media

The Media Operations (MOPS) community keeps a list of references and resources 📖 If you want to keep reading, check out [MOPS-RESOURCES] 🧚

9. IANA Considerations

Good news, this document has no IANA actions 🎉 Nothing to register here, bestie 💅

10. Security Considerations

Security is a huge deal for streaming media applications 😭 The topic of media encryption was explained in Section 7, so go re-read that if you skipped it 🔐 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.

Okay bestie, we're in the reference list now 📚🎀 Here are the RFCs and drafts this one leans on, with every detail kept as-is:

Acknowledgments 🙏💖

Huge 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. 🫶 They're all literally iconic.

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
📦 where this page comes from