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

[Victor Vasiliev <[e-mail]>]

On Mon, Jul 22, 2019 at 5:00 PM Andy Green <[e-mail]> 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.