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

[Bernard Aboba <[e-mail]>]

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=
[e-mail]> wrote:

> +1 to Victor. The server implementation cost is convincing to me.
>
> On Thu, Oct 29, 2020 at 3:43 AM Eric Kinnear <ekinnear=
> [e-mail]> wrote:
>
>>
>>
>> On Oct 28, 2020, at 2:03 AM, Luke Curley <[e-mail]> 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 <[e-mail]>
>> 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
>> [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
>