Regarding Christian’s first point: > please don't force me to implement H2.
I’m confused where this came from. I don’t think anyone was suggesting more H2 in the world. WebTransport over HTTP/2 uses extended CONNECT to establish a reliable bidirectional byte stream and defines Capsules over that stream that mirror some RFC 9000 frames (with some minor differences) to achieve QMux-esque stream multiplexing. If QMux had been defined several years ago, it’s likely that H2/WT would have reused that framing instead of defining its own. I don’t think we need to decide the exact wire framing for QMux right now. Victor brought up a good point that some design choices for RFC9000 might warrant revisiting because parsing variable length frames out of a stream that can arrive one byte at a time is different than parsing them from a datagram that arrives atomically. This can be handled after recharter either pre or post adoption of any documents. I don’t feel that exact bit-for-bit compatibility with RFC9000 frames is a hard requirement, but let’s discuss it. Regarding a tight coupling to TLS: One idea that surfaced during the meeting is publishing both a QMux framing draft, and a QMux+TLS draft, which I think makes sense. The former would define only the serialization for stream multiplexing over a bidirectional byte stream, with requirements for specific usages of QMux like “you need to define how to negotiate the next protocol”. Forcing TLS for all uses of QMux doesn’t make sense for transports (like WebTransport over HTTP/2) that are already *within* a TLS session, for example. Thanks -Alan From: Nick Banks <[email protected]> Date: Wednesday, June 4, 2025 at 7:44 AM To: Kazuho Oku <[email protected]>, Martin Thomson <[email protected]> Cc: Christian Huitema <[email protected]>, Lucas Pardue <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [QMux] choosing between the two wire encodings (Re: Sorry I missed the quic-on-stream interim) 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 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<https://urldefense.com/v3/__http:/aka.ms/weboutlook__;!!Bt8RZUm9aw!4-dIxmpNasJ3mjJ5iIIWnMhZbLka9kpmHMdIDpPF93ZoljtqA0yhDm72_xqxxI1QOBTNZZ79sxPcVKhWnYu8mEdnnA$> From: Kazuho Oku <[email protected]> Sent: Tuesday, June 3, 2025 10:49 PM To: Martin Thomson <[email protected]> Cc: Christian Huitema <[email protected]>; Lucas Pardue <[email protected]>; [email protected] 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 <[email protected]<mailto:[email protected]>>: 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<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams*name-qs_transport_parameters-fra__;Iw!!Bt8RZUm9aw!4-dIxmpNasJ3mjJ5iIIWnMhZbLka9kpmHMdIDpPF93ZoljtqA0yhDm72_xqxxI1QOBTNZZ79sxPcVKhWnYsbXEIfJA$>. 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
