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: Luke Curley
• Published: 2026-05-15T14:56:51.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Luke Curley posted to the MOQ working group mailing list on May 15, 2026. I'll +1 to Mo, While the draft technically allows multiple publishers to produce different objects of the same track, there be dragons. For examp…

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

I'll +1 to Mo, While the draft technically allows multiple publishers to produce different objects of the same track, there be dragons. For example, a relay that

Plain-Text Body

I'll +1 to Mo,

While the draft technically allows multiple publishers to produce different objects of the same track, there be dragons. For example, a relay that receives a (JOINING) FETCH would have to send a copy of that (JOINING) FETCH to all N publishers and zip the responses. Except I'm pretty sure Alan added a line saying a relay SHOULD NOT do this, and I agree.

I totally understand the Nx(N-1) concern. I would strongly recommend starting with separate namespaces/tracks for each participant. If that doesn't scale, I would use an explicit aggregation service instead of expecting generic MoQ relays to handle multi-publisher.

On Fri, May 15, 2026 at 7:38 AM Mo Zanaty (mzanaty) <mzanaty= 40cisco.com@dmarc.ietf.org> wrote: