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. Cheers Lucas On Wed, Dec 3, 2025, at 21:10, Christian Huitema wrote: > > On 12/3/2025 10:32 AM, Bill Gage wrote: > > I have no objection per se, but I think it would be nice to see some > > discussion of alternatives to the problem of adapting QUIC to work > > over a reliable and bidirectional transport (as he shamelessly plugs > > https://datatracker.ietf.org/doc/draft-gage-quic-qort/ ;-). > > > I agree with this sentiment. Doing "QUIC over streams" forces a series > of tradeoffs. For example: > > * Entirely delegate the encryption functions to the underlying layer, or > not. > > * Handling path identification, or not. > > * Aligning packet size with UDP packet size, or not. > > * Using QUIC ACK, or not. > > This defines a whole spectrum of possible tradeoffs. The QMUX > specification is at one extreme of these tradeoffs, which means it > serves exactly one scenario: replace UDP in an end-to-end, single path > connection. But there are other potential scenarios, for example: > > * relaying a QUIC connection between an ECH "fronting server" and a > server, or between a load balancer and a server, > > * migrating from a QUIC over stream path to another QUIC over stream path, > > * migrating from a QUIC over stream path to a QUIC over UDP path, > > * multipath operation using QUIC over stream path and QUIC over UDP path, > > * using QUIC over stream between a QUIC endpoint and a Masque relay, > including a QUIC aware relay, > > * mulltiplexing several QUIC connections over a single stream. > > The proxying scenario probably require maintaining usage of end to end > ACK. The migration scenarios require handling connection identifiers, > and probably also require handling negotiating a master key in a > cryptographic handshake. The "QUIC aware relay" scenarios require > distinguishing relayed packets and packets belonging to the Masque > connection. Etc. > > Focusing on QMUX is only right if most of the WG energy is exactly > behind the QMUX scenario. Are we sure of that? > > -- Christian Huitema > >
