]> Meta

amsharma@meta.com

Web and Internet Transport Media Over QUIC media over quic delivery timeout timestamp This document defines an end-to-end Object delivery timeout for Media over QUIC Transport (MOQT). It uses Object timestamps to include delay accumulated across a chain of relays instead of restarting the timeout at each hop. 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 The MOQT OBJECT_DELIVERY_TIMEOUT is measured from the time an Object reaches the current publisher. Consequently, an Object can receive a new timeout budget at every relay. This document defines a subscription timeout measured against the Object timeline from . The first Object establishes a local reference. Later Objects that fall more than the requested timeout behind that timeline are no longer forwarded. This includes upstream delay accumulated after the reference is established and requires no synchronized clocks.

Conventions 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 terms Object, Publisher, Relay, Subscription, and Message Parameter as defined in . It uses Object Timestamp and Timescale as defined in . This extension applies to version 22 of , identified by the moqt-22 protocol identifier. Its use with other versions is undefined.

Negotiation An endpoint supports this extension by including the zero-length END_TO_END_DELIVERY_TIMEOUT Setup Option in SETUP. The extension is negotiated when both endpoints include the option. An endpoint MUST NOT send the Message Parameter defined below unless the extension was negotiated.

End-to-End Object Delivery Timeout The END_TO_END_OBJECT_DELIVERY_TIMEOUT Message Parameter is a variable-length integer containing a timeout in milliseconds. It MAY appear in SUBSCRIBE, SUBSCRIBE_TRACKS, PUBLISH, or a REQUEST_UPDATE that updates a Subscription. A value of 0 disables the timeout. When included in SUBSCRIBE_TRACKS, the parameter is the initial value for each resulting Subscription and is copied into PUBLISH as specified in . A publisher MUST send PUBLISH_SKIPPED instead of PUBLISH for a Track that cannot provide the timestamps required by this extension. A publisher MUST NOT establish a Subscription with a non-zero value unless it can compute an Object Timestamp for every Normal Object it might forward. A Normal Object without a computable timestamp while the timeout is active makes the Track malformed. For each Subscription with a non-zero timeout, the publisher maintains a reference timestamp and a reference time. Immediately before forwarding the first Normal Object after the timeout is enabled, it records the Object's timestamp as the reference timestamp and its local monotonic time as the reference time. That Object is not expired by this extension. For a later Object with timestamp T, the publisher computes its deadline as: Conversions between ticks and time MUST NOT make the deadline earlier. If the publisher's current time is later than the deadline, it MUST apply the expiration behavior specified for OBJECT_DELIVERY_TIMEOUT in . This comparison applies across all Subgroups in the Subscription. Changing one non-zero timeout to another preserves the reference. Disabling the timeout clears the reference; enabling it again establishes a new reference with the next Normal Object. For example, if the reference Object has timestamp 10 seconds and a later Object has timestamp 12 seconds, a 500 millisecond timeout expires the later Object 2.5 seconds after the reference Object was forwarded. This timeout is independent of OBJECT_DELIVERY_TIMEOUT and SUBGROUP_DELIVERY_TIMEOUT; the first applicable timeout to expire determines the result. As with all Message Parameters, a Relay MUST NOT copy this parameter to an upstream request. The local timestamp comparison already includes delay accumulated upstream.

Limitations This extension bounds lateness relative to the first forwarded Object. It does not bound startup latency, delay Objects that arrive early, or guarantee that an Object reaches the subscriber after it has been handed to the underlying transport. Accuracy depends on the relative stability of the publisher's monotonic clock and the timestamp clock.

IANA Considerations IANA is requested to register the following entry in the "MOQ Setup Options" registry:

Type	Name	Specification
TBD1 (odd)	END_TO_END_DELIVERY_TIMEOUT	This document

TBD1 uses the length-prefixed encoding and has a zero-length value. IANA is also requested to register the following entry in the "MOQ Message Parameters" registry:

Parameter Type	Parameter Name	Specification
TBD2	END_TO_END_OBJECT_DELIVERY_TIMEOUT	This document

Security Considerations Incorrect timestamps can cause useful Objects to be discarded or stale Objects to be retained. Publishers and subscribers SHOULD apply reasonable bounds to timestamps and timeout values. When timestamps need protection from an untrusted Relay, the timestamp Properties SHOULD be carried in Immutable Properties as described in and .

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. Meta Google This document defines a set of MOQT Properties for carrying per- Object timestamps efficiently. The encoded timestamp is intended for use in MOQT, but can be referenced for application specific purposes. 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.

Acknowledgments The relative-time algorithm in this document is based on a proposal by Martin Duke. The timestamp representation was defined by Alan Frindell and Ian Swett.