MoQ Object Timestamp Extension
draft-lcurley-moq-timestamp-01

moq                                                            L. Curley
Internet-Draft                                             3 August 2026
Intended status: Informational                                          
Expires: 4 February 2027

                     MoQ Object Timestamp Extension
                     draft-lcurley-moq-timestamp-01

Abstract

   This document specifies the transport-level use of the TIMESTAMP and
   TIMESCALE properties registered by [loc], independent of the LOC
   container itself.  A track-level Timescale property establishes the
   units, and an object-level Timestamp property carries the
   presentation time of each object.  Exposing media time to the
   transport lets relays make consistent age-based decisions (e.g.
   dropping stale objects) without parsing the media container, and it
   remains consistent across hops regardless of buffering or jitter.  No
   new code points are requested: an endpoint implementing this document
   is on the wire indistinguishable from a LOC endpoint that carries
   only these two properties.

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

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

Curley                   Expires 4 February 2027                [Page 1]
Internet-Draft                moq-timestamp                  August 2026

   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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  TIMESCALE Track Property  . . . . . . . . . . . . . . . . . .   3
   4.  TIMESTAMP Object Property . . . . . . . . . . . . . . . . . .   4
     4.1.  Age-Based Dropping  . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction

   [moqt] treats object payloads as opaque, leaving timing to the
   application's container format.  This works for endpoints that parse
   the media, but not for relays.  A relay frequently needs a notion of
   _when_ an object is meant to be presented:

   *  *Age-based dropping*: a relay serving a live subscription wants to
      drop objects too old to be useful.  Wall-clock arrival time drifts
      across hops and is corrupted by buffering and jitter.

   *  *Consistent expiration across hops*: a timestamp embedded in the
      object is identical at every hop, so every relay makes the same
      drop decision.

   *  *Synchronization hints*: a subscriber can align objects from
      multiple tracks (e.g. audio and video) without first decoding each
      container.

Curley                   Expires 4 February 2027                [Page 2]
Internet-Draft                moq-timestamp                  August 2026

   This extension exposes media time to the transport with two Key-
   Value-Pairs ([moqt] Section 2.5): a track-level *Timescale* and an
   object-level *Timestamp*. The transport does not interpret the
   _meaning_ of the timeline; it only uses the timestamp for relative
   age comparisons.

   Both properties are already registered by [loc], which defines them
   for use inside the LOC container.  This document reuses those
   registrations verbatim and specifies what a _transport_ does with
   them: a timestamp is only useful to a relay if every publisher writes
   it the same way, so a second set of code points for the same concept
   would defeat the purpose.  An endpoint that implements both this
   document and LOC writes one copy of each property, not two.

   The properties are self-describing and require no SETUP negotiation:
   a receiver that understands them uses them directly, and one that
   does not ignores them per [moqt].  TIMESCALE is what opts a track in:
   a track that carries it has media times in the stated units, and a
   track without it has no timeline at all.  There is deliberately no
   default timescale; a wrong guess is off by a factor of 1000 rather
   than detectably broken, and making presence the signal avoids
   contradicting [loc], which reads a bare Timestamp as microseconds.

3.  TIMESCALE Track Property

   The TIMESCALE property opts a track into timestamps and establishes
   the units for every Timestamp on it.  It is a track-level Key-Value-
   Pair, carried with the track's properties (see [moqt] Section 2.5 and
   Section 12).  Because the value is a single integer, TIMESCALE uses
   an even Type so the value is a bare varint with no length prefix:

   TIMESCALE Track Property {
     Type (vi64) = 0x08
     Value (vi64)  ; units per second
   }

   *Value*: The number of timestamp units per second.  Common values
   include 1000 (milliseconds), 1000000 (microseconds), 48000 (a typical
   audio sample rate), and 90000 (the RTP video clock).  A value of 0 is
   invalid; a receiver MUST treat a track that declares it as carrying
   no timeline.

Curley                   Expires 4 February 2027                [Page 3]
Internet-Draft                moq-timestamp                  August 2026

   Absence is meaningful and is not an error.  A track with no TIMESCALE
   has no media timeline: a receiver MUST NOT infer units for it, and
   MUST use wall-clock arrival time for age-based decisions on that
   track.  A publisher that emits Timestamps MUST send TIMESCALE, even
   for units a receiver might otherwise assume. [loc] permits a bare
   Timestamp and reads it as microseconds; a receiver that also
   implements LOC MAY apply that interpretation to a track that omits
   TIMESCALE, and MUST NOT apply any other.

   The Timescale is fixed for the lifetime of the track and MUST NOT
   change. [loc] also registers TIMESCALE with Object scope; a receiver
   that implements both applies such an override to that object alone,
   and a publisher following this document SHOULD NOT send one.

   The track's properties are delivered in SUBSCRIBE_OK or TRACK_STATUS
   ([moqt] Section 12).  Until they arrive, a receiver MUST fall back to
   wall-clock arrival time for any age-based decision.

4.  TIMESTAMP Object Property

   The TIMESTAMP property carries the presentation time of an object, in
   the track's Timescale.  It is an object-level Key-Value-Pair carried
   in the object's properties ([moqt] Section 2.5, 11.2.1.2).  It uses
   an even Type so the value is a bare varint:

   TIMESTAMP Object Property {
     Type (vi64) = 0x10
     Value (vi64)  ; absolute presentation time, in Timescale units
   }

   *Value*: The absolute presentation timestamp of the object, expressed
   in the track's Timescale.  Any value (including 0) is valid.

   Each Timestamp is absolute, not delta-encoded against a previous
   object: [moqt] does not guarantee delivery of every object, and a
   delta would be corrupted by any missing predecessor.

   On a track that declares a TIMESCALE, a publisher SHOULD attach
   TIMESTAMP to every object that has a media time.  For an object with
   no TIMESTAMP, a receiver MUST treat its effective time as the wall-
   clock arrival time, which avoids stalling expiration on objects that
   intentionally carry no timestamp (e.g. keep-alives or gap markers).
   The same fallback covers every object on a track that declares no
   TIMESCALE, so a receiver needs one rule, not two.

Curley                   Expires 4 February 2027                [Page 4]
Internet-Draft                moq-timestamp                  August 2026

4.1.  Age-Based Dropping

   Given two objects on the same track, both with TIMESTAMP, a relay
   computes their relative age as the difference of their timestamps
   divided by the Timescale.  A relay serving a live subscription MAY
   drop an object whose age relative to the most recent object on the
   track exceeds a locally configured or application-supplied threshold,
   resetting the corresponding stream per [moqt].  This decision is
   identical at every hop because it depends only on values embedded in
   the objects, not on arrival time.

   A relay MUST NOT use timestamps to reorder delivery beyond what
   [moqt] already permits; this property informs _dropping_, not
   transmission order.

5.  Security Considerations

   Timestamps expose the media timeline to relays, which is the point of
   the extension, but a relay still treats payloads as opaque and gains
   no access to media content.

   A malicious publisher could supply misleading timestamps (e.g. always
   claiming an object is fresh) to defeat age-based dropping, or wildly
   out-of-range timestamps to cause a receiver to mis-estimate age.  A
   receiver SHOULD bound the age it computes and SHOULD NOT make
   security decisions based on timestamps.  Because age-based dropping
   only affects which objects a live subscription receives, the worst
   case is degraded delivery for that subscription, not a cross-
   subscription effect.

6.  IANA Considerations

   This document requests no registrations.

   Both properties it uses are already registered by [loc] in the "MOQ
   Properties" registry ([moqt] Section 15.8), and this document changes
   neither their code points nor their value encodings:

             +=======+===========+===============+===========+
             | Value | Name      | Scope         | Reference |
             +=======+===========+===============+===========+
             | 0x08  | TIMESCALE | Track, Object | [loc]     |
             +-------+-----------+---------------+-----------+
             | 0x10  | TIMESTAMP | Object        | [loc]     |
             +-------+-----------+---------------+-----------+

                                  Table 1

Curley                   Expires 4 February 2027                [Page 5]
Internet-Draft                moq-timestamp                  August 2026

   Both Types are even, so each value is a bare varint with no length
   prefix (see [moqt] Section 2.5).

   An earlier version of this document requested its own code points
   (0x915C0 and 0x915C2); they are abandoned in favor of the [loc]
   registrations.

7.  Normative References

   [loc]      Zanaty, M., Nandakumar, S., and P. Thatcher, "Low Overhead
              Media Container", Work in Progress, Internet-Draft, draft-
              ietf-moq-loc-04, 20 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-loc-
              04>.

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

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

Acknowledgments

   This document was drafted with the assistance of Claude, an AI
   assistant by Anthropic.

Author's Address

   Luke Curley
   Email: kixelated@gmail.com

Curley                   Expires 4 February 2027                [Page 6]