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
