IETF MOQ WG: Request Synchronization Use Case

Message Snapshot

• List: moq@ietf.org
• Thread subject: Request Synchronization Use Case
• Message subject: [Moq] Re: Request Synchronization Use Case
• Author: Luke Curley
• Published: 2026-05-04T17:10:43.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 May 4, 2026. Hey Cullen, Part of the problem with draft-17 is that required_request_id doesn't interact with request termination. Your use-cases would be pos…

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 Cullen, Part of the problem with draft-17 is that required_request_id doesn't interact with request termination. Your use-cases would be possible via

Plain-Text Body

Hey Cullen,

Part of the problem with draft-17 is that required_request_id doesn't interact with request termination. Your use-cases would be possible via REQUEST_UPDATE, but not a request stream FIN or RESET.

Even worse, if either side RESETs a request, it can cause a deadlock. The peer may never learn about a specific request_id referenced via a required_request_id so it will block (until some timeout).

This is an addressable problem, but there are other options too. Use-cases can help that discussion.

Are you primarily worried about side effects, or are you worried about efficiency?

And by side effects, I mean if the new SUBSCRIBE is processed before the old UNSUBSCRIBE (FIN/RESET), does that change the meaning of the SUBSCRIBE request?

On Mon, May 4, 2026, 3:16 AM Magnus Westerlund <magnus.westerlund= 40ericsson.com@dmarc.ietf.org> wrote: