Actually, I wonder if both Marco and Ben are correct. draft-ietf-webtrans-overview-09 states that "all WebTransport protocols MUST support simultaneously establishing multiple sessions between the same client and server," which I would interpret that running WT/H1 is out of scope, unless we define a way to run multiple sessions on top of H1.
That said, in WT/H2, all the components mandatory for running the WebTransport are defined on top of extended CONNECT, which is HTTP-version-neutral. Therefore, we have the necessary tooling to run WT over H1 (modulo support for multi-session). The practical disadvantage of WT/H1 is that it incurs one additional RT for setup. This is because the server can send the initial flow control credits only after receiving the HTTP request. WT/H2 avoids this problem by allowing servers to send their credits using H2 SETTINGS, but there is nothing that we can use on H1. 2025年6月7日(土) 1:36 Ian Swett <ianswett=40google....@dmarc.ietf.org>: > 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 >> >> >> -- > Webtransport mailing list -- webtransp...@ietf.org > To unsubscribe send an email to webtransport-le...@ietf.org > -- Kazuho Oku
