Media over QUIC - Lite

3.1. Session

A Session consists of a connection between a client and a server. There is currently no P2P support within QUIC so it's out of scope for moq-lite.¶

A session is established after the necessary QUIC, WebTransport, and moq-lite handshakes have completed. The moq-lite handshake is simple and consists of version and extension negotiation.¶

While moq-lite is a point-to-point protocol, it's intended to work end-to-end via relays. Each client establishes a session with a CDN edge server, ideally the closest one. Any broadcasts and subscriptions are transparently proxied by the CDN behind the scenes.¶

3.2. Broadcast

A Broadcast is a collection of Tracks from a single publisher. This corresponds to a MoqTransport's "track namespace".¶

A publisher may produce multiple broadcasts, each of which is advertised via an ANNOUNCE message. The subscriber uses the ANNOUNCE_PLEASE message to discover available broadcasts. These announcements are live and can change over time, allowing for dynamic origin discovery.¶

A broadcast consists of any number of Tracks. The contents and relationship between these tracks is determined by the application or via an out-of-band mechanism.¶

3.3. Track

A Track is a series of Groups identified by a unique name within a Broadcast.¶

A track consists of a single active Group at any moment, called the "latest group". When a new Group is started, the previous Group is closed and may be dropped for any reason. The duration before an incomplete group is dropped is determined by the application and the publisher/subscriber's latency target.¶

Every subscription is scoped to a single Track. A subscription will always start at the latest Group and continues until either the publisher or subscriber cancels the subscription.¶

A subscriber chooses the priority of each subscription, hinting to the publisher which Track should arrive first during congestion. This enables the most important content to arrive during network degradation while still respecting encoding dependencies.¶

3.4. Group

A Group is an ordered stream of Frames within a Track.¶

Each group consists of an append-only list of Frames. A Group is served by a dedicated QUIC stream which is closed on completion, reset by the publisher, or cancelled by the subscriber. This ensures that all Frames within a Group arrive reliably and in order.¶

In contrast, Groups may arrive out of order due to network congestion and prioritization. The application should be prepared to handle this with a jitter buffer at the group level.¶

3.5. Frame

A Frame is a payload of bytes within a Group.¶

A frame is used to represent a chunk of data with a known size. A frame should represent a single moment in time and avoid any buffering that would increase latency.¶

There's no timestamp or metadata associated with a Frame, this is the responsibility of the application.¶

4.1. Connection

moq-lite runs on top of WebTransport. WebTransport is a layer on top of QUIC and HTTP/3, required for web support. The API is nearly identical to QUIC with the exception of stream IDs.¶

How the WebTransport connection is authenticated is out-of-scope for this draft.¶

4.2. Termination

QUIC bidirectional streams have an independent send and receive direction. Rather than deal with half-open states, moq-lite combines both sides. If an endpoint closes the send direction of a stream, the peer MUST also close their send direction.¶

moq-lite contains many long-lived transactions, such as subscriptions and announcements. These are terminated when the underlying QUIC stream is terminated.¶

To terminate a stream, an endpoint may: - close the send direction (STREAM with FIN) to gracefully terminate (all messages are flushed). - reset the send direction (RESET_STREAM) to immediately terminate.¶

After resetting the send direction, an endpoint MAY close the recv direction (STOP_SENDING). However, it is ultimately the other peer's responsibility to close their send direction.¶

4.3. Handshake

After a connection is established, the client opens a Session Stream and sends a SESSION_CLIENT message, to which the server replies with a SESSION_SERVER message. The session is active until either endpoint closes or resets the Session Stream.¶

This session handshake is used to negotiate the moq-lite version and any extensions. See the Extension section for more information.¶

5.1. Bidirectional Streams

Bidirectional streams are used for control streams. There's a 1-byte STREAM_TYPE at the beginning of each stream.¶

5.2. Unidirectional Streams

Unidirectional streams are used for data transmission.¶

6.1. Message Length

Most messages are prefixed with a variable-length integer indicating the number of bytes in the message payload that follows. This length field does not include the length of the varint length itself.¶

An implementation SHOULD close the connection with a PROTOCOL_VIOLATION if it receives a message with an unexpected length. The version and extensions should be used to support new fields, not the message length.¶

6.2. STREAM_TYPE

All streams start with a short header indicating the stream type.¶

STREAM_TYPE {
  Stream Type (i)
}

The stream ID depends on if it's a bidirectional or unidirectional stream, as indicated in the Streams section. A receiver MUST close the session if it receives an unknown stream type.¶

6.3. SESSION_CLIENT

The client initiates the session by sending a SESSION_CLIENT message.¶

SESSION_CLIENT Message {
  Message Length (i)
  Supported Versions Count (i)
  Supported Version (i)
  Extension Count (i)
  [
    Extension ID (i)
    Extension Payload (b)
  ]...
}

6.4. SESSION_SERVER

The server responds with the selected version and any extensions.¶

SESSION_SERVER Message {
  Message Length (i)
  Selected Version (i)
  Extension Count (i)
  [
    Extension ID (i)
    Extension Payload (b)
  ]...
}

6.5. SESSION_UPDATE

SESSION_UPDATE Message {
  Message Length (i)
  Session Bitrate (i)
}

Session Bitrate: The estimated bitrate of the QUIC connection in bits per second. This SHOULD be sourced directly from the QUIC congestion controller. A value of 0 indicates that this information is not available.¶

6.6. ANNOUNCE_PLEASE

A subscriber sends an ANNOUNCE_PLEASE message to indicate it wants to receive an ANNOUNCE message for any broadcasts with a path that starts with the requested prefix.¶

ANNOUNCE_PLEASE Message {
  Message Length (i)
  Broadcast Path Prefix (s),
}

Broadcast Path Prefix: Indicate interest for any broadcasts with a path that starts with this prefix.¶

The publisher MUST respond with an ANNOUNCE_INIT message containing any matching and active broadcasts, followed by ANNOUNCE messages for any updates. Implementations SHOULD consider reasonable limits on the number of matching broadcasts to prevent resource exhaustion.¶

6.7. ANNOUNCE_INIT

A publisher sends an ANNOUNCE_INIT message immediately after receiving an ANNOUNCE_PLEASE to communicate all currently active broadcasts that match the requested prefix. Only the suffixes are encoded on the wire, as the full path can be constructed by prepending the requested prefix.¶

This message is useful to avoid race conditions, as ANNOUNCE_INIT does not trickle in like ANNOUNCE messages. For example, an API server that wants to list the current participants could issue an ANNOUNCE_PLEASE and immediately return the ANNOUNCE_INIT response. Without ANNOUNCE_INIT, the API server would have use a timer to wait until ANNOUNCE to guess when all ANNOUNCE messages have been received.¶

ANNOUNCE_INIT Message {
  Message Length (i)
  Suffix Count (i),
  [
    Broadcast Path Suffix (s),
  ]...
}

Suffix Count: The number of active broadcast path suffixes that follow. This can be 0. A publisher MUST NOT include duplicate suffixes in a single ANNOUNCE_INIT message.¶

Broadcast Path Suffix: Each suffix is combined with the broadcast path prefix from ANNOUNCE_PLEASE to form the full broadcast path. This includes all currently active broadcasts matching the prefix.¶

6.8. ANNOUNCE

A publisher sends an ANNOUNCE message to advertise a change in broadcast availability. Only the suffix is encoded on the wire, as the full path can be constructed by prepending the requested prefix.¶

The status is relative to the ANNOUNCE_INIT and all prior ANNOUNCE messages combined. A client MUST ONLY alternate between status values (from active to ended or vice versa).¶

ANNOUNCE Message {
  Message Length (i)
  Announce Status (i),
  Broadcast Path Suffix (s),
}

Announce Status: A flag indicating the announce status.¶

• ended (0): A path is no longer available.¶

• active (1): A path is now available.¶

Broadcast Path Suffix: This is combined with the broadcast path prefix to form the full broadcast path.¶

6.9. SUBSCRIBE

SUBSCRIBE is sent by a subscriber to start a subscription.¶

SUBSCRIBE Message {
  Message Length (i)
  Subscribe ID (i)
  Broadcast Path (s)
  Track Name (s)
  Subscriber Priority (i)
}

Subscribe ID: A unique identifier chosen by the subscriber. A Subscribe ID MUST NOT be reused within the same session, even if the prior subscription has been closed.¶

Subscriber Priority: The transmission priority of the subscription relative to all other active subscriptions within the session. The publisher SHOULD transmit higher values first during congestion.¶

6.10. SUBSCRIBE_UPDATE

A subscriber can modify a subscription with a SUBSCRIBE_UPDATE message.¶

SUBSCRIBE_UPDATE Message {
  Message Length (i)
  Subscriber Priority (i)
}

Subscriber Priority: The new subscriber priority; see SUBSCRIBE.¶

6.11. SUBSCRIBE_OK

The SUBSCRIBE_OK is sent in response to a SUBSCRIBE.¶

SUBSCRIBE_OK Message {
  Message Length = 0
}

That's right, it's an empty message at the moment.¶

6.12. GROUP

The GROUP message contains information about a Group, as well as a reference to the subscription being served.¶

GROUP Message {
  Message Length (i)
  Subscribe ID (i)
  Group Sequence (i)
}

Subscribe ID: The corresponding Subscribe ID. This ID is used to distinguish between multiple subscriptions for the same track.¶

Group Sequence: The sequence number of the group. This SHOULD increase by 1 for each new group.¶

6.13. FRAME

The FRAME message is a payload at a specific point of time.¶

FRAME Message {
  Message Length (i)
  Payload (b)
}

Payload: An application specific payload. A generic library or relay MUST NOT inspect or modify the contents unless otherwise negotiated.¶

7.1. moq-lite-02

• Added SessionCompat stream.¶

• Editorial stuff.¶

7.2. moq-lite-01

• Added ANNOUNCE_INIT.¶

• Added Message Length (i) to all messages.¶

8.1. Deleted Messages

• GOAWAY¶

• MAX_SUBSCRIBE_ID¶

• REQUESTS_BLOCKED¶

• SUBSCRIBE_ERROR¶

• UNSUBSCRIBE¶

• PUBLISH_DONE¶

• PUBLISH¶

• PUBLISH_OK¶

• PUBLISH_ERROR¶

• FETCH¶

• FETCH_OK¶

• FETCH_ERROR¶

• FETCH_CANCEL¶

• FETCH_HEADER¶

• TRACK_STATUS¶

• TRACK_STATUS_OK¶

• TRACK_STATUS_ERROR¶

• PUBLISH_NAMESPACE¶

• PUBLISH_NAMESPACE_OK¶

• PUBLISH_NAMESPACE_ERROR¶

• PUBLISH_NAMESPACE_CANCEL¶

• SUBSCRIBE_NAMESPACE_OK¶

• SUBSCRIBE_NAMESPACE_ERROR¶

• UNSUBSCRIBE_NAMESPACE¶

• OBJECT_DATAGRAM¶

8.2. Renamed Messages

• SUBSCRIBE_NAMESPACE -> ANNOUNCE_PLEASE¶

• SUBGROUP_HEADER -> GROUP¶

8.3. Deleted Fields

Some of these fields occur in multiple messages.¶

• Request ID¶

• Track Alias¶

• Group Order¶

• Filter Type¶

• StartGroup¶

• StartObject¶

• EndGroup¶

• Expires¶

• ContentExists¶

• Largest Group ID¶

• Largest Object ID¶

• Parameters¶

• Subgroup ID¶

• Object ID¶

• Object Status¶

• Extension Headers¶