]> Google

vasilvv@google.com

moqt object ack bitrate adaptation This document defines an extension to Media over QUIC Transport (MOQT) that allows a subscriber to explicitly acknowledge receiving and processing an incoming object. The acknowledgement includes a time delta indicating how early or late the object arrived relative to an application-specified deadline; the subscriber also provides the publisher with the reference window size that can be used to interpret the time delta. A mechanism to negotiate support for the extension, both on the connection and the subscription level, is also defined. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction MOQT delivers objects over QUIC streams and datagrams. While QUIC itself provides an acknowledgement mechanism on the transport level, those acknowledgements are generally not used for application-level logic as they are not available in all APIs; notably, the W3C WebTransport API does not expose them. Additionally, data being received by the QUIC layer does not necessarily mean the application has read and processed it. This document defines a message, called OBJECT_ACK, that lets the subscriber acknowledge individual objects. The main purpose of object ACKs is to provide a signal for bitrate adaptation on the publisher side. The object ACK is a hop-by-hop message; the publisher can use it to adjust its bitrate directly on the encoder (if it is the original publisher encoding the video), or to switch between different pre-existing tracks encoding the same contents (if a scheme such as SSTS is used to select tracks on a relay). The design described in this document is minimalist and similar in nature to QUIC ACK frames: for every object the subscriber processes, it sends an OBJECT_ACK on the Request Stream for the subscription in question. For every object, the subscriber also specifies a time delta from the deadline by which the subscriber expected to receive the object. A positive time delta indicates that the object arrived early, and a negative time delta indicates that the object arrived late. In addition to the time delta from deadline, the subscriber provides the publisher with the ACK Window Size that allows it to interpret the time deltas it receives. Objects with time deltas greater than or equal to the Window Size are considered to have arrived safely on time. In a regular video player with a fixed-size playback buffer, Window Size corresponds to the size of the buffer, and the time delta corresponds to the amount of playback time left in the buffer by the time the object is received.

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. The terms Subscriber, Publisher, Original Publisher, End Subscriber, Relay, Request Stream, and Subscription-Delivered are used as defined in . This document discusses subscribers "receiving and processing" objects. "Receiving" here means receiving all of the bytes in the Object's payload. "Processing" is application-specific; the applications define what that means, and the effective behavior will vary accordingly. For instance, if the application includes fully decoding a video frame in the definition of "processing", the mechanism described in this document would result in the publisher reducing the video rate when it is too high for the video decoder to handle. All of the time values in this document are expressed in microseconds. Additionally, this document uses a signed variable-length integer encoding called (svi64). An (svi64) is a sign-magnitude-encoded variable-length integer. Its encoding is based on the varint encoding, not the varint encoding. The lowest bit indicates the sign (1 is negative), and the upper bits indicate the magnitude, meaning that the value is decoded as > 1) : (raw >> 1) ]]> Senders MUST encode 0 as a positive value (sign bit set to 0), and receivers MUST gracefully process both possible encodings as 0. TODO: this is annoying to deal with; design a better encoding.

Protocol Overview To use object ACKs, both endpoints have to negotiate the SUPPORT_OBJECT_ACKS SETUP Option. For each individual subscription, the Subscriber includes OBJECT_ACK_WINDOW_SIZE in the SUBSCRIBE Parameters; if it is non-zero, the subscriber sends OBJECT_ACK for every object it receives and processes.

SUPPORT_OBJECT_ACKS Setup Option SUPPORT_OBJECT_ACKS (provisional code point 0xbbf1438) is a varint SETUP Option that can be either 0 or 1; any other value MUST be rejected by closing the session with KEY_VALUE_FORMATTING_ERROR. Duplicate instances of this option are not allowed, and MUST be rejected as a PROTOCOL_VIOLATION. The option is assumed to be 0 by default; the extension is considered to be enabled only if both endpoints specify the value of 1. The extension is available both over native QUIC and over WebTransport. This document only defines the extension for MOQT version draft-22.

OBJECT_ACK_WINDOW_SIZE Parameter The OBJECT_ACK_WINDOW_SIZE Parameter (provisional code point 0xbbf1438) can appear in SUBSCRIBE, in a PUBLISH_OK, and in REQUEST_UPDATE for a subscription. It MUST NOT appear in any other message. TODO: consider how this should work with SUBSCRIBE_TRACKS. TODO: since PUBLISH_OK no longer has Parameters other than EXPIRES, should we require the subscriber to send a separate REQUEST_UPDATE? OBJECT_ACK_WINDOW_SIZE encodes the ACK Window Size (see for semantics) in microseconds. The value of 0 is the default; it means object ACK messages are not used in the subscription. The Parameter is encoded as a single varint (vi64). It MUST NOT appear more than once in a single message. The Parameter MUST NOT be used unless the support has been explicitly negotiated via SETUP Options; in particular, this means that an endpoint MUST NOT send a request with this Parameter before it has received a SETUP message from the peer.

OBJECT_ACK Message The OBJECT_ACK message (provisional code point 0x3184) is sent by the subscriber on the Request Stream for a subscription; sending it in any other context is a PROTOCOL_VIOLATION. The subscriber MUST send OBJECT_ACK messages for every object it has received and processed if it has sent a non-zero OBJECT_ACK_WINDOW_SIZE, and it MUST NOT send any such messages if it has not done so. If the subscriber indicates a non-zero OBJECT_ACK_WINDOW_SIZE, but does not send any object ACKs, the publisher will assume it is not receiving any objects. Note that MOQT typically allows the subscriber to immediately send FIN for SUBSCRIBE requests or PUBLISH responses if it does not intend to send any updates; a subscriber that has sent a non-zero OBJECT_ACK_WINDOW_SIZE MUST NOT send a FIN until the subscription is over. OBJECT_ACK only applies to objects with Normal status; the subscriber MUST NOT send OBJECT_ACK for any other objects, or for objects that do not exist. OBJECT_ACK only applies to Subscription-Delivered objects. OBJECT_ACK is a unilateral notification, not a request: it does not consume Request IDs, and does not require a REQUEST_OK or a REQUEST_ERROR. This document does not provide any mechanism for coalescing object ACKs, or otherwise reducing the ACK traffic; OBJECT_ACK only acknowledges one individual object. Delta from Deadline indicates the duration between when the object was received and processed, and an application-specific deadline (for example, the time at which the video frame would appear on the screen). Positive values indicate that the object arrived before the deadline; negative values indicate that it arrived after.

Security Considerations TODO: discuss. This should probably cover speculative ACKs at minimum.

IANA Considerations TODO: register SETUP Option (0xbbf1438), Message Parameter (0xbbf1438), message type (0x3184).

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. 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 This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Implementation Status This specification is currently implemented in the Google QUICHE library, where it is used for adjusting the sender's bitrate.

Open Issues

• Do we need OBJECT_ACKs without a pre-defined window size?
• Consider whether ACK deltas should be a fraction of window (-1 to +1) instead of a microsecond number.
• Discuss missing object detection (both time-based approach and reordering-based).
• To locally detect missing objects, the publisher has to know its fixed group structure; discuss that.
• MOQT uses milliseconds, this draft uses microseconds, QUIC receive timestamps use scaled microseconds. Should we unify?
• Does the varint format here align with the MOQ Timestamp draft?
• Do we need to get rid of +0/-0 encoding in the signed varint?
• Add text on relay handling.
• Consider allowing ACKs for fill-delivered objects.
• Discuss changing OBJECT_ACK_WINDOW_SIZE via REQUEST_UPDATE mid-subscription; the ability to update it implies the publisher MUST ignore OBJECT_ACKs if it doesn't know window size yet.
• Add text discussing whether having to ACK every individual object is an issue.
• Discuss ACKs for duplicate objects, ACKs for missing objects, etc.
• Discuss flow control and HOLB implications of OBJECT_ACKs.

Acknowledgments TODO: acknowledge people.