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

From: Victor Vasiliev <[email-masked]>
Date: Mon, 22 Jul 2019 16:36:19 -0400

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”).

Since it’s quite likely we will run out of time during dispatch, I
scheduled a side-meeting to discuss this in more depth. Below are the side
meeting details.

*Time:* Tuesday, 15:20 ~ 16:50
*Place:* Room C2 (21st floor)
*Organizers:* Victor Vasiliev, David Schinazi
*Agenda:*

   1. A more in-depth overview of WebTransport.
   2. Discussion of the overall design and the use cases.
   3. As time permits, some of the major outstanding design issues in Web
   transport, e.g.:
      - What fallback protocol to use?
      - How to multiplex streams and datagrams within a single connection?
      - Can we let web applications do their own congestion control?
      - Should WebTransport sessions have URLs associated with them?

As usual, here are some helpful links:

   - 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
   - Web API Spec draft: https://wicg.github.io/web-transport/
   - Discussion on use cases:
   https://discourse.wicg.io/t/webtransport-proposal/3508

Cheers,
  Victor.

---

From: Andy Green <[email-masked]>
Date: Mon, 22 Jul 2019 13:59:57 -0700

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:
>   * QuicTransport:
>   * Http3Transport:

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.

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:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 22 Jul 2019 17:29:09 -0400

> On Jul 22, 2019, at 4:59 PM, Andy Green <[email-masked]> wrote:
> 
> 
> 
>> 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”).
> 
> The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary fragmentation of messages allowing interleaving with control frames.
> 
> 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:
> 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
>

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 23 Jul 2019 11:37:04 -0400

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=
[email-masked]> wrote:

> multiplexed and datagram-oriented transport protocols to be used by the web
> 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
>
> >
> really hurt RFC6455 ws since deploying it usually needed extra, different
> servers with the attendant difficulties interoperating with other protocols.
> >
> 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
> >
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: David Schinazi <[email-masked]>
Date: Tue, 23 Jul 2019 17:35:06 -0400

Thanks to everyone who came to the side-meeting today. We had 27 people in
the room and strong interest in the topic.

In terms of next steps: this work will proceed in parallel at the W3C, and
we will seek to open an IETF mailing list to discuss WebTransport (we'll
report the list here when it exists).

Thanks in particular to Steve Anton for recording the following minutes:

Roberto Peon: best to share connection even for data with different
congestion controllers
Seth Blank: many games open many TCP connections for reliable data, in
addition to UDP
Seth: others will layer a reliable layer on top of UDP
Jana Iyengar: having all types of data under the same cc is very useful,
but needs a way to prioritize traffic. Another issue with existing
approaches: some connections (if multiple TCP/UDP/etc) may fail which is
awkward (e.g., TCP may work but UDP not).
Is connection setup latency important?
Yes, RTC use cases find call setup very important
QUIC should help a lot here
Use case: for legacy apps, map UDP sockets to QUIC datagrams, TCP sockets
to QUIC streams
Brian Trammell: but these legacy apps want to interop with things that
speak TCP and UDP, not QUIC
Solution: host a shim proxy
Roberto: a L7 proxy wants very low level APIs to forward data avoid
compounding delays.
Partial reliability models
Jana: agree that datagrams are too low level for from-scratch applications.
SCTP made this mistake. What is the API for sending application-sized
messages? (streams?)
Roberto: QUIC is missing the concept of “session” (bundling streams
together to the same endpoint). Use case: L7 proxies that route at the
session level.
Roberto: protocol needs to know about framing and ordering (for flow
control)
Martin Thomson: don’t invent partial reliability here, or else it could be
the hill to die on.
Victor Vasiliev: want to just expose APIs for QUIC primitives that are
already defined (imagine streams are a useful abstraction, datagrams are
the most minimal abstraction)
Target application: real-time client-server streaming
Not going to solve this in WebTransport, instead offer primitives to build
on.
TAPS
Brian: Underlying transport depends on application and deployment. Will
likely need a transport selection algorithm.
Victor: want to do transport selection as a higher level layer, not in
WebTransport.
Victor: some of the data API will use Web primitives (like WHATWG Streams).
Don’t want to over abstract.
Brian: take a close look at the TAPS architecture document.
QuicTransport vs. Http3Transport
Roberto: things we implement in HTTP: redirection, shut down state,
caching, multiplexing. These are very valuable, let’s not forget.
Important to ship an API which performs and is what people want to use.
Eric Kinnear: HTTP has a few downsides, e.g. bidirectionality. There’s a
use case for just a QUIC transport.
Peter Thatcher: HTTP doesn’t make sense for P2P.
Martin: How does this spec handle fallback if e.g. QUIC can’t connect?
There should be a transparent fallback.
Victor: WebSocket fallback (can even implement as a polyfill).
Jana: may need to break down spec into pieces before bringing it into the
IETF.
Victor: wire format changes are clearly IETF. API design is clearly W3C.
Framework definition could go either way, not sure which venue right now.
Martin: kind of weird but seems to work to have the same people wear IETF
and W3C hats
David Schinazi: seems to be interest: in terms of process, should a new
IETF mailing list be formed?
Martin: get an AD to form a mailing list. IETF should do work for W3C, not
the other way around.
Roberto: implementations of WebTransport could be useful without it
necessarily being a Web API.
Mark Nottingham/Martin/Peter: W3C work is in WICG right now. Needs to be a
working group before IETF would form a working group.
Can still make a mailing list, have a BOF before the working group was
formed.
Jana: Other way of doing it: W3C driving requirements for IETF protocol,
creates API.
Roberto: some use cases for L7 proxies even if this doesn’t end up in the
browser.
Jana: Is the RTCDataChannel a first application for WebTransport?
Harald Alvestrand: desire in WebRTC to redesign the RTCDataChannel API.
Roberto: a major application that wants this is low latency broadcast video.
Bandwidth prediction APIs
Roberto: value for this, very complicated though. Today the server which
has lower level control can send the browser cc info.
Harald: started with receiver cc, went back to sender cc later
Brian: should take this out of scope for a BOF
Roberto: defer this or else it will fail (e.g., HTTP2 started without QUIC
even though they knew QUIC was needed).
Jana: don’t bring bandwidth prediction up or else it will be front and
center and kill the effort