Summary

  • In the current Media over QUIC Transport draft, a skipped Object ID is an observation about numbering, not proof that media was lost or never produced.
  • The protocol now separates permanent non-existence, unresolved status and a relay that stopped waiting; useful monitoring must preserve the same distinctions.

Object 418 arrives. Object 420 follows. In an ordinary dashboard, the missing 419 is almost irresistible: mark one loss, blame the path, move on.

That conclusion is precisely what the current Media over QUIC Transport draft refuses to permit. MOQT is being designed for media that may arrive over streams or datagrams, through relays, subscriptions and bounded fetches. In that system, number order is not delivery history. The hole between 418 and 420 may name an Object that has not been produced, an Object excluded from this delivery path, an Object waiting upstream, an Object abandoned after a timeout, or an Object the publisher has authoritatively said will never exist.

Those are different events with different owners. Treating them as one counter destroys the evidence needed to diagnose any of them.

Three states, not one absence

Revision 21 of draft-ietf-moq-transport, posted on 8 September, retains a three-state model already present in revision 20. From a subscriber or cache, an Object can be known to exist, known not to exist, or unknown because it has not arrived or has not yet been produced.

The draft then states the operational rule plainly: a gap in observed Object IDs conveys no information by itself. The skipped Objects remain unknown until they arrive or their non-existence is signalled.

This is more than protocol pedantry. A monitoring system sees only a projection of the event. A subscription may have a range filter. A relay may have cached 418 and 420 but still be asking upstream for 419. Different subgroups can use different streams. A datagram can arrive after a stream-carried neighbour. A fill operation can stop waiting while a live subscription continues. One number line is carrying several custody chains.

The safe receipt begins with what was actually observed: track, group, Object ID, delivery mode, path, observer and time. “Did not appear here by this deadline” is honest. “Never existed” requires additional authority.

Who may say “never”

MOQT offers two ways to turn uncertainty into a stronger statement.

The first is a Prior Object ID Gap property. It tells the receiver that a contiguous run of earlier Objects does not, and will never, exist. The authority rule is narrow: the Original Publisher may add the property; relays must not invent it. A relay may remove it only when an equivalent gap is already implicit in a FETCH response. The related Prior Group ID Gap applies the same idea to whole groups.

The second is a completed, bounded FETCH response. Inside that range, gaps can communicate status. But the current wire format does not reduce every unreturned location to permanent absence. It provides separate end markers for a non-existent range, an unknown range and a timed-out range.

That separation exposes the control surface. The publisher can make the durable creation claim. A relay can report its custody and waiting result. A subscriber can specify a waiting budget. None of them should silently speak for the others.

A timeout is a budget receipt

The meaningful recent change carried into the current draft is End of Timed-Out Range. The merged design work behind revision 20 added code point 0x20C so a FETCH can distinguish Objects abandoned when a Fill Timeout expires from Objects whose status remains genuinely unknown.

FILL_TIMEOUT is not an existence oracle. It is the total number of milliseconds a relay should spend waiting across the upstream fetches generated for one request. A value of zero asks only for immediately available Objects. If the subscriber omits the parameter, the relay chooses an implementation-specific duration. If the subscriber asks for longer than the relay is willing to wait, the relay may shorten the period without notification.

The resulting Timed-Out range therefore says: this relay, for this request, stopped waiting under this budget. It does not say the network dropped the Object. It does not say the publisher never created it. It does not even say another relay or a continuing subscription cannot deliver it later.

That last possibility is explicit. Because Objects can be delivered out of order, an endpoint may receive an Object after it recorded non-existence from another source. The draft says this is not automatically a protocol error and does not by itself make the Track malformed. Real implementations will need a reconciliation policy rather than a universal assumption that the first observation owns reality forever.

The player has another clock

Media applications add a separate deadline. A video Object can exist, be fetched successfully and still arrive too late for its decoding dependency. Conversely, an enhancement Object may never be produced without harming the base layer. A skipped Object may be intentional sparsity rather than failure. Two viewers may observe different consequences because one joined later, one had more buffer, or one selected a different representation.

MOQT does not define those application semantics. Its Object model carries identifiers, properties and payloads; the codec and player decide dependency and usefulness. Operational telemetry should therefore avoid promoting a transport receipt into a quality verdict.

A defensible record links, but does not collapse, the Object observation, the status signal, the relay wait budget, cache transitions, the decoder deadline, dependency information and the visible playback result. Only then can an operator tell a path problem from cache incompleteness, publisher intent or a player that simply ran out of time.

Sources