On 12/4/2025 10:05 AM, Bill Gage wrote:
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.
The more I think of it, the more I believe we need some kind of
negotiation mechanism, similar to the version number and the negotiation
of transport protocols in RFC 9000. That would match the requirement of
having motivated folks working on the specs they need. For example,
folks that really want to extend the base QMux to support the
communication between server and load balancer could work on the
extensions to do exactly that.
...
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".
Loopback is very clearly one of the most interesting QMux scenarios, and
there is no question that we want to support that. And in fact, the QMux
draft definitely supports that.
The Qmux draft also supports well using TCP and TLS to communicate with
a QUIC server from a network where UDP is blocked, which is also an
interesting scenario.
The problem is when we use QMux without encryption on local networks.
That's where we run into the NSA smiley. My personal preference would be
to look at solutions using some kind of hardware acceleration, to get
both high performance and high security. If I remember correctly, there
were experiments running QUIC over TCP+TLS at Microsoft, showing data
rate in the 10s of Gigabits. Something like that would be a good start.
-- Christian Huitema
