Subject: Re: [dispatch] [hybi] WebTransport Side Meeting (Tuesday, 15:20)

From: Victor Vasiliev <[email-masked]>
Date: Wed, 14 Aug 2019 07:13:20 -0400

On Mon, Jul 22, 2019 at 5:00 PM Andy Green <[email-masked]> wrote:

>
>
> On 7/22/19 1:36 PM, Victor Vasiliev wrote:
> > Hello everyone,
> >
> > Today, at the dispatch working group meeting (18:10), I am going to
> > present WebTransport. WebTransport is a protocol framework that allows
> > multiplexed and datagram-oriented transport protocols to be used by the
> > web applications (think “WebSocket for UDP”).
>
> "Historically, web applications that needed bidirectional data stream
>     between a client and a server could rely on WebSockets [RFC6455], a
>     message-based protocol compatible with Web security model.  However,
>     since the abstraction it provides is a single ordered stream of
>     messages, it suffers from head-of-line blocking (HOLB), meaning that
>     all messages must be sent and received in order even if they are
>     independent and some of them are no longer needed.  This makes it a
>     poor fit for latency sensitive applications which rely on partial
>     reliability and stream independence for performance."
>
> The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary
> fragmentation of messages allowing interleaving with control frames.
>

It allows them to be fragmented, but the fragments have to be in order.
The multiplexing extension is mentioned as potential future work in RFC
6455, but I don't believe it ever actually materialized.

> ws-over-h2 allows you to can the h2 stream when you want as well.
>

True, though you can't use them in the same way as pure QUIC streams
because QUIC streams are created immediately, whereas a new WS requires a
handshake.

>
> " Each new stream would require a WebSocket handshake to agree on
>        application protocol used, meaning that it would take at least one
>        RTT for each new stream before the client can write to it."
>
> Yes it was knowingly done as a hack to try to encourage uptake from
> browser vendors... it's not really integrated into the encapsulating
> protocol.
>

It = ws-over-http2 being a thin overlay over existing WSP?

> >   * WebTransport overview:
> >     https://tools.ietf.org/html/draft-vvv-webtransport-overview-00
> >   * QuicTransport:
> >     https://tools.ietf.org/html/draft-vvv-webtransport-quic-00
> >   * Http3Transport:
> >     https://tools.ietf.org/html/draft-vvv-webtransport-http3-00
>
> There's no h2 transport implementation?
>
> Not everything that might want to use this will get h3 capability in a
> reasonable timeframe.  If there's more momentum behind it than RFC8441
> there's probably room for a generic long-lived bidirectional extension
> to h2 either reusing DATA or a new frame type.
>

I think we might adapt an HTTP/2 transport as well
(via draft-kinnear-httpbis-http2-transport).

> It's a good idea to have it ride on other protocols.  Not doing this
> really hurt RFC6455 ws since deploying it usually needed extra,
> different servers with the attendant difficulties interoperating with
> other protocols.
>

One idea I had is an object called FallbackTransport, that can simulate
QUIC semantics on top of WebSocket and be fully polyfillable in browsers.

> I really suggest thinking through the effects of not having an RFC6455
> type subprotocol (unless I failed to spot it).  It really makes an
> implicit assumption about what the stream will carry that doesn't scale
> beyond one server carrying one thing.  That's not how things tend to pan
> out if the protocol is useful.  The url path could be hacked to imply
> the subprotocol but if that's not standardized it's still a mess.  And
> the subprotocol binding may be orthogonal to the url layout complicating
> things needlessly.
>

That's definitely an open issue with current proposal (some discussion here
<https://github.com/WICG/web-transport/issues/26>).   The current problem
is that we basically have to choose between either transmitting the
requested protocol in the open, or paying one extra RTT for the protocol
selection mechanism.

---

From: Andy Green <[email-masked]>
Date: Wed, 14 Aug 2019 13:01:14 +0100

>6455, but I don't believe it ever actually materialized.

Yes, you can only have one message on the go at a time; in that sense large messages block it.  But it does not block the stream completely because you can issue control frames inbetween fragments.  And although you may not have control over fragment size since intermediaries can mess with it, as the sender you do have control over message size which puts a ceiling on both how long other messages are blocked, and the max fragment size.  You may choose to split a large logical message into smaller ones so other message content can get a look-in.

The mux extension stuff was a thing on hybi for a while and then the main proponent seemed to lose interest with muxed ws vs h2... h2 was clearly a better result than he could have gotten from ws.

>because QUIC streams are created immediately, whereas a new WS requires

Sure... for clarity I also think h1 ws if not competitive itself with h2 or quic.  But it is widely implemented and deployed, and h2 doesn't have a native equivalent.  So it's still kind of keeping its hand in.

>It = ws-over-http2 being a thin overlay over existing WSP?

Yeah.  It's implemented in ffox and chrome but not turned on by default last time I looked.  There are few server implementations which makes it chicken-and-egg.

>(via draft-kinnear-httpbis-http2-transport).

Sounds good.

>QUIC semantics on top of WebSocket and be fully polyfillable in

In this space the problem isn't really ideas but implementation buy-in.  RFC8441 is educational because it was well positioned politically, the rfc certainly was exemplary for just saying what it needed to say, it solved a real problem, got some key implementations yet has still not been able to reach escape velocity.  There's some psychological and architectural gap between ws and http that is much wider than you would expect for many people (cf h2 addressed every single h1 + html 5 technology except ws -- and it was not an accidental oversight).

RFC8441 went in Chrome... it hasn't been enough by itself.  Maybe the crossover with quic will help your thing over the hump.

>requested protocol in the open, or paying one extra RTT for the

Usually the guy who directed the client to that server does it knowing that the server has the subprotocol he wants, unless something has gone wrong.  And it's only client -> server direction pipelining in question; the server can't send anything until he's had the request and he definitively decided the negotiated subprotocol by then, or killed the stream.

A client that had hot data to send could mark his preferred subprotocol as being non-neogitiable and start issuing data immediately after the stream open request... all being well the server allowed the stream's subprotocol, it lives on and takes the data, in the case it rejected the subprotocol it closes the stream and discards the data.  The client would have to either fail or retry without the non-neotiable part to recover if so.  But typically, he's only talking to the server because he's pretty sure it'll talk his subprotocol and it'll work the first time.

-Andy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Aug 2019 13:46:13 +1000

Folks,

Now that webtransport@ has been created, let's continue the discussion over there, rather than cross-posting to five lists.

Cheers,

> On 14 Aug 2019, at 10:01 pm, Andy Green <[email-masked]> wrote:
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/