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

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> On August 14, 2019 12:13:20 PM GMT+01:00, Victor Vasiliev <[e-mail]> wrote:
>> 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.
> 
> 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.
> 
>>> 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.
> 
> 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.
> 
>> 
>>> 
>>> " 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?
> 
> 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.
> 
>> 
>>>>  * 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).
> 
> Sounds good.
> 
>>> 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.
> 
> 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.
> 
>>> 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.
> 
> 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

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