IETF MOQ WG: MoQ + Compression

Message Snapshot

• List: moq@ietf.org
• Thread subject: MoQ + Compression
• Message subject: [Moq] MoQ + Compression
• Author: Luke Curley
• Published: 2026-06-26T18:00:33.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. Hey MoQ, I wrote a blog post about all of my recent additions lately. One thing I wanted to raise was compression. Some of my users send 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

Hey MoQ, I wrote a blog post about all of my recent additions lately. One thing I wanted to raise was compression. Some of my users send JSON

Plain-Text Body

Hey MoQ,

I wrote a blog post about all of my recent additions lately.

One thing I wanted to raise was compression. Some of my users send JSON blobs for sensor data and/or controls. We want to reduce the bitrate, so I investigated some options.

I tried JSON Merge Patch, DEFLATE (aka gzip*), and zstd. I ultimately dropped zstd because there's no browser support, but more on that later.

There are actually two DEFLATE modes I tested:

1. Compress each frame independently.
2. Compress each sub-group, flushing at each frame (Z_SYNC_FLUSH). See RFC7692 https://datatracker.ietf.org/doc/html/rfc7692#section-6.1 for something similar.

The bitrate savings for each: No DEFLATE DEFLATE per frame DEFLATE per group No deltas 0% 39% 89% JSON Merge Patch 58% 72% 91%^ If that doesn't display: DEFLATE per frame: 39% DEFLATE per group: 89%

It makes a HUGE difference compressing each sub-group because the DEFLATE encoder can reuse the last 32KB as a dictionary instead of starting from scratch. JSON Merge Patch is only marginally worth it because it reduces CPU usage (fewer bytes to compress and parse).

A few takeaways I have regarding MSF:

1. The custom initDataList pointers aren't needed if we compress.
2. The custom add, remove, clone track delta encoding isn't needed if we compress.
3. MSF_COMPRESSION is per-frame, but it should be per sub-group.

Finally, I think compression should be reusable in MoQ. There should be a "standard" way of doing DEFLATE, zstd, brotli, etc even for non-JSON content. Otherwise every application ends up reinventing the wheel.

I even think the compression scheme should be in the moq-transport layer. Otherwise it becomes impossible to add enable compression (ex. zstd) unless literally every possible subscriber supports it. The precedent exists; see HTTP transfer-encoding.

But pls somebody else check my work and try this too.