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

Reply via email to