Summary of S4-260101: pCR on QUIC-based media delivery protocols

Document Overview

This contribution addresses one of the key objectives of the FS_Q4RTC_MED study item (approved in SA#110) by identifying and documenting existing and emerging QUIC-based media delivery protocols suitable for real-time communication. The document provides a comprehensive technical analysis of three IETF-developed protocols: MOQT, RTP over QUIC (ROQ), and WebTransport.

Background on QUIC

The document establishes the foundation by describing QUIC as a user-space UDP-based transport protocol with:
- Built-in TLS 1.3 encryption
- Connection migration support
- Stream multiplexing
- Pluggable congestion control
- Optional unreliable datagrams (RFC 9221)

Key motivations for using QUIC for media transport include:
- Lower latency: 1-RTT handshake with optional 0-RTT resumption
- Independent stream processing: Eliminates head-of-line blocking across streams
- Selective reliability and prioritization: Mix of reliable streams and unreliable datagrams
- Always-on security: Built-in TLS 1.3
- Better mobility: Connection migration without call drops

Media over QUIC Transport (MOQT)

Protocol Overview

• Binary data transport protocol under development by IETF MOQ WG since 2023
• Runs directly over QUIC or via WebTransport
• Companion specifications include Low Overhead Media Container (LOC) and MOQT Streaming Format (MSF)

Key Technical Features

Object-based Data Model

• Content organized as Objects within named Tracks
• Objects grouped into Groups and Subgroups
• Tracks referenced by numeric Track Alias
• Groups typically aligned with codec synchronization points (e.g., GOP boundaries)
• Group boundaries serve as random access points

Publish/Subscribe Architecture

• Publishers: Handle subscriptions and send requested Objects
• Subscribers: Subscribe to and receive tracks
• Relays: Cache and route content, acting as intermediaries for scalable distribution

Key control messages:
- SUBSCRIBE: Requests newly published Objects
- FETCH: Retrieves Objects from the past
- SUBSCRIBE_NAMESPACE: Discovers publishers for a given namespace
- PUBLISH and PUBLISH_NAMESPACE: Advertise available tracks

Data Transport Mechanisms

• Objects transmitted via QUIC streams (reliable, ordered) or DATAGRAM frames (unreliable, unordered)
• Forwarding Preference per Object specifies delivery method
• Subgroups enable grouping of mutually dependent Objects on single QUIC stream
• Stream types: SUBGROUP_HEADER, FETCH_HEADER, control stream with CLIENT_SETUP
• OBJECT_DATAGRAM message for datagram-based delivery

Relay Behavior

• Support both fan-in (multiple publishers) and fan-out (many subscribers)
• Function as policy enforcement points
• Can cache recent Objects for reduced load and quicker late joins
• Terminate QUIC sessions with visibility into Object metadata via Extension Headers
• Object payload treated as opaque (no modification allowed)

Benefits

• Leverages QUIC features (independent streams, prioritization, security, mobility)
• Convergence to single protocol simplifies workflows and infrastructure
• Scalable publish-subscribe architecture
• Potentially reduced session setup delay vs. WebRTC
• MOQT relays can integrate with 5G UPF for network optimizations (e.g., PDU Set information parsing per TS 23.501)

Limitations

• Still evolving (IETF draft not finalized)
• Limited production implementations and operational experience
• Initial deployment costs
• Additional testing needed for scalability validation

Current Applications

Multiple open-source implementations identified:
- Google's production-ready implementation (quiche)
- Meta's experimental relay and encoder/player
- Ozyegin University's MOQT library (moqtail.dev)
- Cloudflare's implementation and relay network deployment
- Commercial integrations: Bitmovin web player, Vindral live streaming, Red5 (upcoming support)

RTP over QUIC (ROQ)

Protocol Overview

• Under development by IETF AVTCORE WG since 2022
• Minimal mapping for encapsulating RTP and RTCP packets within QUIC
• Uses flow identifiers for multiplexing multiple RTP/RTCP streams

Key Technical Features

Packet Mapping Options

Three approaches specified:
1. One RTP packet per QUIC stream (not recommended due to excessive overhead)
2. Multiple RTP packets per stream with in-stream framing (length-prefixed)
3. QUIC datagrams: One RTP/RTCP packet per DATAGRAM frame (only flow ID needed)

Selection depends on application needs and HoL blocking tolerance:
- Datagrams: Unordered, unreliable delivery, no HoL blocking
- Streams: Reliable, ordered delivery with explicit prioritization

RTCP Optimization

• Aims to minimize RTCP traffic by utilizing QUIC data
• QUIC acknowledgments can compute lost packet statistics

Signaling

• SDP Offer/Answer can be used for connection setup and media negotiation

Benefits

• Reuses established RTP payload formats, media semantics, timing, and A/V lip-sync
• Built-in authentication and encryption via QUIC/TLS 1.3 (no separate DTLS-SRTP)

Limitations

• Flow identifier overhead: 1-8 bytes per packet (typically 1 byte for ≤63 flows)
• Coordination needed between application-layer rate control (GCC, SCReAM) and QUIC transport-level congestion control
• No defined API for communication between rate control layers
• Not suitable for point-to-multipoint topologies (QUIC multicast not yet standardized)
• Limited ecosystem and industry adoption

Current Applications

Open-source implementations exist:
- TUM Go implementation
- BBC Gstreamer plugin
- Meetecho C library (imquic) supporting both ROQ and MOQT

No commercial deployments identified; further exploration FFS.

WebTransport

Protocol Overview

• Modern web API and protocol framework for secure, low-latency bidirectional communication
• IETF defines protocol framework with HTTP/2 and HTTP/3 mappings
• W3C specifies web API for browser-server data exchange
• Designed for Web security model (origin verification, TLS)

Key Technical Features

Transport Capabilities

• Utilizes QUIC for unidirectional and bidirectional streams (reliable, ordered)
• Supports unreliable delivery via QUIC datagrams
• API exposes readable/writable streams and datagrams

Session Establishment

• Over HTTP/3: Uses HTTP/3 CONNECT with :protocol=webtransport
• All data flows over QUIC streams/datagrams after session setup

Congestion Control

• API preference hints: "throughput" or "low-latency"
• Actual algorithms determined by user agent (not directly configurable)

Benefits

• Leverages QUIC benefits within standard web security model with browser support
• Simpler deployment vs. WebRTC DataChannels (no ICE/STUN/TURN)
• Minimal overhead: One-time HTTP/3 CONNECT for setup, typically 1-byte session ID per stream

Limitations

• Evolving browser support (no Safari support as of early 2026)
• Requires application-layer protocol for media delivery (custom format or MOQT)
• Exposes only high-level subset of QUIC features (intentional security model constraint)
• No full control over QUIC configuration

Current Applications

• MOQT can be layered on top of WebTransport
• Multiple open-source implementations: Google QUICHE, Rust WebTransport library

References Added

The document adds 18 new normative/informative references covering:
- IETF drafts for MOQT, ROQ, WebTransport, LOC, MSF, SDP for ROQ
- IETF RFCs for QUIC, RTP, SDP, HTTP/2, HTTP/3, QUIC datagrams
- W3C WebTransport specification
- Congestion control algorithms (GCC, SCReAM)
- 3GPP TS 23.501 for 5G system architecture