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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADvbK_d1fuyoG_F8jXNSyuicFqDxmbwSp06mkE1GvgTFkYRm5A@mail.gmail.com>
Date: Fri, 19 Sep 2025 10:41:58 -0400
From: Xin Long <lucien.xin@...il.com>
To: Hannes Reinecke <hare@...e.de>
Cc: network dev <netdev@...r.kernel.org>, quic@...ts.linux.dev, davem@...emloft.net, 
	kuba@...nel.org, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Simon Horman <horms@...nel.org>, Stefan Metzmacher <metze@...ba.org>, Moritz Buhl <mbuhl@...nbsd.org>, 
	Tyler Fanelli <tfanelli@...hat.com>, Pengtao He <hepengtao@...omi.com>, linux-cifs@...r.kernel.org, 
	Steve French <smfrench@...il.com>, Namjae Jeon <linkinjeon@...nel.org>, 
	Paulo Alcantara <pc@...guebit.com>, Tom Talpey <tom@...pey.com>, kernel-tls-handshake@...ts.linux.dev, 
	Chuck Lever <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>, 
	Benjamin Coddington <bcodding@...hat.com>, Steve Dickson <steved@...hat.com>, 
	Alexander Aring <aahringo@...hat.com>, David Howells <dhowells@...hat.com>, 
	Matthieu Baerts <matttbe@...nel.org>, John Ericson <mail@...nericson.me>, 
	Cong Wang <xiyou.wangcong@...il.com>, "D . Wythe" <alibuda@...ux.alibaba.com>, 
	Jason Baron <jbaron@...mai.com>, illiliti <illiliti@...tonmail.com>, 
	Sabrina Dubroca <sd@...asysnail.net>, Marcelo Ricardo Leitner <marcelo.leitner@...il.com>, 
	Daniel Stenberg <daniel@...x.se>, Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: 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 <hare@...e.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.