Message Snapshot

• List: moq@ietf.org
• Thread subject: User case or question to Joining Fetch
• Message subject: [Moq] User case or question to Joining Fetch
• Author: Yu You (Nokia)
• Published: 2026-05-13T08:19:55.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 13, 2026. Hi, While implementing a conferencing PoC over MOQT, we identified a use case and would appreciate feedback and guidance from the MOQT communi…

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, 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

Plain-Text Body

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, the relay is forced to track and save n×(n-1) unique Joining Locations in its memory to properly compute fetch ranges for all participants across all tracks.

Alternative hack

Alternatively, we anticipated a design with a single shared “chat” track to which all participants could publish objects. However, this approach introduces the risk of GroupID/ObjectID collisions. In addition, the relay would need to deduplicate objects before forwarding them.

Even if the collision issue were resolved through ad hoc mechanisms, it remains unclear how Joining Fetch would operate with multiple publishers on the same track. Would a default Starting Location of (0,0) be sufficient in this case, or is a different mechanism expected?

Thanks.

Yu