# IETF 108 WEBTRANS WG Meeting *Monday, July 27, 2020* *14:10 - 15:50 UTC* Virtual Room 1 Chairs: Bernard Aboba and David Schinazi Agenda: https://datatracker.ietf.org/doc/agenda-108-webtrans/ MeetEcho: http://www.meetecho.com/ietf108/webtrans/ Jabber Room: webtrans@jabber.ietf.org Slides: https://docs.google.com/presentation/d/1cr_4jtUCYTkoJQl4jEWT9LKJfZkkYM1W3MW8s2bz47Y/ ## Preliminaries, Chairs 14:10 – 14:20 (10 minutes) Note Well Virtual Bluesheets Jabber Scribe, Etherpad Note Takers Speaking Queue Manager (David Schinazi) Agenda Bash W3C WebTransport Update Jabber Scribe: Spencer Dawkins Note Takers: Lucas Pardue, Amelia Andersdotter and Eric Kinnear ## WebTransport Use Cases, Will Law 14:20 - 14:30 (10 minutes) ### Presentation Update on advancements in W3C, timelines, and use cases. Have gathered use cases from many different sources and pruned them. Examples: Machine Learning (translation, security camera analysis), Multiplayer gaming, low-latency streaming (unidirectional broadcast, bidirectional WebRTC-like), cloud game streaming, server-based video conferencing, remote desktop, time synchronized multimedia web comms, IoT sensor and anayltics, PubSub Models (data tickers, messages) Use cases may be candidates for QuicTransport or Http3Transport, or both Can use cases be solved sufficiently well by existing technologies, extending existing technologies? If a new technology is needed is this best handled by QuicTransport or Http3Transport? Encourage WebTransport to do a few things well rather than attempt to cover all possible things. Encourage collaboration between IETF and W3C WG ### Discussion Lucas: About collaboration between IETF and W3C, some folks are familiar with both groups but tend to stick to the IETF more than other groups. How would you recommend people first reach out? Will: Chairs will coordinate on a more formal update process so that if people miss meetings they can get updates. We can invite people to the other group's meetings, hoping for something regular and scheduled, will hammer that out with Bernard and David Lucas: It would really help if things come back to the mailing list, even if there's duplication, better to help people avoid missing things Will: Certainly, want to avoid email overload, but will also seek help from folks familiar with the IETF. Also keeping use case document open if folks have additional use cases they'd like to raise. Will share links and you can file an issue on GitHub as well. From jabber: Mirja +1 for a joint IETF/W3C meeting for this :-) wseltzer And your W3C-IETF liaisons are here to help :) ## WebTransport Overview and Requirements, Victor Vasiliev 14:30 - 14:50 (20 minutes) https://tools.ietf.org/html/draft-vvv-webtransport-overview ### Presentation Document goal is to assist coordination between IETF and W3C on design of the WebTransport API. Draft has been adopted as a WG document, please review existing issues on [GitHub repo](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues), open new ones if anything is not covered. GH issue [#1](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/1): stream IDs Developers would like to know in what order streams arrived. Stream IDs used to be in the draft but were removed due to some hard problems: proxying, and information disclosure. GH issue [#2](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/2): stream resets No consistent stream reset semantics across HTTP versions. Port H3's STOP_SENDING to H2? Or just go with H2 style? GH issue [#3](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/3): streams, messages WebTransport offers streams of bytes and messages. No capability for streams of messages, do we want to ffer this? There are TODOs in the draft: state machine description depends on #2, missing section on priorities ### Discussion Bernard: it is important to get clarity on the state machine. We used to have a state machine diagram in the API document, which we had to update as QUIC evolved. So support updating it. Note that the state machines of QuicTransport and Http3Transport are different. Victor: two machines, one for transport, one for stream. Transport machine we might wwant to extend if we get 0-RTT support. Yutaka: Regarding messages and byte streams, websocket allows infinite size messages, which prevents us from optimization. I don't want to introduce such a messaging schema. Victor: I agree, personally for #3, since none of our protocols support messaging we should just stick with streams. If applications want message delineation they can do it themselves Yutaka: Thank you Harald: Do you know what happens if we don't define messages is that we will use streams as messages. Victor: That's one of the supported ways in which you can operate QUIC Bernard: That's how WebTransport provides reliable/unordered transport. David: It's possible for the application layer to do this: question for WG? Is this a feature to build into WebTransport, or do we provide supports for streams and leave the rest as an exercise for the application? Harald: The focus on bytes is harmful because you end up retransmitting stuff as parts of messages in a way which is not optimal. Would rather have messages in the protocol itself. Erik: Having messages has more flexibility for applciations to do things. I would prefer these not to be sent in the same packet, in order to support FEC. Victor: Would Datagram satisfy that problem? Erik: I guess so Victor: When talking messages, we mean ones that are reliable and span multiple packets. If you're willing to use Datagram we can solve those problems with some text e.g. anti affinity Ben Schwartz: I wanted to point out that the WebSocket spec and protocol have things in them like binary vs text framing. So it is not just enough to create a messaging stream and call it a drop in replacement for WebSockets. Wants to remind people that the HTTP/2 WebSocket draft also naturally applies to HTTP/3, continues to provide the in order behaviour. Let's develop the cleanest protocol we can think of and rely on W3C to design an API that helps people migrate. Victor: Thanks for the reminder about text vs binary David: Browsers aren't going to drop WebSocket support anytime soon. Having people still use WebSocket is still an option Bernard: What is it important to be compatible with, the WebSockets API or the Websockets Protocol? Peter Thatcher built a shim that demonstrated the WebSockets API over WebTransport. Also, there is a new API (WebSocket Streams) that also uses the Websockets Protocol that is similar to the WebTransport API (not message based). Important to be clear what we're trying to do. Ian: Wanted to say that the idea of messages is interesting but it seems like there's a few different sets of use cases: ordering vs. head of line blocking is desired, putting a message substrate on top of a stream does provide head of line blocking but does not make it that easy to do out of order delivery because it's hard to find the boundaries of messages. Clear requirements on what we need here would be helpful. Jana: Ian said mostly what I wanted to say. Recommend very lightweight streams, could be messages, can have a "begin" and "end" bit for a stream, if you have that as part of a message it can all fit in a packet if lightweight enough. Design WT streams to be lightweight then you get flexibility. ??? will be difficult. From jabber: Magnus Westerlund too: Well SCTP is a transprot protocol that support reliable messages, both in and out of order. Philipp Tiesel: I definitely second the preference for message streams over byte streams ## WebTransport using HTTP/2, Eric Kinnear 14:50 - 15:05 (15 minutes) https://tools.ietf.org/html/draft-kinnear-webtransport-http2 https://github.com/ekinnear/draft-webtransport-http2/ ### Presentation Since IETF 107: great feedback, created some [GitHub issues](https://github.com/ekinnear/draft-webtransport-http2/issues/), updated to a 01 draft Concepts: Http2Transport provides bidirectional streams that either endpoint can initiate. QUIC can do this today. Coexistence with QUIC... H2 is missing some things that H3 has: unidirectional streams, Datagrams and especially unreliable ones. Clarify how much we care about ordering and HoL, who do we expose this to the user i.e. express this via the API Aside: Eventually need to decide if we want to spec a QUIC equivalent over TCP without HTTP/2. GH issue [#3](https://github.com/ekinnear/draft-webtransport-http2/issues/3): new streams without additional roundtrips New streams need a CONNECT, requiring one RTT. Do we need a routing stream and then stream. H2 might not be present across every hop, can we provide an equivalent for each mapping. The question is we we want to sovle this problem to open streams quickly. GH issue [#5](https://github.com/ekinnear/draft-webtransport-http2/issues/5): unidirectional streams Do we want to use half-closed streams (to align with H2's extant state machine)? Or simply prevent endpoints from sending data by layering the requirement on top in WebTransport? Establishing different types of streams requires metadata - does that impact our choices when mapping HTTP/3 vs QUIC. GH issue [#6](https://github.com/ekinnear/draft-webtransport-http2/issues/6): datgrams Reliability: Apps need to know what they requested vs what they got. Some options for this: dedicated datagram stream, new frame, WTHEADERS per datagram. Be good to think and challenge assumptions. Flow control: new frame makes it easier to reason about, interesting things can happen when reliable links drop data, outcome may lead us to somewhere that we are more comfortable making large changes to protcol. Stream IDs: Resonating with Victor's earlier points. Consistency is key. Goals probably prevent us from relying on the stream IDs from anything underneath this layer. ### Discussion Ian Swett: I think a lot of these questions are really good. How many do we need to answer in order to get a technical direction? Eric: Good question - the first half of this presentation is much of what Victor already talked about and we need to collectively decide as a group where we want to go. Many of the other things are just implementation issues, and we can only decide on those after we decide on the particular direction. The big question for today is what the layerings are that we want, and what the destination is that we're heading towards. I defer to the chairs (David and Bernard) for their thoughts on this. Bernard: Victor has a presentation later that might touch on these. Any thoughts, David? David: I would not count on the chairs - we lack the authority to decide what the priorities are, it needs to be decided through consensus. But perhaps we should focus on the presentations we have, and perhaps the opportunities for collaboration with W3C. Bernard: We may need to spend more time. Interim meetings might be needed. ## WebTransport over QUIC, Victor Vasiliev 15:05 - 15:20 (15 minutes) https://tools.ietf.org/html/draft-vvv-webtransport-quic ### Presentation QuicTransport has a URI scheme QuicTransport has an origin trial in Chrome 84-86 - https://web.dev/quictransport (QUIC draft 27, draft-29 starting Chrome 85) Great Transport Zoo: - QuicTransport - Http2Transport - Http3Transport - FallbackTransport (no draft currently) Want one QUIC-based transport so we can have unrelaible datagrams, one TCP-based transport for fallback. Decision to support QuicTransport or HttpTransport, or both? Slide 44 has Victor's intuition on which would be best for some use cases. Advantage of HTTP transport comes from multiplexing, e.g. in a browser when a connection exists in a pool reuse it rather than spin up a new independent QUIC or TCP connection. However, a dedicated connection can be beneficial so this could be controlled at the API layer. ### Discussion Ben: slide 44 shows an implication that a dedicated transport is more appropriate for use cases with tight performance requirements, at least that is my read, this is a speed thing Victor: not necessarily speed, better access to transport properties such as congestion control Bernard: some use cases are p2p, so don't apply to HTTP Ben: if performance of multiplexing is a problem, you can chose not to multiplex. But if you do multiplex, then a single congestion control algorithm can be used to manage both WebTransport and HTTP. Victor: interesting point. There is an argument that on the same connection that you can do meaningful prioritization Jonathan Lennox: for HttpTransport is it anticipated that at least the client would have to support the HTTP state machine e.g. follow a 300 redirect Victor: I'll talk about that on the next slide Ted: going back to what Ben said. I agree with him but have the opposite reaction to slide 44. When I look at HTTP and load balancing, I might have use cases where I don't want that, because the application has its own means for things such as caching. For a use case that doesn't need properties provided by the web (such as a datagram request/response protocol like what is used in games or DNS), there is a good argument for providing QuicTransport that doesn't require them to use the web. ### Presentation resumes Advantages of HTTP transports - Shared metadata, can reuse HTTP headers and status codes e.g. origin, location + 3xx status, forwarded (useful for load balancing), :path/:authority/:scheme - Counterpoint: similarity of HTTP can lead to wrong expectations. Disadvantages of HTTP transports - Requirements for HPACK and QPACK - Multiplexing and socket pools makes things hard in browsers - Need to define interaction with existing HTTP mechanisms, especially something like Alt-Svc - how to decide when to switch between HTTP transports and QuicTransports - Pooling and flow control can lead to DoS, example given related to stream concurrency - Stats are easier to define with dedicated connections Implementation experience - QuicTransport - Implemented in Chrome, various server implementations, easy to implement on an existing python library - HttpTransport - Implementations at Apple and Facebook, no in-browser clients yet Use cases - Both options satisfy WebTransport requirements: datagrams and streams - Other aspects make each individual transport a better fit - HTTP-based options help operators of large server setups - Implementers work on niche platforms where it is useful to minimise complexity and implementation requirements, so preference for QUIC-based option Beyond wire protocol - What URL scheme? Determines whether WebTransport and HTTP are same-origin - High level concerns: cookies, HTTP auth, TLS client certs, Alt-svc and socket pools Next steps - Current discussion is between two options "only QUIC", "only HTTP" - Need more input, continue discussion on list, potential focus of an interim? ### Further discussion Yutaka: I didn't mention on mailing list, I am not opposed to having both QuicTranport and HttpTransport David: interested in folks that have opinions on which protocols they want to build, so we can start making progress Phillip Tiesel: question whether the transports are end-to-end or if proxies can convert protocols Victor: possibly. Converting between H2 and H3 is straightforward. Converting H3 and QUIC is harder because we'd need to describe how to map things like metadata. If metadata is available to both, we'd need to understand why there is an advantage to defining both. Erik: it would seem preferable to avoid having all four and avoid the pressure to implement all 4. It would be easier/more flexible to use reuse headers etc so the H2/H3 model seems better. Ben's mention of a profiled HTTP seems like a option. Ben: I wonder how hard it would be to expose the WebTransport semantics in ??? raw framing Victor: it would not be that hard Ben: we should make it possible to implement as either endpoint without having to implement a full HTTP stack. For example, I could write a simple Http3Transport client that could even speak to a full HTTP server that is also an Http3Tranport. Ted: I tend to think it is entirely possible to define such a profile for a client. But I don't think there a good chance that it will *only* go into an environment that would treat it special/ any different to any other HTTP client. Build on a bare transport would avoid this. ??? middleboxes From jabber: Ben: can we profile down Http3Transport for Webtransport-only use cases e.g. minimise required methods i.e. make it possible to implement a WebTransport-only server Eik: Upside to muxing: lots of those apps (IoT/streaming/etc) also make HTTP API calls today and may continue to do so. Downside to muxing with H2/H3: some non-spec-compliant clients/servers will (continue to) make bad assumptions about multiple requests sharing a connection and having connection-associated state. ## WebTransport over HTTP/3, Victor Vasiliev 15:20 - 15:35 (15 minutes) https://tools.ietf.org/html/draft-vvv-webtransport-http3 ### Presentation Rolled into previous segment ### Discussion Rolled into previous segment ## Wrap up and Summary, Chairs & ADs 15:35 - 15:50 (15 minutes) Bernard: Please help in answering these questions by continuing discussion on the list. An interim meeting may be in order. David: Will take a lot of these questions to the list. Interim will also be discussed on the list. Thank you everyone!