QPACK Compression for MoQ Transport

1.1. Motivation

Consider a session where a client sends 100 SUBSCRIBE messages, each carrying the same 500-byte authorization token. Without compression, this results in 50,000 bytes of token data. With QPACK compression, the token is transmitted once and subsequent references require only a few bytes, reducing total overhead to approximately 600 bytes.¶

3.1. MOQT_QPACK_MAX_TABLE_CAPACITY

The MOQT_QPACK_MAX_TABLE_CAPACITY setup option (Option Type 0x10) specifies the maximum size in bytes of the QPACK dynamic table the endpoint is willing to maintain for decoding. This corresponds to SETTINGS_QPACK_MAX_TABLE_CAPACITY in HTTP/3.¶

The value is encoded as a variable-length integer. The default value is 0.¶

QPACK compression is enabled when both endpoints send this parameter with a value greater than 0. If either endpoint omits this parameter or sends a value of 0, QPACK compression MUST NOT be used and control messages use the standard MOQT format.¶

3.2. MOQT_QPACK_BLOCKED_STREAMS

The MOQT_QPACK_BLOCKED_STREAMS setup option (Option Type 0x11) specifies the maximum number of streams that can be blocked waiting for dynamic table updates. This corresponds to SETTINGS_QPACK_BLOCKED_STREAMS in HTTP/3.¶

The value is encoded as a variable-length integer. The default value is 0, which prevents any stream from being blocked. When set to 0, encoders MUST NOT reference dynamic table entries that have not been acknowledged.¶

This option is only meaningful when QPACK compression is enabled.¶

3.3. MOQT_QPACK_INDEX_SETUP_AUTH

The MOQT_QPACK_INDEX_SETUP_AUTH setup option (Option Type 0x12) controls whether AUTHORIZATION TOKEN options from the Setup messages are implicitly inserted into the dynamic table.¶

The value is encoded as a variable-length integer:¶

• 0: Do not implicitly insert setup auth tokens (default)¶

• 1: Implicitly insert setup auth tokens¶

When either endpoint omits this option or sends 0, implicit insertion does not occur and endpoints that wish to reference auth tokens explicitly insert them via the encoder stream.¶

This allows endpoints to authenticate the connection via setup auth tokens while still using Never-Indexed Literals for subsequent auth token references if desired.¶

When both endpoints send MOQT_QPACK_INDEX_SETUP_AUTH with value 1, any AUTHORIZATION TOKEN options from the Setup messages are implicitly inserted into the dynamic table without requiring encoder stream instructions.¶

Tokens from the Setup message, in the order they appeared, are inserted into the receiver's decoder dynamic table (indices 0, 1, 2, ...)¶

This allows the client to immediately reference its setup auth token in the first SUBSCRIBE message using a dynamic table reference, without resending it on the encoder stream.¶

The implicit entries count against the MOQT_QPACK_MAX_TABLE_CAPACITY limit. If the implicit entries would exceed the peer's advertised capacity, the excess entries (in reverse order) are not inserted and cannot be referenced.¶

Encoder stream insertions after setup use indices starting after the implicit entries. For example, if CLIENT_SETUP contained 2 auth tokens, the first explicit insertion would be at index 2.¶

4.1. Stream Types

This extension defines two new MOQT unidirectional stream types:¶

QPACK_ENCODER_STREAM (0x1f107a60):

Carries QPACK encoder instructions from the endpoint that opens the stream. The format and semantics are defined in Section 4.3.1 of [QPACK].¶

QPACK_DECODER_STREAM (0x1f107a61):

Carries QPACK decoder instructions from the endpoint that opens the stream. The format and semantics are defined in Section 4.4.1 of [QPACK].¶

4.2. Stream Initialization

Each endpoint MUST open exactly one QPACK encoder stream and one QPACK decoder stream for QPACK use. These streams MUST be opened before sending any message with a Compressed Block.¶

An endpoint MAY open these streams immediately after sending its Setup message if it included MOQT_QPACK_MAX_TABLE_CAPACITY with a non-zero value. If a receiving endpoint does not enable QPACK (omits the parameter or sends value 0), it MAY send STOP_SENDING on these streams; this is not an error and the streams SHOULD be reset.¶

Note that implicitly-inserted dynamic table entries from Setup auth tokens (see Section 3.3) do not require encoder stream instructions. A Compressed Block MAY reference these implicit entries even if no encoder stream instructions have been sent.¶

If an endpoint receives a Compressed Block that references a dynamic table entry beyond the implicit entries before receiving any encoder stream data, it MUST buffer the message until the required encoder instructions arrive or close the session with PROTOCOL_VIOLATION if buffering limits are exceeded.¶

4.3. Stream Lifetime

QPACK encoder and decoder streams MUST remain open for the duration of the MOQT session. If either stream is closed after QPACK is negotiated, the endpoint MUST close the MOQT session with PROTOCOL_VIOLATION.¶

5.1. MOQPACK Flag Bit

This extension uses a flag bit in the message type to indicate if QPACK is used. Bit 6 (0x40) of the message type indicates MOQPACK format:¶

• Type & 0x40 == 0: Standard MOQT format¶

• Type & 0x40 == 0x40: MOQPACK format¶

For example: - SUBSCRIBE standard = 0x03 - SUBSCRIBE MOQPACK = 0x43¶

All MOQPACK message types listed in this document are reserved in the MOQT message type registry and MUST NOT be used for other purposes.¶

When MOQPACK is negotiated, endpoints MUST accept both standard and MOQPACK formats for all applicable messages. An endpoint MAY send either format, but SHOULD prefer MOQPACK format to benefit from compression.¶

When MOQPACK is NOT negotiated, endpoints MUST NOT send MOQPACK format messages and MUST close the session with PROTOCOL_VIOLATION if they receive one.¶

In MOQPACK format, Track Namespace, Track Name, and Parameters are moved into a QPACK Compressed Block. Other message-specific fields including Properties remain unchanged.¶

When the Compressed Block is the last field in the message, it extends to the end of the message payload (as determined by the message Length field) and no explicit Compressed Block Length is needed. When additional fields follow the Compressed Block (such as Properties), an explicit Compressed Block Length field is present to delimit the block.¶

5.2. Pseudo-Parameter Types

The following pseudo-parameter types are reserved for encoding namespace and track name fields in the Compressed Block:¶

These pseudo-types use the same encoding as regular parameters: Literal with Static Name Reference for new values, or Indexed with Dynamic Table for previously-inserted values.¶

TRACK_NAMESPACE_SET Value {
  Number of Track Namespace Fields (vi64),
  Track Namespace Field (..) ...
}

Track Namespace Field {
  Track Namespace Field Length (vi64),
  Track Namespace Field Value (..)
}

5.3. Namespace Reconstruction

A Track Namespace, Track Namespace Prefix or Track Namespace Suffix is reconstructed by assembling consecutive TRACK_NAMESPACE_ELEMENT and TRACK_NAMESPACE_SET field lines, which MUST appear first in the Compressed Block before TRACK_NAME or any parameters.¶

TRACK_NAMESPACE_ELEMENT adds a single element to the namespace tuple. TRACK_NAMESPACE_SET appends all elements from a serialized tuple. These can be intermixed and appear in any combination. For example:¶

Namespace ("conference", "room1", "audio"):

Option A - All elements:
  TRACK_NAMESPACE_ELEMENT: "conference"
  TRACK_NAMESPACE_ELEMENT: "room1"
  TRACK_NAMESPACE_ELEMENT: "audio"

Option B - Full set:
  TRACK_NAMESPACE_SET: ("conference", "room1", "audio")

Option C - Mixed:
  TRACK_NAMESPACE_ELEMENT: "conference"
  TRACK_NAMESPACE_SET: ("room1", "audio")

This allows encoders to maximize compression by inserting commonly-reused elements or partial tuples into the dynamic table.¶

The message type determines the semantics of the assembled namespace:¶

• SUBSCRIBE, PUBLISH, FETCH, TRACK_STATUS, PUBLISH_NAMESPACE: Full namespace¶

• SUBSCRIBE_NAMESPACE: Namespace prefix¶

• NAMESPACE, NAMESPACE_DONE: Namespace suffix¶

5.4. Field Ordering

Namespace elements (TRACK_NAMESPACE_ELEMENT and TRACK_NAMESPACE_SET) MUST appear first in the Compressed Block, followed by TRACK_NAME (if present), followed by parameters in increasing order of parameter type.¶

Within the namespace elements section, entries appear in the order they contribute to the namespace tuple and are not required to be in increasing order of type. TRACK_NAMESPACE_ELEMENT (0x0A) and TRACK_NAMESPACE_SET (0x0B) MAY be intermixed.¶

Parameters (excluding pseudo-parameter types) MUST appear in increasing order of their parameter type. If parameters appear out of order, the receiver MUST close the session with PROTOCOL_VIOLATION.¶

5.5. Required Fields

When decoding a Compressed Block, the receiver MUST verify that all required fields are present:¶

• SUBSCRIBE, PUBLISH, TRACK_STATUS, Standalone FETCH: At least one namespace element (TRACK_NAMESPACE_ELEMENT or TRACK_NAMESPACE_SET) and TRACK_NAME¶

• SUBSCRIBE_NAMESPACE, PUBLISH_NAMESPACE, NAMESPACE, NAMESPACE_DONE: At least one namespace element¶

• Joining FETCH, parameter-only messages: No required pseudo-parameters¶

An empty namespace (zero elements) is valid only if explicitly allowed by the message semantics.¶

If a required field is missing, the receiver MUST close the session with PROTOCOL_VIOLATION.¶

5.6. MOQPACK Message Formats

SUBSCRIBE Message (MOQPACK) {
  Type (vi64) = 0x43,
  Length (16),
  Request ID (vi64),
  Track Alias (vi64),
  Compressed Block (..)
}

PUBLISH Message (MOQPACK) {
  Type (vi64) = 0x5D,
  Length (16),
  Request ID (vi64),
  Track Alias (vi64),
  Compressed Block Length (vi64),
  Compressed Block (..),
  Properties (..)
}

Standalone Fetch (MOQPACK) {
  Start Location (Location),
  End Location (Location),
  Compressed Block (..)
}

Joining Fetch (MOQPACK) {
  Joining Request ID (vi64),
  Join Type (vi64),
  Joining Start (vi64),
  Compressed Block (..)
}

FETCH Message (MOQPACK) {
  Type (vi64) = 0x56,
  Length (16),
  Request ID (vi64),
  Fetch Type (vi64),
  [Standalone (Standalone Fetch QPACK),]
  [Joining (Joining Fetch QPACK),]
}

SUBSCRIBE_NAMESPACE Message (MOQPACK) {
  Type (vi64) = 0x51,
  Length (16),
  Request ID (vi64),
  Subscribe Options (vi64),
  Compressed Block (..)
}

PUBLISH_NAMESPACE Message (MOQPACK) {
  Type (vi64) = 0x46,
  Length (16),
  Request ID (vi64),
  Compressed Block (..)
}

NAMESPACE Message (MOQPACK) {
  Type (vi64) = 0x48,
  Length (16),
  Compressed Block (..)
}

NAMESPACE_DONE Message (MOQPACK) {
  Type (vi64) = 0x4E,
  Length (16),
  Compressed Block (..)
}

SUBSCRIBE_OK Message (MOQPACK) {
  Type (vi64) = 0x44,
  Length (16),
  Request ID (vi64),
  Compressed Block Length (vi64),
  Compressed Block (..),
  Properties (..)
}

FETCH_OK Message (MOQPACK) {
  Type (vi64) = 0x58,
  Length (16),
  Request ID (vi64),
  Compressed Block Length (vi64),
  Compressed Block (..),
  Properties (..)
}

Parameter-Only Message (MOQPACK) {
  Type (vi64) = <standard type> | 0x40,
  Length (16),
  [Message-specific fields...],
  Compressed Block (..)
}

6.1. Compressed Block Format

Each Compressed Block begins with the standard QPACK encoded field section prefix as defined in Section 4.5.1 of [QPACK]:¶

Compressed Block {
  Required Insert Count (8+),
  Sign and Delta Base (8+),
  Encoded Field Lines (..)
}

Required Insert Count:

Encoded as specified in Section 4.5.1.1 of [QPACK]. Indicates the minimum dynamic table state needed to decode this block. A value of 0 means the block has no dynamic table references.¶

Base:

Encoded as a sign bit and Delta Base as specified in Section 4.5.1.2 of [QPACK]. Used to resolve relative indices in field line representations.¶

6.2. Indexing

Dynamic table references in field lines use relative indexing as specified in [QPACK] Section 3.2.5. A relative index of 0 refers to the entry with absolute index equal to Base - 1. Encoders and decoders MUST use relative indices, not absolute indices, in Compressed Blocks.¶

Post-Base indexing (Section 3.2.6 of [QPACK]) MAY be used for entries inserted after the Base. This enables single-pass encoding where the encoder inserts entries while encoding a field section and references them using Post-Base indices.¶

6.3. MOQT Static Table Semantics

In standard QPACK, a static table index retrieves a predefined (name, value) pair. In this extension, the static table conceptually contains entries where the "name" is the parameter type integer and there is no predefined value.¶

The static table index equals the MOQT parameter type:¶

For example: * Static index 0x02 represents DELIVERY_TIMEOUT * Static index 0x03 represents AUTHORIZATION_TOKEN * Static index 0x0A represents TRACK_NAMESPACE_ELEMENT * Static index 0x0C represents TRACK_NAME * Static index 0x20 represents SUBSCRIBER_PRIORITY¶

This means any valid MOQT parameter type can be referenced by static index without requiring pre-registration in a table.¶

6.4. Dynamic Table

Dynamic table entries store complete MOQT parameters (type and value). The entry size calculation follows [QPACK] Section 3.2.1: the size of an entry is the sum of its name size, value size, and 32 bytes of overhead. This extension uses a fixed name size of 4 bytes for the parameter type regardless of its encoded length.¶

Token Value = Token Type (vi64) || Token Payload (..)

Literal Field Line With Name Reference:
  Name Index: 0x03 (AUTHORIZATION_TOKEN)
  Value: 0x01 || "eyJhbGciOiJIUzI1NiIs..."

6.5. Decoding

When receiving a message with a Compressed Block, the receiver:¶

1. Parses fixed message fields (Request ID, Track Alias, etc.)¶

2. If a Compressed Block is present: a. Waits for any referenced dynamic table entries to become available, subject to MOQT_QPACK_BLOCKED_STREAMS limits b. Decodes the QPACK Compressed Block to recover namespace elements, track name, and parameters¶

3. Processes the fully decoded message¶

If QPACK decoding fails, the receiver MUST close the session with MOQPACK_DECOMPRESSION_FAILED.¶

The total size of the decompressed message fields (the sum of all parameter values, namespace elements, and track name, excluding interior length fields) MUST NOT exceed 65535 bytes. If a decompressed message exceeds this limit, the receiver MUST close the session with MOQPACK_DECOMPRESSION_FAILED.¶

7.1. Encoder Behavior

Encoders SHOULD insert frequently-used parameter values into the dynamic table. Authorization tokens, Track Namespace Elements and Track names that will be reused across multiple messages are prime candidates for insertion.¶

Short values like brief track names ("audio", "video") MAY be sent as literals rather than inserted, since the overhead of insertion and indexed reference is similar to sending the literal value. Insertion is more beneficial for: - Long values (large auth tokens, long namespace elements) - Values that will be reused across multiple messages (namespace elements shared by many tracks, auth tokens used for many subscriptions)¶

Encoders MUST respect the peer's MOQT_QPACK_MAX_TABLE_CAPACITY and MOQT_QPACK_BLOCKED_STREAMS limits when making insertion and reference decisions.¶

Encoders SHOULD use the QPACK duplicate instruction when a dynamic table entry is at risk of eviction but is still frequently referenced.¶

7.2. Decoder Behavior

Decoders MUST process encoder instructions from the QPACK encoder stream before processing any message that might reference those insertions.¶

Decoders MUST send Section Acknowledgment instructions on the QPACK decoder stream after successfully decoding a Compressed Block that references the dynamic table (Required Insert Count > 0). Compressed Blocks that contain only Literal Field Lines with Static Name References do not require acknowledgment.¶

8.1. MOQPACK_DECOMPRESSION_FAILED

This document defines a new MOQT session error code:¶

MOQPACK_DECOMPRESSION_FAILED (0xTBD):

A QPACK Compressed Block could not be decoded, or the decompressed message exceeded implementation limits. This is always a session error; the endpoint MUST close the MOQT session.¶

8.2. QPACK Errors

QPACK decoding errors (as defined in Section 6 of [QPACK]) result in session termination. The specific mapping is:¶

9.1. Dynamic Table State

The QPACK dynamic table maintains state across messages. An attacker with knowledge of dynamic table contents could potentially:¶

• Determine which authorization tokens have been used¶

• Infer subscription patterns from parameter compression ratios¶

Implementations SHOULD consider these privacy implications when deciding which values to insert into the dynamic table.¶

9.2. Compression Oracle Attacks

As with HTTP compression, implementers need to take care to avoid compression oracle attacks where an attacker can infer secret values by observing compressed message sizes. Applications SHOULD NOT mix attacker-controlled data with secret authorization tokens in the same field section.¶

9.3. Resource Exhaustion

Endpoints MUST enforce the negotiated table capacity limits to prevent resource exhaustion attacks. An endpoint that attempts to exceed these limits causes a session error.¶

10.1. Setup Option Types

This document registers the following Setup Option Types in the "MOQT Setup Options" registry:¶

10.2. Unidirectional Stream Types

This document registers the following unidirectional stream types in the "MOQT Stream Types" registry:¶

10.3. Pseudo-Parameter Types

This document registers the following pseudo-parameter types in the "MOQT Message Parameters" registry. These types are reserved for use in QPACK Compressed Blocks and MUST NOT appear in standard Parameters fields.¶

10.4. Message Types

This document reserves the following message types in the "MOQT Message Types" registry for use as MOQPACK-format messages:¶

10.5. Session Error Codes

This document registers the following session error code in the "MOQT Session Error Codes" registry:¶

11.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-16, 13 January 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-16>.

[QPACK]

Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: Field Compression for HTTP/3", RFC 9204, DOI 10.17487/RFC9204, June 2022, <https://www.rfc-editor.org/rfc/rfc9204>.

[QUIC]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[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>.

[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>.

11.2. Informative References

[HPACK]

Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/rfc/rfc7541>.

Scenario

A client sends three SUBSCRIBE messages to the same track with the same authorization token:¶

• Track Namespace: ("conference", "room42")¶

• Track Name: "audio"¶

• Token Type: 1 (e.g., JWT)¶

• Token Value: "eyJhbGciOiJIUzI1NiIs..." (500 bytes)¶

The auth token was sent in CLIENT_SETUP and is implicitly inserted at dynamic table absolute index 0 after QPACK negotiation succeeds.¶

First SUBSCRIBE

The encoder inserts namespace elements on the encoder stream. The short track name "audio" is sent as a literal rather than inserted:¶

Encoder Stream:
  Insert With Static Name Reference
    Name Index: 0x0A (TRACK_NAMESPACE_ELEMENT)
    Value: "conference"
  Insert With Static Name Reference
    Name Index: 0x0A (TRACK_NAMESPACE_ELEMENT)
    Value: "room42"

Dynamic table state after insertions:¶

The encoder sends the SUBSCRIBE with Required Insert Count = 3 and Base = 3:¶

SUBSCRIBE Message:
  Type: 0x43
  Request ID: 1
  Track Alias: 100
  Compressed Block:
    Required Insert Count: 3 (encoded per RFC 9204 Section 4.5.1.1)
    Base: Sign=0, Delta=0 (Base = Required Insert Count = 3)
    Indexed Field Line (Dynamic, relative index 1)  // abs 1 = "conference"
    Indexed Field Line (Dynamic, relative index 0)  // abs 2 = "room42"
    Literal Field Line (Static Name 0x0C, Value "audio")  // TRACK_NAME
    Indexed Field Line (Dynamic, relative index 2)  // abs 0 = AUTH_TOKEN

Relative index calculation: relative = Base - 1 - absolute¶

• "conference": relative = 3 - 1 - 1 = 1¶

• "room42": relative = 3 - 1 - 2 = 0¶

• AUTH_TOKEN: relative = 3 - 1 - 0 = 2¶

Compressed Block: ~12 bytes (including prefix and literal track name) Uncompressed equivalent: ~526 bytes¶

Subsequent SUBSCRIBEs to Same Track

No encoder stream instructions needed; namespace elements are in the table, track name is sent as literal again:¶

SUBSCRIBE Message:
  Type: 0x43
  Request ID: 2
  Track Alias: 101
  Compressed Block:
    Required Insert Count: 3
    Base: Sign=0, Delta=0
    Indexed Field Line (Dynamic, relative index 1)  // "conference"
    Indexed Field Line (Dynamic, relative index 0)  // "room42"
    Literal Field Line (Static Name 0x0C, Value "audio")  // TRACK_NAME
    Indexed Field Line (Dynamic, relative index 2)  // AUTH_TOKEN

Each subsequent SUBSCRIBE to the same track: ~12 bytes instead of ~526 bytes.¶

SUBSCRIBE to Different Track, Same Namespace

The track name "video" is also short, so we send it as a literal. No encoder stream instructions needed:¶

SUBSCRIBE Message:
  Type: 0x43
  Request ID: 3
  Track Alias: 102
  Compressed Block:
    Required Insert Count: 3
    Base: Sign=0, Delta=0
    Indexed Field Line (Dynamic, relative index 1)  // "conference"
    Indexed Field Line (Dynamic, relative index 0)  // "room42"
    Literal Field Line (Static Name 0x0C, Value "video")  // TRACK_NAME
    Indexed Field Line (Dynamic, relative index 2)  // AUTH_TOKEN

The namespace elements are reused; the different track name is sent as a literal.¶

Setup Options

Stream Types

Pseudo-Parameter Types

MOQPACK Message Types

The MOQPACK flag bit (0x40) is OR'd with standard MOQT message types:¶

Static Table

Standard QPACK libraries include a static table of 99 predefined HTTP header (name, value) pairs. For MOQPACK, the static table is reinterpreted: the static table index directly represents the MOQT parameter type integer, and there are no predefined values. Implementations need to replace or bypass the HTTP static table. A simple approach is to treat the static table as a mapping from index to a 4-byte big-endian representation of the parameter type, with no predefined value.¶

Prohibited Encodings

Standard QPACK supports all field line representations. MOQPACK prohibits several (see Section 6.3.1). Implementations should configure the encoder to only emit:¶

• Literal Field Line With Static Name Reference (for new parameter values)¶

• Indexed Field Line with Dynamic Table (for previously-inserted values)¶

• Indexed Field Line with Post-Base Index¶

And should configure the decoder to reject:¶

• Indexed Field Line with Static Table¶

• Literal Field Line With Dynamic Name Reference¶

• Literal Field Line with Post-Base Name Reference¶

• Literal Field Line With Literal Name¶

• Huffman-encoded string literals (H=1)¶

Encoder Stream Instructions

Only two insertion forms are used:¶

• Insert With Static Name Reference¶

• Duplicate¶

Insert With Dynamic Name Reference and Insert With Literal Name are not used.¶

Decoder Stream: Request IDs Instead of Stream IDs

Standard QPACK decoder instructions (Section Acknowledgment, Stream Cancellation) carry QUIC stream IDs. In MOQPACK, these carry MOQT Request IDs instead (see Section 7.2.1). The encoder needs to track Compressed Blocks per Request ID rather than per stream ID. This also enables MOQPACK to operate over WebTransport where QUIC stream IDs are not exposed to the application.¶

Entry Size Calculation

The name size for all entries is fixed at 4 bytes (rather than the variable-length header name strings used in HTTP). The 32-byte per-entry overhead from [QPACK] Section 3.2.1 still applies.¶