Reverso for the QUIC protocol#

Florentin Rochet (University of Namur).

• Why: A genuinely surprising transport result: QUIC v1's wire layout — encrypted data potentially surrounded by encrypted control — makes contiguous zero-copy at the receiver impossible in a conforming implementation. This draft proposes a QUIC version that fixes it, and it's grounded in a published paper (ACM SIGCOMM CCR, Jan 2026).
• What: vReverso changes three things from v1: a few more bytes in the short header (worst case 13 vs 5 — a stream ID and offset), a stream frame must be first in the packet, and frame element ordering is reversed on the wire. That's enough to drive data reassembly using decryption's hidden copy, so a receiver can expose a whole HTTP/3 data frame of arbitrary size in zero-copy.
• How: Reversed frame ordering minimizes added header info (no need to locate where control begins), and a bidirectional buffer abstraction means the same code parses both v1 and vReverso. Loopback microbenchmarks show ~15.4 Gb/s for the prototype vs ~15.2 Gb/s QUIC v1 on comparable stacks — the author himself flags these numbers as "to be taken with a grain of salt."
• Where applicable: Receiver-side throughput optimization for QUIC and derivatives (QMux is called out). Early individual draft with real maintenance-cost questions, but a rare case of wire-format research feeding directly into a standards venue.