IETF MOQ WG: How timestamps totally solve delivery timeout

Message Snapshot

• List: moq@ietf.org
• Thread subject: How timestamps totally solve delivery timeout
• Message subject: [Moq] Re: How timestamps totally solve delivery timeout
• Author: Luke Curley
• Published: 2026-06-12T16:13:42.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Luke Curley posted to the MOQ working group mailing list on June 12, 2026. Hey Martin, I've been on the fence about application timestamps being in moq-transport for a long time now.

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

Hey Martin, I've been on the fence about application timestamps being in moq-transport for a long time now.

Plain-Text Body

Hey Martin,

I've been on the fence about application timestamps being in moq-transport for a long time now.

I 100% agree that the relay should not use wall-clock timestamps. It doesn't make sense when cache filling is involved. Delivery timeout should be based on when the content was generated, not when a cache was populated.

Additionally, most MoQT applications need some form of timestamp for synchronization. We force all tracks to be desynchronized, and then expect the application to encode a timestamp header on each frame to resynchronize. It's just annoying to add a ts field to every JSON blob, media frame, markdown text, etc.

Some applications encode the timestamp into the group ID. But like we should have an explicit timestamp field so the relay can use this knowledge.

YOLO I decided to add timestamps to moq-lite-05 (not released yet). I'm going to give it a try and report back to the WG.

I also churned out a corresponding moq-transport extension https://www.ietf.org/archive/id/draft-lcurley-moq-timestamp-00.html that uses track/object properties similar to LOC if anybody else wants to interop.

Timescale: A track property that sets the units for every object. Timestamp: An object property that can go backwards (b-frames). Duration: (optional) an object property that indicates the end timestamp.

Duration is useful for gap detection, but it's optional because computing it may add a frame of latency. Might be worth removing, IDK.