IETF MOQ WG: User case or question to Joining Fetch

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: Mo Zanaty (mzanaty)
• Published: 2026-05-13T17:02:14.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Mo Zanaty (mzanaty) posted to the MOQ working group mailing list on May 13, 2026. Hi Yu, we built something similar using the anti-pattern Zafer described. It's an anti-pattern because MOQT says such tracks SHOULD NOT u…

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 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 de…

Plain-Text Body

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://github.com/moqtail/moqtail/tree/main/apps/meet 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