]> IMT Atlantique

rue de la Chataigneraie 35576 Cesson-Sevigne Cedex France samar.sirohi@imt-atlantique.fr

IMT Atlantique

rue de la Chataigneraie 35576 Cesson-Sevigne Cedex France laurent.toutain@imt-atlantique.fr

Internet SCHC Working Group SCHC QUIC Compression This document explores whether Static Context Header Compression (SCHC) can be applied to the metadata carried in QUIC frames. QUIC already uses compact frame encodings and variable-length integers, so any compressed representation has to recover enough bytes to pay for its own integration overhead. The document compares several possible organizations for SCHC rules, discusses how frame compression could be integrated, and analyzes representative STREAM and ACK frame examples. The analysis suggests that SCHC compression of QUIC frames is technically possible, but that generic or base rules are likely to provide only modest savings at best. More substantial savings require predictable traffic, pre-provisioned or negotiated rules, bundling of several frames under one rule, or a negotiated QUIC payload syntax with low per-packet overhead. This document is exploratory. It does not define an interoperable QUIC extension, SCHC profile, wire format, or IANA allocation.

Introduction QUIC provides a secure, reliable, multiplexed transport over UDP. QUIC packets carry one or more frames in the packet payload. Those frames carry application data, acknowledgments, flow-control updates, and other transport information. QUIC frame encodings are already compact. Most core frame types fit in one byte, and integer fields are encoded using QUIC variable-length integers. This makes QUIC efficient for general Internet use, but frame metadata can still matter when packets are small or when every transmitted byte has high cost. Examples include constrained links, specialized machine-to-machine deployments, and space communication scenarios. SCHC compresses protocol fields using rules shared by the sender and receiver. A rule can remove fields that are fixed, predictable, or known from a static context. Only the residual values that cannot be inferred by the decompressor have to be sent. This document explores applying SCHC to QUIC frame metadata. The term "frame metadata" includes QUIC Frame Types and frame-specific fields such as Stream ID, Offset, Length, Largest Acknowledged, ACK Delay, and ACK ranges. Application data carried by STREAM frames is not compressed by the mechanisms considered here. The scope is intentionally exploratory. The document asks when SCHC can reduce QUIC frame overhead enough to justify the required changes to QUIC packet construction, parsing, context management, and implementation complexity. It does not define a QUIC extension, a SCHC profile for QUIC frames, a transport parameter, or any final wire format.

Background and Scope

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

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 and management approaches such as 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 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.

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.

Problem Statement QUIC frame compression is not equivalent to ordinary network-layer header compression. Several properties make it harder to apply SCHC efficiently. First, a QUIC packet can contain multiple frames. The frame sequence can vary from packet to packet, and frames can appear in different orders. A single packet might contain only a STREAM frame, only an ACK frame, an ACK followed by a STREAM frame, multiple STREAM frames, control frames, or padding. Second, some important frame syntaxes are optional or variable. STREAM frames can include or omit Offset and Length fields. ACK frames can contain a variable number of acknowledgment ranges. Control frames often carry values whose meaning depends on the current connection state. Third, QUIC already compresses small fields by design. A one-byte Frame Type and a one-byte variable-length integer leave little redundancy for a general-purpose compression scheme to remove. If a compressed representation has to carry a QUIC extension Frame Type, a length, and a Rule ID, those bytes can consume the expected savings. Fourth, the rule-selection problem is non-trivial. A sender can choose a rule for a complete frame sequence, for each frame, for a generic frame shape, or for a deployment-specific traffic pattern. Each choice changes both the achievable compression and the robustness of the design. The central question is therefore:

• Under which assumptions can SCHC reduce QUIC frame overhead enough to justify the required integration and implementation complexity?

This document does not attempt to answer that question for every deployment. Instead, it identifies design options, explains their costs, and gives representative size calculations.

Possible Compression Organizations

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.

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.

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.

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

Integration with QUIC This section describes three possible ways to integrate SCHC frame compression with QUIC. They are alternatives for analysis, not protocol definitions.

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.

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

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.

Implementation Architectures

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.

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.

Example Compression Analysis The numerical examples in this section are illustrative. They are not a proposed wire format and are not protocol guarantees. Unless otherwise stated, the examples use the following sizing assumptions:

• QUIC variable-length integers use their shortest valid encoding;
• a generic compressed-frame extension Frame Type occupies one byte;
• a container length occupies one byte when the container body length is at most 63 bytes and two bytes otherwise;
• a SCHC Rule ID occupies one byte;
• a negotiated alternative packet-payload syntax carries one Rule ID;
• a terminal container consumes the rest of the packet and therefore omits an explicit container length; and
• application data bytes are unchanged.

The tables distinguish frame-metadata savings from complete packet savings. When application data is unchanged and outer header compression is not counted, the complete packet reduction is equal to the frame-metadata reduction.

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. Representative STREAM Metadata Sizes

STREAM case	Native metadata	Generic extension	Traffic-specific extension	Alternative payload syntax
Stream ID only, one-byte Stream ID	2 B	5 B, loses 3 B	4 B if Stream ID known, loses 2 B	1 B if Stream ID known, saves 1 B
Stream ID only, four-byte Stream ID	5 B	8 B, loses 3 B	4 B if Stream ID known, saves 1 B	1 B if Stream ID known, saves 4 B
Offset and Length, one-byte Stream ID, two-byte Offset, two-byte Length	6 B	7 B if Length is inferred from container, loses 1 B	5 B if Stream ID known and Offset sent, saves 1 B	3 B if Stream ID known and Offset sent, saves 3 B
Offset and Length, four-byte Stream ID, two-byte Offset, two-byte Length	9 B	10 B if Length is inferred from container, loses 1 B	5 B if Stream ID known and Offset sent, saves 4 B	3 B if Stream ID known and Offset sent, saves 6 B

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.

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. Representative ACK Metadata Sizes

ACK case	Native metadata	Generic extension	Traffic-specific extension	Alternative payload syntax
One range, ACK Range Count 0, First ACK Range sent	5 B	6 B if only Range Count is elided, loses 1 B	5 B if First ACK Range is derived, saves 0 B	3 B if First ACK Range is derived, saves 2 B
One range, two-byte Largest Acknowledged, one-byte delay and range	6 B	7 B if only Range Count is elided, loses 1 B	6 B if First ACK Range is derived, saves 0 B	4 B if First ACK Range is derived, saves 2 B
Two ranges with one-byte fields	7 B	8 B when the range list is preserved, loses 1 B	8 B if range count and range list remain variable, loses 1 B	6 B if the rule fixes the range count to 1, saves 1 B

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.

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. Illustrative Complete Payload Savings

Frame sequence	Native payload	Generic extension	Optimized extension	Alternative payload syntax
Small single-range ACK	5 B	6 B, loses 1 B	5 B, saves 0 B	3 B, saves 2 B
STREAM with known four-byte Stream ID and 64 bytes of data	69 B	72 B, loses 3 B	68 B, saves 1 B	65 B, saves 4 B
ACK followed by that STREAM	74 B	77 B if both are preserved in one container, loses 3 B	70 B, saves 4 B	67 B, saves 7 B
ACK plus STREAM in a terminal optimized container	74 B	not applicable	68 B, saves 6 B	67 B, saves 7 B

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.

Discussion and Conclusions SCHC compression of QUIC frames is technically possible when compression and decompression are integrated into the QUIC endpoints. The compressed representation can be protected by normal QUIC packet protection because compression occurs before encryption and decompression occurs after decryption. Generic static rules are likely to provide modest savings at best. QUIC already encodes small Frame Types and integer values compactly, and a compressed extension has to pay for its own Frame Type, length, and Rule ID. For small isolated frames, the compressed representation can be the same size as native QUIC or larger. Extension-frame approaches are easier to deploy incrementally because ordinary and compressed frames can coexist. Their fixed overhead is the main limitation. They become more attractive when several logical frames are compressed together or when a rule removes a multi-byte field such as a known Stream ID. A negotiated alternative packet-payload syntax offers better compression because it avoids an extension Frame Type and often avoids a container length. It also requires deeper QUIC integration, explicit negotiation, clear fallback, and precise error handling. Whole-packet and traffic-specific rules can provide better savings when traffic is predictable. Examples include known streams, fixed frame combinations, ACK Range Count equal to zero, and values derived within the same compressed container. Stateful compression across packets can improve results, but it introduces robustness and synchronization problems in the presence of loss, reordering, and retransmission. A split implementation appears practical. An inner compressor inside QUIC can handle frame metadata before encryption, while an outer compressor can handle IP, UDP, and accessible QUIC header fields after packet construction. This matches the QUIC security boundary and allows reuse of existing SCHC components. The approach is unlikely to be attractive for ordinary Internet QUIC traffic. Traffic is diverse, frame combinations vary, and the expected savings from frame metadata are small compared with the required implementation and context-management machinery. The approach may be useful where links are highly constrained, bandwidth is expensive, endpoints are under common control, and rules can be pre-provisioned or managed by mechanisms such as SCHC CORECONF. Space communication scenarios and other controlled constrained deployments are plausible examples. Trace-based evaluation is needed before selecting a concrete design. Such evaluation should measure both frame-metadata reduction and complete packet reduction. It should also measure CPU cost, latency, energy, rule-set size, fallback frequency, and robustness under loss and reordering.

References Normative References This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. Informative References This document describes loss detection and congestion control mechanisms for QUIC. This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules. This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules. IMT Atlantique IMT Atlantique This document specifies a mechanism for applying Static Context Header Compression (SCHC) to QUIC (Quick UDP Internet Connections) packets. It leverages SCHC to compress both the QUIC packet header and the headers or type information of QUIC frames contained within the packet payload. This approach aims to significantly reduce QUIC overhead, optimizing bandwidth usage. This is particularly beneficial for valuable in bandwidth-sensitive scenarios like deep space communications. This document defines the SCHC architecture. Consultant IMT Atlantique IMT Atlantique IMT Atlantique Orange This document describes how CORECONF can be applied to SCHC for context and rule set management between endpoints.

Acknowledgments This document builds on prior discussions of SCHC compression for QUIC packet headers and frames. The authors thank participants in the SCHC and QUIC communities for discussions on constrained deployments and QUIC extensibility.