The fragmented state of real-time streaming

For more than two decades, real-time communication on the Internet has been built on a patchwork of specialized protocols. RTMP handles ingest. HLS and DASH deliver scale. WebRTC provides interactivity. Each solved the problem of its era, but stitching them together in 2025 means juggling incompatible tools with different assumptions about transport, latency, and state.

The compromises are visible everywhere. Streaming platforms face a three-way tension between latency, scale, and operational complexity. Live auctions need sub-second delivery. Massive interactive events need broadcast reach. Developers are forced to pick which of those requirements to sacrifice.

Cloudflare is now launching the first Media over QUIC (MoQ) relay network across its 330+ city footprint. MoQ is an open protocol under development at the IETF—not a proprietary technology—and Cloudflare joins Meta, Google, Cisco, and others building interoperable implementations.

How we got here: A history of trade-offs

The current fragmentation is the product of successive architectural compromises, each solving one problem while creating another.

The RTMP era: Low latency, poor scale

In the early 2000s, RTMP (Real-Time Messaging Protocol) broke new ground by replacing the "download and wait" model of web video with a persistent, stateful TCP connection between a Flash client and a server. That enabled 2-5 second latency and powered the first wave of live platforms like Justin.tv, which later became Twitch.

But the stateful connection that made RTMP fast also made it hard to scale. Every viewer required a maintained connection to specialized media servers. Commodity HTTP-based CDNs couldn't be used, and because RTMP ran over TCP, a single lost packet stalled the entire stream—the head-of-line blocking problem. The industry kept RTMP for the "first mile" of ingest but needed another solution for delivery to viewers.

The HLS and DASH era: Scale at the cost of latency

When the iPhone rejected Flash, Apple created HLS (HTTP Live Streaming). HLS and its open counterpart MPEG-DASH treated video as a sequence of small static files delivered over standard HTTP. That shift to a stateless, interoperable transport meant any web server or CDN could distribute content, enabling platforms to reach millions of viewers reliably and cheaply.

The trade-off was baked-in latency. Players had to buffer at least three segments before starting, and with 6-10 second segment durations, that meant 15-30 seconds of delay. Low-Latency HLS extensions have since pushed this toward 3 seconds, but they work against the protocol's fundamental design—introducing stateful, real-time communication mechanisms like held-open playlist requests that complicate HTTP's stateless request-response model.

The WebRTC era: Interactivity without broadcast scale

WebRTC solved a different problem: plugin-free, two-way conversational video with sub-500ms latency in the browser. It achieved this through direct peer-to-peer media paths that bypassed central servers.

That P2P model collapses at broadcast scale. In a mesh network, connections grow quadratically with each participant—the N-squared problem. The industry responded with server-based topologies like Selective Forwarding Units (SFUs) and Multipoint Control Units (MCUs), but these amount to building a private, stateful, real-time CDN. It's expensive, complex, and not standardized across infrastructure providers.

What MoQ changes

MoQ is designed to resolve this trilemma rather than add another compromise. It targets sub-second latency at broadcast scale, a single protocol for ingest, distribution, and interactive use, and a transport that avoids TCP's head-of-line blocking by building on QUIC.

The protocol started with a "Media" focus, but the working group now calls it simply "MoQ." The core abstraction—named tracks of timed, ordered, independent data—turns out to be generic enough for any real-time data fanout or pub/sub system, from high-bandwidth audio and video to low-bandwidth sports score updates.

The MoQ protocol stack

MoQ's design solves problems at distinct layers. Building on QUIC addresses transport issues that have plagued streaming for decades:

  • No head-of-line blocking: QUIC streams are independent, so a lost packet on one stream doesn't block another. A dropped audio packet won't stall the video track.
  • Connection migration: Switching from Wi-Fi to cellular mid-stream doesn't interrupt the session.
  • Fast connection establishment: QUIC's 0-RTT resumption lets returning viewers start playback immediately.
  • Mandatory encryption: All QUIC connections are encrypted by default with TLS 1.3.

Pub/sub for media

MoQ's key innovation is treating media as subscribable tracks in a publish/subscribe system. Publishers announce named tracks; subscribers request them by name. A relay network handles distribution without parsing or understanding the media itself.

Data is organized in three levels:

  • Tracks: Named streams like "video-1080p" or "audio-english."
  • Groups: Independently decodable chunks of a track. For video, this typically aligns with a GOP starting at a keyframe, so new subscribers can join at group boundaries.
  • Objects: The actual packets on the wire, each belonging to a track with a position within a group.

Network components

MoQ's network roles are similarly straightforward:

  • Publishers: Announce track namespaces and send objects.
  • Subscribers: Request specific tracks by name.
  • Relays: Forward immutable objects upstream and downstream without transcoding.

A relay acts as both subscriber (receiving from upstream) and publisher (forwarding downstream). One upstream subscription can fan out to thousands of viewers.

Three distinct layers

MoQ's architecture separates concerns cleanly:

  1. Transport foundation (QUIC or WebTransport): MoQT runs directly over raw QUIC for native applications, or over WebTransport in browsers. The WebTransport protocol and W3C API make QUIC's multiplexed reliable streams and unreliable datagrams accessible to browser applications. Protocols like SRT may be efficient but lack native browser support, relegating them to ingest-only roles.
  2. MoQT layer: This provides the signaling and structure for the pub/sub system—the core focus of the IETF working group. It defines control messages like ANNOUNCE and SUBSCRIBE, plus the basic data model. MoQT doesn't know whether it's carrying H.264 video, Opus audio, or game state.
  3. Streaming format layer: Media-specific logic—manifests, codec metadata, packaging rules—lives here. WARP is being developed alongside MoQT at the IETF, but the layered design leaves room for others. A standards body like DASH-IF could define a CMAF-based format, and a company controlling both publisher and subscriber could experiment with a proprietary format for new codecs.

How media flows through the network

A typical broadcast flow relies on ANNOUNCE and SUBSCRIBE messages to establish a data path:

  1. Initiation: The publisher connects to its nearest relay (Relay A) and the end subscriber connects to its own local relay (Relay B). Both perform a SETUP handshake to establish a MoQ session.
  2. Announcement: The publisher sends an ANNOUNCE message to Relay A, declaring itself the source for a track namespace. Relay A registers this in a shared control plane.
  3. Subscription: The end subscriber sends a SUBSCRIBE message to Relay B, requesting a specific track name within a namespace.
  4. Relay connection: Relay B queries the control plane, discovers Relay A is the source, establishes a session if needed, and forwards the subscription upstream.
  5. Forwarding: Relay A passes the subscription to the publisher. Objects then flow from publisher to Relay A to Relay B to the end subscriber. If another subscriber on Relay B requests the same track, Relay B serves it from the existing upstream subscription.

Newer drafts also define a push-based PUBLISH model. A publisher sends a PUBLISH message and the relay responds with PUBLISH_OK if it will accept the objects. This suits ingest scenarios where the publisher wants media available at the network edge before the first subscriber connects.

Prioritization under congestion

MoQ handles congested networks through Subgroups—subdivisions within a Group that map directly to underlying QUIC streams. Objects in the same Subgroup share a stream, guaranteeing delivery order. Lower-numbered Subgroups have higher priority within a Group.

This enables intelligent degradation with layered codecs like SVC:

  • Subgroup 0: Base video layer (360p), must deliver.
  • Subgroup 1: Enhancement to 720p, delivered if bandwidth allows.
  • Subgroup 2: Enhancement to 1080p, first dropped under congestion.

When a relay detects congestion, it drops objects from higher-numbered Subgroups, so viewers see reduced quality instead of buffering. The specification also defines a scheduling algorithm that prioritizes ready-to-send objects by group order first, then subgroup ID. Descent group ordering can help lagging viewers catch up to the live edge by prioritizing the newest group. The optimal strategies for specific use cases remain an open research question.

Implementation at Cloudflare

Building one of the first global MoQ relay networks required connecting the protocol's abstract concepts to Cloudflare's edge stack. The "shared control plane" used for routing subscriptions is implemented on Durable Objects. When a publisher announces a namespace to a relay in London, that relay uses a Durable Object—Cloudflare's strongly consistent, single-threaded storage—to record the namespace's availability at that location. A subscriber in Paris querying the network can find the nearest source and route the SUBSCRIBE request accordingly.

The current relay implementation targets a subset of the features in draft-ietf-moq-transport-07, which became a de facto interop target across several open-source projects. Building against an evolving open specification meant accepting a moving target; pausing at version 07 let the team focus on deploying the network itself.