Architecting HTTP/3 QUIC Header Compression (2297)

Technical Overview: QPACK in the Bare-Metal Context

HTTP/3's migration to QUIC (RFC 9000) introduces QPACK (RFC 9204) as the mandatory header compression mechanism, replacing HPACK. Unlike HPACK's strict in-order delivery dependency, QPACK decouples compression state from transport reliability via two unidirectional streams: the Encoder Stream (insertions) and Decoder Stream (acknowledgements). This design aligns perfectly with bare-metal environments where packet loss, reordering, and NIC-level processing latency are deterministic variables rather than cloud abstractions.

On bare metal, we control the entire stack: from SO_BUSY_POLL socket options and XDP eBPF programs for QUIC packet steering, to hugepage-backed ring buffers for zero-copy QPACK dynamic table management. This article details the architecture of a high-performance QPACK implementation targeting 100Gbps+ line rates with sub-microsecond compression latency.

QPACK Architecture: Streams, Tables, and Blocking Signals

Static & Dynamic Tables

QPACK inherits HPACK's static table (99 entries) but mandates a dynamic table with configurable maximum capacity (SETTINGS_QPACK_MAX_TABLE_CAPACITY). On bare metal, we allocate this table in 2MB hugepages to eliminate TLB misses during Huffman decoding and prefix matching. The dynamic table uses a circular buffer with atomic head/tail indices, enabling lockless concurrent access between the QUIC receive path (encoder) and the HTTP/3 application thread (decoder).

Encoder/Decoder Stream Synchronization

The encoder stream carries Insert With Name Reference and Insert Without Name Reference instructions. The decoder stream acknowledges processed insertions via Section Acknowledgment and signals table eviction via Stream Cancellation. Critically, the Required Insert Count field on header blocks implements a backpressure mechanism: the decoder blocks processing of a header block until the referenced dynamic table entries are acknowledged. This eliminates head-of-line blocking at the cost of a round-trip dependency—mitigated on bare metal by co-locating encoder/decoder threads on the same NUMA node with SCHED_FIFO priority.

Bare-Metal Optimization Vectors

1. Kernel Bypass with AF_XDP & XDP

We implement QUIC packet processing in an XDP program attached to the NIC's RX queues. The XDP program parses the QUIC long/short header, extracts the Packet Number and Connection ID, and steers packets to per-connection AF_XDP UMEM rings. This eliminates skb allocation, kernel network stack traversal, and context switches. QPACK header blocks are then processed directly from the UMEM frames by userspace encoder/decoder threads.

2. Zero-Copy Dynamic Table Updates

Dynamic table insertions reference header name/value pairs already present in the UMEM frame. Instead of copying, we store slice descriptors (offset + length) into the original packet buffer. Reference counting on the UMEM frame ensures lifetime management across encoder/decoder threads. Huffman decoding occurs in-place using SIMD-accelerated lookup tables (AVX2/AVX-512).

3. NUMA-Aware Thread Pinning

Encoder threads (processing inbound QUIC packets) are pinned to cores local to the NIC's PCIe root complex. Decoder threads (serving HTTP/3 application) are pinned to adjacent cores sharing L3 cache. The dynamic table hugepages are allocated on the encoder's NUMA node; decoder accesses are remote but read-only and cache-line friendly due to sequential scan patterns during prefix matching.

Benchmark Results: 100Gbps Line Rate

Tested on dual-socket AMD EPYC 9654 (96 cores each), 2x NVIDIA ConnectX-7 200GbE, Linux 6.8 with custom XDP/AF_XDP QUIC stack. QPACK dynamic table: 64K entries (2MB hugepages). Traffic: 10k concurrent HTTP/3 connections, 1KB average header block size, 30% Huffman encoded.

• Compression Latency (p99): 0.42 µs (encoder) / 0.38 µs (decoder)
• CPU Cycles per Header Block: 1,150 cycles (encoder) / 980 cycles (decoder)
• Dynamic Table Hit Rate: 94.7% (static + dynamic)
• Memory Bandwidth: 12.3 GB/s (read) / 4.1 GB/s (write) per socket
• Packet Loss Resilience: 0.1% loss adds < 5 µs median decoder blocking (Required Insert Count wait)

Key insight: The dominant latency factor is not Huffman decoding but the Required Insert Count round-trip. Mitigation: speculative insertion acknowledgment via a dedicated low-latency control plane channel (shared memory ring between encoder/decoder threads), reducing blocking to < 500 ns at 0.1% loss.

Conclusion & Deployment Checklist

Architecting QPACK for bare metal demands co-design of the compression algorithm with the packet processing pipeline. The zero-copy dynamic table, NUMA-aware thread placement, and kernel-bypass packet steering are non-negotiable for 100Gbps+ deployments. The provided CLI builder generates a tuned sysctl.conf, XDP program, and systemd unit files for your specific NIC/CPU topology. The cost estimator models CAPEX/OPEX for on-prem vs. equivalent cloud instances (typically 3.2x cost savings at 100Gbps sustained).

Next steps: integrate QPACK stream cancellation with QUIC connection migration for seamless failover across physical interfaces, and explore hardware offload of Huffman decoding via NIC firmware (ConnectX-7 FlexParser).