Re: [Webtransport] Choosing the Transport

[Victor Vasiliev <[e-mail]>]

On Thu, Jul 23, 2020 at 1:57 AM Martin Thomson <[e-mail]> wrote:

> Thanks for the summary Victor, that really helps frame things.
>
> There are other differences, I think, so it would be good to make sure
> that we've captured all the relevant ones before making a call.  And
> understanding all the implications of each is important.
>
> The one that comes to mind is the way that fallbacks work.  In HTTP, you
> can imagine leaning heavily on the HTTP mechanisms for QUIC upgrade (or TCP
> fallback), like Alt-Svc and so forth.  The questions raised regarding
> non-uniform support for features are relevant here, so this isn't
> completely free.  In another scheme, you can code the fallback directly,
> even to the point of having it in the API:
> connect(quicTransport=quic-transport://..., webSocketTransport=wss://...).
> In other words, a clean slate means that you have to build the features you
> want, but you don't necessarily have to deal with the baggage you might not.
>

What exactly do you mean by "non-uniform support for features"?

It's true that HttpTransport in its default state basically has to defer
the protocol choice to the browser, since the JavaScript code has no
visibility into the state of the socket pool.  I'll note, however, that
this is not an inherent property of the HTTP wire protocol itself, but
rather just the natural way we would treat this kind of URL by default
(which is why I split the two questions below the way I did).  You can
imagine adding extra options to connect() that would change this as needed.


>
> I haven't formed an opinion on this yet.  I have a few concerns/wrinkles
> to add below though.
>
> On Thu, Jul 23, 2020, at 07:23, Victor Vasiliev wrote:
> > I was previously concerned that having to
> > implement HPACK/QPACK would be a burden to the Web developers since
> > those are more complex than what you’d typically find in a WebSocket
> > implementation, but now that we have a draft to turn compression off
> > <https://tools.ietf.org/html/draft-vvv-httpbis-alps-00>, I’m less
> > worried about this.
>
> I think that suggests some additional complexities.  You have to implement
> all of that stack, and trust that browsers do so as well.  As we have
> learned, sourcing a new capability like this isn't necessarily free.  And
> this seems at least on-par with ALPN in terms of operational costs for
> server deployments.  Maybe it is less of a concern as webtransport
> endpoints are the only ones that need upgrading, but I don't see this as an
> easy solution.
>

That's true, though any HTTP extension of this kind would to some extent
rely on ALPS (or some other form of half-RTT settings), since otherwise you
have to pay a round-trip penalty by waiting for an indication that the
server actually supports ALPS.  Overall, I think that between this,
Accept-CH reliability draft, and other extensions, we would have to solve
the SETTINGS latency problem sooner or later anyways.


>
> > While on the surface the question here is “which drafts should we
> > adopt?”, I would like to break this question down into two layers:
>
> I think that there is question zero: do we need to pick one set, or do we
> need to build all four protocols?
>
> We have not seen sufficient justification for building four protocols
> rather than two, so I'm firmly in the "do less work camp" on this.
>

I don't believe I've seen any enthusiasm for four protocols so far, which
is why I posed the first question as a binary choice.  Fortunately, even if
more interest becomes apparent down the road, WebTransport is
currently structured in a way that we can always add more.


>
> >  1. Do we want to use the wire format in which we try to build
> > minimally on top of QUIC (QuicTransport), or do we base it on HTTP?
> >  2. To what extent WebTransport connections act like HTTP connections?
> > Do they have https URLs or a dedicated schema?  Which HTTP headers do
> > and don’t work?
>
> I think that the answer to the second depends on the first.  As much as
> possible I would prefer NOT to mint new URI schemes, but that is much
> harder if you define a completely new protocol.  I think that an important
> question to resolve before this (1.5?) is how these connections integrate
> into the origin model.


I think the "origin model" question is automatically answered by the URI
scheme, since that would tell us if WebTransport can be, in principle,
same-origin to a Web page.