Notes on QUIC

QUIC is not Quick Enough over Fast Internet

I did some napkin math estimation:

• MTU (1500B)
• Large receiver segment (64KB)
• 64000/1500=42x fewer syscalls with a receiver segment

syscalls go from 231k in QUIC to 15K in http/2, so 231/15=15.4x 15.4x is ~2x in range of 42x speedup. Not bang on accurate but the receiver segment could be smaller than 64KB as they mention

But then they enable GRO for the UDP and it doesn’t improve performance, which is counterevidence to their whole hypothesis?

Get in touch with Tailscale who seems to have run the same experiments and talk to them about it - https://tailscale.com/blog/quic-udp-throughput

The client-side processing (ACK’s etc) being a main cause (3.2s of 8.5s) of CPU spin really surprised me

I read deeper into it. There’s another paper they cite which has much more specific claims as to what is supposedly taking so long in userspace. The difference is this paper is based of 4 different QUIC libraries, which aren’t either the curl quic library or the chrome one used in this paper, so impossible to faithfully compare - https://www.researchgate.net/profile/Xiangrui-Yang/publication/343556175_Making_QUIC_Quicker_With_NIC_Offload/links/605a923c299bf173676446f9/Making-QUIC-Quicker-With-NIC-Offload.pdf