[Moq] Re: MoQ + Compression

[Luke Curley <[e-mail]>]

Sorry hit the send button to early.

But you can imagine the headache if both of these files were large


I meant tracks.

Some companies use my libraries to publish sensor data or controls over
Starlink. We don't want a scenario where one outdated subscriber that
doesn't support compression causes 9x the data transfer from the publisher
to the relay.

Making DEFLATE mandatory to implement in moq-transport would fix a lot.


On Fri, Jun 26, 2026 at 11:35 AM Luke Curley <[e-mail]> wrote:

> 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.
>
>
> On Fri, Jun 26, 2026 at 11:08 AM Alan Frindell <[e-mail]> wrote:
>
>> Cool work Luke.
>>
>> MOQT's model is clearly "the objects can't change for the same track
>> name" - therefore the only way we have to signal compression support now is
>> it bake it into the Full Track Name (eg: SUBSCRIBE namespace--name.deflate
>> or something).  Otherwise, aren't you wandering into HTTP content
>> negotiation, Vary header, etc territory?
>>
>> -Alan
>>
>>