IETF MOQ WG: Review of PR1673

Message Snapshot

• List: moq@ietf.org
• Thread subject: Review of PR1673
• Message subject: [Moq] Review of PR1673
• Author: Cullen Fluffy Jennings
• Published: 2026-06-29T18:26:48.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Cullen Fluffy Jennings posted to the MOQ working group mailing list on June 29, 2026. On a plane and can’t put these in the PR but rough comments on PR 1673. I have a bunch of significant issues with the PR as it stands…

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

On a plane and can’t put these in the PR but rough comments on PR 1673. I have a bunch of significant issues with the PR as it stands. Need a way to have different priorities on fetch parts vs subscriber part.

Plain-Text Body

On a plane and can’t put these in the PR but rough comments on PR 1673.

I have a bunch of significant issues with the PR as it stands.

Need a way to have different priorities on fetch parts vs subscriber part.

This does not say what the relay does to get objects it does not have on the fill fetch stream.

There is not way to provide what the error was for a fill stream. For example, say the fill stream needed a token refreshed, there is no way to do that.

Need a way to deal with rate limits of fetch parts.

"already-published" is very confusing term because it depends on published where in the overall system. If we are going to use it, it needs to get well defined in terms of information that a relay has. Same comment on with live only.

The idea that a object can be delivered twice ( once over fetch and once over subscribe ) seems like a very bad design. Can we eliminate this problem?

It seems like the wrong design to have pausing a subscription ( forward=0 ) cancel the fills. It would be better to directly controll what is needed.

I don't think we should remove joining fetch in the same PR. This need to go in the spec, we can see how well it works, then make a decision about removing a long term feature of joining fetch. People are using joining fetch and we need a transition period.

The interaction around updates of filters and such seems littered with changes that happen to fill streams that are unintended and surprising to the client.

This talks about before and after in the sense of time but I don't think time is really known. I think it needs to be phrased in timer of great or less Locations.

Not a big issues but I find the huge push to reuse all parameters everywhere making the protocol design worse. Let me give you an example, On one hand we have "An endpoint that receives a parameter inside FILL_PARAMETERS that is not permitted above MUST close the session with PROTOCOL_VIOLATION." even though all we really need to do is fail that request. While on the other hand on the next line that is : "FILL_PARAMETERS is meaningful only with a fill filter type. If it is present without a fill filter type, it is ignored."