]> Cisco

snandaku@cisco.com

Cisco

fluffy@cisco.com

Applications and Real-Time Media Over QUIC MOQT QMux TCP fallback media streaming This document specifies how Media over QUIC Transport (MOQT) can operate over QMux, enabling MOQT applications to function over reliable byte-oriented streams such as TCP with TLS. By utilizing QMux as an intermediate layer, MOQT deployments gain the ability to fall back to TCP-based transport when UDP is blocked or unreliable, while maintaining API compatibility with QUIC-native implementations. This document analyzes the benefits and trade-offs of this approach and provides implementation guidance for deploying MOQT over QMux. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Media over QUIC Transport (MOQT) is designed to leverage QUIC's advanced features for efficient media delivery, including stream multiplexing, low-latency connection establishment, and built-in encryption. However, real-world deployments face challenges where UDP traffic may be blocked, rate-limited, or unreliable due to middlebox interference, enterprise firewalls, or network policies. QMux addresses this challenge by providing a "polyfill" that enables QUIC-based applications to operate over reliable, bidirectional byte-oriented streams such as TLS over TCP. QMux preserves QUIC's multiplexing semantics while delegating reliability and encryption to the underlying transport. This document specifies how MOQT can utilize QMux as an alternative transport substrate, enabling:

• Fallback capability when QUIC/UDP is unavailable
• Single codebase for both QUIC and TCP deployments
• Broader network compatibility for media streaming applications
• Graceful degradation in restrictive network environments

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Architecture Overview

Protocol Stack When MOQT operates over QMux, the protocol stack is organized as follows:

MOQT over QMux Protocol Stack

Transport Selection Implementations supporting both native QUIC and QMux transports SHOULD implement transport selection logic to choose the optimal path:

Transport Selection Flow

Happy Eyeballs for MOQT Implementations MAY use a Happy Eyeballs-style algorithm to race QUIC and QMux connections simultaneously:

1. Initiate QUIC connection attempt
2. After a short delay (e.g., 100ms), initiate QMux connection in parallel
3. Use the first connection that succeeds
4. Cancel remaining connection attempts

This approach minimizes connection latency while preferring QUIC when available.

Connection Establishment

QMux Handshake When establishing MOQT over QMux, the connection sequence is:

Connection Establishment Sequence

ALPN Identification MOQT over QMux uses the same protocol identification as native MOQT over QUIC, as defined in . This document does not define a new ALPN protocol identifier. For TLS connections carrying QMux, implementations MUST use the MOQT ALPN value corresponding to the MOQT version in use:

• For the final specification: moqt
• For draft versions: moqt-XX where XX is the draft number (e.g., moqt-16 for draft-ietf-moq-transport-16)

When MOQT operates over WebTransport , the WT-Available-Protocols mechanism is used instead of ALPN, following the same version identification scheme. The underlying transport (native QUIC vs QMux over TCP) is distinguished by the connection type itself, not by the ALPN value. This allows:

• Consistent version negotiation across all transport substrates
• Simplified client implementation with a single MOQT version identifier
• Seamless fallback from QUIC to QMux without protocol identifier changes

QMux Transport Parameters QMux inherits transport parameters from QUIC v1 , which does not specify default values for most parameters (absent parameters default to 0, disabling the corresponding feature). The only exception is max_frame_size, which QMux defines with an initial value of 16384 bytes. The following transport parameter values are RECOMMENDED for MOQT deployments over QMux. These values are chosen to support typical media streaming workloads and are not mandated by either QMux or QUIC v1:

Parameter	Recommended Value	Rationale
max_idle_timeout	30000 ms	Common QUIC implementation default; balances resource cleanup with connection stability
initial_max_data	1048576	1 MiB; sufficient for buffering multiple media objects at connection level
initial_max_stream_data_bidi_local	262144	256 KiB; adequate per-stream buffer for control messages
initial_max_stream_data_bidi_remote	262144	256 KiB; symmetric with local for bidirectional streams
initial_max_streams_bidi	100	Supports concurrent request-response patterns
initial_max_streams_uni	100	Supports multi-track media delivery (audio, video, multiple qualities)
max_frame_size	16384	QMux initial value; matches HTTP/2 default MAX_FRAME_SIZE

Implementations MAY adjust these values based on deployment requirements, expected media bitrates, and network conditions.

MOQT Mapping to QMux

Stream Mapping MOQT streams map directly to QMux streams. The stream semantics are preserved, with QMux providing the multiplexing layer:

MOQT Stream Type	QMux Stream Type	Purpose
Control Stream	Bidirectional Stream 0	SETUP, SUBSCRIBE, PUBLISH messages
Data Streams	Unidirectional Streams	Object delivery
Request Streams	Bidirectional Streams	Request-response patterns

Control Stream The MOQT control stream MUST use QMux bidirectional stream ID 0. All MOQT control messages (CLIENT_SETUP, SERVER_SETUP, SUBSCRIBE, PUBLISH, etc.) are exchanged on this stream.

Object Delivery MOQT objects are delivered over QMux unidirectional streams following the same patterns as native QUIC:

MOQT Object over QMux Stream

Flow Control QMux provides flow control at both connection and stream levels, mapping to MOQT's requirements:

• Connection-level: MAX_DATA frames limit total data across all streams
• Stream-level: MAX_STREAM_DATA frames limit per-stream data
• Stream count: MAX_STREAMS frames limit concurrent streams

MOQT implementations MUST respect QMux flow control signals and implement appropriate backpressure mechanisms.

Benefits of MOQT over QMux

Universal Network Accessibility The primary benefit of MOQT over QMux is network accessibility:

• Firewall Traversal: TCP port 443 is rarely blocked, unlike UDP
• Middlebox Compatibility: TCP/TLS is well-understood by NATs, proxies, and load balancers
• Enterprise Networks: Many corporate networks restrict UDP traffic
• Mobile Networks: Some carriers rate-limit or block UDP

Code Consolidation QMux enables a single MOQT implementation to serve both transport paths:

Unified Implementation Architecture

This architecture provides:

• Reduced development and maintenance effort
• Consistent behavior across transport paths
• Simplified testing and certification
• Single API surface for applications

Existing Infrastructure Leverage MOQT over QMux can utilize existing TCP/TLS infrastructure:

• Load Balancers: Standard L4/L7 load balancers work with TCP
• TLS Termination: Hardware TLS accelerators can be used
• CDN Integration: Existing TCP-based CDNs can front MOQT traffic
• Monitoring Tools: TCP traffic analysis tools apply unchanged

0-RTT Connection Resumption When operating over TLS 1.3, MOQT/QMux supports 0-RTT session resumption:

0-RTT Connection Resumption

Note: 0-RTT data is subject to replay attack considerations per . Implementations MUST follow TLS 1.3 guidance on 0-RTT security.

Trade-offs and Limitations Operating MOQT over QMux involves several trade-offs compared to native QUIC:

• Head-of-Line Blocking: TCP packet loss blocks all multiplexed streams until retransmission completes, unlike QUIC where streams are independent. This impacts live streaming, multi-track media, and interactive applications. Mitigation strategies include priority-based multiplexing, reduced buffering, and application-level adaptation.
• No Connection Migration: QUIC's seamless IP address change and mobile handoff capabilities are unavailable. Applications requiring mobility support should prefer native QUIC or implement application-layer session resumption.
• Additional Latency: Initial connection adds 1-2 RTT overhead due to TCP and TLS handshakes. Packet loss recovery is also slower with connection-wide rather than per-stream congestion response.
• Unreliable Datagram Limitations: True unreliable delivery is impossible over TCP. Applications requiring unreliable datagrams (e.g., low-latency audio with acceptable loss) should use native QUIC.
• Computational Overhead: QMux adds frame encoding/decoding, stream state management, and flow control processing, though this is typically small compared to TLS and application-layer processing.

Implementation Considerations Implementations SHOULD minimize buffering by keeping TCP send buffers appropriately sized and reacting promptly to flow control signals. MOQT priority semantics SHOULD be preserved by mapping Publisher Priority values to QMux stream scheduling, servicing higher-priority streams first. QMux connection errors such as CONNECTION_CLOSE terminate the MOQT session, while STREAM_RESET cancels the affected track or subscription. Implementations supporting both transports MUST ensure identical MOQT behavior, consistent object delivery semantics, and equivalent authentication regardless of the underlying transport.

Security Considerations TODO

IANA Considerations TODO

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Informative References Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.

Acknowledgments The authors would like to thank the IETF MOQT working group for their ongoing work on media transport protocols, and the authors of the QMux specification for enabling QUIC applications to operate over TCP.