Skip to main content

Minutes IETF109: webtrans
minutes-109-webtrans-00

Meeting Minutes WebTransport (webtrans) WG
Title Minutes IETF109: webtrans
State Active
Other versions plain text
Last updated 2020-11-17

minutes-109-webtrans-00
IETF 109 WEBTRANS WG Agenda

Monday, November 16, 2020 01:00 - 03:00 Pacific Time
Monday, November 16, 2020 09:00 - 11:00 UTC
Monday, November 16, 2020 16:00 - 18:00 Bangkok

Chairs: Bernard Aboba and David Schinazi

16:00 – 16:10 Preliminaries, Chairs (10 minutes)
   Note Well
   Jabber Scribe, Etherpad Note Takers
   Speaking Queue Manager (David Schinazi)
   Agenda Bash

# 16:10 - 16:15 W3C WebTransport Update, Bernard Aboba (5 minutes)

W3C created WG, meetings scheduled, CFC to adopt WebTransport deliverable spec

# 16:15 - 16:25 WebTransport Developer Feedback, Luke Curley and Bernard Aboba
(10 minutes)

## Twitch Origin Trial (Luke)

Luke: WebTransport API Origin Trial available with current Chrome releases
(latest API in M87+). Reliable stream part of the API works "somewhat well"

What are we trying to achieve with QuicTransport? Trying to solve Head-of-line
blocking in the presence of congestion. Today we (Twitch/Amazon) use RTMP for
uploads, HLS for distribution. Desire is to use QuicTransport for both,
delivering media with multiple prioritized streams to avoid HoL blocking. We
have a custom QUIC implementation, and are currently experimenting internally.
Production experiments early next year

Why not HTTP/3?  Latency and prioritization is hard; server push is harder.
Directionality makes for different APIs. Found several bugs in Chromium QUIC
implementation.

Would like to see added:  Prioritization; better congestion control, esp. for
datagrams

David:  Why no HTTP/2?
Luke:  We would just fall back to HLS, and we already have that. Http2Transport
would be worse, based on prioritization. Bernard:  Heard the same from game
streaming, remote desktop and event streaming developers: fallback is what they
have currently deployed. David:  Would you use H3Transport? Luke:  No, not
useful.  We don't need pooling. Bernard: Heard preference for QuicTransport
from game streaming and remote desktop developers. Those use cases can be
peer-to-peer as well as client/server. Don't want to have to implement an
HTTP/3 server in a browser or client to do P2P (perceived as a security risk).

Victor Vasiliev:  Http3Transport would give you prioritization, potentially.
But you might not need that without a reverse proxy. Luke:  We assign users to
particular servers; the host can prioritize.  No load balancers in-band.

Ian Swett:  BBR2 likely to become default CC for QUIC (in Chromium) in 1Q2021.
Youtube doesn't want HTTP/2 fallback, they'll stick with HTTP/1.1 which is
widely deployed.

Lucas Pardue:  Played with this some, using example client/server and Quiche.
QuicTransport didn't require any substantial changes.  Http3Transport would
have been easy, but I didn't need it so didn't build it.

Eric Kinnear:  Would be interesting to share congestion control across
connections.  Any data about that?  Also, if your stack exposes transport-layer
ACKs, you wouldn't need application-level ACKs. Luke:  Congestion control with
Datagrams, you don't know when WebTransport might decide to drop things.  So
you need to implement congestion control in your application currently.  You
can't use transport ACKs because they aren't flow controlled; the packet can be
ACK'd and the datagram not delivered.

## Streaming use cases (Bernard)

Key question: What's the bar / incentive for people with existing code to move
to something new?

### Low-Latency Feedback
Use cases include game streaming and remote desktop. Game streaming is often
implemented with WebRTC today. Some cloud gaming services use WebRTC data
channel for audio/video as well as mouse/keyboard/control. Others use RTP
audio/video + data channel. Remote Desktop typically uses RTP audio/video +
data channel.  Some implementations of game streaming and remote desktop
support both client/server and P2P; want to use one codebase for both scenarios.

Due to backpressure issues with the WebRTC datachannel API (and WebSockets),
implementers have had to support application-layer ACKs and congestion control.
This is an extra level of effort, so if WebTransport can take care of that
problem (which it seems to for reliable streams), this makes the implementation
less complicated. However, you still need application-layer ACKs for
unreliable/unordered (datagrams), and this the transport used in game streaming
and remote desktop.  So for datagrams, WebTransport isn't removing the need for
the application-layer ACKs developers have had to support in WebRTC data
channel. Since QuicTransport only currently supports client/server, not P2P
(the RTCQuicTransport Origin Trial in Chromium was based on gQUIC and an
earlier API so it was removed), you can't do both client/server and P2P with it.

Another thing that developers missed about QuicTransport compared with WebRTC
is migration and fallback.  WebRTC over ICE makes it possible for a connection
to migrate from one interface to another. Fallback is provided via TURN over
TCP/TLS. So ICE isn't deadweight, it has some benefits even in client/server
use cases. A distinct migration issue is how to move a QuicTransport to another
server, if you are bringing a VM down. This isn't something that can be solved
using ICE, more likely with QUIC migration. However, the WebTransport API
doesn't support that.

One thing that was never implemented with WebRTC data channel was bandwidth
allocation or priority. In the game streaming or remote desktop scenario it is
important for keyboard, mouse and control traffic not to be starved out by
audio/video.

### Event Streaming
The difference between low-latency streaming and event streaming is that event
streaming latency can be larger. One second latency is typically fine, maybe
can live with a few seconds. Here WebTransport is competing against HLS,
offering a way around HoL blocking, which means fewer video freezes. Since the
events can be large scale (political rallies with 100K+ participants), the
developers are looking for broad ecosystem support: support from multiple
browsers, cloud providers, CDN vendors, load balancers, etc. Interoperability
is not negotiable.

For this use case, developers initially showed an interest in Http3Transport,
based on the belief that it offers functionality beyond HTTP/3 (e.g. datagrams)
while leveraging existing infrastructure better than QuicTransport, where
they'd have to build things from scratch. However, when we got into the details
of the design, they began to have doubts.  For example, they were initially
thinking about pooling HTTP/3 with Http3Transport, so they could use HTTP/3 for
selecting the event and datagrams over Http3Transport to send the event media.
However, support for pooling with WebTransport is not a required HTTP/3
feature. Even if their HTTP/3 server supports Http3Transport, that doesn't mean
that it would support HTTP/3 and Http3Transport pooling in the way they were
envisaging. From their CDN vendor, they learned that Http3Transport is not
CDN-compatible. This lead to investigation of HTTP/3 with multiple reliable
streams to eliminate HoL blocking. This alternative (HLS over HTTP/3) provides
most of the benefits they were looking for, while still letting them leverage
the HTTP ecosystem. So is Event Streaming actually an HTTP/3 use case, not an
Http3Transport use case? I wonder whether other Http3Transport use cases might
turn out to actually be HTTP/3 use cases when you get into the details.

For enterprise scenarios (company meetings) there is concern about
compatibility of QUIC with enterprise firewalls, which can block UDP or even
TCP/TLS on ports other than 443. In those kind of scenarios, HTTP/2 fallback is
unlikely to help (the enterprise proxy probably won't support HTTP/2). So the
developers indicated a preference to fallback to HLS, as Luke said.

# 16:25 - 16:40 WebTransport Overview and Requirements, Victor Vasiliev (15
minutes) https://tools.ietf.org/html/draft-ietf-webtransport-overview

Since last version, PR to add option for HTTP-style headers for all transports

Lucas:  Is this proposal still the best option if we don't keep the
H{2,3}Transports? Victor: Meetecho problems, will discuss on list

# 16:40 - 16:55 WebTransport using HTTP/2, Alan Frindell for Eric Kinnear (15
minutes) https://tools.ietf.org/html/draft-kinnear-webtransport-http2

Eric:  Also encountering Meetecho problems, Alan will present

Issues, PRs; Http2Transport is in a holding period waiting for WG to decide
whether to proceed

== Issue 5 ==
Do we want half-closed streams?  Flag similar to SPDY; maps more naturally to
QUIC

== Issue 3 ==
H2 can establish multiple WebTransport streams in a single RTT; H3 and QUIC
might not be able to

== Issue 6 ==
Reliability of datagrams

Remaining implementation details are less critical than choosing a direction as
a WG

# 17:10 - 17:30 WebTransport over HTTP/3 and QUIC, Victor Vasiliev (20 minutes)
https://tools.ietf.org/html/draft-vvv-webtransport-http3
https://tools.ietf.org/html/draft-vvv-webtransport-quic

H3Transport converging toward H2Transport-like behaviors (PR 21)

QuicTransport adds request and response headers; new ALPN token, URI scheme

# Exiting the Transport Zoo

No one seems to be arguing for FallbackTransport, but matrix of QUIC/TCP and
Connection/Pooled. Changes allow for nicer API surface, single class passed
different URLs

Martin:  Yes, but the different transports will have different fallback
properties.

QuicTransport and H3Transport are converging; H3Transport is basically
QuicTransport with connection pooling. What if we completely abstract it away? 
Separates semantics from wire protocol selection, lets us make progress on
semantics even if we get stuck on selection of transports.

QuicTransport is the simplest possible option.
Selection boils down to:  Is pooling worth it?  Is TCP fallback necessary?
Personally, yes and nice-to-have.

Alan:  Pooling can mean two things.  Multiple WebTransport sessions per
connection, or WebTransport + HTTP traffic.  These are different.

Eric:  Like the idea of simplifying the API.  Express properties you need/want
and let the stack figure it out.  Not sure these are the only two.

Luke:  Need to have two connections to the same host with lots of data transfer
for pooling to be useful.  Otherwise, QUIC is fine.  No point in pretending to
support things like datagrams if it's not actually there.

Victor:  HTTP is more amenable to intermediation.  Priority, for example.
Martin:  Not relevant, since you can't use the HTTP-level signalling.  Every
QUIC stack should implement prioritization, even if the signalling isn't there.

Martin:  Alan, what experience are you looking for with your pooling?  I'd
expect them to be going to different back-ends; is there a benefit besides
congestion control?  Strongly leaning toward non-pooled; only one QUIC-based
option, please. Alan:  Scale; Facebook has LOTS of open HTTP connections. So
pooling reduces the load on the server and improves scaling. There are also
non-HTTP, pub-sub / real-time things going to the same service.  One
connection; front-end can demux sessions.  Why not build our own extension for
our app?  Push to use native stacks, and need to support web browsers.

Daniel Havey:  Absolutely have to be able to tell caller what transport is
being used.

EKR:  Agree there should be only one WebTransport protocol; not sure which it
should be.  If MASQUE is based on H3+DATAGRAM, should we follow suit?  Some
kind of TCP fallback is necessary; not everyone has UDP reachability.

Jana:  We're trying to do too many things.  Do we need all of these?  This is
TAPS reborn, and that scares me.  If we want an evolution of WebSockets,
QuicTransport is the most obvious choice (when QUIC works).  But if pooling is
important, maybe we just do H3Transport. Victor:  Each transport has at least
one advocate with a use-case.

Bernard:  I have heard a desire to pool HTTP and WebTransport, to extend the
web to support datagrams. Doing it all on the same QUIC connection improves
scalability and also helps with firewall traversal. However, there are a lot of
moving parts, but it's a big win if you can make it all work. However, I wonder
whether pooling of HTTP/3 with Http3Transport is the right way to accomplish
this, or whether extending HTTP/3 makes more sense.

Eric:  Important to wind up with one thing, but we need something when QUIC
doesn't work.  Either we use HTTP generically, or we think about
FallbackTransport.

David:  Getting a sense that we only need one of the QUIC-based transports. 
Can we reach consensus on that? Victor:  Why do we need only one? Martin: 
Fewer things; if there's added complexity, it needs to be justified, and I
haven't heard it. Jana:  Can we hear out Philipp first?

Philipp:  We can implement pooling by adding Masque beneath WebTransport.  No
extra layer of hole-punching or pooling; can add prioritization, fate-sharing,
etc. while still having simple QuicTransport.  Only the load-balancer needs to
speak HTTP/3, and the back-ends can only do QuicTransport. David:  That would
entail double encryption with the basic draft.

"HUM" result:  roughly 2/3rds voting (29) say only one, 1/3rd say both (10).
30+ participants not voting (unsure?)

Victor:  Let's adopt QuicTransport, but not preclude adopting H3Transport later
if we need it. EKR:  That could result in us doing both. Alan:  Yes.  H3 is a
superset, and you can opt not to use features.

Eric:  Standardizing only one (but then having people implement more than one)
would potentially lead to interop issues.

EKR:  I'm happy to pick one, but pick it because we think it's right, not just
because it's easy.

FINAL CONCLUSION:  We don't know yet.  Let's schedulie an interim to hash this
out; it can't wait another four months.