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-13T10:05:43.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. HI Yu You Interesting problem that you surface. The shared chat track seems intuitively more useful, as all subscribers essentially want the same m…

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 You Interesting problem that you surface. The shared chat track seems intuitively more useful, as all subscribers essentially want the same merged chats, sequenced by time, not for each to have to merge 100 different chats from 100 different participants.

Plain-Text Body

HI Yu You

Interesting problem that you surface.

The shared chat track seems intuitively more useful, as all subscribers essentially want the same merged chats, sequenced by time, not for each to have to merge 100 different chats from 100 different participants.

Solutions:

You could deploy the equivalent of a Multipoint Control Unit (MCU) , that subscribes to each of the end-users published chats and then produces a single merged track to which all participants subscribe. 2. Or you could have each participant directly publish into a shared track which all participants subscribe to. * How to avoid LOCATION conflicts? * GROUP ID is wall clock millisecond. Object id is a participant ID that is allocated each user when they join the chat. The Group ID orders the chats and the Object ID prevents collisions if two users publish a chat message in the same millisecond. This scheme assumes that an individual user will not publish faster than once per millisecond, but that can be enforced by your client app. * How to do a JOINING FETCH to start? * Since the GroupIDs are wall-clock time, if the client wants the last N minutes of chat, it does an absolute JOINING FETCH, which starts at NOW - N*60000 and adds a SUBSCRIBE for future objects.

Cheers Will

---

Chief Architect - Cloud Technology Group Akamai Technologies Switzerland Mobile +41 79 535 07 94

From: Yu You (Nokia) yu.you=40nokia.com@dmarc.ietf.org Date: Wednesday, 13 May 2026 at 10:21 To: moq@ietf.org moq@ietf.org Subject: [Moq] User case or question to Joining Fetch

This Message Is From an External Sender This message came from outside your organization.

Hi,

While implementing a conferencing PoC over MOQT, we identified a use case and would appreciate feedback and guidance from the MOQT community on how to implement this in a MOQT‑compliant way.

User use

The use case concerns multi‑participant text chat and fetching message history. In a per‑participant design, each participant could have an individual media track (e.g., video) and a chat track for messages.

Participants would subscribe to each other’s tracks under a shared namespace (e.g., room1). New track information could be discovered via SUBSCRIBE_NAMESPACE.

The media track is live, so new participants likely do not need to fetch past video objects. For chat messages, however, it would be useful to fetch past messages before receiving live ones, in order to understand the discussion context.

Problems?

Joining Fetch is designed to do the job. However, it appears tedious for subscribers. More importantly, the relay must track starting locations for n participants across (n-1) chat tracks. Because this state must be tracked on a strictly per-subscription basis, a relay hosting a chat room with n participants who are each fully subscribed to m distinct chat tracks must independently manage n×(n-1) downstream subscriptions. Consequently,…