Would running QUIC with zero-length CID over TCP meet your needs?
(By "QUIC", I mean the protocol defined by the streams, connections,
packets and (necessary) frames specified in RFC9000 but without the
cryptographic protection described in RFC9001 nor the loss detection and
congestion control procedures of RFC9002).
/bill
On 2025-12-03 11:43 p.m., Willy Tarreau wrote:
On Thu, Dec 04, 2025 at 01:34:20AM +0000, Lucas Pardue wrote:
Hey,
Speaking as chair:
Now is a great time to have these discussions, please do continue.
However, I do want to draw attention to the specific language in the charter
The fourth area of work is the specification of how QUIC stream
multiplexing and other application-oriented extensions (e.g. Datagram)
can be adapted to work over a reliable and bidirectional byte stream
substrate.
The work is not about taking all of QUIC to other transports. While there may
be opportunity to specify a design that can be used in inventive ways, the
lead up to rechartering identified the primary use case as taking stream
multiplexing to reliable bidirectional bytestreams in simple/common/existing
deployment models.
As Christian rightly highlights, design choices and features need to be
supported by folks willing to do the work on specifications and running code.
As one of those interested in seeing this succeed, I'd like to express
my motivations, which I think more or less match some of the authors'
and possible supporters'.
My goal is not to use something different from UDP under QUIC, it is to
have a cleaner alternative to H1 and H2 on the loopback, between containers,
VMs and on the local network, where QUIC currently is overkill since it is
designed to excel over the real internet and not over sub-microsecond,
zero-loss, congestion-less multi-terabit "links".
Currently, inside hosts, TCP benefits from all this knowledge to eliminate
all these unneeded layers, ending as just moving pages between processes.
On a local network, you send 64 kB segments using TSO, that are segmented
by the hardware, reassembled by the destination hardware and delivered
again as super-large segments to the remote application. RTT is considered
to be almost null, reordering does not exist, losses are extremely rare
and congestion is avoided at the Ethernet layer thanks to flow control
on switch ports.
To give some estimates, over the loopback and local network, I'm seeing
roughly 100 Gbps per TCP connection and 1 Tbps per CPU core. That's about
82 million packets per second per core, something that's clearly out of
reach in userland, and even in kernel land, it's just that it's eliminated
by software layers or offloaded by the hardware where relevant.
Does this mean we should be deprived from using the much better H3 on
the local host and local network, and continue to encourage applications
to only choose between H1 and H2 ? In my opinion no. During the design
of H3 I was already interested in seeing it replace H1, but it relies on
QUIC streams. And QUIC's multiplexing layer does a lot of things way
better than H2, which is expected since it has learned a lot from
previous versions. And instead of reinventing yet another protocol for
local networks and encourage applications to implement it instead of
QUIC, I think it is very valuable to reuse the upper layers of QUIC
that already work very well, and keep a similar interface with H3, and
likely all other protocols that people will want to transport over QUIC.
Right now I'm seeing the QMUX draft as the right approach to that goal.
It tries to draw the dotted lines between the multiplexing layer and the
transport layer to figure how to touch the least possible in the protocol
and just figure where to cut in order to separate the two layers. This
is the difficult part of the exercise and it explains why there can be
so many questions. But I think it's sane for the long term to think that
TCP and QUIC-transport will made be more compatible thanks to an evolution
of QUIC-multiplexing on top that could map to both and expose the exact
same layers to application protocols. Then there will be no excuse for
not implementing H3/QUIC in applications because it would be the default
unified way to access the optimal transport layer everywhere, both locally
and over the internet.
Regards,
Willy
