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

From: Victor Vasiliev <[email-masked]>
Date: Tue, 27 Oct 2020 12:22:06 -0400

(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: Lucas Pardue <[email-masked]>
Date: Tue, 27 Oct 2020 16:50:14 +0000

Hey Victor,

Thanks for the update. I reviewed the QuicTransport changes in the PR you
linked and the similarity to HTTP was striking, so it's good that you call
this out.

I wonder what Http3Transport looks like now. Have you done that update?

For me, it would help to understand what the drafts look like in this new
model before considering what is adoption worthy. Maybe its simple but my
imagination is lacking right now.

Cheers
Lucas

---

From: Luke Curley <[email-masked]>
Date: Tue, 27 Oct 2020 17:34:04 -0700

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.

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.

On Tue, Oct 27, 2020 at 9:50 AM Lucas Pardue <[email-masked]>
wrote:

>> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 28 Oct 2020 14:40:48 +0900

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

---

From: virat tara <[email-masked]>
Date: Wed, 28 Oct 2020 14:28:40 +0530

Are the challenges in implementing WebTransport over HTTP related to the
ones that are being faced while implementing RFC 8441
<https://tools.ietf.org/html/rfc8441> (WebSockets over HTTP)? I suspect
this because RFC 8441 has been in development
<https://www.chromestatus.com/feature/6251293127475200> for a long time.

On Tue, Oct 27, 2020 at 9:52 PM Victor Vasiliev <vasilvv=
[email-masked]> wrote:

> If we compare the WebTransport proposals to the HTTP ecosystem, besides
> the obvious equivalences (webtransport-http2 ≅ HTTP/2, webtransport-http3 ≅
> 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.
>

---

From: Luke Curley <[email-masked]>
Date: Wed, 28 Oct 2020 02:03:09 -0700

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.

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 28 Oct 2020 11:42:48 -0700

> On Oct 28, 2020, at 2:03 AM, Luke Curley <[email-masked]> wrote:
> 
> 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] <mailto:[email-masked]>> wrote:

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 29 Oct 2020 20:17:18 +0900

+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:

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