Thanks Ben, as long as your interpretation is correct, my deployment will be fine.
On Fri, Jun 6, 2025 at 12:21 PM Ben Schwartz <bemasc= 40meta....@dmarc.ietf.org> wrote: > 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> > 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> 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 > > >