Exploring SCHC Compression of QUIC Frames

2.1. QUIC Frames

After QUIC packet protection is removed, the payload of a QUIC packet is parsed as a sequence of frames. Each frame starts with a Frame Type followed by fields whose syntax depends on that type. QUIC version 1 defines frames such as STREAM, ACK, PADDING, CRYPTO, MAX_DATA, RESET_STREAM, STOP_SENDING, and CONNECTION_CLOSE.¶

STREAM frames carry bytes for an application stream. The STREAM Frame Type encodes three flags that indicate whether the frame contains an Offset field, a Length field, and the FIN flag. The frame also carries a Stream ID and the stream data itself.¶

ACK frames carry acknowledgment information. An ACK frame contains the Largest Acknowledged packet number, an ACK Delay, an ACK Range Count, a First ACK Range, and zero or more additional Gap and ACK Range Length pairs. The ACK_ECN frame variant additionally carries ECN counters.¶

QUIC uses a variable-length integer encoding for many frame fields. Values are encoded in 1, 2, 4, or 8 bytes, and the two most significant bits of the first byte identify the length. Frame Types are also QUIC variable-length integers and are encoded using the shortest possible representation. All QUIC version 1 frame types used as examples in this document fit in one byte.¶

QUIC packet payloads are protected by QUIC-TLS [RFC9001]. For protected 1-RTT packets, frame bytes are encrypted and authenticated. An on-path compressor that is not part of a QUIC endpoint cannot inspect or modify these frames.¶

2.2. SCHC

SCHC defines a rule-based compression framework. A SCHC rule contains field descriptors, matching operators, target values, and compression/decompression actions. The sender selects a rule that matches a packet or header description, sends a Rule ID and any required residue, and the receiver reconstructs the original fields using the same rule.¶

SCHC is designed for environments where both endpoints share a static context. That context can be provisioned, configured, or otherwise agreed before compression is used. The SCHC YANG data model [RFC9363] and management approaches such as [I-D.toutain-schc-coreconf-management] are relevant building blocks for deployments that need managed SCHC contexts.¶

RFC 8724 defines SCHC compression for IPv6 and UDP headers and the generic SCHC rule model. It does not define field descriptors or compression behavior for QUIC frames. Applying SCHC to QUIC frames would therefore require a QUIC-specific profile or an equivalent set of deployment rules.¶

The related draft [I-D.sirohi-schc-quic-compression] discusses applying SCHC to accessible outer packet fields, including IP, UDP, and QUIC header fields. This document focuses on the inner QUIC frame sequence that becomes visible only inside participating QUIC endpoints.¶

2.3. Scope and Assumptions

The examples and discussion in this document use the following assumptions:¶

• compression is performed inside participating QUIC endpoints;¶

• frame compression occurs before QUIC payload encryption;¶

• frame decompression occurs after QUIC payload decryption;¶

• compressed bytes remain protected by normal QUIC packet protection;¶

• application data compression is out of scope;¶

• the main examples are STREAM and ACK frames; and¶

• packets that cannot be compressed profitably can be sent using ordinary QUIC frame encoding.¶

The document does not assume that a compressor can read encrypted QUIC frames in the network. It also does not assume that a SCHC rule can change QUIC transport semantics. After decompression, the receiver has to process the reconstructed logical frames as ordinary QUIC frames.¶

4.1. One Rule for the Complete Frame Sequence

One approach is to define a SCHC rule for a complete expected sequence of frames in one QUIC packet payload. Examples include:¶

• a packet containing exactly one STREAM frame;¶

• a packet containing exactly one ACK frame;¶

• a packet containing an ACK followed by one STREAM frame; and¶

• a packet containing a fixed sequence of several STREAM frames.¶

This approach can provide high compression when traffic is predictable. The selected rule can imply the number of frames, their order, their Frame Types, and the presence or absence of optional fields. A single Rule ID can replace several ordinary Frame Types and can also remove repeated or derived values.¶

For example, a rule for "ACK followed by STREAM on a known stream" can elide the ACK Range Count when it is known to be zero, elide the STREAM Frame Type, elide the known Stream ID, and use the remaining packet length to derive the STREAM Length. The fixed rule overhead is shared across both logical frames.¶

The cost is rule-set growth. If the deployment needs to support ACK, STREAM, ACK plus STREAM, two STREAM frames, STREAM plus MAX_DATA, and other combinations, the number of useful sequence rules can grow quickly. Unexpected frame sequences either need a generic fallback rule or have to be sent using ordinary QUIC encoding.¶

Complete-sequence rules are therefore most attractive for controlled traffic with stable packet shapes. They are less attractive for general QUIC traffic, where scheduling, congestion control, loss recovery, and application behavior can change the frame sequence dynamically.¶

4.2. One Rule per Frame

A second approach is to compress each QUIC frame independently. A STREAM rule compresses a STREAM frame, an ACK rule compresses an ACK frame, and so on. The compressed packet payload is then a sequence of compressed-frame encodings.¶

This approach gives better rule reuse. The same STREAM rule can be used regardless of whether the packet also carries an ACK frame or a control frame. Frame ordering remains flexible, and the rule set does not need a separate rule for every complete packet shape.¶

The cost is per-frame overhead. Each compressed frame needs enough information for the receiver to identify the rule and find the next compressed or native frame. That usually implies a Rule ID and either an explicit length, an implicit fixed size, or a rule-specific delimiter.¶

For small frames, this overhead can exceed the removed bytes. For example, a one-byte Rule ID used to remove a one-byte Frame Type does not help if an additional delimiter is also required. A per-frame approach is therefore flexible but often weak for isolated small frames.¶

4.3. Generic Frame Rules

A conservative baseline is to define generic rules that preserve most values and remove only fields that are constant or structurally predictable. For example, a generic STREAM rule might imply the STREAM frame variant while still carrying the Stream ID, Offset, Length, and data. A generic ACK rule might remove a zero ACK Range Count only when the rule explicitly matches that case.¶

Generic rules require few deployment assumptions. They can operate using static context only and can support a broad set of connections. They are also easier to reason about because most QUIC values are still transmitted directly.¶

The downside is modest compression. If the rule only removes a one-byte Frame Type but the compressed representation adds a Rule ID and a length, the packet becomes larger. Generic rules are useful as an evaluation baseline, but they are unlikely to justify a QUIC extension by themselves.¶

4.4. Traffic-Specific or Stateful Rules

More aggressive rules can exploit information that is known in a particular deployment. Possible examples include:¶

• known Stream IDs for long-lived application streams;¶

• predictable STREAM offsets;¶

• known or derived STREAM lengths;¶

• ACK Range Count equal to zero;¶

• fixed ACK Delay encodings;¶

• delta encoding of Largest Acknowledged;¶

• ECN counters derived from packet numbers in controlled deployments; and¶

• values derived from earlier frames in the same compressed container.¶

These rules can provide better compression, but the assumptions have to remain true at the receiver. If a value is derived from prior packet state, the design has to remain correct when packets are lost, reordered, duplicated, or retransmitted. That is difficult for QUIC because packet delivery order is not guaranteed and QUIC recovery retransmits information rather than retransmitting the same packet bytes [RFC9002].¶

Deriving values inside one compressed container is usually safer than deriving values across packets. For example, the offset of a second STREAM fragment in the same container can be computed from the first fragment's offset and length. That information arrives atomically after decryption of the same packet.¶

Stateful compression can improve the compression ratio, but it adds state synchronization, fallback behavior, and error handling. It is most plausible in closed deployments that can bound reordering and loss behavior or that already maintain synchronized compression state.¶

5.1. Negotiated Alternative Packet-Payload Syntax

The most efficient approach is to negotiate an alternative syntax for eligible QUIC packet payloads. After negotiation, selected 1-RTT packet payloads would contain a SCHC representation instead of the ordinary sequence of QUIC frames. The first field in the protected payload could be a Rule ID that identifies the complete frame sequence or an uncompressed escape format.¶

This approach has low per-packet overhead. The Rule ID can replace the ordinary first Frame Type, and no extension Frame Type is needed. If the rule describes the complete protected payload, no container length is needed either. This gives the best theoretical compression and makes complete-sequence rules more attractive.¶

The cost is deep QUIC integration. The QUIC stack has to know during payload parsing whether the packet uses ordinary frame syntax or the negotiated SCHC syntax. It also needs a way to fall back to ordinary frame encoding, to preserve frame semantics for loss recovery and congestion control, and to reject malformed compressed payloads.¶

A reserved Rule ID could identify an uncompressed frame sequence. That would provide a simple escape path while keeping the alternative syntax active. However, the negotiation, context activation, and error handling would still have to be specified precisely.¶

5.2. Generic Compressed-Frame Extension

A less invasive option is to define a QUIC extension frame that encapsulates one or more compressed frames. A packet could contain ordinary QUIC frames, a compressed-frame container, or both. The container body would include a Rule ID and any compression residue.¶

A conceptual format is:¶

+=======================+==================+====================+
| Extension Frame Type  | Container Length | SCHC Representation|
+=======================+==================+====================+

This approach fits the existing QUIC frame parser model. Unknown extension frames can be handled using ordinary QUIC extension rules when negotiation has not enabled the feature. Native and compressed frames can coexist, and a sender can use the compressed container only when it is smaller than the ordinary encoding.¶

The cost is overhead. The extension Frame Type consumes at least one byte and possibly more, depending on the assigned codepoint. The container needs a length unless it is constrained to consume the rest of the packet. The SCHC representation also needs a Rule ID or an equivalent rule selector.¶

This design can amortize the overhead when several frames are compressed together. It is weaker for a single small frame, where the extension Frame Type, length, and Rule ID may cost as much as the original frame metadata.¶

5.3. Extension Frame per Compressed Frame Type

A third option is to allocate distinct QUIC extension Frame Types for specific compressed frame shapes. For example, one extension Frame Type could mean "compressed STREAM with known Stream ID and no explicit length", while another could mean "compressed single-range ACK".¶

This approach makes frame semantics clearer. The extension Frame Type itself can act as a compact rule selector, so an additional Rule ID might not be needed for simple cases. A parser can also know the basic shape immediately from the Frame Type.¶

The drawbacks are significant. Many rule variants would require many codepoints, and extension Frame Types above 63 require at least two bytes in QUIC variable-length integer encoding. If the compressed Frame Type itself occupies two bytes, the savings for already-small frames can disappear.¶

This approach is generally unattractive unless a small number of frame shapes remove several bytes each and the codepoint space can be managed cleanly.¶

6.1. Unified SCHC Compressor

One logical SCHC context could describe IP, UDP, accessible QUIC header fields, and inner QUIC frames. In principle, a single rule could represent a complete packet pattern across several layers. This could provide cross-layer optimization and avoid duplicated context decisions.¶

The main difficulty is placement. QUIC frame bytes are encrypted, while IP, UDP, and accessible QUIC header fields are outside the encrypted payload. A compressor that operates on all fields at once has to be tightly coupled to QUIC packet construction, QUIC packet protection, and lower-layer encapsulation.¶

This model may be useful for tightly integrated endpoints in a specialized stack. It is likely difficult to reuse in ordinary QUIC implementations because it crosses the QUIC encryption boundary.¶

6.2. Separate Inner and Outer Compressors

A more practical model is to use separate compressors:¶

• an inner compressor inside QUIC handles frames before payload encryption; and¶

• an outer compressor handles IP, UDP, and accessible QUIC header fields after packet construction.¶

The inner compressor sees logical QUIC frame objects or plaintext frame bytes. The outer compressor sees only fields that are visible outside QUIC packet protection. Each compressor has its own rule set, Rule IDs, and error handling.¶

This separation matches the security boundary. It also allows existing SCHC implementations for IP and UDP to be reused more easily. The cost is that cross-layer optimization becomes harder because the inner and outer compressors make separate decisions.¶

This split architecture appears to be the most practical implementation model for experimentation.¶

7.1. STREAM Frames

A native STREAM frame contains a one-byte Frame Type, a Stream ID, optional Offset and Length fields, optional FIN information encoded in the Frame Type, and stream data. The Length field can be omitted when the STREAM frame extends to the end of the packet payload.¶

The following examples use a STREAM frame carrying 64 bytes of application data unless otherwise stated.¶

The generic extension is larger in these examples because it preserves most values while adding an extension Frame Type, a container length, and a Rule ID. It removes little or no metadata that QUIC has not already encoded compactly.¶

The traffic-specific extension becomes useful when it can remove a multi-byte Stream ID or other fields. For a known four-byte Stream ID and a 64-byte terminal STREAM payload, the native metadata is 5 bytes and the compressed extension overhead is 4 bytes. The saving is only 1 byte because the 64-byte stream data makes the container length require two bytes.¶

The alternative packet-payload syntax is more efficient because it avoids the extension Frame Type and container length. If the rule identifies a known Stream ID and the data consumes the remainder of the packet payload, a single Rule ID can represent the frame metadata. This gives better compression, but it requires a deeper change to QUIC payload parsing.¶

STREAM offsets are sensitive to state assumptions. Sending an Offset residue can still save bytes when the Stream ID is known. Deriving an Offset from previous packets is unsafe without additional synchronization because QUIC packets can be lost and reordered. Deriving an Offset from earlier STREAM fragments in the same compressed container is safer because the reference information is carried in the same protected payload.¶

7.2. ACK Frames

A native ACK frame with one contiguous range can be very small. If Largest Acknowledged, ACK Delay, ACK Range Count, and First ACK Range are all one-byte values, the native ACK occupies 5 bytes including the Frame Type.¶

The first row illustrates the main problem for ACK compression. A small native ACK is already close to the minimum size. An extension container can remove the zero ACK Range Count and derive First ACK Range from Largest Acknowledged, but the extension Frame Type, length, and Rule ID consume the savings.¶

ACK compression becomes more attractive when the integration overhead is lower or when several frames are compressed together. It can also be useful when deployment-specific rules make ACK fields derivable. However, ACK values are dynamic and are tied to QUIC loss detection and RTT estimation. Any reconstructed ACK has to be semantically equivalent to the ACK that would have been sent natively.¶

Multi-range ACKs are harder to compress generically. The number of ranges and the Gap and ACK Range Length values vary with loss and reordering. A rule that fixes the number of ranges can save a small amount of structure, but a generic rule usually has to transmit the range list.¶

7.3. Net Savings

Every analysis has to count all compression overhead. Relevant overhead includes:¶

• the Rule ID or equivalent rule selector;¶

• any QUIC extension Frame Type;¶

• a container length or delimiter;¶

• per-frame delimiters when several compressed frames are independent;¶

• residue fields that are not inferred by the rule;¶

• padding or byte alignment introduced by the profile; and¶

• any fallback marker for uncompressed frame sequences.¶

The following examples use the same assumptions as the previous sections. They compare complete QUIC packet payload bytes for the represented frame sequence. Outer IP, UDP, and QUIC header compression is not included.¶

The ACK-plus-STREAM examples show why bundling matters. One extension Frame Type, one length, and one Rule ID can represent both logical frames. The fixed overhead is amortized, and the rule can remove fields from both frames.¶

The alternative payload syntax gives the best byte savings because it has the lowest integration overhead. It is also the most invasive option because it changes how protected QUIC payloads are interpreted.¶

These examples do not include processing cost. A sender still has to identify candidate rules, evaluate matches, compute residues, and compare the compressed size with the native encoding. If the sender then falls back to native QUIC, wire savings are zero but rule evaluation cost has already been paid.¶

9.1. Normative References

[RFC8724]

Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, <https://www.rfc-editor.org/rfc/rfc8724>.

[RFC9000]

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

[RFC9001]

Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.

9.2. Informative References

[I-D.sirohi-schc-quic-compression]

Sirohi, S. and L. Toutain, "QUIC compression using SCHC", Work in Progress, Internet-Draft, draft-sirohi-schc-quic-compression-00, 12 May 2025, <https://datatracker.ietf.org/doc/html/draft-sirohi-schc-quic-compression-00>.

[I-D.toutain-schc-coreconf-management]

Minaburo, A., Toutain, L., FERNANDEZ, J. A., Banier, C., and M. Dumay, "CORECONF Rule management for SCHC", Work in Progress, Internet-Draft, draft-toutain-schc-coreconf-management-01, 19 October 2025, <https://datatracker.ietf.org/doc/html/draft-toutain-schc-coreconf-management-01>.

[RFC9002]

Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

[RFC9363]

Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, March 2023, <https://www.rfc-editor.org/rfc/rfc9363>.