[Webtransport] Choosing the Transport, pt. 2

[Victor Vasiliev <[e-mail]>]

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