[Moq] Proposal to recharter to include non-media use cases.

["Law, Will" <[e-mail]>]

IETF Media over QUIC was chartered back in August 2022 with the goal of building a "low-latency media delivery solution for ingest and distribution of media." That framing reflected the use cases — live streaming, gaming, conferencing — that drove the original consensus to form the working group, and those remain central to what MoQ is for.

In the course of building MOQT to serve those use cases, the group has produced a publish/subscribe protocol that is, by design, payload-agnostic. Operational experience and external interest now show that the same protocol is well suited not only to low-latency media but also to medium- and high-latency media, database change streams, financial market data, sensor and vehicle telemetry, AR/VR input and output data, and model inference and agent interfaces, among other adjacent application spaces. The rigor that the real-time media use cases imposed on the design is what makes the protocol useful across this wider set of applications.

The current charter understandably did not anticipate this broader applicability, and as it stands it narrows the addressable use cases for a specification that already serves them. Importantly, expanding the charter requires no changes to MOQT itself and no compromise of its low-latency media capabilities — the mechanisms are already in place. The proposal is to update the charter to reflect what has been built and how it is being used, not to redirect the work.

In that spirit, I'd like to propose the following revised charter for the group's discussion:

—————————————————————————————————————————


Media over QUIC (moq) will develop a simple low-latency delivery solution for the ingest and distribution of real-time data. The working group's foundational use cases are in media — including live streaming, gaming, and media conferencing — and these remain central to the work. Because the protocol is payload-agnostic by design, however, it is also applicable to a broader class of latency-sensitive applications, and the working group's deliverables will be specified so as to serve them. These broader use cases include, but are not limited to:

  *
​input, output, and streaming interfaces for AI inference, agentic systems, and other ML workloads.
  *
sensor and telemetry data ingest and distribution, including industrial IoT and vehicle telemetry;
  *   command-and-control channels, such as flight control and operator links for uncrewed aerial vehicles (UAVs) and other robotics;
  *   financial market data distribution and related low-latency feeds;
  *
input, output and interactive data transmission for augmented and virtual reality (AR/VR) and other immersive applications;

The name "Media over QUIC" reflects the working group's origins and the centrality of media to its initial deliverables; the protocol mechanisms developed by the group are intended to apply equally to the non-media use cases listed above. The solution will scale efficiently and will be implementable in both browser and non-browser endpoints.

The work focuses on building protocol mechanisms for the publication of data objects and the means to identify and receive them. The common publication protocol will support:

  *   one or more payload formats, including media formats and non-media payload types;
  *   an interoperable way to indicate the type and format of the data being sent;
  *   rate adaptation strategies based on changing encoding rates, changing chosen encodings or representations, or other mechanisms;
  *   cache- and relay-friendly delivery semantics.

The mechanism to name and receive data will enable:

  *   requesting that the server begin sending data relative to a given point in the stream (for example, the latest object, a specific position, or a relative offset);
  *   selection of a desired representation, such as choosing language, bit rate, sensor channel, region of interest, or other application-defined dimensions.

Data will be mapped onto underlying QUIC mechanisms (QUIC streams and/or QUIC datagrams) and can be used over raw QUIC or WebTransport.

The proposed solution will provide extensibility for supporting different payload types and encodings. This includes media — audio, video, and timed metadata such as closed captions and cue points — as well as non-media payloads such as telemetry samples, control messages, market data ticks, AR/VR input and pose events, and AI prompts, responses, and intermediate tokens.

The working group will define MoQ so that the publication protocol can leverage coordinating relays, caches, or replication points wherever applicable to improve delivery performance and scale, regardless of payload type.

The solution will specify a simple method for clients to authenticate to the relay or server to transmit or receive data. Data will be encrypted at the transport layer using the standard QUIC mechanisms. Application payloads may be end-to-end encrypted in certain use cases, where the "end-to-end" keys are available to producers and consumers but not to relays. Even when payloads are end-to-end encrypted, relays can access metadata needed for caching (such as timestamps or object identifiers), for making forwarding decisions (such as drop or delay under congestion), and so on. Such metadata will be authenticated and integrity-protected end-to-end. Mechanisms for establishing keys for these end-to-end protections are outside the scope of this group.

This working group will not propose changes to the underlying QUIC transport, but may propose requirements for QUIC extensions to the QUIC WG. This working group will not define signaling mechanisms for discovery of relays, producers, or consumers. It will also not define application-layer schemas or semantics for specific non-media payload types (for example, telemetry data models, drone command sets, market data formats, AR/VR input schemas, or AI message formats); those are expected to be defined by the relevant application or industry communities, potentially in other IETF working groups or external standards bodies, and carried as opaque payloads by MoQ.

This working group will coordinate with the QUIC, WebTransport, and MOPS working groups as needed. It will liaise with MPEG Systems WG, DASH Industry Forum, and W3C WebTransport as appropriate. As the work develops, the group may engage with additional communities whose use cases motivate or exercise the protocol, including those working on industrial IoT and telemetry, financial data distribution, immersive media (e.g., MPEG-I), and AI/ML systems.

--------------------------------------------------------------------------------------------------


Cheers
Will




---------------------------------------------------------
Chief Architect - Cloud Technology Group
Akamai Technologies
Switzerland
Mobile [phone]