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

[Eric Rescorla <[e-mail]>]

On Tue, Nov 10, 2020 at 8:38 AM Bernard Aboba <[e-mail]>
wrote:

> Martin said:
>
> "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."
>
> [BA] There is a question whether h2 is supported within the WebTransport
> API:
> https://github.com/w3c/webtransport/issues/164
>
> Part of the concern is the complexity that would be added by supporting
> failover within the API, rather than outside of it.
>
> Currently, if QUIC and associated functionality (such as datagram support)
> cannot be negotiated, the WebTransport constructor will fail.  Among other
> things this implies that if the WebTransport constructor succeeds and the
> ready promise is resolved, that the datagramWritable and datagramReadable
> attributes are always defined.
>
> It does not make sense to me to pretend that datagram functionality is
> available when running over a transport that does not support datagrams.
>

I don't agree with this. The availability or non-availability of UDP is
unpredictable to users and context-dependent, and the user experience of
having things just not in one network is extremely frustrating. Moreover,
we have extensive experience that it is possible to provide inferior, yet
somewhat acceptable, low-latency applications such as videoconferencing
even over non-datagram transport (hence the support for ICE TCP and TURN
TCP etc in WebRTC), especially in fast networks. I believe the same
reasoning applies here.

-Ekr

>
> On Mon, Nov 9, 2020 at 9:05 PM Martin Thomson <[e-mail]> wrote:
>
>> 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
>> >
>>
>> --
>> Webtransport mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>