At least I could polyfill webtransport in this way over WebSocket:
https://datatracker.ietf.org/doc/draft-richter-webtransport-websocket/
and it works without problems, see for implementation:
https://github.com/fails-components/webtransport/tree/master/main/lib/http2
I block currently plain http websocket, but it should work with minor
modifications.
Also the pure http/2 capsule protocol should work via http1.
Marten
Am 06.06.25 um 18:36 schrieb Ian Swett:
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
<[email protected]> 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 <[email protected]>
*Sent:* Friday, June 6, 2025 11:40 AM
*To:* [email protected]
<[email protected]>
*Cc:* Lucas Pardue <[email protected]>; [email protected]
<[email protected]>; WebTransport <[email protected]>
*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
<[email protected]> 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
<[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
<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
