DEFLATE Compressed Tracks for MoQ
draft-lcurley-moq-flate-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Luke Curley | ||
| Last updated | 2026-09-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lcurley-moq-flate-00
moq L. Curley
Internet-Draft 24 September 2026
Intended status: Informational
Expires: 28 March 2027
DEFLATE Compressed Tracks for MoQ
draft-lcurley-moq-flate-00
Abstract
This document specifies how a MoQ Transport [moqt] track carries
DEFLATE-compressed payloads. Each subgroup is one raw DEFLATE
stream, sync flushed at each object boundary, so every object stays
self-delimited while later objects compress against the earlier ones
in the subgroup. Small repetitive payloads compress several times
better than they do alone, and a dropped group costs nothing beyond
itself because the window never spans one. Nothing is added to the
wire: the application declares the track compressed, and a relay
forwards it unchanged.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Curley Expires 28 March 2027 [Page 1]
Internet-Draft moq-flate September 2026
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Compression Scope . . . . . . . . . . . . . . . . . . . . . . 3
4. Compressed Stream . . . . . . . . . . . . . . . . . . . . . . 3
5. Declaring Compression . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Introduction
A live track is usually many small payloads rather than a few large
ones. DEFLATE [RFC1951] on one such payload alone is close to
useless: the window starts cold, and below a few hundred bytes the
block overhead can exceed the savings. The redundancy worth
exploiting is between payloads: a JSON snapshot followed by its
deltas, a telemetry record repeated at 50 Hz, successive subtitle
cues.
Compressing a whole track captures that redundancy but breaks on
delivery. Groups are dropped, arrive out of order, and a subscriber
joins at an arbitrary point, so a window spanning data it never
received cannot be reconstructed. Scoping the window to a subgroup
is the compromise: a drop costs nothing beyond itself, joining costs
only the current group, and the transport never has to know.
Curley Expires 28 March 2027 [Page 2]
Internet-Draft moq-flate September 2026
3. Compression Scope
Each subgroup is a separate DEFLATE stream: its object payloads share
one window, in order, starting cold. [moql] has no subgroups, so each
group is one stream of frames.
The application decides which subgroups a track uses; a consumer
knows which to expect and decodes each one's objects in order.
A publisher MUST NOT send a compressed track in datagrams, which are
neither ordered nor reliable.
An object with no payload is skipped, neither advancing nor resetting
the window.
4. Compressed Stream
A subgroup's payloads are compressed, in order, into one raw DEFLATE
stream [RFC1951], with no zlib or gzip wrapper. A publisher MUST
sync flush after each payload, which ends the block and byte-aligns
the output while retaining the window ([RFC1951], Section 3.2.4,
Z_SYNC_FLUSH in zlib). Each object carries the bytes that flush
produced, with no length prefix.
A sync flush always ends with the marker 0x00 0x00 0xff 0xff. A
publisher MUST omit it from each object and a consumer MUST append it
before decompressing, the same trick as permessage-deflate
([RFC7692], Section 7.2.1).
A zero-length payload is neither compressed nor decompressed.
The stream is never terminated: no object ends in a final block, so a
consumer decompresses incrementally and MUST NOT treat the absent end
of stream as truncation.
A consumer missing an object MUST abandon the rest of the subgroup,
which it can no longer decompress. The compression level is a
publisher's choice; any conformant stream decodes.
5. Declaring Compression
The application declares a track compressed, conventionally with a .z
suffix on the track name, or in its catalog. A consumer MUST NOT
infer compression from the payload: raw DEFLATE has no magic number,
so a wrong guess yields plausible garbage.
Curley Expires 28 March 2027 [Page 3]
Internet-Draft moq-flate September 2026
There is deliberately no transport signal. A relay drops objects and
re-frames what it forwards, so a transport that knew about the window
would make the relay responsible for emitting a stream that still
decodes, which means carrying a DEFLATE implementation. Instead a
relay forwards opaque bytes, and an endpoint that has never heard of
this document never asks for a compressed track.
6. Security Considerations
A shared window is a side channel. The compressed size of one
payload reveals how much it has in common with the payloads before
it, enough to recover a secret an attacker can partially guess, as
CRIME and BREACH demonstrated against TLS and HTTP compression. A
publisher MUST NOT compress a secret and attacker-influenced data in
the same subgroup. Encryption does not mitigate this, since the
sizes are visible to anyone on the path.
A few bytes can inflate to gigabytes, so a consumer MUST bound the
decompressed size of each object and abandon the subgroup once that
bound is exceeded. Each open subgroup also holds a window of up to
32 KiB, so a consumer SHOULD bound how many it decompresses at once.
7. IANA Considerations
This document requests no registrations. The format lives inside
object payloads, which [moqt] treats as opaque.
8. References
8.1. Normative References
[moqt] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
"Media over QUIC Transport", Work in Progress, Internet-
Draft, draft-ietf-moq-transport-21, 8 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
transport-21>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/rfc/rfc1951>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Curley Expires 28 March 2027 [Page 4]
Internet-Draft moq-flate September 2026
[RFC7692] Yoshino, T., "Compression Extensions for WebSocket",
RFC 7692, DOI 10.17487/RFC7692, December 2015,
<https://www.rfc-editor.org/rfc/rfc7692>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
[moql] Curley, L., "Media over QUIC - Lite", Work in Progress,
Internet-Draft, draft-lcurley-moq-lite-05, 30 June 2026,
<https://datatracker.ietf.org/doc/html/draft-lcurley-moq-
lite-05>.
Acknowledgments
This document was drafted with the assistance of Claude, an AI
assistant by Anthropic.
Author's Address
Luke Curley
Email: kixelated@gmail.com
Curley Expires 28 March 2027 [Page 5]