Re: [External⚠] Re: Unbound DATA frames in HTTP/3 proposal

On Thu, Oct 9, 2025 at 11:09 AM Demi Marie Obenour <demiobenour@gmail.com>
wrote:

> I would like to see proper benchmarks, though.


This would certainly depend on the details and constraints of the
implementation stack.

Two contrasting examples on a TCP-to-HTTP/3 CONNECT proxy illustrate the
range:

When the proxy uses a well-integrated library or set of libraries that
stream data transparently through kernel sockets and library layers, with
64Kb TCP segmentation offload and large enough buffers, the impact of
HTTP/3 DATA framing is minimal. The savings are limited to a few bytes on
the wire every few dozen packets.

At the other extreme, when data is forwarded entirely in user space
performing zero-copy transfers from a correctly ordered TCP packet into
HTTP/3 CONNECT stream, the situation changes. If the implementation can
reuse the received TCP header buffer to encode UDP and QUIC headers, the
additional HTTP/3 DATA framing can determine whether a memory copy of the
data is required. Depending on destination connection id length and size of
varint encoded integers, the requirement to add HTTP/3 DATA framing could
push the size of combined UDP/QUIC/HTTP/3 overhead beyond the size of the
original TCP header, resulting in a memory copy of the proxied data.
Depending on various other factors this may reduce throughput by ~5-10%.
Some zero-copy architectures allow reserving per-packet headroom
to mitigate this, but some don't.

I'm sure a similar range exists with other applications encapsulating data
into HTTP/3 streams.


Best Regards,
Yaroslav

-- 


This communication (including any attachments) is intended for the sole 
use of the intended recipient and may contain confidential, non-public, 
and/or privileged material. Use, distribution, or reproduction of this 
communication by unintended recipients is not authorized. If you received 
this communication in error, please immediately notify the sender and then 
delete all copies of this communication from your system.

Received on Thursday, 9 October 2025 20:19:45 UTC