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

[Martin Thomson <[e-mail]>]

Hey Victor,

I have a hard time understanding this.

If I recall correctly, your original proposal involved multiple protocols.  So this sounds like you have discovered something that supports that view, or at least has consolidated your own opinion.  But I don't see any actual evidence here to support building multiple protocols.

Building one protocol is hard enough.  It seems like we signed on to do two here, on the basis that we need a fallback.  But I don't see how that naturally extends to three.  On the contrary, just one protocol is pretty tempting at this point.  TCP fallback could be handled by a websockets polyfill outside of the browser (or a WebRTC polyfill for those who are less complexity-averse).

It seems your arguments are based on it being possible to hide a bunch of this complexity under a unified API.  That's great, but it doesn't mean that the abstraction won't leak.  I'm sure that running over h2 will look very different to running on bare QUIC.

That doesn't meant that I'm not curious about your semantic unification idea.  I don't understand that either, but it's an abstract notion with some appeal to me.

Cheers,
Martin

On Wed, Oct 28, 2020, at 03:22, Victor Vasiliev 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
>