| Internet-Draft | moq-e2e-delivery-timeout | October 2026 |
| Sharma | Expires 9 April 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://sharmafb.github.io/draft-sharma-moq-end-to-end-delivery-timeout/draft-sharma-moq-end-to-end-delivery-timeout.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sharma-moq-end-to-end-delivery-timeout/.¶
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/sharmafb/draft-sharma-moq-end-to-end-delivery-timeout.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 9 April 2027.¶
Copyright (c) 2026 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.¶
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 [TIMESTAMP]. 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.¶
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.¶
This document uses the terms Object, Publisher, Relay, Subscription, and Message Parameter as defined in [MOQT]. It uses Object Timestamp and Timescale as defined in [TIMESTAMP].¶
This extension applies to version 22 of [MOQT], identified by the moqt-22
protocol identifier. Its use with other versions is undefined.¶
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.¶
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 [MOQT]. 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:¶
deadline = reference_time
+ (T - reference_timestamp) / timescale
+ timeout
¶
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 [MOQT]. 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.¶
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 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 |
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 [MOQT] and [TIMESTAMP].¶
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.¶