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: Yu You (Nokia)
• Published: 2026-05-15T05:50:29.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Yu You (Nokia) posted to the MOQ working group mailing list on May 15, 2026. 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 c…

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

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

Plain-Text Body

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 Date: Wednesday, 13. May 2026 at 21.40 To: Zafer Gurel zafer.gurel@ozu.edu.tr Cc: Yu You (Nokia) yu.you@nokia.com; moq@ietf.org moq@ietf.org; Mo Zanaty (mzanaty) mzanaty=40cisco.com@dmarc.ietf.org Subject: Re: [Moq] Re: User case or question to Joining Fetch

You don't often get email from wilaw@akamai.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

@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 signallin…