IETF MOQ WG: User case or question to Joining Fetch
Law, Will posted to the MOQ working group mailing list on May 13, 2026. @Zafer - "Using milliseconds didn't help, sometimes the group IDs collided (when a join message is received by the participants in the room, they s…
Message Snapshot
- List:
moq@ietf.org - Thread subject: User case or question to Joining Fetch
- Message subject: [Moq] Re: User case or question to Joining Fetch
- Author: Law, Will
- Published: 2026-05-13T18:40:09.000Z
- Source tag:
ietf-mailing-list - Message URL: Open in IETF Mail Archive
Summary
Law, Will posted to the MOQ working group mailing list on May 13, 2026. @Zafer - "Using milliseconds didn't help, sometimes the group IDs collided (when a join message is received by the participants in the room, they s…
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
@Zafer - "Using milliseconds didn't help, sometimes the group IDs collided (when a join message is received by the participants in the room, they send a join message at the same time which results in group ID collision)” - but if each participant sends their data on a different Object ID as I proposed, then there woul…
Plain-Text Body
@Zafer - "Using milliseconds didn't help, sometimes the group IDs collided (when a join message is received by the participants in the room, they send a join message at the same time which results in group ID collision)” - but if each participant sends their data on a different Object ID as I proposed, then there would be no collisions. The cached entities are Objects, not groups. The tuple of (NS, N, G-ID, O-ID) would be unique for each user.
-Will
Chief Architect - Cloud Technology Group Akamai Technologies Switzerland Mobile +41 79 535 07 94
From: Mo Zanaty (mzanaty) mzanaty=40cisco.com@dmarc.ietf.org Date: Wednesday, 13 May 2026 at 19:02 To: Zafer Gurel zafer.gurel@ozu.edu.tr; Law, Will wilaw@akamai.com Cc: Yu You (Nokia) yu.you@nokia.com; moq@ietf.org moq@ietf.org Subject: Re: [Moq] Re: User case or question to Joining Fetch
This Message Is From an External Sender This message came from outside your organization.
Hi Yu, we built something similar using the anti-pattern Zafer described. It's an anti-pattern because MOQT says such tracks SHOULD NOT use group range filters at all (in any fetch or subscribe). See section 2.3.1. So there is little to no chance joining fetch will evolve to make this work well.
The n^2 problem you describe is inherent in all full mesh designs. The overall state required dwarfs joining location, so that is not really the bottleneck. Alternative designs often add hierarchy to avoid a flat full mesh.
Regards, Mo
From: Zafer Gurel Hi Yu You, That's an interesting problem which I also encountered while developing the Meet applicationhttps://urldefense.com/v3/__https://github.com/moqtail/moqtail/tree/main/apps/meet__;!!GjvTz_vk!V2MZ-NZlwq45uDing-dR4eMyQfhK9AY7DiCv6D3ivD4ARq_-6Rj7JVyGPw5Ad1loB4XZxbCQrwnUxxM8apNAQ2PX61kA$ within MOQtail. But instead of a shared chat track, I used a shared signalling track to distribute messages such as join, welcome, etc. among the participants. Using milliseconds didn't help, sometimes the group IDs collided (when a join message is received by the participants in the room, they send a join message at the same time which results in group ID collision). So, I ended up using a random base group ID to start the group ID counter for each participant, which solved my problem. But this is an anti-pattern because you don't get monotonically increasing group IDs. Best, Zafer