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.