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
