Re: [Webtransport] Choosing the Transport

[Martin Thomson <[e-mail]>]

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.

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.

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

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