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> 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://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 <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 > [2] - > https://github.com/quicwg/wg-materials/blob/main/interim-25-06/agenda.md > > >
