I also agree with Christian here. I would much rather reuse the TLS parts that we already have in QUIC for QMUX. As Martin brings up it doesn’t require a new way to do protocol/extension negotiation. Also, from an implementation standpoint, I feel this would be a lot simpler for our stack since we wouldn’t have to have multiple ways for interacting with TLS.
- Nick Sent from Outlook<http://aka.ms/weboutlook> From: Kazuho Oku <kazuho...@gmail.com> Sent: Tuesday, June 3, 2025 10:49 PM To: Martin Thomson <m...@lowentropy.net> Cc: Christian Huitema <huit...@huitema.net>; Lucas Pardue <lu...@lucaspardue.com>; quic@ietf.org Subject: Re: [QMux] choosing between the two wire encodings (Re: Sorry I missed the quic-on-stream interim) 2025年6月4日(水) 14:37 Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>>: On Wed, Jun 4, 2025, at 14:54, Kazuho Oku wrote: > Option a) Use QUICv1 encodings > > * transfer QUIC frames / TPs as-is > * disallow frames & TPs unrelated to stream/datagram delivery > * add a new max-payload-length TP for STREAM frames to compensate for > the loss of packet boundaries > > Option b) Use WT/H2 encodings > > * wire format: Capsule TLV encoding (RFC 9297) > * map each QUIC frame to a capsule type > * silently drop unknown capsules (unlike QUIC’s connection error rule) > * map each applicable TP to its own HTTP/2 setting; initial per-stream > limits may be encoded as text[1] > > Assuming our goal is a stream-friendly counterpart to QUIC v1, I favor > Option A. If QMux were to adopt a different wire format, anyone writing > or maintaining QUIC and its extensions would have to describe, review, > and test two parallel encodings-with different semantics-for every new > feature. That duplication would multiply editorial effort and make it > harder to keep the two tracks in lock-step as the protocol evolves. > > I acknowledge that the WT/H2 encoding appeals to deployments that must > support WebTransport over HTTP/2. However, QMux is intended as a > fallback substrate for any deployment that speaks QUIC; many of those > would have no WT/H2 stack at all, and for them re-using the existing > QUIC v1 encoding is clearly the lower-cost path. > > In short, between the two available encodings, the overall trade-off > favors QMux adopting the QUIC v1 format. For that you would need some sort of prearrangement system (like transport parameters) for negotiating extensions. Otherwise, you would not be able to add new capabilities (like RESET_AT, though I suspect you would want to build that specific feature in to the base and not have RESET at all). What facilities do you expect to have for negotiating protocol (like ALPN) and exchanging configuration? WebTransport ducked that issue to some extent by using the capsule protocol. If you don't use capsules, you really need to solve that. quic-on-streams-00 proposes to use a first frame (called QS_TRANSPORT_PARAMETERS frame) that carries the "Transport Paramters" struct of RFC 9000 as-is; please see https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams#name-qs_transport_parameters-fra. To paraphrase, my argument here is the same; i.e., we can (and should) reuse the existing encoding and semantics. Regarding ALPN, I think we can rely on TLS. There will be deployments that do not need encryption, but they will be smaller in scale and have less need for negotiating the application protocol. -- Kazuho Oku
