IETF MOQ WG: Review of PR1673

Message Snapshot

• List: moq@ietf.org
• Thread subject: Review of PR1673
• Message subject: [Moq] Re: Review of PR1673
• Author: Alan Frindell
• Published: 2026-06-30T06:09:23.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Alan Frindell posted to the MOQ working group mailing list on June 30, 2026. Hi Cullen, thank you for the detailed read of the PR. See some replies inline. This is already possible in #1673, as the subscription is gover…

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

Hi Cullen, thank you for the detailed read of the PR. See some replies inline. This is already possible in #1673, as the subscription is governed by

Plain-Text Body

Hi Cullen, thank you for the detailed read of the PR. See some replies inline.

This is already possible in #1673, as the subscription is governed by SUBSCRIBER_PRIORITY as it appears in the Parameters on the SUBSCRIBE request and each fill can contain a FILL_PARAMETERS block which contains an override for the SUBSCRIBER_PRIORITY for the fetch generated, if any.

I think we can clarify that by adding a reference to the FETCH section. For example:

available Objects in the requested range in the requested order

and

sending objects immediately in response to a FETCH. If it encounters an object in the requested range that is not cached and has unknown status, the relay MUST pause subsequent delivery until it has confirmed the object's status upstream. If the upstream FETCH fails, the relay sends a REQUEST_ERROR and can reset the unidirectional stream. It can choose to do so immediately or wait until the cached objects have been delivered before resetting the stream.

There is not way to provide what the error was for a fill stream. For

The provided mechanism in the PR is to open and then reset the fill fetch stream with a reset stream error code, which includes EXPIRED_AUTH_TOKEN. And someone using different tokens with different lifetimes for the fill-fetch and subscription parts of a Track sort of gets what they deserve.

This is not a problem with #1673 any more than it is a problem with Joining FETCH or FETCH itself. The nature of FETCH is to flatten the response into a single stream in such a way that QUIC stream flow control can prevent the sender from overrunning the connection. We've discussed, for example, adding a separate Send Rate https://github.com/moq-wg/moq-transport/issues/1453 param, but the working group hasn't expressed enthusiasm for it. In any case, any solution should apply to all forms of FETCH, so I think this is separable.

I agree that it's somewhat ambiguous, we'll try to crisp this up. "Already published" was taken from the beginning of the section on FETCH

publisher to request a range of already published objects within a track.

The idea that a object can be delivered twice ( once over fetch and once

The problem can be mitigated by passing FILL_TIMEOUT=0 in the FILL_PARAMETERS block (Ian suggested adding this notation to the PR text). In that case, a late object will get omitted in the fill FETCH, and delivered via the subscription when it arrives. Joining FETCH avoids this problem by making the fill range and the subscription filter entirely disjoint, at the cost of HOL blocking on missing fill objects, which is arguably worse in some cases? HOL blocking is nominally a driving motivator of doing anything in this space. Current Group from #1642, which the wg wanted to separate into a follow-up PR, removes the possibility of duplicates at least in the current group, which is where they are most likely to occur. I'm open to specific suggestions for how to make this better.

I'm neutral on this proposal.…