# IETF 112 WEBTRANS WG Agenda Tuesday, November 9, 2021 12:00 - 14:00 UTC 04:00 - 06:00 Pacific Time Session I, Room 2 Chairs: Bernard Aboba and David Schinazi ------ IETF 112 info: https://www.ietf.org/how/meetings/112/ Meeting URL: https://wws.conf.meetecho.com/conference/?group=webtrans Etherpad: https://notes.ietf.org/s/notes-ietf-112-webtrans Slides: https://docs.google.com/presentation/d/1BfAUQui73mFhKqXY5Awv4rjBe_eLPmfgx_8zjQnPN1M/ ## Preliminaries, Chairs (10 minutes) Note Well, Jabber Scribe, Etherpad Note Takers (James Gruessing, Spencer Dawkins) Speaking Queue Manager (David Schinazi) Agenda Bash No bashing occurred. The agenda was unscathed. ## W3C WebTransport Update, Jan-Ivar Bruaroey (10 minutes) Jan-Ivar: Have published an updated working draft. * New `WebTransportError` DOMException with source and error code * Minimal prioritisation * Chrome shipping webtransport in M97 * Still needs prioritisation and stats * Multicast-for-the-web presentation, requesting multicast for consideration in WebTrans working group * Issue identified in bi-direction video conferencing, encoder and cc algorithm need to work together * Probing of network to determine bandwidth to be requested * Mirja (from Jabber): rmcat wg for real-time media congestion avoidance had draft-singh-rmcat-adaptive-fec to add fec to fill the cwnd for probing. that draft never made it to RFC because there was not enough interest but I always thought it interesting work ## WebTransport over HTTP/3, Victor Vasiliev (40 minutes) https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-02.html Victor: New draft version, 6 months of changes, including: * Clean close connection * Version negotiation Chrome 97 ships, but negotiates separate version but will be removed later ### Issue #27 - Do we need something like a GOAWAY frame to drain sessions? Alan: Value in having a GOAWAY, seems lightweight, and cheaper Martin: I'm not sure what semantics would be? Alan: A signal as intention Martin: If there's a generic signal, no need to attach Alan: Not sure if we've defined if it's okay to have unknown capsules, or do they have to go over application stream? Victor: We should not add new concepts trivial to add to the APIs we provide Alan: There may be applications that don't use a control stream Lucas: The value on GOAWAY depends on what the receiver would act upon - how is this more than HTTP/3 GOAWAY? Erik: Benefit at this layer is intermediate to send it, alternatively API exposed H2/H3 GOAWAY Alan: The intermediator use case is useful, if the intermediator wants to go away and needs to tell both endpoints Victor: Sounds like we need specific proposal with use cases, Alan would you volunteer for handling this? **Action**: Alan to write a PR, and everyone else to argue about this in the PR ### Issue #22/#36 - Pool resources Victor: Pooling resources is useful, but how do we limit resources, in an ideal scenario we would isolate connections and prevent starvation Currently no proposals, so can we start a discussion about this? Martin: We give sites `fetch` almost without constraint, but that might be the best solution for the time being and do nothing Victor: That's possible, but I'm afraid of logical indirections such as opening so many streams you can't fetch at all Martin: That's possible Spencer: Do you think laissez-faire, would be easier to add or take away later? Martin: I'd have to think about that - easy to add *something*, but not sure it could easily be made reliable if something bad DOES happen. Lucas: This seems similar to a discussion about H3 priorities, where endpoints detect the number of streams, to think about bidirection streams that all information is available to clients, and this is an API problem not protocol. I don't think there's much to do here. Yutaka: Ideally memory consumed should be a function of bandwidth, more streams shouldn't result in more memory only bytes transmitted, correct? Victor: Some extent, QUIC has a limit is shared between all Dragana: I'm afraid of different implementations having different limits, and timing dependency Victor: We should give developers some idea on what limits the browser supports - 4 streams versus 100 would make a difference on how you design the application protocol. Dragana: I wondering of different pooling behaviours, but this is a different problem Martin: Imagine the ease of exhaustion, but no guarantee of number of concurrent streams for QUIC (unlike H2). There should be a cap or minimum guarantee. Victor: We have some ideas, this should be taken to the list ### Issue #61 - Redirects Victor: Two options: either follow or not follow redirects, in W3C we agreed not to follow the redirect (to give the redirect to the application) David: I'm okay with that, no strong opinion but we should be clear Martin: I think if we're playing HTTP, we have to play by the BCP56bis rules, there are 3xxs that don't make sense for webtrans, but some that do. We shouldn't ignore all of them Mark Nottingham (in Jabber): HTTP doesn't require clients to follow redirects. It's up to them whether they do (and they often do, if they want to complete their task). Jonathan Lennox (in jabber): Returning the 3xx to the JS API and letting the JS handle it doesn't seem terrible, so long as the JS to implement standard redirect handling is simple. Victor: Redirects are something they don't build initially, and later regret Victor: We should figure out what to do based on the BCP, and if not revisit this ### Issue #63 - Request Forgery Victor: In Websocket we use masking to avoid confusion attacks on the intermediaries, do we need something similar? Martin: The impersonation is not only HTTP but any protocol, e.g. STUN, SIP. Because you have full control over the packets, you can do a lot. Harald (in Jabber): it was STUN + UDP message fragmentation Victor: Is this specific to webtrans? Why is this not a problem with `fetch`? Martin: It is a problem. Harald: The problem with masking is you can count on a middlebox doing something inappropriate if the attack can control the first bytes in a packet. If content is encrypted, or header controlled by the protocol the attack can't control it and you're safe against forgery. David: Encryption helps but not here, because it's predictable. Because we use stream-ciphers, you can influence the cipher text. How do we solve this? Maybe add a few port blocklists, punting the problem to the W3C. Victor: Port blocking will protect against NAT slip-streaming attacks and others, but not all attacks we might not be aware of. Yutaka: In seems both directions of client to server need masking? Victor: It doesn't help requiring masking on server to client, and client to server is more important Yutaka: Masking is relying on server to client is safe Victor: There's nothing we can do about it, because it can send whatever it wants David (in Jabber): Slipstream attack relies on middlebox treating client-originated traffic as trusted Harald: A server leaking keys will work against any QUIC-based protocol, and that's not this WG's problem to solve Harald (in Jabber): webrtc is using the tcp blocklist for udp as a stopgap. Victor: This is something we should punt to quic WG. Does anyone disagree? Martin: I can live with us having the discussion elsewhere Harald Alvestrand (in jabber): webrtc is using the tcp blocklist for udp as a stopgap. And webrtc (the implementation) is arbitrarily blocking all ports < 1024. Erik Nygren (in jabber): see https://github.com/whatwg/fetch/issues/1268 for a udp blocklist in Fetch. @mt raises the good point of it's unclear where the best place is to own this between ietf and w3c. ## WebTransport using HTTP/2, Eric Kinnear (40 minutes) https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-02.html Eric: New layered design, as it'll be easier to implement Instead of adding new frames to H2, we use extended connect Inside the connect we have webtrans streams and datagrams ### Issue #29 - Frame Formats Eric: Some fields are not necessary, for example in a `WT_RESET_STREAM` Final Size is not required Eric: Currently we've put length after type, but if we swap them it could be parsed by a QUIC parser after removing the length Martin: Even more clever and use the same length field for multiple frames, but this is the fallback protocol, so we shouldn't be TOO clever. Removing final size doesn't make me uncomfortable Lucas: I would go for the simple thing and not be overly clever Alan: Put the length first, but QUIC doesn't have the lengths so maybe we drop it Eric: We're headed toward a binary choice - do we make this look like QUIC, or do we care if it doesn't look like QUIC? Ian: Do we really think we need a length here? Victor: Length is fine where we're not concerned about size David: This is a fallback transport, length sounds like fewer headaches, and this is starting to look like a capsule. Why don't we just register 8 frame types as WT capsules and move on? Martin (in Jabber): "once you have a length, these are capsules" Eric: You're saying make it a capsule, register it, and keep going? David: That's what I'm saying. Alan: All capsules buy you is a parser that knows how to parse the length and hand you a blob. If we're going to do this, I'd also like a type. Martin (in Jabber): I don't think that we get any benefit from sharing code for capsule parsing. Frame decoding is not a whole lot of code. David: Given there's 6 frame types with 2-3 fields, reusing QUIC frame parser doesn't fit. When it comes to processing, it's stream and flow control. Drop trying to re-use the parser. Eric: Hearing an overall lack of concern, and it's okay if it's a little bit different. ### Issue #25 - Capsule Eric: Do we make webtrans datagram its own thing? Alan: I'm not sure of the capsule value, given the capsules are kept in a global register. If it's no big deal to copy+paste QUIC parser, then it's really no big deal to copy+paste a capsule parser David: Depends on the plan for getting across intermediates Eric: We're not talking about H1 here Eric: We have this sit until MASQUE design team on capsules concludes Alan: Intermediates are not participating, and if they are they have to parse it all anyway. ### What about streams? Eric: We try to use the existing features. HTTP/2 has native streams. Should we have HTTP/2 streams in WebTrans? We haven't seen a strong case for this. Does anyone else see one? Everybody: (crickets), so, no strong case suggested in the meeting session ### Issue #27 - Flow Control Eric: We have an issue to write up flow control behaviour, which we have 4 layers: * H2 * CONNECT * WebTransport Session * WebTransport Stream That's a lot of flow control. Eric: We're going to write up some text for visibility and avoid common pitfalls. Does anyone think this isn't workable? Everybody: (crickets), so no objections in the meeting session. ### Issue #44 - Error Handling Eric: We didn't import all of QUIC's error handling, which needs to be brought in Eric: We could bring a GOAWAY, the webtrans close capsule Eric: Do we want this to look like H3? Or H2? Alan: This may depend on capsule's direction Ian: Shouldn't we make sure they are similar? Martin: H3 webtrans has means to signal before close, let's see what Alan comes up with the GOAWAY requirements Eric: So we'll end up with whatever we do in H3 Victor: What does "WT over H3 shares error space with H3"? Eric: The error codes shared by the same registry Victor: This is for resetting the streams, the close webtrans is for the session. Does this issue cover both streams and sessions? Eric: short answer is "yes", but we haven't been super clear about that. The intent of the issue was to tear down the session, but we need the ability to tear down individual streams. Victor: I need to take a closer look at this ### Other Discussion? None ### WebTransport for HTTP/2 over HTTP/3 Eric: Using additional frames over WebTrans, not in WebTrans (please verify!) Should all the mappings of webtrans be doing the same thing? Two points of conflicts: if you have an intermediate, do we have neogitation in speaking transport protocol? Do we need to support both? **Eric hands off mike control to the chairs for this generic discussion** Martin: I think it should support operation over H3, but you must use datagrams and streams - just describe the way that streams and datagrams are lifted off to the native capabilities Victor: We should not require servers to support operation over H2 if they're only interested in H3. That's just requiring them to deploy twice the code. Alan: If they're the same protocol, but there's only a few shared things between them - you can't use H2 frames over H3 CONNECT stream, and we should make it not possible Eric: Martin's proposal is attractive, Alan says there's not 100% overlap because H2 adopts native H3 things Victor: The overview draft provides a model of interaction based on QUIC, and webtrans over h2/h3 are an implementation of that model. The fundamental abstraction is streams and datagrams. Alan: If you couldn't speak WebTrans H2 over H3, this is interacting with an intermediate that can't translate, Victor: (???) Alan (in Jabber): +1 - make the proxies do this. They already advertised the H2 SETTING. Alan: The stream limits can be different, this isn't only a HTTP version problem, which might be more hairy ## Hums, Wrap up and Summary, Chairs & ADs (20 minutes) Bernard: WebTransport is now available in Chrome, with the APIs available so it's no longer an academic exercise David: see you on the mailing list, and in March, if we don't have an interim before then!