Re: [Webtransport] Choosing the Transport, pt. 2

[virat tara <[e-mail]>]

Are the challenges in implementing WebTransport over HTTP related to the
ones that are being faced while implementing RFC 8441
<https://tools.ietf.org/html/rfc8441> (WebSockets over HTTP)? I suspect
this because RFC 8441 has been in development
<https://www.chromestatus.com/feature/6251293127475200> for a long time.

On Tue, Oct 27, 2020 at 9:52 PM Victor Vasiliev <vasilvv=
[e-mail]> wrote:

> (previous iteration of this thread here
> <https://mailarchive.ietf.org/arch/msg/webtransport/CEGNLkMqrvug3uPyPmQIXnWVIAY/>
> )
>
> Hello everyone,
>
> As you might remember, we've still not decided which of QuicTransport,
> Http2Transport and Http3Transport we should adapt:
>
>    1. There has been a strong interest in running WebTransport over HTTP.
>    HTTP allows us to do connection pooling, a well-understood mechanism of
>    falling back to TCP and better integration with existing load balancers.
>    2. There has also been interest in running WebTransport over QUIC
>    itself, due to the complexity of WebTransport over HTTP, both in terms of
>    design and in terms of writing servers for it (nice discussion here
>    <https://mailarchive.ietf.org/arch/msg/webtransport/O8P5nmmw0ywra1VWtJmS4lBglhI/>
>    ).
>    3. There has been a desire to pick only one of those.
>
> I've been reworking <https://github.com/vasilvv/webtransport/pull/18> the
> QuicTransport draft based on what we've found while implementing it in
> Chrome.  Doing that, and observing how it becomes more and more like HTTP
> with every revision, has convinced me more than ever that all of the
> transports above should be the same thing conceptually, differing only in
> wire protocol.  That observation was very helpful, since it allowed us to
> replace <https://github.com/w3c/webtransport/issues/129> all of the
> different API entry points with just one, already dramatically simplifying
> the situation.  Same observation also can potentially help us make some
> progress here.  We can unify all of the proposals semantically (make them
> share a URL scheme and the headers format), and then the variants just
> become different encodings.
>
> If we compare the WebTransport proposals to the HTTP ecosystem, besides
> the obvious equivalences (webtransport-http2 ≅ HTTP/2, webtransport-http3 ≅
> HTTP/3), it becomes apparent that webtransport-quic ≅ HTTP/1.1.  This gives
> us a hint of why we might want all three of those.  This is also really
> nice, since we know how to switch between all of those protocols, and we
> have a lot of experience with an ecosystem shaped like that:
> webtransport-quic and webtransport-http3 can be switched via ALPN,
> webtransport-http2 can be raced in parallel with the former.
>
> So I propose that we adapt all of them.  As it stands, webtransport-quic
> is a simple-to-implement and proven-to-work solution that should not
> require much of working group's time.  There are questions regarding
> whether webtransport-http is too complex; I believe that we won't know
> unless we try, and since there's clearly interest in trying, I believe we
> should adopt that draft and actually start working out those complex
> details.
>
> What does everyone think?
>
> Cheers,
>   Victor.
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>