# 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