Re: [PATCH net-next v3 00/15] net: introduce QUIC infrastructure and core subcomponents

Xin Long
2025-09-19T14:42:12Z

On Fri, Sep 19, 2025 at 2:44 AM Hannes Reinecke <hare@suse.de> wrote:
>
> On 9/19/25 00:34, Xin Long wrote:
> > Introduction
> > ============
> >
> > The QUIC protocol, defined in RFC 9000, is a secure, multiplexed transport
> > built on top of UDP. It enables low-latency connection establishment,
> > stream-based communication with flow control, and supports connection
> > migration across network paths, while ensuring confidentiality, integrity,
> > and availability.
> >
> [ .. ]>
> > - Performance Testing
> >
> > Performance was benchmarked using iperf [8] over a 100G NIC with
> > using various MTUs and packet sizes:
> >
> > - QUIC vs. kTLS:
> >
> > UNIT size:1024 size:4096 size:16384 size:65536
> > Gbits/sec QUIC | kTLS QUIC | kTLS QUIC | kTLS QUIC | kTLS
> > ────────────────────────────────────────────────────────────────────
> > mtu:1500 2.27 | 3.26 3.02 | 6.97 3.36 | 9.74 3.48 | 10.8
> > ────────────────────────────────────────────────────────────────────
> > mtu:9000 3.66 | 3.72 5.87 | 8.92 7.03 | 11.2 8.04 | 11.4
> >
> > - QUIC(disable_1rtt_encryption) vs. TCP:
> >
> > UNIT size:1024 size:4096 size:16384 size:65536
> > Gbits/sec QUIC | TCP QUIC | TCP QUIC | TCP QUIC | TCP
> > ────────────────────────────────────────────────────────────────────
> > mtu:1500 3.09 | 4.59 4.46 | 14.2 5.07 | 21.3 5.18 | 23.9
> > ────────────────────────────────────────────────────────────────────
> > mtu:9000 4.60 | 4.65 8.41 | 14.0 11.3 | 28.9 13.5 | 39.2
> >
> >
> I have been following the QUIC implementation progress for quite some
> while, and always found the performance impact rather frustrating.
> At the onset it looks as if you would suffer heavily from the additional
> complexity the QUIC protocol imposes up you.
> But that would make the use of QUIC rather pointless for most use-cases.
> So one wonders if this is not rather a problem of an unsuitable test
For fast networks, like the ones I used in my iperf tests, it’s expected
that QUIC does not outperform TCP+TLS at the time, The main reason is that
TCP has decades of kernel-level optimizations, including features like
GSO/GRO and even hardware offload support, which I don't think QUIC can
catch up due to its complexity.

That said, QUIC shows advantages in other scenarios web browsing or
similar workloads. QUIC can outperform TCP+TLS because of:

- Faster connection setup: QUIC combines the transport and TLS handshakes,
avoiding the extra round trips of TCP’s three-way handshake plus TLS
negotiation.

- No head-of-line blocking across streams: QUIC multiplexes multiple
streams over a single connection, so a single lost packet doesn’t stall
unrelated streams, unlike TCP.

> case. From my understanding QUIC is geared up for handling a
> multi-stream connection workload, so one should use an adequate test to
> simulate a multi-stream connection. Did you use the '-P' option for
> iperf when running the tests?
>
> And it might also be an idea to add QUIC support to iperf itself,
> especially transforming the '-P' option onto QUIC streams looks
> promising.
>
Yes, we could add QUIC to iperf, but then testing would need to include
packet loss and ensure the CPU isn’t the bottleneck, which moves away
from a fast-network environment.

Thanks Hannes for your comment. I’d be glad to hear any further ideas on
QUIC performance testing. So far, I haven’t seen a common method or tool
adopted for it from the community.