I read that sentence a different way. In my reading, a WebTransport implementation that uses a new TCP connection for each session (e.g. atop HTTP/1.1) would be entirely acceptable: it supports multiple simultaneous sessions between the same client and server (on separate TCP connections).
An example of a noncompliant implementation might be something that sits inside a WebRTC session and wraps a single WebRTC Data Channel, without the ability to renegotiate the connection. --Ben ________________________________ From: Ian Swett <ianswett=40google....@dmarc.ietf.org> Sent: Friday, June 6, 2025 11:40 AM To: marco=40marcopolo...@dmarc.ietf.org <marco=40marcopolo...@dmarc.ietf.org> Cc: Lucas Pardue <lu...@lucaspardue.com>; quic@ietf.org <quic@ietf.org>; WebTransport <webtransp...@ietf.org> Subject: [Webtransport] Re: Reminder: upcoming QUIC virtual interim 2025-06-02 You make some good points and I agree with your conclusion. I like to think of WebTransport as an incarnation of QMux that's more restrictive in the ways you outline. On Thu, Jun 5, 2025 at 6: 21 PM <marco=40marcopolo. io@ dmarc. ietf. org> You make some good points and I agree with your conclusion. I like to think of WebTransport as an incarnation of QMux that's more restrictive in the ways you outline. On Thu, Jun 5, 2025 at 6:21 PM <marco=40marcopolo...@dmarc.ietf.org<mailto:40marcopolo...@dmarc.ietf.org>> wrote: Hi all, During the meeting, the comparison to WebTransport came up multiple times. The question seems to be: "WebTransport has already defined an API that works across various underlying transports, why not use that instead of QMux?". At a very high level these are doing similar things, so the question is natural. To better answer the question, I assigned myself the homework of reviewing the WebTransport overview draft[0] and outlining why it would or would not obviate the work for QMux. WebTransport at its core is designed and constrained by the Web Security Model. It imposes restrictions that make sense in the context of the Web, but make less sense for lower level applications and non-browser use cases. Take for example the following restrictions: > All WebTransport protocols MUST use TLS or a semantically equivalent security > protocol. While I think TLS + QMux will be a common combination, I do not believe the core QMux proposal should be restricted this way. As mentioned in the meeting, QMux would be useful on Unix Domain Sockets where TLS would simply be overhead. > All WebTransport protocols MUST support simultaneously establishing multiple > sessions between the same client and server. I missed this requirement and I think it's problematic in practice. I have a very widely deployed server that only supports HTTP/1 and HTTP/3 and never intends to support HTTP/2. It'd be nice to support WebTransport on that server for both HTTP/1 and HTTP/3, and I don't think it's practical to make a version of WebTransport that supports multiple sessions over HTTP/1. Adding the webtransport mailing list to see what the relevant WG's thoughts are on this MUST. This asks more of the underlying transport than what we need in QMux. Which, summarizing from the meeting, is something like a "Secure Byte Stream". > All WebTransport protocols MUST provide a way for the user agent to indicate > the origin > [RFC6454<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc6454__;!!Bt8RZUm9aw!-xswDm0k2z5PC5ukjDKaByidWQ2RBg7qBSp7DCmmOdS2_9qyI-G3noiBIE8Cub6NHEzeYUoXQ5ATPiZWh5yMSCExprk$>] > of the client to the server. When building on top of TLS, I think this is included. Either way, I'm not sure it would make sense to restrict QMux in this way. > User agent/Client separation I don't think this is necessary for many of the QMux use cases. The WebTransport Protocol framework is well designed for the Web Security Model. Many use cases we discussed in the meeting live outside that model. In my mind, QMux is a lower layer in the abstraction stack. QUIC is not constrained by the Web Security Model, and neither should QMux be. I think it's reasonable to imagine a WebTransport over QMux implementation (just as I think it's reasonable to imagine a WebTransport over QUIC implementation. IIRC I think someone working with moq said they had something like this). I'm not convinced that WebTransport, even a WebTransport over TCP implementation, can fulfill all of the usecases we have in mind for QMux. To summarize, I like WebTransport. While there is overlap at a high level in the API both WebTransport and QMux provide, QMux serves a more general use case than WebTransport. We should not shoehorn WebTransport into solving these general use cases. [0]: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-09<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-09__;!!Bt8RZUm9aw!-xswDm0k2z5PC5ukjDKaByidWQ2RBg7qBSp7DCmmOdS2_9qyI-G3noiBIE8Cub6NHEzeYUoXQ5ATPiZWh5yMOx4paWg$> -- -Marco Munizaga On May 27, 2025, at 3:00 PM, Lucas Pardue <lu...@lucaspardue.com<mailto:lu...@lucaspardue.com>> wrote: Hi folks, This email is a reminder that we'll be holding a virtual interim next week on the topic of QMux: 2025-06-02 21:00-23:00 UTC. The datracker page has further inforation including the MeetEcho link that we'll be using [1]. Participation is open but a free datatracker account is required. An agenda has been posted [2]. As usual this is subject to change up to and including the meeting itself. This meeting will run slightly different from past meetings focused on adopted documents and issues. Time will be dedicated to sufficient discussion of the QMux topic, with the focus being to iterate on the scope of work to do and proposed charter text to permit that in the QUIC WG. As usual, any meeting outcomes will be brought back to the list for confirmation. Cheers Lucas & Matt QUIC WG Co-chairs [1] - https://datatracker.ietf.org/meeting/interim-2025-quic-01/session/quic<https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/interim-2025-quic-01/session/quic__;!!Bt8RZUm9aw!-xswDm0k2z5PC5ukjDKaByidWQ2RBg7qBSp7DCmmOdS2_9qyI-G3noiBIE8Cub6NHEzeYUoXQ5ATPiZWh5yMPBgLMCs$> [2] - https://github.com/quicwg/wg-materials/blob/main/interim-25-06/agenda.md
