WEBTRANS WG @ IETF 107 Virtual Meeting - 27 March 2020 22:10 - 0:10 WebEx: https://ietf.webex.com/ietf/j.php?MTID=m730d59fbafc6d18db1f05b3d9b759a18 Mailing list: webtransport@ietf.org Jabber Chat: xmpp:webtrans@jabber.ietf.org?join Chairs: Bernard Aboba, David Schinazi Notetakers: Bron Gondwana, Peter Wu Slide turner: Bernard Aboba Jabber Scribe: Lucas Pardue Queue Manager: David Schinazi ********************************************************************** Agenda IETF 107 WEBTRANS ********************************************************************** ### Preliminaries and Agenda Bash - Chairs (20 min) W3C WebTransport update - Dominique Hazael-Massieux * Started the process of creating a formal working group https://github.com/w3c/webtransport-charter * Takes some time to get charter developed and accepted - will be a few weeks. * You're all welcome to go to the repo and file issues. ### WebTransport Overview and Requirements - Victor Vasiliev (20 min) [WebTransport-Overview](https://tools.ietf.org/html/draft-vvv-webtransport-overview) Martin Thomson: * There's a few things we've had on our plate for a while. Want to talk about multiplexing - do you want to talk about that now. * Martin: Multiplexing of the transport to multiple origins? * Victor: up to applications. * Martin: need to be careful about the choices that endpoints make and the signalling they use to make sure the transport is properly used. * Victor: question is whether we address it in API docuemnts or protocol documents. * Martin: this is an API question * Martin via Jabber: I also support adoption. The requirements parts are mostly solid. I have concerns about the composition of transports in the overview piece. Mark Nottingham: * Support adoption of this document. * Mark: There is no HTTP/1.1 transport. What is the fallback if the hops do not support the transport? * Victor: it has to support h2 or h3 on each hop. * Bernard: do you have an opinion on H1? * Mark: fail hard is acceptable, better than weird corner cases. * Bernard: API currently does not describe well what happens on failure. * Martin: what about websockets? * Victor: not directly mappable to websockets, but they can be simulated. * Martin: do not call it "Transport sessions", it is confusing. Use "WebSockets 2.0" or soemthing. ekr via jabber: support adoption of the draft Lucas Pardue: * Q: is this purely a requirement to fulfil the SHOULD of quick. Do you want to prioritize datagrams against streams? * Victor: discuss for DATAGRAM draft, or in the API draft when discussing priorities. * Bernard: API docs does not discuss priorities. * Victor: it should at some point * Victor: Github for API document has at least 4 open issues on this topic. Harald Alvestrand: * Q: stream identifier - from high level overview, then 64 bit stream IDs. Where are IDs allocated from? * Bernard: do you have an opinion? * Herald: no, streams should be identifiable by ID, or not. And in the latter case, you have to build it yourself as an application. * Victor: we cannot use ID with HTTP transport, it exposes details from transport to app. * Harald: confusion about "priority" about local node should do and what the network should do. Mistake from WebRTC experience. Currently priorities cannot be tested in WebRTC. ### WebTransport using HTTP/2 - Eric Kinnear (15 min) [HTTP2-Transport](https://tools.ietf.org/html/draft-kinnear-webtransport-http2) Mark Nottingham: * Q: Connect Stream - can understand if connecting to a proxy, but if just connecting to a server, what utility does it have? * Eric: Significantly reduced utility! Can do what you want so long as you're happy with the client receiving it out of the blue from the server. * Martin via Jabber: you don't get return routing affinity with a pinhole driven by the client (what Eric is saying, I guess) * Victor Vasiliev: with routing stream, route is always attached. There is no information in WT header. Even direct client-server connection, want to make sure all streams that servers open to client go to same tab / JS listener. Martin Thomson: * Thanks for walking through, this helped undersatnd the draft. * Unsure how this meets the requirements that were laid out. unidirectional vs bidirectional? * Eric: not covered in the text, but we have to. Depends on the underlying transports that WebTransport map to. Depending on the underlying transport, some features may be lost. The user has to be able to express requirement vs optional (nice to have, but if not available, fallback). For both uni and bidi streams, use bidi stream, and close the other direction. * Martin: from draft it looks like you use same ID as in HTTP2. Is the ID mapping compatible with datagram, it affects priorities and such? * Eric: Good question, need to put in its own number space or [..] * Martin: the header block per item complexifies things a lot, do we need it? * Eric: we can look into it * Alan Frind: If you envision them as a datagram then they don't make sense, but if you see them as streams too, you can send structured metadata. * Martin: this is a failing of HTTP/2 design, it mixes the layers. Should continue this conversation elsewhere. * Victor Vasiliev: ability to use unified metadata format is appealing, but also not entirely clear if we should make headers part of the model or not. Ben Schwartz: * Comment opposed to Mark: WebTransport is identified by a path that can be secret. Except for SETTINGS frame which has to happen before authentication. For Connect Stream, the client has to advertise it and the server confirms it via SETTINGS frame. Think about whether settings frame leaks information about the server configuration which the client shouldn't know. * Eric: acknowledges it. Number of roundtrips are also to be considered for negotiation. Lucas Pardue: * What do you care about in the WTHEADERS frame with the Connect Stream ID. Is it possible to include this field in as pseudo-header in a normal HEADERS frame? Doesn't like this frame, are there different ways to solve this problem? * Eric: would be great to have this design conversation. Let's talk about it. Jonathan Lennox: * It has its own identifier different from connect stream frame. Why? * Eric: [..] * Jonathan: for datagram you want the frame to be small as possible. * Eric: it is not the intention to use a WTHEADERS per datagram, to be determined later with care. Harald Alvestrand: * Q: where is the origin carried? And is it associated with the stream or with the connection? * Eric: believe it is associated with the connect stream * Victor: it's a header on the connect stream. Follows CORS. ### WebTransport over QUIC - Victor Vasiliev (15 min) [QuicTransport](https://tools.ietf.org/html/draft-vvv-webtransport-quic) Mark Nottingham: * Regarding the fallback transport in the "Other considerations" slide, I don't think it is needed. Most of the time there is a TLS-protected transport. Fallback is only necessary for widespread WebSocket impl on server side. Does not see a need for it. * Even though it is related to HTTP, it is not necessarily for free. * Victor: believes it is still a lot of work, but compared to WebSocket frameworks it is reasonable. * Mark: so because WebSockets is already there, WebTransport is easier? Martin Thomson: * Don't think we need 4 protocols. We could get away with one from each column. Would think hard about distinction between dedicated and pooled. Complexity of pooled options is significant. Don't think benefits will acrue to pooled that much. People will put websocket endpoints with different names on different infrastructure. * Would argue more towards dedicated things with fallback transport being just websockets. Eric Rescorla: * Concur with Martin - we don't need 4, fewer the better! * We should define the ones that get the job done minimally first, if we need more - add more! * Intuition is opposite of MT: H3 and H2, but could maybe be persuaded otherwise * This isn't a good forum for figuring out which one to adopt, so adopt none now and figure out which ones we want! Tommy Pauly: * Agree with EKR. Lower-level layers (QuicTransport, FallbackTransport) [<-- is this true? or did he mean h2/h3? pls fix] indeed seem simpler. * Argument to bump up a layer, combine solution with other things (MASQUE) * Would rather see more unified solutions. * Victor: if we go with pooled options it's appealing to see if MASQUE can be layered. Lucas Pardue: * Wondering if document is in scope for WEBTRANS or if another home is better. * David (chair): feels like HTTP might be right home - mnot? * Mark: there's an expectation that it'll come to HTTPBIS - we've been talking about it, but it hasn't come up yet. * David: happy to bring it to httpbis if there is an interim soon. Jonathan Lennox: * RIPT? wants to send media and signalling simultaneously. * Victor: with HTTP transport, you can always set headers on the Connect stream. Convenient for Offer/Answer model. Victor: * we have time - questions? * Q to audience: we have no consensus so far, what is the best way forward to make a decision? * Martin: would like to see more discussion about pros and cons on the mailing list and what people think would be deployable in their infrastructure. * Eric Rescorla: agree with Martin. We now have 3 different attempts to layer crud on QUIC! MASQUE, RIPT, this all be different is suboptimal. Cullen Jennings: * This has been asked for for a few years, but the QUIC WG was not ready yet. There seem to be more commonalities than differences. * David: DATAGRAM has been adopted by QUIC WG. DATAGRAM in HTTP/3 not yet, but conversations will happen soon. Victor: * QuicTransport as described in the draft is simple and implemented in Chrome. Works and behind a flag. If there is interest, please provide specific feedback (reach out directly). Especially performance and requirements. * Eventually it will go in a Origin trial, so it might not be shipped broadly. So no four transports. ### WebTransport over HTTP/3 - Victor Vasiliev (15 min) [HTTP3-Transport](https://tools.ietf.org/html/draft-vvv-webtransport-http3) (covered in previous session on QUIC) ### Wrap up and Summary - Chairs and ADs (10 min) Bernard about next steps / action items: * No call of adoption for the overview, will be taken to the mailing list. * Performance requirements, size of headers, datagram, latency, etc. To be discussed. * Get Github repo in order David: overview document call for adoption can be expected on the list, it is a milestone. Bernard: we need a repo for issues on the document. Bernard: the list of requirements for datagrams, http/3 is needed. Discussion from httpbis might help. Bernard: RIPT folks, please provide feedback and missing requirements. [paraphrased:] Requirements, requirements, requirements! Martin Thomson: * We have a clarity on functional requirements (sending streams, datagrams, etc.). We need more clarity on existing HTTP infrastructure. This will provide feedback to the pooled/dedicated [..]. Requirements there are lacking. Mo Zanaty: * Don't hold your breath for feedback. Need to work out requirements for RIPT core before we can work on the transport bindings. Victor: * am going to try to clarify requirements and use cases that I've heard from different people who want different people. There are tradeoffs in complexity and infrastructure. * Motivation: reached out to people developing games for the web. Interested in RTCDatachannels? Feedback was that it was too hard. * People interested in using this for load balancing. Facebook have deployed h2 transport and have experience with how it works. * Will summarise to the mailing list. THANKS EVERYONE