End-to-End Delivery Timeouts for MOQT
draft-sharma-moq-end-to-end-delivery-timeout-00

Media Over QUIC                                                A. Sharma
Internet-Draft                                                      Meta
Intended status: Standards Track                          6 October 2026
Expires: 9 April 2027

                 End-to-End Delivery Timeouts for MOQT
            draft-sharma-moq-end-to-end-delivery-timeout-00

Abstract

   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

   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.

Status of This Memo

   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/.

Sharma                    Expires 9 April 2027                  [Page 1]
Internet-Draft          moq-e2e-delivery-timeout            October 2026

   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 Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Negotiation . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  End-to-End Object Delivery Timeout  . . . . . . . . . . . . .   3
   5.  Limitations . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  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 [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.

Sharma                    Expires 9 April 2027                  [Page 2]
Internet-Draft          moq-e2e-delivery-timeout            October 2026

2.  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 [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.

3.  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.

4.  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 [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.

Sharma                    Expires 9 April 2027                  [Page 3]
Internet-Draft          moq-e2e-delivery-timeout            October 2026

   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.

5.  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.

6.  IANA Considerations

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

Sharma                    Expires 9 April 2027                  [Page 4]
Internet-Draft          moq-e2e-delivery-timeout            October 2026

       +============+=============================+===============+
       |       Type | Name                        | Specification |
       +============+=============================+===============+
       | TBD1 (odd) | END_TO_END_DELIVERY_TIMEOUT | This document |
       +------------+-----------------------------+---------------+

                                 Table 1

   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 | Parameter Name                     | Specification |
    |      Type |                                    |               |
    +===========+====================================+===============+
    |      TBD2 | END_TO_END_OBJECT_DELIVERY_TIMEOUT | This document |
    +-----------+------------------------------------+---------------+

                                 Table 2

7.  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
   [MOQT] and [TIMESTAMP].

8.  Normative References

   [MOQT]     Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
              "Media over QUIC Transport", Work in Progress, Internet-
              Draft, draft-ietf-moq-transport-22, 1 October 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
              transport-22>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Sharma                    Expires 9 April 2027                  [Page 5]
Internet-Draft          moq-e2e-delivery-timeout            October 2026

   [TIMESTAMP]
              Frindell, A. and I. Swett, "Timestamp Properties for
              MOQT", Work in Progress, Internet-Draft, draft-frindell-
              moq-timestamp-00, 5 October 2026,
              <https://datatracker.ietf.org/doc/html/draft-frindell-moq-
              timestamp-00>.

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.

Author's Address

   Aman Sharma
   Meta
   Email: amsharma@meta.com

Sharma                    Expires 9 April 2027                  [Page 6]