| Internet-Draft | MoQ Overview | May 2025 |
| Westerlund & Sarker | Expires 6 November 2025 | [Page] |
This document provides a high level overview of Media over QUIC protocol components, how interoperability is specified for particular use cases, and how things relate.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-westerlund-moq-overview/.¶
Discussion of this document takes place on the Media over QUIC (MOQ) Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/.¶
Source for this draft and an issue tracker can be found at https://github.com/https://github.com/gloinul/draft-westerlund-moq-overview.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 November 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Media over QUIC (MoQ) is an IETF Working Group (WG). Its output of set of specifications that is inteded to be useable to address use cases related to media delivery over the Internet, including low-latency delivery. This document provides a high level overview of how these components relates to each other and what is needed for a specific use case to define an interoperable media delivery solution.¶
The protocol work¶
The development of the MoQ components considers the following use cases and their main requirements. However, this may not prevent the MoQ protocol components to be used for other use cases than what is listed here.¶
In general the goal of the solution is enable ease of dynamic scaling of number of participanting endpoints and distributed cloud deployments. The solution only assumes existance of unicast IP transport between involved nodes.¶
Editors Note: Describe basic delivery chain.¶
Editor Note: This might be distributed mesh and end-to-end distribution of original publishers. Might be publish multiple track varaiants of a media, but if not enough resources, processing or bandwidth only one representation might exist.¶
Editors Note: Describe ingestion. Reflect on difference with Live Streaming media delivery. And the fact that streaming service transcoding is new original publisher of the different tracks representing the contributors media streams.¶
MoQ consists of several different components, which allows the design of various applications. We provide below an overview of these components after discussing the involved type of nodes.¶
Consumer: An endpoint that want to consume (receive) one or more tracks from one or more track namespaces.¶
Publisher: An endpoint that can send a consumer one or more tracks for a given track namespace.¶
Original Publisher: The endpoint is the originator of one or more tracks for a particular track namespace.¶
Relay: An endpoint that is both a consumer and a publisher, but not an orignal publisher. The Relay acts between the orignal publisher and a consumer endpoint. Relays can also use another relay as publisher to enable scaling of the publisher nodes, as well as to handle geographical distribution of receivers to optimize performance.¶
Media over QUIC Transprot (MOQT) [I-D.ietf-moq-transport] is the protocol, which is used between a publisher and a consumer. The protocol supports a couple of different capabilities:¶
Subscribe: Request the publisher to forward media objects of a media track as they are created or received from upstream publisher. Subscribe is the support for any future distribution of media generated by a Publisher.¶
Fetch: Request the publisher to provide a specific range of media objects for a track that the publisher has previously received or stored.¶
Join-Fetch:¶
Announce: A publisher announces a track namespace, which is available for subscribe and fetch to the consumer.¶
Publish:¶
When the consumer is subscribed to a track, the publisher tries to forward all media objects of the track scheduling the transmission according to priorities on the different objects competing for available transport bitrates across all tracks the consumer is subscribed to.¶
MOQT uses either QUIC [RFC9000] or WebTransport [I-D.ietf-webtrans-overview] to transport its messages and media objects. These transport protocols also are used to provide hop-by-hop confidentiality and integrity.¶
MOQT is dependent on existing methods for authorization and authentication of the consumer and publisher to ensure that they have the right to either access a track or publish a track in this namespace. This mechanism has not yet been defined.¶
The media objects related to a track are delivered over either independent streams or using unreliable datagrams depending on what best suits the media and application when it comes to latency and reliability.¶
Note: Add something about what happens when there are insufficinet bandwidth.¶
The catalog is a media track, which carries essentially some textual information to enable the application to understand what track names exists in a track namespace. The catalog describes, for each track, some key properties such as peak bitrate and encoding format for video tracks. It can also carry information to relate one track to another track, for example lip synch.¶
A catalog is not necessary for all applications, as the application may have a fixed track name structure with known encodings and properties.¶
The WARP streaming format [I-D.ietf-moq-warp] defines one catalog format, which is specific to WARP. Yet, this catalog is expected to be the basis for other formats and to be extended for other applications. It is up to the application specifications to define which catalog format they use.¶
MoQT treats objects as opaque payloads. The transport protocol does not impose restrictions on the encoding format of these objects. Instead, interpretation of the object payload is left to the application, which must ensure compatibility with the decoding capabilities of the consumer endpoint.¶
Editors note: Update to clarify Media and other object formats.¶
To foster interoperability, the MoQ community has initiated standardization efforts around specific media formats. Currently, the primary supported format is the Low Overhead Container (LOC) [I-D.ietf-moq-loc], as defined by the WebCodecs API. LOC provides minimal packaging overhead and facilitates low-latency media transport, making it suitable for real-time applications such as live streaming and video conferencing.¶
The MoQ Media Interop (moq-mi) [I-D.cenzano-moq-media-interop] draft specifies a number of media formats for use with LOC, including: - Video H264 in AVCC - Audio Opus Bitstream - UTF-8 Text - Audio AAC-LC in MPEG4¶
Each of these media types is assigned a specific identifier and is accompanied by metadata header extensions to convey essential decoding parameters (e.g., timestamps, duration, and codec configuration).¶
While these formats represent the current scope of interoperable media, the MoQ community recognizes the wide adoption of CMAF (Common Media Application Format) in traditional streaming workflows. There is ongoing discussion around defining a MoQ media format based on CMAF, though no concrete proposal has been adopted as of now.¶
MOQT provides only hop-by-hop confidentiality and integrity protection. It has been expected that some applications want stronger security properties, like end-to-end confidentiality as well as source authentication. To meet these goals, [I-D.jennings-moq-secure-objects] proposes that each media object's payload is encapsualted in an SFRAME [RFC9605].¶
Keying and cipher negotiation is currently application specific.¶
One or more application sharing the same needs for how MoQ operates can define a interoperaiblity point. An interoperability point is defining which components and their versions that is need to be supported to be interoperable.¶
The WARP Streaming Format [I-D.ietf-moq-warp] is such an interoperability point that defines the following:¶
The media format is LOC and with additional requirements such that audio and video can be time aligned.¶
A Catalog format to describe the tracks.¶
That MOQT as defined in [I-D.ietf-moq-transport] is used for Media¶
transmission.¶
Describe how subscribers are intented to know about publisher (directly or via relays). ## Discovery ## Session setup ## Object metadata extension handling¶
Describe how relays are intregated to and initialized by the publisher. ## Discovery ## Session setup ## Object metadata extension handling¶
Editors Note: Describe both comsec and authorization, and privacy Describe example of how trust model for a streaming delivery service interacts with a CDN providing relay service. Original publisher to CDN ingress. Consumer learning connect-uri, verifying relay in TLS, sending authorization tokens to prove right to access. Relay's verification. Original publisher accepting subscribes/publish to CDN relay network.¶
The following persons have contributed text to this document:¶
Gwendal Simon¶