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

On Fri, Sep 19, 2025 at 2:44 AM Hannes Reinecke <[email protected]> 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.