Skip to main content

DEFLATE Compressed Tracks for MoQ
draft-lcurley-moq-flate-00

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]