IETF MOQ WG: MoQ + Compression

Message Snapshot

• List: moq@ietf.org
• Thread subject: MoQ + Compression
• Message subject: [Moq] Re: MoQ + Compression
• Author: Luke Curley
• Published: 2026-06-26T18:35:40.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 June 26, 2026. Yeah Alan, that's the problem with doing it at the application layer. I'm currently publishing two tracks: - catalog.json

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

Yeah Alan, that's the problem with doing it at the application layer. I'm currently publishing two tracks: - catalog.json

Plain-Text Body

Yeah Alan, that's the problem with doing it at the application layer. I'm currently publishing two tracks:

• catalog.json
• catalog.json.z

But you can imagine the headache if both of these files were large, and there was a 50-50 split among subscribers.

I mocked up a transport extension that was something like:

1. SETUP indicates decompression schemes in preferred order (1 = deflate, 2 = zstd, etc).
2. SUBGROUP_HEADER (or SUBSCRIBE_OK?) indicates the compression scheme.

Like what Lucas said, the real problem is intermediaries. You ideally want a relay to proxy the data, not waste CPU on (re)compression. A relay can always decompress the data for subscribers that don't support a compression scheme, but it probably shouldn't (re)compress it.

Suhas you run into rollout issues with that approach because it's not backwards compatible. You blindly have to assume that every single subscriber supports a compression scheme before you can turn it on.