Re: [Webtransport] Choosing the Transport

[virat tara <[e-mail]>]

Hi,

For an app that would use both regular HTTP calls and WebTransport, from
the server's perspective, won't using HttpTransport instead of a dedicated
connection like in QuicTransport help it to reduce the number of active
connections/sockets per client? Thus allowing it to serve more
distinct clients per server. Particularly for apps that make
occasional HTTP calls and heavily rely on a full-duplex protocol for the
rest of their working.

On Thu, Jul 23, 2020 at 2:53 AM Victor Vasiliev <vasilvv=
[e-mail]> wrote:

> Hello everyone,
>
> We recently adopted the overview draft
> <https://tools.ietf.org/html/draft-ietf-webtrans-overview-00> that
> describes the general requirements for and the model of WebTransport.
> However, we haven't yet adopted any specific wire protocol proposals.
> There are currently three of those presented to the working group:
>
>    - QuicTransport
>    <https://tools.ietf.org/html/draft-vvv-webtransport-quic-02>
>    - Http2Transport
>    <https://tools.ietf.org/html/draft-kinnear-webtransport-http2-01>
>    - Http3Transport
>    <https://tools.ietf.org/html/draft-vvv-webtransport-http3-02>
>    - [hypothetical WebTransport over WebSocket]
>
> Back when the original idea of WebTransport was forming, the hope was to
> implement and ship all four of those, since they all fit different use
> cases better.  After talking more to the people at IETF, it sounds like
> four transports is a bit too much, and we should settle on two (one over
> QUIC, and one over TCP).  The natural picks would be either Http3Transport
> with Http2Transport as fallback (HttpTransport for short), or QuicTransport
> with… *something* as a fallback.  Let’s look at the differences between
> those two options.
>
> *Differences*
>
> The most substantial wire format difference between those two proposals is
> the handshake.  QuicTransport originally did not have any handshake; we had
> to add a bespoke handshake later in order to implement the Origin header,
> and we also added a Path header later on.  We currently don’t have any form
> of response headers, so if the server is unhappy with the origin or path
> received, it has to close the connection with CONNECTION_CLOSE..  In
> HttpTransport, we have regular HTTP header fields for both request and
> response, meaning that the server can do things like return a 4xx/5xx for
> an error.
>
> During the connection itself, the difference is minimal: QuicTransport
> uses streams and datagrams as-is, while Http3Transport prefixes everything
> with an ID, since it is multiplexed with other HTTP traffic.  There might
> be a question of whether prefixing can impose undesirable framing overhead;
> I think if that ever becomes a serious problem, we can come up with some
> extension to work this around.
>
> If we decide that QuicTransport is a way to go, we’d have to add more
> features into its handshake, since I suspect most people won’t be happy
> with what’s in there right now (HTTP headers like Location or Forwarded
> would be a good example of what people would end up needing in practice,
> together with an ability to tag along arbitrary key-value metadata for
> debugging purposes).  If we decide that HttpTransport is a way to go, we
> would have to ensure that the result is easy for Web developers to use, and
> that we understand the differences between it and regular HTTP.
>
> From the server complexity standpoint, I am not particularly worried about
> either.  We’ve implemented QuicTransport in Chrome, and I wrote two servers
> for it, in C++ and in Python; the Python one took about 100 lines of code.
> Http2Transport has been implemented, in somewhat different forms, by both
> Apple and Facebook, so we have practical experience with it too..  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.
>
> There is a question of how much of the HTTP ecosystem we would be actually
> getting by adopting HTTP.  It is true that basing WebTransport on HTTP does
> not mean HTTP middleware would automatically implement it.  That said, we
> do get a lot of useful features from HTTP, notably message routing and a
> well-understood metadata format.  Everyone knows what a code 200 or 404 is,
> and a lot of people have built their internal debugging/tracing tools based
> on adding HTTP headers to things, and being able to easily port those to
> WebTransport would be an asset.  I’ve seen some arguments that content
> negotiation and caching might be applicable to certain classes of
> WebTransport resources too (e.g. a live stream can be cached in the sense
> that requesting a live stream is joining it), though those kinds of cases
> would have to be content-specific and they do not generalize as nicely as
> caching for regular HTTP resources.  An interesting point to note is that
> WebTransport is always included programmatically (as opposed to being
> navigated to or sourced via URL from HTML), thus alleviating the need for a
> lot of otherwise useful HTTP headers.
>
> *Questions*
>
> While on the surface the question here is “which drafts should we adopt?”,
> I would like to break this question down into two layers:
>
>    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?
>
>
> Regarding the first issue, I am increasingly leaning towards keeping only
> the HTTP-based option. QuicTransport’s most appealing feature is its
> simplicity; however, ever since we’ve had to add a header to communicate
> the Web origin, there has been increasingly more and more reasons to add
> new features to it, so even if we go that way, we’re probably going to end
> up with something that’s a lot like HTTP.  Also, we know exactly how to do
> TCP fallback in this case, so this removes a lot of design problems from
> consideration.  Fixing complexity and other problems with HTTP is probably
> more viable.
>
> Regarding the second issue, I am not sure how much of it is in scope for
> this working group.  While we do need to define a URL schema, and the
> choice of schema will give us a lot of answer (by making WebTransport same
> or different origin as HTTP), a lot of those questions have been
> traditionally answered somewhere in Fetch spec, or simply not addressed in
> the standards at all.  I am not quite sure what to do with those.
>
> What do people think?
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>