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

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Nov 2020 17:37:44 -0800

Yutaka said:

"+1 to Victor. The server implementation cost is convincing to me."

[BA]  I (Chair hat off) agree with what Victor said in the paragraph below,
but perhaps not for the same reasons.

Victor said:

"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."

[BA] Sometimes it is easier to specify multiple (potentially competing)
protocols rather than spend a lot of resources trying to figure out which
one will eventually succeed. Once the protocols are specified the market
often makes a very clearcut decision. For example, WebSockets over HTTP/2
hasn't gotten much traction.

In this case, one of the transports (QuicTransport) is simple, so it's not
like the WG will spend a lot of time and effort getting it to the point
where implementers can get their hands on it, and decide if it is useful.
It is nearly there now (it would be nice to have more choices for a
QuicTransport server, but aioquic is usable today).  Having QuicTransport
is also convenient for testing the API, as well as gaining experience with
WebTransport deployment in general.  There may be some more work to do on
QuicTransport in order to address some of the deployment problems with
WebSockets (such as in draining and load balancing), but that's probably
not too onerous and might also carry over to other transports.

So the decision is really about going forward with HTTP/2 and HTTP/3. These
will take more time and effort to get right and so there's a higher cost to
working on them. But there still seems to be enough enthusiasm among the
authors and implementers, and there are use cases that these transports
seem uniquely able to address. They also have quite a bit in common.

What use cases will be compelling enough to follow all the way through to
implementation and deployment of the various transports is always a
guessing game.  I wonder whether QuicTransport will overcome the
deficiencies of WebSockets and also whether the complexity of
Http3Transport will eventually lead to simpler solutions being preferred.
But those are engineering challenges that the WG can presumably recognize
and work on solving, assuming we can get started and focus on them.

One particular challenge that I see relates to the mixed HTTP/3 and
WebTransport use cases.  There seems to be quite a bit of enthusiasm about
those, because they enable things that are not possible today while reusing
HTTP infrastructure. But I suspect that most HTTP/3 servers will not be
able to easily support the mixed HTTP/3 and WebTransport over HTTP/3
scenarios, and those that do (e.g. node.js) could take 18+ months at least.
So Http3Transport could be a "late bloomer".

On Thu, Oct 29, 2020 at 4:17 AM Yutaka Hirano <yhirano=
[email-masked]> wrote:

> +1 to Victor. The server implementation cost is convincing to me.
>
> On Thu, Oct 29, 2020 at 3:43 AM Eric Kinnear <ekinnear=
> [email-masked]> wrote:
>
>>
>>
>> On Oct 28, 2020, at 2:03 AM, Luke Curley <[email-masked]> wrote:
>>
>> Sorry, I was trying to be too terse and should explain.
>>
>> The QuicTransport indication involves an origin and a path using a custom
>> encoding. Like Victor mentioned, these are very similar to existing HTTP
>> headers and could be encoded as such. This would reduce the differences
>> between QuicTransport and Http3Transport.
>>
>> Http3Transport establishes the connection with HTTP headers but then
>> ditches the HTTP semantics. It instead exposes the underlying QUIC
>> connection and offers the same API as QUIC and QuicTransport.
>>
>> I was trying to express that QuicTransport and Http3Transport are
>> converging. You can look at this in one of two ways: Either there's not
>> enough differences to justify two protocols, or there are so few
>> differences that they can share everything but the wire protocol.
>>
>>
>> Just curious: if they share everything but the wire protocol, then are
>> there significant use cases where we’d expect someone to need or only
>> support one wire protocol over another? In other words, if they share
>> everything but a wire protocol, why do we need two wire protocols?
>> (There may be completely sensible reasons for this, just thought I’d ask
>> since I thought we’d previously been discussing choosing one or the other
>> as a layering decision, rather than maintaining both.)
>>
>> Thanks,
>> Eric
>>
>>
>> On Tue, Oct 27, 2020 at 10:40 PM Martin J. Dürst <[email-masked]>
>> wrote:
>>
>>> On 28/10/2020 09:34, Luke Curley wrote:
>>> > Yeah, I definitely agree that there's a grey area between
>>> QuicTransport and
>>> > Http3Transport. The QuicTransport indication is similar to HTTP, while
>>> > HttpTransport behaves like QUIC.
>>>
>>> I'm confused by the last sentence. Reformatting it, it reads:
>>>
>>> The   QuicTransport indication is similar to HTTP,
>>> while HttpTransport behaves       like       QUIC.
>>>
>>> Is that a typo, or does this crossover naming carry some deep
>>> philosophical meaning that I didn't get?
>>>
>>> Regards,   Martin.
>>>
>>> > But I think the decision to implement multiple protocols needs to be
>>> more
>>> > objective. Every WebTransport variant should add functionality or
>>> provide
>>> > backwards compatibility. Otherwise we'll be defining and implementing
>>> > standards that serve no purpose.
>>>
>>> --
>> Webtransport mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
>>
>> --
>> Webtransport mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Nov 2020 16:04:52 +1100

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.
> --

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Nov 2020 08:37:13 -0800

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.

On Mon, Nov 9, 2020 at 9:05 PM Martin Thomson <[email-masked]> wrote:

> 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
>
> > <
> https://mailarchive.ietf.org/arch/msg/webtransport/CEGNLkMqrvug3uPyPmQIXnWVIAY/
> >)
> >
> > Hello everyone,
> >
> > <
> https://mailarchive.ietf.org/arch/msg/webtransport/O8P5nmmw0ywra1VWtJmS4lBglhI/
> >).

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Nov 2020 06:34:12 -0800

> 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