]> Meta

afrind@meta.com

Google

ianswett@google.com

Web and Internet Transport Media Over QUIC media over quic flow control This document defines an extension to Media over QUIC Transport (MOQT) that lets a subscriber limit the number of subgroup streams and the total bytes a publisher may send for an individual subscription. It defines a Setup Option to negotiate the extension and set initial limits, message parameters for advertising these limits, messages for granting credit and signaling flow control state, and a session error code. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Media over QUIC Transport (MOQT) delivers a subscription's Objects across one or more subgroup streams, but provides no way for a subscriber to bound how many streams or bytes a publisher sends for that subscription. Transport-layer flow control operates per stream and per session, so it cannot express a limit spanning a subscription's streams. This extension lets a subscriber limit the total subgroup streams (MAX_SUB_STREAMS) and total bytes (MAX_SUB_BYTES) for a subscription, and grant further credit with SUB_FLOW_CONTROL_UPDATE. Publishers signal that they are blocked with SUB_STREAMS_BLOCKED and SUB_BYTES_BLOCKED, and report the final size of reset subgroup streams with SUBGROUP_RESET. Violations terminate the session with FLOW_CONTROL_EXCEEDED. Support for this extension is negotiated during session establishment using the SUBSCRIPTION_FLOW_CONTROL Setup Option ().

Conventions 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 when, and only when, they appear in all capitals, as shown here. This document uses the terminology and wire format notation of . The subscriber sets the limits and the publisher honors them, regardless of which endpoint is the client or server.

Extension Negotiation

SUBSCRIPTION_FLOW_CONTROL Setup Option An endpoint indicates support for this extension by including the SUBSCRIPTION_FLOW_CONTROL Setup Option in its SETUP message. The option also sets the initial limits for subscriptions in which the endpoint is the subscriber ().

SUBSCRIPTION_FLOW_CONTROL Setup Option

• Initial Max Sub Streams: The initial MAX_SUB_STREAMS limit.
• Initial Max Sub Bytes: The initial MAX_SUB_BYTES limit.

When an endpoint receives a SUBSCRIPTION_FLOW_CONTROL Setup Option whose value does not contain exactly two varints, it MUST close the session with a KEY_VALUE_FORMATTING_ERROR. The extension is negotiated when an endpoint has both sent and received this option, per the extension negotiation described in . It applies to both directions of the session. An endpoint that offers this extension MUST support RESET_STREAM_AT (). When an endpoint negotiates this extension with a peer that does not support RESET_STREAM_AT, it MUST close the session with a PROTOCOL_VIOLATION.

Flow Control Model Every subscription has a stream limit and a byte limit, initialized from the subscriber's SUBSCRIPTION_FLOW_CONTROL Setup Option (), which SUBSCRIBE or SUBSCRIBE_TRACKS can override (). The subscriber grants additional credit with SUB_FLOW_CONTROL_UPDATE (). Credit is not granted with REQUEST_UPDATE because it solicits a response, which is unnecessary. The limits apply only to subgroup streams; Objects sent as datagrams are not counted. Limits and the messages defined here are scoped to a single session and are not forwarded. A relay honors its downstream subscriber's limits and independently sets its own limits toward its upstream publisher. Limits are per subscription and cumulative over its lifetime: the stream count is the total number of subgroup streams opened, and the byte count is the total bytes sent across them (). A publisher MUST NOT exceed a limit in effect for a subscription. When a subscriber detects a violation, it MUST close the session with a FLOW_CONTROL_EXCEEDED (). The subscriber attributes each subgroup stream to a subscription by its Track Alias, so when the extension is negotiated, a publisher MUST NOT assign the same Track Alias to more than one subscription in the session, even if the subscriptions are to the same Track or are not concurrent. When a subscriber detects a SUBSCRIBE_OK or PUBLISH with a Track Alias previously assigned to another subscription, it MUST close the session with a DUPLICATE_TRACK_ALIAS.

Stream Sequence When the extension is negotiated, every SUBGROUP_HEADER includes a Stream Sequence field:

SUBGROUP_HEADER with Stream Sequence

Stream Sequence uniquely identifies a subgroup stream within its subscription. The publisher sets it to 0 on the first subgroup stream it opens for a subscription and increments it by 1 for each subsequent stream. When a subscriber receives a SUBGROUP_HEADER with a Stream Sequence greater than or equal to the stream limit, it MUST close the session with a FLOW_CONTROL_EXCEEDED. When a subscriber detects a Stream Sequence it has already received for the subscription, it MUST close the session with a PROTOCOL_VIOLATION.

Publisher Behavior When Blocked When sending would exceed a limit, the publisher MUST NOT open a subgroup stream beyond the stream limit and MUST NOT send bytes beyond the byte limit, even if this means stopping in the middle of a stream. It retains the blocked Objects until it receives additional credit, and SHOULD send SUB_STREAMS_BLOCKED or SUB_BYTES_BLOCKED, as applicable. Being blocked does not extend an Object's lifetime; the delivery timeouts of (SUBGROUP_DELIVERY_TIMEOUT and OBJECT_DELIVERY_TIMEOUT) continue to apply. A subgroup stream reset because of an expired timeout is accounted for as described in . If retaining blocked Objects would exceed its resource limits, a publisher MAY terminate the subscription with PUBLISH_DONE and TOO_FAR_BEHIND ().

Byte Accounting The byte count includes all bytes serialized on the subscription's subgroup streams: the SUBGROUP_HEADER (including the stream type) and each Object's header fields and payload. It excludes QUIC and WebTransport framing. Accounting is at byte granularity. A publisher MAY send part of an Object and stop at the byte limit, leaving the stream open and resuming when credit arrives, subject to the delivery timeout and ordering rules of . Each subgroup stream consumes byte credit exactly once. For a stream closed with a FIN, the bytes received consume credit. When a publisher resets a stream, it reports the bytes sent on it in the Final Size field of SUBGROUP_RESET (), and the stream consumes that much credit. A publisher MUST reset subgroup streams using RESET_STREAM_AT with a reliable_size that includes the SUBGROUP_HEADER, so the subscriber always learns the stream's Stream Sequence () and can match it to the corresponding SUBGROUP_RESET. On native QUIC, this Final Size equals that of RESET_STREAM_AT (). WebTransport () implementations do not necessarily expose the transport Final Size. When a subscriber receives a SUBGROUP_RESET whose Final Size does not match the one reported by the transport, it MUST close the session with a PROTOCOL_VIOLATION. For example, with 100 bytes of credit and a 200-byte Object:

Message Parameters This extension defines two Message Parameters (). If set in SUBSCRIBE or SUBSCRIBE_TRACKS, each parameter overrides the initial limit (), even if the value is smaller. In PUBLISH, it echoes the value from the corresponding SUBSCRIBE_TRACKS. When sent in SUB_FLOW_CONTROL_UPDATE, the value is added to the current limit. A SUB_FLOW_CONTROL_UPDATE MUST NOT raise a limit above 2^64-1. When a publisher receives a SUB_FLOW_CONTROL_UPDATE that would raise a limit above 2^64-1, it MUST close the session with a PROTOCOL_VIOLATION.

MAX_SUB_STREAMS Parameter MAX_SUB_STREAMS (Parameter Type 0x33) is a varint limiting the total number of subgroup streams the publisher can open for the subscription.

MAX_SUB_BYTES Parameter MAX_SUB_BYTES (Parameter Type 0x36) is a varint limiting the total bytes the publisher can send across the subscription's subgroup streams ().

Messages Each message below is sent on the subscription's request stream using MOQT control message framing with a 16-bit Length (). None consumes a Request ID or solicits a response.

SUB_FLOW_CONTROL_UPDATE A subscriber sends SUB_FLOW_CONTROL_UPDATE to grant additional credit. It MAY be sent any time after the subscription is established, whether or not the publisher is blocked, so a subscriber that intends to grant credit MUST keep the send direction of the request stream open. It has no effect if received after the subscription ends. Each parameter value is a delta to the current limit, so limits never decrease. When a publisher receives a SUB_FLOW_CONTROL_UPDATE with a delta of 0, it MUST close the session with a PROTOCOL_VIOLATION.

MOQT SUB_FLOW_CONTROL_UPDATE Message

• Parameters: MAX_SUB_STREAMS and/or MAX_SUB_BYTES, each granting additional credit. When a publisher receives a SUB_FLOW_CONTROL_UPDATE with neither parameter, it MUST close the session with a PROTOCOL_VIOLATION.

SUBGROUP_RESET A publisher sends SUBGROUP_RESET to report the final byte count of a reset subgroup stream ().

MOQT SUBGROUP_RESET Message

• Stream Sequence: The Stream Sequence of the reset subgroup stream ().
• Final Size: The bytes sent on the stream before it was reset.

SUB_STREAMS_BLOCKED A publisher sends SUB_STREAMS_BLOCKED when it wants to open a subgroup stream but MAX_SUB_STREAMS prevents it.

MOQT SUB_STREAMS_BLOCKED Message

• Maximum Streams: The stream limit that was reached.

SUB_BYTES_BLOCKED A publisher sends SUB_BYTES_BLOCKED when it has data to send but MAX_SUB_BYTES prevents it.

MOQT SUB_BYTES_BLOCKED Message

• Maximum Bytes: The byte limit that was reached.

Error Handling

FLOW_CONTROL_EXCEEDED (0x1C):

A session termination error code indicating that the peer violated a subscription flow control limit (MAX_SUB_STREAMS or MAX_SUB_BYTES).

Security Considerations These limits let a subscriber bound the resources a publisher consumes per subscription, complementing transport flow control. A subscriber SHOULD set limits consistent with the resources it will devote to a subscription. SUB_STREAMS_BLOCKED and SUB_BYTES_BLOCKED are advisory. A subscriber MUST NOT rely on receiving them and MUST enforce limits regardless. A subscriber that grants credit only in response to them could stall a publisher that does not send them; granting credit proactively avoids this. A misbehaving publisher could under-report Final Size in SUBGROUP_RESET to evade MAX_SUB_BYTES; describes how a subscriber detects this when the transport reports the stream's Final Size.

IANA Considerations This document registers entries in registries established by . All codepoints are provisional pending working group adoption and can be reassigned by IANA to avoid collisions.

Setup Option IANA is requested to add the following entry to the "MOQT Setup Options" registry:

Type	Name	Specification
0x0B	SUBSCRIPTION_FLOW_CONTROL

Message Parameters IANA is requested to add the following entries to the "MOQT Message Parameters" registry:

Parameter Type	Parameter Name	Specification
0x33	MAX_SUB_STREAMS
0x36	MAX_SUB_BYTES

Message Types IANA is requested to add the following entries to the "MOQT Message Types" registry. None is the first message on a stream.

ID	Messages	Stream
0x12	SUB_STREAMS_BLOCKED ()	Request
0x13	SUB_BYTES_BLOCKED ()	Request
0x14	SUB_FLOW_CONTROL_UPDATE ()	Request
0x1F	SUBGROUP_RESET ()	Request

Session Termination Error Code IANA is requested to add the following entry to the "MOQT Session Termination Error Codes" registry:

Name	Code	Specification
FLOW_CONTROL_EXCEEDED	0x1C

References Normative References Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. Fastly QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Meta Apple Inc. Google WebTransport over HTTP/3 is a binding of the WebTransport protocol framework [OVERVIEW] to HTTP/3 [HTTP3]. It provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. WebTransport enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport.

Acknowledgments This extension is derived from a proposal to add subscription flow control to the base Media over QUIC Transport protocol. The initial conversion of that proposal into this extension draft was drafted with the assistance of Claude Code.