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. 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://www.rfc-editor.org/rfc/rfc6454>] 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 -- -Marco Munizaga > On May 27, 2025, at 3:00 PM, Lucas Pardue <[email protected]> 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 > [2] - https://github.com/quicwg/wg-materials/blob/main/interim-25-06/agenda.md
