Media over QUIC Transport
draft-ietf-moq-transport-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Luke Curley , Kirill Pugin , Suhas Nandakumar , Victor Vasiliev , Ian Swett | ||
| Last updated | 2024-09-19 (Latest revision 2024-07-08) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-moq-transport-06
Media Over QUIC L. Curley
Internet-Draft Discord
Intended status: Standards Track K. Pugin
Expires: 23 March 2025 Meta
S. Nandakumar
Cisco
V. Vasiliev
I. Swett, Ed.
Google
19 September 2024
Media over QUIC Transport
draft-ietf-moq-transport-06
Abstract
This document defines the core behavior for Media over QUIC Transport
(MOQT), a media transport protocol designed to operate over QUIC and
WebTransport, which have similar functionality. MOQT allows a
producer of media to publish data and have it consumed via
subscription by a multiplicity of endpoints. It supports
intermediate content distribution networks and is designed for high
scale and low latency distribution.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://moq-
wg.github.io/moq-transport/draft-ietf-moq-transport.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-moq-transport/.
Discussion of this document takes place on the Media Over QUIC
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/moq-wg/moq-transport.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Curley, et al. Expires 23 March 2025 [Page 1]
Internet-Draft moq-transport September 2024
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 23 March 2025.
Copyright Notice
Copyright (c) 2024 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Latency . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2. Leveraging QUIC . . . . . . . . . . . . . . . . . . . 5
1.1.3. Universal . . . . . . . . . . . . . . . . . . . . . . 5
1.1.4. Relays . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 6
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 7
2. Object Model . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Objects . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Subgroups . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Groups . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Track . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Track Naming and Scopes . . . . . . . . . . . . . . . 10
2.4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.3. Connection URL . . . . . . . . . . . . . . . . . . . 11
3. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Session establishment . . . . . . . . . . . . . . . . . . 11
3.1.1. WebTransport . . . . . . . . . . . . . . . . . . . . 11
3.1.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 11
Curley, et al. Expires 23 March 2025 [Page 2]
Internet-Draft moq-transport September 2024
3.2. Version and Extension Negotiation . . . . . . . . . . . . 12
3.3. Session initialization . . . . . . . . . . . . . . . . . 12
3.4. Stream Cancellation . . . . . . . . . . . . . . . . . . . 13
3.5. Termination . . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Migration . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Priorities . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Subscriber Interactions . . . . . . . . . . . . . . . . . 17
5.1.1. Graceful Publisher Relay Switchover . . . . . . . . . 19
5.2. Publisher Interactions . . . . . . . . . . . . . . . . . 19
5.2.1. Graceful Publisher Network Switchover . . . . . . . . 20
5.2.2. Graceful Publisher Relay Switchover . . . . . . . . . 21
5.3. Relay Object Handling . . . . . . . . . . . . . . . . . . 21
6. Control Messages . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1. Version Specific Parameters . . . . . . . . . . . . . 25
6.2. CLIENT_SETUP and SERVER_SETUP . . . . . . . . . . . . . . 26
6.2.1. Versions . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2. Setup Parameters . . . . . . . . . . . . . . . . . . 27
6.3. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.1. Filter Types . . . . . . . . . . . . . . . . . . . . 28
6.4.2. SUBSCRIBE Format . . . . . . . . . . . . . . . . . . 29
6.5. SUBSCRIBE_UPDATE . . . . . . . . . . . . . . . . . . . . 31
6.6. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 32
6.7. ANNOUNCE_OK . . . . . . . . . . . . . . . . . . . . . . . 32
6.8. ANNOUNCE_ERROR . . . . . . . . . . . . . . . . . . . . . 33
6.9. ANNOUNCE_CANCEL . . . . . . . . . . . . . . . . . . . . . 33
6.10. TRACK_STATUS_REQUEST . . . . . . . . . . . . . . . . . . 34
6.11. SUBSCRIBE_NAMESPACE . . . . . . . . . . . . . . . . . . . 34
6.12. UNSUBSCRIBE_NAMESPACE . . . . . . . . . . . . . . . . . . 35
6.13. SUBSCRIBE_OK . . . . . . . . . . . . . . . . . . . . . . 35
6.14. SUBSCRIBE_ERROR . . . . . . . . . . . . . . . . . . . . . 36
6.15. SUBSCRIBE_DONE . . . . . . . . . . . . . . . . . . . . . 37
6.16. MAX_SUBSCRIBE_ID . . . . . . . . . . . . . . . . . . . . 37
6.17. ANNOUNCE . . . . . . . . . . . . . . . . . . . . . . . . 38
6.18. UNANNOUNCE . . . . . . . . . . . . . . . . . . . . . . . 38
6.19. TRACK_STATUS . . . . . . . . . . . . . . . . . . . . . . 39
6.20. SUBSCRIBE_NAMESPACE_OK . . . . . . . . . . . . . . . . . 40
6.21. SUBSCRIBE_NAMESPACE_ERROR . . . . . . . . . . . . . . . . 40
7. Data Streams . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Object Headers . . . . . . . . . . . . . . . . . . . . . 41
7.1.1. Canonical Object Fields . . . . . . . . . . . . . . . 41
7.2. Object Datagram Message . . . . . . . . . . . . . . . . . 43
7.3. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3.1. Stream Header Track . . . . . . . . . . . . . . . . . 44
7.3.2. Stream Header Subgroup . . . . . . . . . . . . . . . 44
7.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 45
Curley, et al. Expires 23 March 2025 [Page 3]
Internet-Draft moq-transport September 2024
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8.1. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Normative References . . . . . . . . . . . . . . . . . . . . . 48
Informative References . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
Media Over QUIC Transport (MOQT) is a protocol that is optimized for
the QUIC protocol [QUIC], either directly or via WebTransport
[WebTransport], for the dissemination of media. MOQT utilizes a
publish/subscribe workflow in which producers of media publish data
in response to subscription requests from a multiplicity of
endpoints. MOQT supports wide range of use-cases with different
resiliency and latency (live, interactive) needs without compromising
the scalability and cost effectiveness associated with content
delivery networks.
MOQT is a generic protocol is designed to work in concert with
multiple MoQ Streaming Formats. These MoQ Streaming Formats define
how content is encoded, packaged, and mapped to MOQT objects, along
with policies for discovery and subscription.
* Section 2 describes the object model employed by MOQT.
* Section 3 covers aspects of setting up a MOQT session.
* Section 4 covers mechanisms for prioritizing subscriptions.
* Section 5 covers behavior at the relay entities.
* Section 6 covers how messages are encoded on the wire.
1.1. Motivation
The development of MOQT is driven by goals in a number of areas -
specifically latency, the robustness of QUIC, workflow efficiency and
relay support.
Curley, et al. Expires 23 March 2025 [Page 4]
Internet-Draft moq-transport September 2024
1.1.1. Latency
HTTP Adaptive Streaming (HAS) has been successful at achieving scale
although often at the cost of latency. Latency is necessary to
correct for variable network throughput. Ideally live content is
consumed at the same bitrate it is produced. End-to-end latency
would be fixed and only subject to encoding and transmission delays.
Unfortunately, networks have variable throughput, primarily due to
congestion. Attempting to deliver content encoded at a higher
bitrate than the network can support causes queuing along the path
from producer to consumer. The speed at which a protocol can detect
and respond to queuing determines the overall latency. TCP-based
protocols are simple but are slow to detect congestion and suffer
from head-of-line blocking. Protocols utilizing UDP directly can
avoid queuing, but the application is then responsible for the
complexity of fragmentation, congestion control, retransmissions,
receiver feedback, reassembly, and more. One goal of MOQT is to
achieve the best of both these worlds: leverage the features of QUIC
to create a simple yet flexible low latency protocol that can rapidly
detect and respond to congestion.
1.1.2. Leveraging QUIC
The parallel nature of QUIC streams can provide improvements in the
face of loss. A goal of MOQT is to design a streaming protocol to
leverage the transmission benefits afforded by parallel QUIC streams
as well exercising options for flexible loss recovery. Applying
[QUIC] to HAS via HTTP/3 has not yet yielded generalized improvements
in throughput. One reason for this is that sending segments down a
single QUIC stream still allows head-of-line blocking to occur.
1.1.3. Universal
Internet delivered media today has protocols optimized for ingest and
separate protocols optimized for distribution. This protocol switch
in the distribution chain necessitates intermediary origins which re-
package the media content. While specialization can have its
benefits, there are gains in efficiency to be had in not having to
re-package content. A goal of MOQT is to develop a single protocol
which can be used for transmission from contribution to distribution.
A related goal is the ability to support existing encoding and
packaging schemas, both for backwards compatibility and for
interoperability with the established content preparation ecosystem.
Curley, et al. Expires 23 March 2025 [Page 5]
Internet-Draft moq-transport September 2024
1.1.4. Relays
An integral feature of a protocol being successful is its ability to
deliver media at scale. Greatest scale is achieved when third-party
networks, independent of both the publisher and subscriber, can be
leveraged to relay the content. These relays must cache content for
distribution efficiency while simultaneously routing content and
deterministically responding to congestion in a multi-tenant network.
A goal of MOQT is to treat relays as first-class citizens of the
protocol and ensure that objects are structured such that information
necessary for distribution is available to relays while the media
content itself remains opaque and private.
1.2. Terms and Definitions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Client: The party initiating a MoQ transport session.
Server: The party accepting an incoming transport session.
Endpoint: A Client or Server.
Publisher: An endpoint that handles subscriptions by sending
requested Objects from the requested track.
Subscriber: An endpoint that subscribes to and receives tracks.
Original Publisher: The initial publisher of a given track.
End Subscriber: A subscriber that initiates a subscription and does
not send the data on to other subscribers.
Relay: An entity that is both a Publisher and a Subscriber, but not
the Original Publisher or End Subscriber.
Upstream: In the direction of the Original Publisher
Downstream: In the direction of the End Subscriber(s)
Transport session: A raw QUIC connection or a WebTransport session.
Congestion: Packet loss and queuing caused by degraded or overloaded
networks.
Curley, et al. Expires 23 March 2025 [Page 6]
Internet-Draft moq-transport September 2024
Group: A temporal sequence of objects. A group represents a join
point in a track. See (Section 2.3).
Object: An object is an addressable unit whose payload is a sequence
of bytes. Objects form the base element in the MOQT model. See
(Section 2.1).
Track: An encoded bitstream. Tracks contain a sequential series of
one or more groups and are the subscribable entity with MOQT. See
(Section 2.4).
1.3. Notational Conventions
This document uses the conventions detailed in ([RFC9000],
Section 1.3) when describing the binary encoding.
As a quick reference, the following list provides a non normative
summary of the parts of RFC9000 field syntax that are used in this
specification.
x (L): Indicates that x is L bits long
x (i): Indicates that x holds an integer value using the variable-
length encoding as described in ([RFC9000], Section 16)
x (..): Indicates that x can be any length including zero bits long.
Values in this format always end on a byte boundary.
[x (L)]: Indicates that x is optional and has a length of L
x (L) ...: Indicates that x is repeated zero or more times and that
each instance has a length of L
This document extends the RFC9000 syntax and with the additional
field types:
x (b): Indicates that x consists of a variable length integer
encoding as described in ([RFC9000], Section 16), followed by that
many bytes of binary data
x (f): Indicates that x is a flag and is encoded as a single byte
with the value 0 or 1. A value of 0 indicates the flag is false
or off, while a value of 1 indicates the flag is true or on. Any
other value is a protocol error and SHOULD terminate the session
with a Protocol Violation (Section 3.5).
x (tuple): Indicates that x is a tuple, consisting of a variable
Curley, et al. Expires 23 March 2025 [Page 7]
Internet-Draft moq-transport September 2024
length integer encoded as described in ([RFC9000], Section 16),
followed by that many variable length tuple fields, each of which
are encoded as (b) above.
To reduce unnecessary use of bandwidth, variable length integers
SHOULD be encoded using the least number of bytes possible to
represent the required value.
2. Object Model
MOQT has a hierarchical object model for data, comprised of objects,
groups and tracks.
2.1. Objects
The basic data element of MOQT is an object. An object is an
addressable unit whose payload is a sequence of bytes. All objects
belong to a group, indicating ordering and potential dependencies.
Section 2.3 An object is uniquely identified by its track namespace,
track name, group ID, and object ID, and must be an identical
sequence of bytes regardless of how or where it is retrieved. An
Object can become unavailable, but its contents MUST NOT change over
time.
Objects are comprised of two parts: metadata and a payload. The
metadata is never encrypted and is always visible to relays. The
payload portion may be encrypted, in which case it is only visible to
the Original Publisher and End Subscribers. The application is
solely responsible for the content of the object payload. This
includes the underlying encoding, compression, any end-to-end
encryption, or authentication. A relay MUST NOT combine, split, or
otherwise modify object payloads.
2.2. Subgroups
A subgroup is a sequence of one or more objects from the same group
(Section 2.3) in ascending order by Object ID. Objects in a subgroup
have a dependency and priority relationship consistent with sharing a
QUIC stream. In some cases, a Group will be most effectively
delivered using more than one QUIC stream.
When a Track's forwarding preference (see Section 7.1.1) is "Track"
or "Datagram", Objects are not sent in Subgroups, no Subgroup IDs are
assigned, and the description in the remainder of this section does
not apply.
Curley, et al. Expires 23 March 2025 [Page 8]
Internet-Draft moq-transport September 2024
QUIC streams offer in-order reliable delivery and the ability to
cancel sending and retransmission of data. Furthermore, many
implementations offer the ability to control the relative priority of
streams, which allows control over the scheduling of sending data on
active streams.
Every object within a Group belongs to exactly one Subgroup.
Objects from two subgroups cannot be sent on the same QUIC stream.
Objects from the same Subgroup MUST NOT be sent on different QUIC
streams, unless one of the streams was reset prematurely, or upstream
conditions have forced objects from a Subgroup to be sent out of
Object ID order.
Original publishers assign each Subgroup a Subgroup ID, and do so as
they see fit. The scope of a Subgroup ID is a Group, so Subgroups
from different Groups MAY share a Subgroup ID without implying any
relationship between them. In general, publishers assign objects to
subgroups in order to leverage the features of QUIC streams as
described above.
An example strategy for using QUIC stream properties follows. If
object B is dependent on object A, then delivery of B can follow A,
i.e. A and B can be usefully delivered over a single QUIC stream.
Furthermore, in this example:
* If an object is dependent on all previous objects in a Subgroup,
it is added to that Subgroup.
* If an object is not dependent on all of the objects in a Subgroup,
it goes in a different Subgroup.
* There are often many ways to compose Subgroups that meet these
criteria. Where possible, choose the composition that results in
the fewest Subgroups in a group to minimize the number of QUIC
streams used.
2.3. Groups
A group is a collection of objects and is a sub-unit of a track
(Section 2.4). Objects within a group SHOULD NOT depend on objects
in other groups. A group behaves as a join point for subscriptions.
A new subscriber might not want to receive the entire track, and may
instead opt to receive only the latest group(s). The publisher then
selectively transmits objects based on their group membership.
Curley, et al. Expires 23 March 2025 [Page 9]
Internet-Draft moq-transport September 2024
2.4. Track
A track is a sequence of groups (Section 2.3). It is the entity
against which a subscriber issues a subscription request. A
subscriber can request to receive individual tracks starting at a
group boundary, including any new objects pushed by the publisher
while the track is active.
2.4.1. Track Naming and Scopes
In MOQT, every track has a track name and a track namespace
associated with it. A track name identifies an individual track
within the namespace.
Track namespace is an ordered N-tuple of bytes where N can be between
1 and 32. The structured nature of Track Namespace allows relays and
applications to manipulate prefixes of a namespace. Track name is a
sequence of bytes.
In this specification, both the Track Namespace tuple fields and the
Track Name are not constrained to a specific encoding. They carry a
sequence of bytes and comparison between two Track Namespace tuple
fields or Track Names is done by exact comparison of the bytes.
Specifications that use MoQ Transport may constrain the information
in these fields, for example by restricting them to UTF-8. Any
specification that does needs to specify the canonicalization into
the bytes in the Track Namespace or Track Name such that exact
comparison works.
2.4.2. Scope
A MOQT scope is a set of servers (as identified by their connection
URIs) for which the tuple of Track Name and Track Namespace are
guaranteed to be unique and identify a specific track. It is up to
the application using MOQT to define how broad or narrow the scope
is. An application that deals with connections between devices on a
local network may limit the scope to a single connection; by
contrast, an application that uses multiple CDNs to serve media may
require the scope to include all of those CDNs.
Because the tuple of Track Namespace and Track Name are unique within
an MOQT scope, they can be used as a cache key. MOQT does not
provide any in-band content negotiation methods similar to the ones
defined by HTTP ([RFC9110], Section 10); if, at a given moment in
time, two tracks within the same scope contain different data, they
have to have different names and/or namespaces.
Curley, et al. Expires 23 March 2025 [Page 10]
Internet-Draft moq-transport September 2024
2.4.3. Connection URL
Each track MAY have one or more associated connection URLs specifying
network hosts through which a track may be accessed. The syntax of
the Connection URL and the associated connection setup procedures are
specific to the underlying transport protocol usage Section 3.
3. Sessions
3.1. Session establishment
This document defines a protocol that can be used interchangeably
both over a QUIC connection directly [QUIC], and over WebTransport
[WebTransport]. Both provide streams and datagrams with similar
semantics (see [I-D.ietf-webtrans-overview], Section 4); thus, the
main difference lies in how the servers are identified and how the
connection is established. When using QUIC, datagrams MUST be
supported via the [QUIC-DATAGRAM] extension, which is already a
requirement for WebTransport over HTTP/3.
There is no definition of the protocol over other transports, such as
TCP, and applications using MoQ might need to fallback to another
protocol when QUIC or WebTransport aren't available.
3.1.1. WebTransport
A MOQT server that is accessible via WebTransport can be identified
using an HTTPS URI ([RFC9110], Section 4.2.2). A MOQT session can be
established by sending an extended CONNECT request to the host and
the path indicated by the URI, as described in [WebTransport],
Section 3.
3.1.2. QUIC
A MOQT server that is accessible via native QUIC can be identified by
a URI with a "moq" scheme. The "moq" URI scheme is defined as
follows, using definitions from [RFC3986]:
moq-URI = "moqt" "://" authority path-abempty [ "?" query ]
The authority portion MUST NOT contain a non-empty host portion. The
moq URI scheme supports the /.well-known/ path prefix defined in
[RFC8615].
This protocol does not specify any semantics on the path-abempty and
query portions of the URI. The contents of those are left up to the
application.
Curley, et al. Expires 23 March 2025 [Page 11]
Internet-Draft moq-transport September 2024
The client can establish a connection to a MoQ server identified by a
given URI by setting up a QUIC connection to the host and port
identified by the authority section of the URI. The path-abempty and
query portions of the URI are communicated to the server using the
PATH parameter (Section 6.2.2.2) which is sent in the CLIENT_SETUP
message at the start of the session. The ALPN value [RFC7301] used
by the protocol is moq-00.
3.2. Version and Extension Negotiation
Endpoints use the exchange of Setup messages to negotiate the MOQT
version and any extensions to use.
The client indicates the MOQT versions it supports in the
CLIENT_SETUP message (see Section 6.2). It also includes the union
of all Setup Parameters Section 6.2.2 required for a handshake by any
of those versions.
Within any MOQT version, clients request the use of extensions by
adding Setup parameters corresponding to that extension. No
extensions are defined in this document.
The server replies with a SERVER_SETUP message that indicates the
chosen version, includes all parameters required for a handshake in
that version, and parameters for every extension requested by the
client that it supports.
New versions of MOQT MUST specify which existing extensions can be
used with that version. New extensions MUST specify the existing
versions with which they can be used.
If a given parameter carries the same information in multiple
versions, but might have different optimal values in those versions,
there SHOULD be separate Setup parameters for that information in
each version.
3.3. Session initialization
The first stream opened is a client-initiated bidirectional control
stream where the peers exchange Setup messages (Section 6.2). All
messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH
are sent on the control stream after the Setup message. Control
messages MUST NOT be sent on any other stream, and a peer receiving a
control message on a different stream closes the session as a
'Protocol Violation'. Objects MUST NOT be sent on the control
stream, and a peer receiving an Object on the control stream closes
the session as a 'Protocol Violation'.
Curley, et al. Expires 23 March 2025 [Page 12]
Internet-Draft moq-transport September 2024
This draft only specifies a single use of bidirectional streams.
Objects are sent on unidirectional streams. Because there are no
other uses of bidirectional streams, a peer MAY currently close the
session as a 'Protocol Violation' if it receives a second
bidirectional stream.
The control stream MUST NOT be abruptly closed at the underlying
transport layer. Doing so results in the session being closed as a
'Protocol Violation'.
3.4. Stream Cancellation
Streams aside from the control stream MAY be canceled due to
congestion or other reasons by either the publisher or subscriber.
Early termination of a stream does not affect the MoQ application
state, and therefore has no effect on outstanding subscriptions.
3.5. Termination
The transport session can be terminated at any point. When native
QUIC is used, the session is closed using the CONNECTION_CLOSE frame
([QUIC], Section 19.19). When WebTransport is used, the session is
closed using the CLOSE_WEBTRANSPORT_SESSION capsule ([WebTransport],
Section 5).
The application MAY use any error message and SHOULD use a relevant
code, as defined below:
Curley, et al. Expires 23 March 2025 [Page 13]
Internet-Draft moq-transport September 2024
+======+===========================+
| Code | Reason |
+======+===========================+
| 0x0 | No Error |
+------+---------------------------+
| 0x1 | Internal Error |
+------+---------------------------+
| 0x2 | Unauthorized |
+------+---------------------------+
| 0x3 | Protocol Violation |
+------+---------------------------+
| 0x4 | Duplicate Track Alias |
+------+---------------------------+
| 0x5 | Parameter Length Mismatch |
+------+---------------------------+
| 0x6 | Too Many Subscribes |
+------+---------------------------+
| 0x10 | GOAWAY Timeout |
+------+---------------------------+
Table 1
* No Error: The session is being terminated without an error.
* Internal Error: An implementation specific error occurred.
* Unauthorized: The endpoint breached an agreement, which MAY have
been pre-negotiated by the application.
* Protocol Violation: The remote endpoint performed an action that
was disallowed by the specification.
* Duplicate Track Alias: The endpoint attempted to use a Track Alias
that was already in use.
* Too Many Subscribes: The session was closed because the subscriber
used a Subscribe ID equal or larger than the current Maximum
Subscribe ID.
* GOAWAY Timeout: The session was closed because the client took too
long to close the session in response to a GOAWAY (Section 6.3)
message. See session migration (Section 3.6).
Curley, et al. Expires 23 March 2025 [Page 14]
Internet-Draft moq-transport September 2024
3.6. Migration
MoqTransport requires a long-lived and stateful session. However, a
service provider needs the ability to shutdown/restart a server
without waiting for all sessions to drain naturally, as that can take
days for long-form media. MoqTransport avoids this via the GOAWAY
message (Section 6.3).
The server sends a GOAWAY message, signaling that the client should
establish a new session and migrate any active subscriptions. The
GOAWAY message may contain a new URI for the new session, otherwise
the current URI is reused. The server SHOULD terminate the session
with 'GOAWAY Timeout' after a sufficient timeout if there are still
open subscriptions on a connection.
The GOAWAY message does not immediately impact subscription state. A
subscriber SHOULD individually UNSUBSCRIBE for each existing
subscription, while a publisher MAY reject new SUBSCRIBEs while in
the draining state. When the server is a subscriber, it SHOULD send
a GOAWAY message prior to any UNSUBSCRIBE messages.
After the client receives a GOAWAY, it's RECOMMENDED that the client
waits until there are no more active subscriptions before closing the
session with NO_ERROR. Ideally this is transparent to the
application using MOQT, which involves establishing a new session in
the background and migrating active subscriptions and announcements.
The client can choose to delay closing the session if it expects more
OBJECTs to be delivered. The server closes the session with a
'GOAWAY Timeout' if the client doesn't close the session quickly
enough.
4. Priorities
MoQ priorities allow a subscriber and original publisher to influence
the transmission order of Objects within a session in the presence of
congestion.
Given the critical nature of control messages and their relatively
small size, the control stream SHOULD be prioritized higher than all
subscribed Objects.
The subscriber indicates the priority of a subscription via the
Subscriber Priority field and the original publisher indicates
priority in every stream or datagram header. As such, the
subscriber's priority is a property of the subscription and the
original publisher's priority is a property of the Track and the
Objects it contains. In both cases, a lower value indicates a higher
priority, with 0 being the highest priority.
Curley, et al. Expires 23 March 2025 [Page 15]
Internet-Draft moq-transport September 2024
When Objects are contained in Subgroups, all Objects in the Subgroup
have the same priority.
The Subscriber Priority is considered first when selecting a
subscription to send data on within a given session. When two or
more subscriptions have equal subscriber priority, the original
publisher priority is considered next and can change within the
track, so subscriptions are prioritized based on the highest priority
data available to send. For example, if the subscription had data at
priority 6 and priority 10 to send, the subscription priority would
be 6. When both the subscriber and original publisher priorities for
a subscription are equal, how much data to send from each
subscription is implementation-dependent, but the expectation is that
all subscriptions will be able to send some data.
The subscriber's priority can be changed via a SUBSCRIBE_UPDATE
message. This updates the priority of all unsent data within the
subscription, though the details of the reprioitization are
implementation-specific.
Subscriptions have a Group Order of either 'Ascending' or
'Descending', which indicates whether the lowest or highest Group Id
SHOULD be sent first when multiple Groups are available to send. A
subscriber can specify either 'Ascending' or 'Descending' in the
SUBSCRIBE message or they can specify they want to use the Original
Publisher's Group Order, which is indicated in the corresponding
SUBSCRIBE_OK.
Within the same Group, and the same priority level, Objects with a
lower Object Id are always sent before objects with a higher Object
Id, regardless of the specified Group Order. If the group contains
more than one Subgroup and the priority varies between these
Subgroups, higher priority Subgroups are sent before lower priority
Subgroups. If the specified priority of two Subgroups in a Group are
equal, the lower Subgroup ID has priority. Within a Subgroup,
Objects MUST be sent in increasing Object ID order.
The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and
instead an UNSUBSCRIBE and SUBSCRIBE can be used.
Relays SHOULD respect the subscriber and original publisher's
priorities. Relays SHOULD NOT directly use Subscriber Priority or
Group Order from incoming subscriptions for upstream subscriptions.
Relays use of Subscriber Priority for upstream subscriptions can be
based on factors specific to it, such as the popularity of the
content or policy, or relays can specify the same value for all
upstream subscriptions.
Curley, et al. Expires 23 March 2025 [Page 16]
Internet-Draft moq-transport September 2024
MoQ Sessions can span multiple namespaces, and priorities might not
be coordinated across namespaces. The subscriber's priority is
considered first, so there is a mechanism for a subscriber to fix
incompatibilities between different namespaces prioritization
schemes. Additionally, it is anticipated that when multiple
namespaces are present within a session, the namespaces could be
coordinating, possibly part of the same application. In cases when
pooling among namespaces is expected to cause issues, multiple MoQ
sessions, either within a single connection or on multiple
connections can be used.
5. Relays
Relays are leveraged to enable distribution scale in the MoQ
architecture. Relays can be used to form an overlay delivery
network, similar in functionality to Content Delivery Networks
(CDNs). Additionally, relays serve as policy enforcement points by
validating subscribe and publish requests at the edge of a network.
Relays can cache Objects, but are not required to.
5.1. Subscriber Interactions
Subscribers interact with the Relays by sending a SUBSCRIBE
(Section 6.4) control message for the tracks of interest. Relays
MUST ensure subscribers are authorized to access the content
associated with the track. The authorization information can be part
of subscription request itself or part of the encompassing session.
The specifics of how a relay authorizes a user are outside the scope
of this specification. The subscriber is notified of the result of
the subscription via a SUBSCRIBE_OK (Section 6.13) or SUBSCRIBE_ERROR
Section 6.14 control message. The entity receiving the SUBSCRIBE
MUST send only a single response to a given SUBSCRIBE of either
SUBSCRIBE_OK or SUBSCRIBE_ERROR.
If a relay does not already have a subscription for the track, or if
the subscription does not cover all the requested Objects, it will
need to make an upstream subscription. The relay SHOULD NOT return a
SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the
track, to ensure the Group Order is correct.
For successful subscriptions, the publisher maintains a list of
subscribers for each track. Each new OBJECT belonging to the track
within the subscription range is forwarded to each active subscriber,
dependent on the congestion response. A subscription remains active
until the publisher of the track terminates the subscription with a
SUBSCRIBE_DONE (see Section 6.15).
Curley, et al. Expires 23 March 2025 [Page 17]
Internet-Draft moq-transport September 2024
A caching relay saves Objects to its cache identified by the Object's
Full Track Name, Group ID and Object ID. Relays MUST be able to
process objects for the same Full Track Name from multiple publishers
and forward objects to active matching subscriptions. If multiple
objects are received with the same Full Track Name, Group ID and
Object ID, Relays MAY ignore subsequently received Objects or MAY use
them to update the cache. Implementations that update the cache need
to be protect against cache poisoning.
Objects MUST NOT be sent for unsuccessful subscriptions, and if a
subscriber receives a SUBSCRIBE_ERROR after receiving objects, it
MUST close the session with a 'Protocol Violation'.
A relay MUST not reorder or drop objects received on a multi-object
stream when forwarding to subscribers, unless it has application
specific information.
Relays MAY aggregate authorized subscriptions for a given track when
multiple subscribers request the same track. Subscription
aggregation allows relays to make only a single upstream subscription
for the track. The published content received from the upstream
subscription request is cached and shared among the pending
subscribers.
The application SHOULD use a relevant error code in SUBSCRIBE_ERROR,
as defined below:
+======+======================+
| Code | Reason |
+======+======================+
| 0x0 | Internal Error |
+------+----------------------+
| 0x1 | Invalid Range |
+------+----------------------+
| 0x2 | Retry Track Alias |
+------+----------------------+
| 0x3 | Track Does Not Exist |
+------+----------------------+
| 0x4 | Unauthorized |
+------+----------------------+
| 0x5 | Timeout |
+------+----------------------+
Table 2
The application SHOULD use a relevant status code in SUBSCRIBE_DONE,
as defined below:
Curley, et al. Expires 23 March 2025 [Page 18]
Internet-Draft moq-transport September 2024
+======+====================+
| Code | Reason |
+======+====================+
| 0x0 | Unsubscribed |
+------+--------------------+
| 0x1 | Internal Error |
+------+--------------------+
| 0x2 | Unauthorized |
+------+--------------------+
| 0x3 | Track Ended |
+------+--------------------+
| 0x4 | Subscription Ended |
+------+--------------------+
| 0x5 | Going Away |
+------+--------------------+
| 0x6 | Expired |
+------+--------------------+
Table 3
5.1.1. Graceful Publisher Relay Switchover
This section describes behavior a subscriber MAY implement to allow
for a better user experience when a relay sends a GOAWAY.
When a subscriber receives the GOAWAY message, it starts the process
of connecting to a new relay and sending the SUBSCRIBE requests for
all active subscriptions to the new relay. The new relay will send a
response to the subscribes and if they are successful, the
subscriptions to the old relay can be stopped with an UNSUBSCRIBE.
5.2. Publisher Interactions
Publishing through the relay starts with publisher sending ANNOUNCE
control message with a Track Namespace (Section 2.4). The announce
enables the relay to know which publisher to forward a SUBSCRIBE to.
Relays MUST ensure that publishers are authorized by:
* Verifying that the publisher is authorized to publish the content
associated with the set of tracks whose Track Namespace matches
the announced namespace. Where the authorization and
identification of the publisher occurs depends on the way the
relay is managed and is application specific.
Curley, et al. Expires 23 March 2025 [Page 19]
Internet-Draft moq-transport September 2024
Relays respond with an ANNOUNCE_OK or ANNOUNCE_ERROR control message
providing the result of announcement. The entity receiving the
ANNOUNCE MUST send only a single response to a given ANNOUNCE of
either ANNOUNCE_OK or ANNOUNCE_ERROR.
A Relay can receive announcements from multiple publishers for the
same Track Namespace and it SHOULD respond with the same response to
each of the publishers, as though it was responding to an ANNOUNCE
from a single publisher for a given tracknamespace.
When a publisher wants to stop new subscriptions for an announced
namespace it sends an UNANNOUNCE. A subscriber indicates it will no
longer route subscriptions for a namespace it previously responded
ANNOUNCE_OK to by sending an ANNOUNCE_CANCEL.
A relay manages sessions from multiple publishers and subscribers,
connecting them based on the track namespace. This MUST use an exact
match on track namespace unless otherwise negotiated by the
application. For example, a SUBSCRIBE namespace=foobar message will
be forwarded to the session that sent ANNOUNCE namespace=foobar.
When a relay receives an incoming SUBSCRIBE request that triggers an
upstream subscription, it SHOULD send a SUBSCRIBE request to each
publisher that has announced the subscription's namespace, unless it
already has an active subscription for the Objects requested by the
incoming SUBSCRIBE request from all available publishers.
When a relay receives an incoming ANNOUCE for a given namespace, for
each active upstream subscription that matches that namespace, it
SHOULD send a SUBSCRIBE to that publisher that send the ANNOUNCE.
OBJECT message headers carry a short hop-by-hop Track Alias that maps
to the Full Track Name (see Section 6.13). Relays use the Track
Alias of an incoming OBJECT message to identify its track and find
the active subscribers for that track. Relays MUST forward OBJECT
messages to matching subscribers in accordance to each subscription's
priority, group order, and delivery timeout.
5.2.1. Graceful Publisher Network Switchover
This section describes behavior that a publisher MAY choose to
implement to allow for a better users experience when switching
between networks, such as WiFi to Cellular or vice versa.
If the original publisher detects it is likely to need to switch
networks, for example because the WiFi signal is getting weaker, and
it does not have QUIC connection migration available, it establishes
a new session over the new interface and sends an ANNOUCE. The relay
Curley, et al. Expires 23 March 2025 [Page 20]
Internet-Draft moq-transport September 2024
will forward matching subscribes and the publisher publishes objects
on both sessions. Once the subscriptions have migrated over to
session on the new network, the publisher can stop publishing objects
on the old network. The relay will drop duplicate objects received
on both subscriptions. Ideally, the subscriptions downstream from
the relay do no observe this change, and keep receiving the objects
on the same subscription.
5.2.2. Graceful Publisher Relay Switchover
This section describes behavior that a publisher MAY choose to
implement to allow for a better user experience when a relay sends
them a GOAWAY.
When a publisher receives a GOAWAY, it starts the process of
connecting to a new relay and sends announces, but it does not
immediately stop publishing objects to the old relay. The new relay
will send subscribes and the publisher can start sending new objects
to the new relay instead of the old relay. Once objects are going to
the new relay, the announcement and subscription to the old relay can
be stopped.
5.3. Relay Object Handling
MOQT encodes the delivery information for a stream via OBJECT headers
(Section 7.1). A relay MUST NOT modify Object properties when
forwarding.
A relay MUST treat the object payload as opaque. A relay MUST NOT
combine, split, or otherwise modify object payloads. A relay SHOULD
prioritize sending Objects based on Section 4.
A publisher SHOULD begin sending incomplete objects when available to
avoid incurring additional latency.
A relay that reads from a stream and writes to stream in order will
introduce head-of-line blocking. Packet loss will cause stream data
to be buffered in the library, awaiting in order delivery, which will
increase latency over additional hops. To mitigate this, a relay
SHOULD read and write stream data out of order subject to flow
control limits. See section 2.2 in [QUIC].
6. Control Messages
MOQT uses a single bidirectional stream to exchange control messages,
as defined in Section 3.3. Every single message on the control
stream is formatted as follows:
Curley, et al. Expires 23 March 2025 [Page 21]
Internet-Draft moq-transport September 2024
MOQT Control Message {
Message Type (i),
Message Payload (b),
}
Figure 1: MOQT Message
Curley, et al. Expires 23 March 2025 [Page 22]
Internet-Draft moq-transport September 2024
+======+=========================================+
| ID | Messages |
+======+=========================================+
| 0x2 | SUBSCRIBE_UPDATE (Section 6.5) |
+------+-----------------------------------------+
| 0x3 | SUBSCRIBE (Section 6.4) |
+------+-----------------------------------------+
| 0x4 | SUBSCRIBE_OK (Section 6.13) |
+------+-----------------------------------------+
| 0x5 | SUBSCRIBE_ERROR (Section 6.14) |
+------+-----------------------------------------+
| 0x6 | ANNOUNCE (Section 6.17) |
+------+-----------------------------------------+
| 0x7 | ANNOUNCE_OK (Section 6.7) |
+------+-----------------------------------------+
| 0x8 | ANNOUNCE_ERROR (Section 6.8) |
+------+-----------------------------------------+
| 0x9 | UNANNOUNCE (Section 6.18) |
+------+-----------------------------------------+
| 0xA | UNSUBSCRIBE (Section 6.6) |
+------+-----------------------------------------+
| 0xB | SUBSCRIBE_DONE (Section 6.15) |
+------+-----------------------------------------+
| 0xC | ANNOUNCE_CANCEL (Section 6.9) |
+------+-----------------------------------------+
| 0xD | TRACK_STATUS_REQUEST (Section 6.10) |
+------+-----------------------------------------+
| 0xE | TRACK_STATUS (Section 6.19) |
+------+-----------------------------------------+
| 0x10 | GOAWAY (Section 6.3) |
+------+-----------------------------------------+
| 0x11 | SUBSCRIBE_NAMESPACE (Section 6.11) |
+------+-----------------------------------------+
| 0x12 | SUBSCRIBE_NAMESPACE_OK (Section 6.20) |
+------+-----------------------------------------+
| 0x13 | SUBSCRIBE_NAMESPACE_ERROR (Section 6.21 |
+------+-----------------------------------------+
| 0x14 | UNSUBSCRIBE_NAMESPACE (Section 6.12) |
+------+-----------------------------------------+
| 0x15 | MAX_SUBSCRIBE_ID (Section 6.16) |
+------+-----------------------------------------+
| 0x40 | CLIENT_SETUP (Section 6.2) |
+------+-----------------------------------------+
| 0x41 | SERVER_SETUP (Section 6.2) |
+------+-----------------------------------------+
Table 4
Curley, et al. Expires 23 March 2025 [Page 23]
Internet-Draft moq-transport September 2024
An endpoint that receives an unknown message type MUST close the
session. Control messages have a length to make parsing easier, but
no control messages are intended to be ignored. If the length does
not match the length of the message content, the receiver MUST close
the session.
6.1. Parameters
Some messages include a Parameters field that encode optional message
elements. They contain a type, length, and value.
Senders MUST NOT repeat the same parameter type in a message.
Receivers SHOULD check that there are no duplicate parameters and
close the session as a 'Protocol Violation' if found.
Receivers ignore unrecognized parameters.
The format of Parameters is as follows:
Parameter {
Parameter Type (i),
Parameter Length (i),
Parameter Value (..),
}
Figure 2: MOQT Parameter
Parameter Type is an integer that indicates the semantic meaning of
the parameter. Setup message parameters use a namespace that is
constant across all MoQ Transport versions. All other messages use a
version-specific namespace. For example, the integer '1' can refer
to different parameters for Setup messages and for all other message
types.
SETUP message parameter types are defined in Section 6.2.2. Version-
specific parameter types are defined in Section 6.1.1.
The Parameter Length field of the String Parameter encodes the length
of the Parameter Value field in bytes.
Each parameter description will indicate the data type in the
Parameter Value field. If a receiver understands a parameter type,
and the parameter length implied by that type does not match the
Parameter Length field, the receiver MUST terminate the session with
error code 'Parameter Length Mismatch'.
Curley, et al. Expires 23 March 2025 [Page 24]
Internet-Draft moq-transport September 2024
6.1.1. Version Specific Parameters
Each version-specific parameter definition indicates the message
types in which it can appear. If it appears in some other type of
message, it MUST be ignored. Note that since Setup parameters use a
separate namespace, it is impossible for these parameters to appear
in Setup messages.
6.1.1.1. AUTHORIZATION INFO
AUTHORIZATION INFO parameter (key 0x02) identifies a track's
authorization information in a SUBSCRIBE, SUBSCRIBE_NAMESPACE or
ANNOUNCE message. This parameter is populated for cases where the
authorization is required at the track level. The value is an ASCII
string.
6.1.1.2. DELIVERY TIMEOUT Parameter
The DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE,
SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message. It is the duration in
milliseconds the relay SHOULD continue to attempt forwarding Objects
after they have been received. The start time for the timeout is
based on when the beginning of the Object is received, and does not
depend upon the forwarding preference. There is no explicit signal
that an Object was not sent because the delivery timeout was
exceeded.
If both the subscriber and publisher specify the parameter, they use
the min of the two values for the subscription. The publisher SHOULD
always specify the value received from an upstream subscription when
there is one, and nothing otherwise. If an earlier Object arrives
later than subsequent Objects, relays can consider the receipt time
as that of the next later Object, with the assumption that the
Object's data was reordered.
If neither the subscriber or publisher specify DELIVERY TIMEOUT,
Objects are delivered as indicated by their Group Order and Priority.
When sent by a subscriber, this parameter is intended to be specific
to a subscription, so it SHOULD NOT be forwarded upstream by a relay
that intends to serve multiple subscriptions for the same track.
Publishers SHOULD consider whether the entire Object is likely to be
delivered before sending any data for that Object, taking into
account priorities, congestion control, and any other relevant
information.
Curley, et al. Expires 23 March 2025 [Page 25]
Internet-Draft moq-transport September 2024
6.1.1.3. MAX CACHE DURATION Parameter
MAX_CACHE_DURATION (key 0x04): An integer expressing a number of
milliseconds. If present, the relay MUST NOT start forwarding any
individual Object received through this subscription after the
specified number of milliseconds has elapsed since the beginning of
the Object was received. This means Objects earlier in a multi-
object stream will expire earlier than Objects later in the stream.
Once Objects have expired, their state becomes unknown, and a relay
that handles a subscription that includes those Objects re-requests
them.
6.2. CLIENT_SETUP and SERVER_SETUP
The CLIENT_SETUP and SERVER_SETUP messages are the first messages
exchanged by the client and the server; they allows the peers to
establish the mutually supported version and agree on the initial
configuration before any objects are exchanged. It is a sequence of
key-value pairs called Setup parameters; the semantics and format of
which can vary based on whether the client or server is sending. To
ensure future extensibility of MOQT, the peers MUST ignore unknown
setup parameters. TODO: describe GREASE for those.
The wire format of the Setup messages are as follows:
CLIENT_SETUP Message Payload {
Number of Supported Versions (i),
Supported Version (i) ...,
Number of Parameters (i) ...,
Setup Parameters (..) ...,
}
SERVER_SETUP Message Payload {
Selected Version (i),
Number of Parameters (i) ...,
Setup Parameters (..) ...,
}
Figure 3: MOQT Setup Messages
The available versions and Setup parameters are detailed in the next
sections.
Curley, et al. Expires 23 March 2025 [Page 26]
Internet-Draft moq-transport September 2024
6.2.1. Versions
MoQ Transport versions are a 32-bit unsigned integer, encoded as a
varint. This version of the specification is identified by the
number 0x00000001. Versions with the most significant 16 bits of the
version number cleared are reserved for use in future IETF consensus
documents.
The client offers the list of the protocol versions it supports; the
server MUST reply with one of the versions offered by the client. If
the server does not support any of the versions offered by the
client, or the client receives a server version that it did not
offer, the corresponding peer MUST close the session.
[[RFC editor: please remove the remainder of this section before
publication.]]
The version number for the final version of this specification
(0x00000001), is reserved for the version of the protocol that is
published as an RFC. Version numbers used to identify IETF drafts
are created by adding the draft number to 0xff000000. For example,
draft-ietf-moq-transport-13 would be identified as 0xff00000D.
6.2.2. Setup Parameters
6.2.2.1. ROLE
The ROLE parameter (key 0x00) allows each endpoint to independently
specify what functionality they support for the session. It has
three possible values, which are of type varint:
0x01: Publisher The endpoint can process subscriptions and send
objects, but not subscribe. The endpoint MUST NOT send a
SUBSCRIBE message and an ANNOUNCE MUST NOT be sent to it.
0x02: Subscriber The endpoint can send subscriptions and receive
objects, but not publish. The endpoint MUST NOT send an ANNOUNCE
message and a SUBSCRIBE MUST NOT be sent to it.
0x03: PubSub The endpoint can act as a publisher or subscriber, and
can send or process any message type.
Both endpoints MUST send a ROLE parameter with one of the three
values specified above. Both endpoints MUST close the session if the
ROLE parameter is missing or is not one of the three above-specified
values.
Curley, et al. Expires 23 March 2025 [Page 27]
Internet-Draft moq-transport September 2024
6.2.2.2. PATH
The PATH parameter (key 0x01) allows the client to specify the path
of the MoQ URI when using native QUIC ([QUIC]). It MUST NOT be used
by the server, or when WebTransport is used. If the peer receives a
PATH parameter from the server, or when WebTransport is used, it MUST
close the connection. It follows the URI formatting rules [RFC3986].
When connecting to a server using a URI with the "moq" scheme, the
client MUST set the PATH parameter to the path-abempty portion of the
URI; if query is present, the client MUST concatenate ?, followed by
the query portion of the URI to the parameter.
6.2.2.3. MAX_SUBSCRIBE_ID
The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial
value for the Maximum Subscribe ID to the receiving subscriber. The
default value is 0, so if not specified, the peer MUST NOT create
subscriptions.
6.3. GOAWAY
The server sends a GOAWAY message to initiate session migration
(Section 3.6) with an optional URI.
The server MUST terminate the session with a Protocol Violation
(Section 3.5) if it receives a GOAWAY message. The client MUST
terminate the session with a Protocol Violation (Section 3.5) if it
receives multiple GOAWAY messages.
GOAWAY Message {
New Session URI (b)
}
Figure 4: MOQT GOAWAY Message
* New Session URI: The client MUST use this URI for the new session
if provided. If the URI is zero bytes long, the current URI is
reused instead. The new session URI SHOULD use the same scheme as
the current URL to ensure compatibility.
6.4. SUBSCRIBE
6.4.1. Filter Types
The subscriber specifies a filter on the subscription to allow the
publisher to identify which objects need to be delivered.
Curley, et al. Expires 23 March 2025 [Page 28]
Internet-Draft moq-transport September 2024
There are 4 types of filters:
Latest Group (0x1) : Specifies an open-ended subscription with
objects from the beginning of the current group. If no content has
been delivered yet, the subscription starts with the first published
or received group.
Latest Object (0x2): Specifies an open-ended subscription beginning
from the current object of the current group. If no content has been
delivered yet, the subscription starts with the first published or
received group.
AbsoluteStart (0x3): Specifies an open-ended subscription beginning
from the object identified in the StartGroup and StartObject fields.
AbsoluteRange (0x4): Specifies a closed subscription starting at
StartObject in StartGroup and ending at EndObject in EndGroup. The
start and end of the range are inclusive. EndGroup and EndObject
MUST specify the same or a later object than StartGroup and
StartObject.
A filter type other than the above MUST be treated as error.
6.4.2. SUBSCRIBE Format
A subscriber issues a SUBSCRIBE to a publisher to request a track.
The format of SUBSCRIBE is as follows:
SUBSCRIBE Message {
Subscribe ID (i),
Track Alias (i),
Track Namespace (tuple),
Track Name (b),
Subscriber Priority (8),
Group Order (8),
Filter Type (i),
[StartGroup (i),
StartObject (i)],
[EndGroup (i),
EndObject (i)],
Number of Parameters (i),
Subscribe Parameters (..) ...
}
Figure 5: MOQT SUBSCRIBE Message
Curley, et al. Expires 23 March 2025 [Page 29]
Internet-Draft moq-transport September 2024
* Subscribe ID: The subscriber specified identifier used to manage a
subscription. Subscribe ID is a variable length integer that MUST
be unique and monotonically increasing within a session and MUST
be less than the session's Maximum Subscribe ID.
* Track Alias: A session specific identifier for the track.
Messages that reference a track, such as OBJECT (Section 7.1),
reference this Track Alias instead of the Track Name and Track
Namespace to reduce overhead. If the Track Alias is already being
used for a different track, the publisher MUST close the session
with a Duplicate Track Alias error (Section 3.5).
* Track Namespace: Identifies the namespace of the track as defined
in (Section 2.4.1).
* Track Name: Identifies the track name as defined in
(Section 2.4.1).
* Subscriber Priority: Specifies the priority of a subscription
relative to other subscriptions in the same session. Lower
numbers get higher priority. See Section 4.
* Group Order: Allows the subscriber to request Objects be delivered
in Ascending (0x1) or Descending (0x2) order by group. See
Section 4. A value of 0x0 indicates the original publisher's
Group Order SHOULD be used. Values larger than 0x2 are a protocol
error.
* Filter Type: Identifies the type of filter, which also indicates
whether the StartGroup/StartObject and EndGroup/EndObject fields
will be present. See (Section 6.4.1).
* StartGroup: The start Group ID. Only present for "AbsoluteStart"
and "AbsoluteRange" filter types.
* StartObject: The start Object ID. Only present for
"AbsoluteStart" and "AbsoluteRange" filter types.
* EndGroup: The end Group ID. Only present for the "AbsoluteRange"
filter type.
* EndObject: The end Object ID, plus 1. A value of 0 means the
entire group is requested. Only present for the "AbsoluteRange"
filter type.
* Subscribe Parameters: The parameters are defined in Section 6.1.1.
Curley, et al. Expires 23 March 2025 [Page 30]
Internet-Draft moq-transport September 2024
On successful subscription, the publisher MUST reply with a
SUBSCRIBE_OK, allowing the subscriber to determine the start group/
object when not explicitly specified and the publisher SHOULD start
delivering objects.
If a publisher cannot satisfy the requested start or end for the
subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'.
A publisher MUST NOT send objects from outside the requested start
and end.
6.5. SUBSCRIBE_UPDATE
A subscriber issues a SUBSCRIBE_UPDATE to a publisher to request a
change to a prior subscription. Subscriptions can only become more
narrower, not wider, because an attempt to widen a subscription could
fail. If Objects before the start or after the end of the current
subscription are needed, a separate subscription can be made. The
start Object MUST NOT decrease and when it increases, there is no
guarantee that a publisher will not have already sent Objects before
the new start Object. The end Object MUST NOT increase and when it
decreases, there is no guarantee that a publisher will not have
already sent Objects after the new end Object. A publisher SHOULD
close the Session as a 'Protocol Violation' if the SUBSCRIBE_UPDATE
violates either rule or if the subscriber specifies a Subscribe ID
that does not exist within the Session.
Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object
to be delivered multiple times. Like SUBSCRIBE, EndGroup and
EndObject MUST specify the same or a later object than StartGroup and
StartObject.
The format of SUBSCRIBE_UPDATE is as follows:
SUBSCRIBE_UPDATE Message {
Subscribe ID (i),
StartGroup (i),
StartObject (i),
EndGroup (i),
EndObject (i),
Subscriber Priority (8),
Number of Parameters (i),
Subscribe Parameters (..) ...
}
Figure 6: MOQT SUBSCRIBE_UPDATE Message
* Subscribe ID: The subscription identifier that is unique within
the session. This MUST match an existing Subscribe ID.
Curley, et al. Expires 23 March 2025 [Page 31]
Internet-Draft moq-transport September 2024
* StartGroup: The start Group ID.
* StartObject: The start Object ID.
* EndGroup: The end Group ID, plus 1. A value of 0 means the
subscription is open-ended.
* EndObject: The end Object ID, plus 1. A value of 0 means the
entire group is requested.
* Subscriber Priority: Specifies the priority of a subscription
relative to other subscriptions in the same session. Lower
numbers get higher priority. See Section 4.
* Subscribe Parameters: The parameters are defined in Section 6.1.1.
6.6. UNSUBSCRIBE
A subscriber issues a UNSUBSCRIBE message to a publisher indicating
it is no longer interested in receiving media for the specified track
and Objects should stop being sent as soon as possible. The
publisher sends a SUBSCRIBE_DONE to acknowledge the unsubscribe was
successful and indicate the final Object.
The format of UNSUBSCRIBE is as follows:
UNSUBSCRIBE Message {
Subscribe ID (i)
}
Figure 7: MOQT UNSUBSCRIBE Message
* Subscribe ID: Subscription Identifier as defined in Section 6.4.
6.7. ANNOUNCE_OK
The subscriber sends an ANNOUNCE_OK control message to acknowledge
the successful authorization and acceptance of an ANNOUNCE message.
ANNOUNCE_OK
{
Track Namespace (tuple),
}
Figure 8: MOQT ANNOUNCE_OK Message
* Track Namespace: Identifies the track namespace in the ANNOUNCE
message for which this response is provided.
Curley, et al. Expires 23 March 2025 [Page 32]
Internet-Draft moq-transport September 2024
6.8. ANNOUNCE_ERROR
The subscriber sends an ANNOUNCE_ERROR control message for tracks
that failed authorization.
ANNOUNCE_ERROR
{
Track Namespace (tuple),
Error Code (i),
Reason Phrase (b),
}
Figure 9: MOQT ANNOUNCE_ERROR Message
* Track Namespace: Identifies the track namespace in the ANNOUNCE
message for which this response is provided.
* Error Code: Identifies an integer error code for announcement
failure.
* Reason Phrase: Provides the reason for announcement error.
6.9. ANNOUNCE_CANCEL
The subscriber sends an ANNOUNCE_CANCEL control message to indicate
it will stop sending new subscriptions for tracks within the provided
Track Namespace.
If a publisher receives new subscriptions for that namespace after
receiving an ANNOUNCE_CANCEL, it SHOULD close the session as a
'Protocol Violation'.
ANNOUNCE_CANCEL Message {
Track Namespace (tuple),
Error Code (i),
Reason Phrase (b),
}
Figure 10: MOQT ANNOUNCE_CANCEL Message
* Track Namespace: Identifies a track's namespace as defined in
(Section 2.4.1).
* Error Code: Identifies an integer error code for canceling the
announcement.
* Reason Phrase: Provides the reason for announcement cancelation.
Curley, et al. Expires 23 March 2025 [Page 33]
Internet-Draft moq-transport September 2024
6.10. TRACK_STATUS_REQUEST
A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the
control stream to obtain information about the current status of a
given track.
A TRACK_STATUS message MUST be sent in response to each
TRACK_STATUS_REQUEST.
TRACK_STATUS_REQUEST Message {
Track Namespace (tuple),
Track Name (b),
}
Figure 11: MOQT TRACK_STATUS_REQUEST Message
6.11. SUBSCRIBE_NAMESPACE
The subscriber sends the SUBSCRIBE_NAMESPACE control message to a
publisher to request the current set of matching announcements, as
well as future updates to the set.
SUBSCRIBE_NAMESPACE Message {
Track Namespace Prefix (tuple),
Number of Parameters (i),
Parameters (..) ...,
}
Figure 12: MOQT SUBSCRIBE_NAMESPACE Message
* Track Namespace Prefix: An ordered N-Tuple of byte fields which
are matched against track namespaces known to the publisher. For
example, if the publisher is a relay that has received ANNOUNCE
messages for namespaces ("example.com", "meeting=123",
"participant=100") and ("example.com", "meeting=123",
"participant=200"), a SUBSCRIBE_NAMESPACE for ("example.com",
"meeting=123") would match both.
* Parameters: The parameters are defined in Section 6.1.1.
The publisher will respond with SUBSCRIBE_NAMESPACE_OK or
SUBSCRIBE_NAMESPACE_ERROR. If the SUBSCRIBE_NAMESPACE is successful,
the publisher will forward any matching ANNOUNCE messages to the
subscriber that it has not yet sent. If the set of matching ANNOUNCE
messages changes, the publisher sends the corresponding ANNOUNCE or
UNANNOUNCE message.
Curley, et al. Expires 23 March 2025 [Page 34]
Internet-Draft moq-transport September 2024
A subscriber cannot make overlapping namespace subscriptions on a
single session. Within a session, if a publisher receives a
SUBSCRIBE_NAMESPACE with a Track Namespace Prefix that is a prefix of
an earlier SUBSCRIBE_NAMESPACE or vice versa, it MUST respond with
SUBSCRIBE_NAMESPACE_ERROR, with error code
SUBSCRIBE_NAMESPACE_OVERLAP.
The publisher MUST ensure the subscriber is authorized to perform
this namespace subscription.
SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE
and UNANNOUNCE messages to a subscriber. It is useful in
applications or relays where subscribers are only interested in or
authorized to access a subset of available announcements.
6.12. UNSUBSCRIBE_NAMESPACE
A subscriber issues a UNSUBSCRIBE_NAMESPACE message to a publisher
indicating it is no longer interested in ANNOUNCE and UNANNOUNCE
messages for the specified track namespace prefix.
The format of UNSUBSCRIBE_NAMESPACE is as follows:
UNSUBSCRIBE_NAMESPACE Message {
Track Namespace Prefix (tuple)
}
Figure 13: MOQT UNSUBSCRIBE Message
* Track Namespace Prefix: As defined in Section 6.11.
6.13. SUBSCRIBE_OK
A publisher sends a SUBSCRIBE_OK control message for successful
subscriptions.
SUBSCRIBE_OK
{
Subscribe ID (i),
Expires (i),
Group Order (8),
ContentExists (f),
[Largest Group ID (i)],
[Largest Object ID (i)],
Number of Parameters (i),
Subscribe Parameters (..) ...
}
Curley, et al. Expires 23 March 2025 [Page 35]
Internet-Draft moq-transport September 2024
Figure 14: MOQT SUBSCRIBE_OK Message
* Subscribe ID: Subscription Identifier as defined in Section 6.4.
* Expires: Time in milliseconds after which the subscription is no
longer valid. A value of 0 indicates that the subscription does
not expire or expires at an unknown time. Expires is advisory and
a subscription can end prior to the expiry time or last longer.
* Group Order: Indicates the subscription will be delivered in
Ascending (0x1) or Descending (0x2) order by group. See
Section 4. Values of 0x0 and those larger than 0x2 are a protocol
error.
* ContentExists: 1 if an object has been published on this track, 0
if not. If 0, then the Largest Group ID and Largest Object ID
fields will not be present.
* Largest Group ID: The largest Group ID available for this track.
This field is only present if ContentExists has a value of 1.
* Largest Object ID: The largest Object ID available within the
largest Group ID for this track. This field is only present if
ContentExists has a value of 1.
* Subscribe Parameters: The parameters are defined in Section 6.1.1.
6.14. SUBSCRIBE_ERROR
A publisher sends a SUBSCRIBE_ERROR control message in response to a
failed SUBSCRIBE.
SUBSCRIBE_ERROR
{
Subscribe ID (i),
Error Code (i),
Reason Phrase (b),
Track Alias (i),
}
Figure 15: MOQT SUBSCRIBE_ERROR Message
* Subscribe ID: Subscription Identifier as defined in Section 6.4.
* Error Code: Identifies an integer error code for subscription
failure.
* Reason Phrase: Provides the reason for subscription error.
Curley, et al. Expires 23 March 2025 [Page 36]
Internet-Draft moq-transport September 2024
* Track Alias: When Error Code is 'Retry Track Alias', the
subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias
instead. If this Track Alias is already in use, the subscriber
MUST close the connection with a Duplicate Track Alias error
(Section 3.5).
6.15. SUBSCRIBE_DONE
A publisher sends a SUBSCRIBE_DONE message to indicate it is done
publishing Objects for that subscription. The Status Code indicates
why the subscription ended, and whether it was an error.
The format of SUBSCRIBE_DONE is as follows:
SUBSCRIBE_DONE Message {
Subscribe ID (i),
Status Code (i),
Reason Phrase (b),
ContentExists (f),
[Final Group (i)],
[Final Object (i)],
}
Figure 16: MOQT SUBSCRIBE_DONE Message
* Subscribe ID: Subscription identifier as defined in Section 6.4.
* Status Code: An integer status code indicating why the
subscription ended.
* Reason Phrase: Provides the reason for subscription error.
* ContentExists: 1 if an object has been published for this
subscription, 0 if not. If 0, then the Final Group and Final
Object fields will not be present.
* Final Group: The largest Group ID sent by the publisher in an
OBJECT message in this track.
* Final Object: The largest Object ID sent by the publisher in an
OBJECT message in the Final Group for this track.
6.16. MAX_SUBSCRIBE_ID
A publisher sends a MAX_SUBSCRIBE_ID message to increase the number
of subscriptions a subscriber can create within a session.
Curley, et al. Expires 23 March 2025 [Page 37]
Internet-Draft moq-transport September 2024
The Maximum Subscribe Id MUST only increase within a session, and
receipt of a MAX_SUBSCRIBE_ID message with an equal or smaller
Subscribe ID value is a 'Protocol Violation'.
MAX_SUBSCRIBE_ID
{
Subscribe ID (i),
}
Figure 17: MOQT MAX_SUBSCRIBE_ID Message
* Subscribe ID: The new Maximum Subscribe ID for the session. If a
Subscribe ID equal or larger than this is received in any message,
including SUBSCRIBE, the publisher MUST close the session with an
error of 'Too Many Subscribes'. More on Subscribe ID in
Section 6.4.
6.17. ANNOUNCE
The publisher sends the ANNOUNCE control message to advertise where
the receiver can route SUBSCRIBEs for tracks within the announced
Track Namespace. The receiver verifies the publisher is authorized
to publish tracks under this namespace.
ANNOUNCE Message {
Track Namespace (tuple),
Number of Parameters (i),
Parameters (..) ...,
}
Figure 18: MOQT ANNOUNCE Message
* Track Namespace: Identifies a track's namespace as defined in
(Section 2.4.1)
* Parameters: The parameters are defined in Section 6.1.1.
6.18. UNANNOUNCE
The publisher sends the UNANNOUNCE control message to indicate its
intent to stop serving new subscriptions for tracks within the
provided Track Namespace.
UNANNOUNCE Message {
Track Namespace (tuple),
}
Figure 19: MOQT UNANNOUNCE Message
Curley, et al. Expires 23 March 2025 [Page 38]
Internet-Draft moq-transport September 2024
* Track Namespace: Identifies a track's namespace as defined in
(Section 2.4.1).
6.19. TRACK_STATUS
A publisher sends a 'TRACK_STATUS' message on the control stream in
response to a TRACK_STATUS_REQUEST message.
TRACK_STATUS Message {
Track Namespace (tuple),
Track Name (b),
Status Code (i),
Last Group ID (i),
Last Object ID (i),
}
Figure 20: MOQT TRACK_STATUS Message
The 'Status Code' field provides additional information about the
status of the track. It MUST hold one of the following values. Any
other value is a malformed message.
0x00: The track is in progress, and subsequent fields contain the
highest group and object ID for that track.
0x01: The track does not exist. Subsequent fields MUST be zero, and
any other value is a malformed message.
0x02: The track has not yet begun. Subsequent fields MUST be zero.
Any other value is a malformed message.
0x03: The track has finished, so there is no "live edge." Subsequent
fields contain the highest Group and object ID known.
0x04: The publisher is a relay that cannot obtain the current track
status from upstream. Subsequent fields contain the largest group
and object ID known.
Any other value in the Status Code field is a malformed message.
When a relay is subscribed to a track, it can simply return the
highest group and object ID it has observed, whether or not that
object was cached or completely delivered. If not subscribed, a
relay SHOULD send a TRACK_STATUS_REQUEST upstream to obtain updated
information.
Alternatively, the relay MAY subscribe to the track to obtain the
same information.
Curley, et al. Expires 23 March 2025 [Page 39]
Internet-Draft moq-transport September 2024
If a relay cannot or will not do either, it should return its best
available information with status code 0x04.
The receiver of multiple TRACK_STATUS messages for a track uses the
information from the latest arriving message, as they are delivered
in order on a single stream.
6.20. SUBSCRIBE_NAMESPACE_OK
A publisher sends a SUBSCRIBE_NAMESPACE_OK control message for
successful namespace subscriptions.
SUBSCRIBE_NAMESPACE_OK
{
Track Namespace Prefix (tuple),
}
Figure 21: MOQT SUBSCRIBE_NAMESPACE_OK Message
* Track Namespace Prefix: As defined in Section 6.11.
6.21. SUBSCRIBE_NAMESPACE_ERROR
A publisher sends a SUBSCRIBE_NAMESPACE_ERROR control message in
response to a failed SUBSCRIBE_NAMESPACE.
SUBSCRIBE_NAMESPACE_ERROR
{
Track Namespace Prefix (tuple),
Error Code (i),
Reason Phrase (b),
}
Figure 22: MOQT SUBSCRIBE_NAMESPACE_ERROR Message
* Track Namespace Prefix: As defined in Section 6.11.
* Error Code: Identifies an integer error code for the namespace
subscription failure.
* Reason Phrase: Provides the reason for the namespace subscription
error.
7. Data Streams
A publisher sends Objects matching a subscription on Data Streams.
Curley, et al. Expires 23 March 2025 [Page 40]
Internet-Draft moq-transport September 2024
All unidirectional MOQT streams, as well as all datagrams, start with
a variable-length integer indicating the type of the stream in
question.
+=====+========================================+
| ID | Stream Type |
+=====+========================================+
| 0x1 | OBJECT_DATAGRAM (Section 7.2) |
+-----+----------------------------------------+
| 0x2 | STREAM_HEADER_TRACK (Section 7.3.1) |
+-----+----------------------------------------+
| 0x4 | STREAM_HEADER_SUBGROUP (Section 7.3.2) |
+-----+----------------------------------------+
Table 5
An endpoint that receives an unknown stream type MUST close the
session.
Every Track has a single 'Object Forwarding Preference' and the
Original Publisher MUST NOT mix different forwarding preferences
within a single track. If a subscriber receives different forwarding
preferences for a track, it SHOULD close the session with an error of
'Protocol Violation'.
7.1. Object Headers
An OBJECT message contains a range of contiguous bytes from from the
specified track, as well as associated metadata required to deliver,
cache, and forward it. Objects are sent by publishers.
7.1.1. Canonical Object Fields
A canonical MoQ Object has the following information:
* Track Namespace and Track Name: The track this object belongs to.
* Group ID: The object is a member of the indicated group ID
Section 2.3 within the track.
* Object ID: The order of the object within the group. The IDs
starts at 0, increasing sequentially for each object within the
group.
* Publisher Priority: An 8 bit integer indicating the publisher's
priority for the Object Section 4.
Curley, et al. Expires 23 March 2025 [Page 41]
Internet-Draft moq-transport September 2024
* Object Forwarding Preference: An enumeration indicating how a
publisher sends an object. The preferences are Track, Subgroup,
and Datagram. An Object MUST be sent according to its Object
Forwarding Preference, described below.
* Subgroup ID: The object is a member of the indicated subgroup ID
(Section 2.2) within the group. This field is omitted if the
Object Forwarding Preference is Track or Datagram.
* Object Status: As enumeration used to indicate missing objects or
mark the end of a group or track. See Section 7.1.1.1 below.
* Object Payload: An opaque payload intended for an End Subscriber
and SHOULD NOT be processed by a relay. Only present when 'Object
Status' is Normal (0x0).
7.1.1.1. Object Status
The Object Status informs subscribers what objects will not be
received because they were never produced, are no longer available,
or because they are beyond the end of a group or track.
Status can have following values:
* 0x0 := Normal object. The payload is array of bytes and can be
empty.
* 0x1 := Indicates Object does not exist. Indicates that this
object does not exist at any publisher and it will not be
published in the future. This SHOULD be cached.
* 0x3 := Indicates end of Group. ObjectId is one greater that the
largest object produced in the group identified by the GroupID.
This is sent right after the last object in the group. If the
ObjectID is 0, it indicates there are no Objects in this Group.
This SHOULD be cached. A publisher MAY use an end of Group object
to signal the end of all open Subgroups in a Group.
* 0x4 := Indicates end of Track and Group. GroupID is one greater
than the largest group produced in this track and the ObjectId is
one greater than the largest object produced in that group. This
is sent right after the last object in the track. This SHOULD be
cached.
* 0x5 := Indicates end of Subgroup. Object ID is one greater than
the largest normal object ID in the Subgroup.
Curley, et al. Expires 23 March 2025 [Page 42]
Internet-Draft moq-transport September 2024
Any other value SHOULD be treated as a protocol error and terminate
the session with a Protocol Violation (Section 3.5). Any object with
a status code other than zero MUST have an empty payload.
Though some status information could be inferred from QUIC stream
state, that information is not reliable and cacheable.
7.2. Object Datagram Message
An OBJECT_DATAGRAM message carries a single object in a datagram.
An Object received in an OBJECT_DATAGRAM message has an Object
Forwarding Preference = Datagram. To send an Object with Object
Forwarding Preference = Datagram, determine the length of the header
and payload and send the Object as datagram. In certain scenarios
where the object size can be larger than maximum datagram size for
the session, the Object will be dropped.
OBJECT_DATAGRAM Message {
Subscribe ID (i),
Track Alias (i),
Group ID (i),
Object ID (i),
Publisher Priority (8),
Object Payload Length (i),
[Object Status (i)],
Object Payload (..),
}
Figure 23: MOQT OBJECT_DATAGRAM Message
7.3. Streams
When objects are sent on streams, the stream begins with a stream
header message and is followed by one or more sets of serialized
object fields. If a stream ends gracefully in the middle of a
serialized Object, terminate the session with a Protocol Violation.
A publisher SHOULD NOT open more than one stream at a time with the
same stream header message type and fields.
TODO: figure out how a relay closes these streams
Curley, et al. Expires 23 March 2025 [Page 43]
Internet-Draft moq-transport September 2024
7.3.1. Stream Header Track
When a stream begins with STREAM_HEADER_TRACK, all objects on the
stream belong to the track requested in the Subscribe message
identified by Subscribe ID. All objects on the stream have the
Publisher Priority specified in the stream header.
STREAM_HEADER_TRACK Message {
Subscribe ID (i)
Track Alias (i),
Publisher Priority (8),
}
Figure 24: MOQT STREAM_HEADER_TRACK Message
All Objects received on a stream opened with STREAM_HEADER_TRACK have
an Object Forwarding Preference = Track.
To send an Object with Object Forwarding Preference = Track, find the
open stream that is associated with the subscription, or open a new
one and send the STREAM_HEADER_TRACK if needed, then serialize the
following object fields. The Object Status field is only sent if the
Object Payload Length is zero.
{
Group ID (i),
Object ID (i),
Object Payload Length (i),
[Object Status (i)],
Object Payload (..),
}
Figure 25: MOQT Track Stream Object Fields
A publisher MUST NOT send an Object on a stream if its Group ID is
less than a previously sent Group ID on that stream, or if its Object
ID is less than or equal to a previously sent Object ID with the same
Group ID.
7.3.2. Stream Header Subgroup
When a stream begins with STREAM_HEADER_SUBGROUP, all objects on the
stream belong to the track requested in the Subscribe message
identified by Subscribe ID and the subgroup indicated by 'Group ID'
and Subgroup ID.
Curley, et al. Expires 23 March 2025 [Page 44]
Internet-Draft moq-transport September 2024
STREAM_HEADER_SUBGROUP Message {
Subscribe ID (i),
Track Alias (i),
Group ID (i),
Subgroup ID (i),
Publisher Priority (8),
}
Figure 26: MOQT STREAM_HEADER_SUBGROUP Message
All Objects received on a stream opened with STREAM_HEADER_SUBGROUP
have an Object Forwarding Preference = Subgroup.
To send an Object with Object Forwarding Preference = Subgroup, find
the open stream that is associated with the subscription, Group ID
and Subgroup ID, or open a new one and send the
STREAM_HEADER_SUBGROUP. Then serialize the following fields.
The Object Status field is only sent if the Object Payload Length is
zero.
{
Object ID (i),
Object Payload Length (i),
[Object Status (i)],
Object Payload (..),
}
Figure 27: MOQT Group Stream Object Fields
A publisher MUST NOT send an Object on a stream if its Object ID is
less than a previously sent Object ID within a given group in that
stream.
7.4. Examples
Sending a track on one stream:
Curley, et al. Expires 23 March 2025 [Page 45]
Internet-Draft moq-transport September 2024
STREAM_HEADER_TRACK {
Subscribe ID = 1
Track Alias = 1
Publisher Priority = 0
}
{
Group ID = 0
Object ID = 0
Object Payload Length = 4
Payload = "abcd"
}
{
Group ID = 1
Object ID = 0
Object Payload Length = 4
Payload = "efgh"
}
Sending a subgroup on one stream:
Stream = 2
STREAM_HEADER_SUBGROUP {
Subscribe ID = 2
Track Alias = 2
Group ID = 0
Subgroup ID = 0
Publisher Priority = 0
}
{
Object ID = 0
Object Payload Length = 4
Payload = "abcd"
}
{
Object ID = 1
Object Payload Length = 4
Payload = "efgh"
}
8. Security Considerations
TODO: Expand this section, including subscriptions.
8.1. Resource Exhaustion
Live content requires significant bandwidth and resources. Failure
to set limits will quickly cause resource exhaustion.
Curley, et al. Expires 23 March 2025 [Page 46]
Internet-Draft moq-transport September 2024
MOQT uses stream limits and flow control to impose resource limits at
the network layer. Endpoints SHOULD set flow control limits based on
the anticipated bitrate.
Endpoints MAY impose a MAX STREAM count limit which would restrict
the number of concurrent streams which a MOQT Streaming Format could
have in flight.
The publisher prioritizes and transmits streams out of order.
Streams might be starved indefinitely during congestion. The
publisher and subscriber MUST cancel a stream, preferably the lowest
priority, after reaching a resource limit.
9. IANA Considerations
TODO: fill out currently missing registries:
* MOQT version numbers
* Setup parameters
* Subscribe parameters
* Subscribe Error codes
* Subscribe Namespace Error codes
* Announce Error codes
* Announce Cancel Reason codes
* Message types
TODO: register the URI scheme and the ALPN
Contributors
* Alan Frindell
* Ali Begen
* Charles Krasic
* Christian Huitema
* Cullen Jennings
* James Hurley
Curley, et al. Expires 23 March 2025 [Page 47]
Internet-Draft moq-transport September 2024
* Jordi Cenzano
* Mike English
* Mo Zanaty
* Will Law
References
Normative References
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[WebTransport]
Frindell, A., Kinnear, E., and V. Vasiliev, "WebTransport
over HTTP/3", Work in Progress, Internet-Draft, draft-
Curley, et al. Expires 23 March 2025 [Page 48]
Internet-Draft moq-transport September 2024
ietf-webtrans-http3-10, 25 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-
webtrans-http3-10>.
Informative References
[I-D.ietf-webtrans-overview]
Vasiliev, V., "The WebTransport Protocol Framework", Work
in Progress, Internet-Draft, draft-ietf-webtrans-overview-
08, 25 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-
webtrans-overview-08>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
Authors' Addresses
Luke Curley
Discord
Email: kixelated@gmail.com
Kirill Pugin
Meta
Email: ikir@meta.com
Suhas Nandakumar
Cisco
Email: snandaku@cisco.com
Victor Vasiliev
Google
Email: vasilvv@google.com
Ian Swett (editor)
Google
Email: ianswett@google.com
Curley, et al. Expires 23 March 2025 [Page 49]