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-15T14:37:48.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 15, 2026. Hi Yu, beware of pitfalls in this anti-pattern. A track is malformed (see 2.4.2) if different objects end a subgroup or group. So you mus…

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, beware of pitfalls in this anti-pattern. A track is malformed (see 2.4.2) if different objects end a subgroup or group. So you must never FIN a subgroup or END a group. Or set subgroup id to object id (if truly unique). Or put the unique user id in the lower bits of group id instead of object id which can then…

Plain-Text Body

Hi Yu, beware of pitfalls in this anti-pattern. A track is malformed (see 2.4.2) if different objects end a subgroup or group. So you must never FIN a subgroup or END a group. Or set subgroup id to object id (if truly unique). Or put the unique user id in the lower bits of group id instead of object id which can then be 0. But that results in group id jumping around not strictly increasing. Did I mention anti-pattern? :)

Consider using Subscribe Tracks to get Publish from each sender with a unique name (in a shared namespace). To rewind, fetch from each sender. Each sender can also declare unique track properties (impossible in the anti-pattern) which may obviate the need for a catalog (or a simple static one with only the namespace).

Good luck! Mo

---

From: Yu You (Nokia)

Thanks for the helpful suggestions. I will re-implement the chat using a wall-clock-based Group ID together with a unique Object ID to avoid collisions, which should allow Joining Fetch to work.

So does the catalog publishing for A/V info plus any extra user-specific tracks. Currently all participants publish to the same “catalog” track and each published catalog JSON has a unique “track name” which represents the user names or IDs.

Cheers,

Yu

From: Law, Will wilaw@akamai.com

@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

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