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

At a quick glance,
https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/?include_text=1
seems
like a decent fit for the WebTransport  API.  It seems better than trying
to fit the WebSocket API.  But do we expect people to implement it on
servers before they implement QUIC?  I suppose even if it takes longer, it
may have the advantage of working on more networks than QUIC and HTTP/3
potentially (for networks that still block UDP, for example).



On Mon, Jul 22, 2019 at 5:29 PM Eric Kinnear <ekinnear=
40apple.com@dmarc.ietf.org> wrote:

>
>
> > On Jul 22, 2019, at 4:59 PM, Andy Green <andy@warmcat.com> 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.
> >
> > ws-over-h2 allows you to can the h2 stream when you want as well.
> >
> > " 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.
> >
> >>  * 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.
>
> Definitely agree! I know that we’ve been chatting a bit with Victor about
> https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/
> which aims to provide this, and I think it would be worth making sure that
> this works nicely with WebTransport.
> -00 for that document covers effectively what you’d get with a new frame
> type, and -01 extends 8441 to cover more than just WebSockets with the
> extended CONNECT handshake.
> I don’t have a particularly strong preference for the mechanism used, but
> rather care more about the outcome — very much agree that this is a useful
> component.
>
> Thanks,
> Eric
>
> >
> > 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.
> >
> > 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.
> >
> > -Andy
> >
> >>  * Web API Spec draft: https://wicg.github.io/web-transport/
> >>  * Discussion on use cases:
> >>    https://discourse.wicg.io/t/webtransport-proposal/3508
> >> Cheers,
> >>   Victor.
> >> _______________________________________________
> >> hybi mailing list
> >> hybi@ietf.org
> >> https://www.ietf.org/mailman/listinfo/hybi
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>