Each MOQT subscription has two timeout values associated with it: a SUBGROUP_DELIVERY_TIMEOUT and an OBJECT_DELIVERY_TIMEOUT. Both of those values are expressed in milliseconds; both are optional; a value of 0 means that there is no timeout set.
The publisher communicates both timeout values as a Track Property; the subscriber communicates them as Message Parameters. For each type of timeout, if both the publisher and the subscriber have a non-zero value, the smaller of the two is used.
If the OBJECT_DELIVERY_TIMEOUT is not zero, the MOQT implementation MUST retain the time at which the first payload byte of every object has been either received from the upstream subscription, or provided by the original publisher application. The actual mechanism by which the timeout works depends on the Object Forwarding Preference:
-
For subgroups, the implementation MUST check the time elapsed since the first byte of the object before attempting to pass it to the underlying transport for transmission; if the time elapsed exceeds OBJECT_DELIVERY_TIMEOUT, it MUST reset the underlying transport stream with the reset stream code DELIVERY_TIMEOUT (see Section 11.4.3) and SHOULD NOT attempt to open a new stream to deliver additional Objects in that Subgroup. The implementation SHOULD check object delivery timeouts before retransmitting object data if the underlying transport implementation allows that. The implementations SHOULD minimize the amount of data buffered at the underlying transport layer, as any data buffered at this layer can no longer be timed out, potentially leading to transmission of expired data.
-
For datagrams, the implementation MUST drop the datagrams if the time elapsed since the first byte exceeds OBJECT_DELIVERY_TIMEOUT. Similar to subgroups, implementations SHOULD either minimize datagram queueing, or use datagram queueing mechanisms that support time bounds (such as the
outgoingMaxAgeparameter in the W3C WebTransport API).
If the Object Forwarding Preference is Subgroup and the value of SUBGROUP_DELIVERY_TIMEOUT is not zero, the MOQT implementation MUST start a timer of SUBGROUP_DELIVERY_TIMEOUT duration once it becomes aware that all of the objects on the subgroup have been published (either by receiving a FIN from the upstream subscription, or, in case of the original publisher, through being notified of this fact by the application). If the timer expires before the underlying transport stream reaches "all data committed" state ([I-D.ietf-webtrans-overview], Section 4.3), the implementation MUST reset the stream. This ensures that MOQT can time out subgroups where all of the data has been sent but not yet fully delivered due to packet loss.
For objects with Object Forwarding Preference set to Datagram, the SUBGROUP_DELIVERY_TIMEOUT acts the same way as OBJECT_DELIVERY_TIMEOUT; if both are non-zero, the smaller of the two is used.
| SUBGROUP_DELIVERY_TIMEOUT | OBJECT_DELIVERY_TIMEOUT | |
|---|---|---|
| Timeout starts | When the FIN for the subgroup is received | When the first byte of the object is received |
| Timeout checked at | Via a timer until all data is acknowledged | When the object is sent to the underlying transport |
| Action upon timeout | Reset for subgroups, drop for datagrams | Reset for subgroups, drop for datagrams |
Publishers can, at their discretion, discontinue forwarding Objects before
either of the timeouts occurs, subject to stream closure and ordering
constraints described in Section 11.4.3. However, if none of the
timeouts are set to a non-zero value, all Objects in the track matching the
subscription filter are delivered as indicated by their Group Order and
Priority. If a subscriber fails to consume Objects at a sufficient rate,
causing the publisher to exceed its resource limits, the publisher MAY
terminate the subscription using PUBLISH_DONE with error TOO_FAR_BEHIND.