Re: WebTransport Side Meeting (Tuesday, 15:20)

[David Schinazi <[e-mail]>]

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

On Mon, Jul 22, 2019 at 4:36 PM Victor Vasiliev <vasilvv=
[e-mail]> 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”).
>
> 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.
>