WEBTRANS WG Virtual Interim Meeting Agenda Thursday, May 20, 2021 09:30 - 11:00 AM Pacific Time Google Meet URL: https://meet.google.com/eur-udvp-bsn Sides: https://docs.google.com/presentation/d/1FtDsHKC5gCZPUjDbLX2dDsj5syGwlVu5zW_u1jsLbFk/ CodiMD (Meeting Minutes & Virtual Bluesheets): https://codimd.ietf.org/notes-ietf-interim-2021-webtrans-02-webtrans Chairs: Bernard Aboba and David Schinazi 9:30 AM Preliminaries, Chairs (15 minutes) Note Well Virtual Bluesheets Jabber Scribe, Etherpad Note Takers Speaking Queue Manager (David Schinazi) Agenda Bash W3C WebTransport Update, Will Law Will: We’ve now progressed our public draft as of May 4 to be the first official WG draft status. This kicks off an IPR process on the W3C side, moving down the road to a published spec, likely within the time window we anticipated. Some questions on the W3C side, issues listed on the slide. Connection throttling to avoid DDoS. Should there be language that we mandate some mechanism to introduce limits? Some clarification on stats. Some language that all protocols should provide client with available bandwidth estimates. Does this apply to pooled clients? Will RTT be available? Issue raised by Lucas around WebTransport and Alt-Svc. W3C issue and was requested to return to IETF, opened #47 on IETF GitHub. Google is signalling intent to ship WebTransport in Chrome, very exciting. 9:45 AM WebTransport over HTTP/3, Victor Vasiliev (30 minutes) https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3 Victor: We just published -01 for WebTransport over HTTP/3 this week, reflects consensus at the March IETF 110. Two biggest changes, whenever we receive a WebTransport data stream before we get a connect stream, we are allowed and recommended to buffer it for some period of time. This allows both client and server to send those streams in parallel to the connect stream. Second, we defined server-initiated bidi streams to match the ones from the client side, so the design is the same in both directions now. Had some other editorial fixes too. This draft is exciting because I’ve implemented it, shipping Chrome Origin Trial in the next few weeks, currently in beta. Mostly ships draft-01, some things are somewhat undefined like error codes and other details around error handling. Ships dedicated HTTP/3 connections, no pooling support, every WebTransport object results in a connection. Datagrams are specifically implemented with the H3 datagrams as they were in January, those are the ones with the idea of an associated stream but without any context. Flow ID combined with Datagram Flow ID header where that is an integer. We are waiting for H3 datagram draft to stabilize so we can upgrade to a new version, expecting that to happen mid-trial, we will ship the new version and un-ship the old before the trial is over. If the trial is successful, we expect to actually ship this as API pending discussion in W3C, this doesn’t mean all that much within the IETF because we shipped QUIC 6 or more years before it was done, we can upgrade protocols. Notably, this will still commit us to some level of semantics, for example it will have to have bidirectional streams. If we ship them, we can’t really unship them. This means that we’ll need to do more work on the overview draft, but I don’t have slides for it and I don’t think there’s anything interesting to discuss, just needs to reflect reality. Issues Issue 39 Victor: If we want to use settings for versioning, then we need to wait so we know what version to use. Proposing that we should wait for settings, I don’t see how we can get out of it. Alan Frindell: It’s annoying to wait for settings and have to buffer things. I guess we already have to buffer things for streams, it’s annoying, but I agree we’ll lose the ability to version if we don’t. Victor: Fwiw, I just buffer all streams and don’t read anything until we get settings in the implementation. I know Ian was really unhappy about that. Alan: You can also cheat until Version 2 comes out. Victor: Good point. Jonathan Lennox: Do you anticipate having some limits on buffering to avoid DDos? Victor: We will need some text, we don’t have any right now, we picked some values in the implementation because you definitely need something. Lucas Pardue: I may be missing something, what the server receives should be compliant with what it sent. If it sent something declaring what it needed, why would it wait to process the request. Victor: There are two aspects, imagine I support two versions, v1, v2, I only advertise both but the client only supports v1, then my processing might differ based on which version we use. Lucas: Could we just put the version in the protocol string so that we don’t have to deal with it. Victor: In theory, yes, but I already have one issue which would require a breaking change. Lucas: I think I need to think some more, how would a client know what version to send stuff with. Victor: You have versions supported and you take the max of both. David: So from the client perspective, I think the client can’t send the connect request until it has received and parsed the server settings, you just wait and don’t need to buffer. On the server side it’s harder to handle because you have to buffer. Lucas’s proposal, which Marten Seemann is supporting in the chat, would solve that right? Victor: Yes, but you need to put the version of HTTP/3 datagram in there as well. David: Oh, I see, yeah we really didn’t get that part of HTTP/3 right. Victor: If you think ALPS is real and will happen, then ALPS guarantees you’ll have it up front and it’s all good. I’m not sure how much buffering is a problem in practice. I know Ian said he had concerns, not only from a performance perspective, but also from the perspective to get this wrong. I don’t believe it is likely, because eventually flow control will kick in, and if you’re not reading from the streams before you get settings there’s not much you can do. It sounds like we’re in agreement that we have to buffer it for now. Any objections? Issue 40 Victor: This is for resetting data streams, not connect streams. We discussed this at the last interim, then at W3C, where we agreed that 256 error codes should be roughly enough. There should be a more detailed description of what was agreed in the minutes. We changed the API to accept UInt8 as a reason code. We wanted it to be as widely compatible as possible and HTTP/2 reason code error space is fairly small, we cannot take the entire space because then untrusted JS can send semantically meaningful reset stream codes. We can reserve some small sub-space and say those are all WebTransport reset stream codes. There is a small problem with HTTP/3 in which it does not have any contiguous error code spaces since we reserved all 0x1f codepoints for grease, we’ll have to un-grease and re-grease unless someone has a better proposal. Mike Bishop: Just pointing out that there’s a draft to grease in HTTP/2 as well, so you’re likely to hit the same issue there. I don’t have a great answer than working around it or pre-reserving the ones that overlap your code space. David: Just reiterating something I said at W3C, having an encoding that maps around them, if you have some grease points in the middle, just having the range not be contiguous isn’t super elegant but it’s an easy way to work around this, I’d suggest doing that and moving on. Victor: It sounds like we have agreement to just do that and move on, unless anyone objects I will reflect that in the draft. Issue 41 Victor: Previously we were looking at individual stream error codes, this is for sessions. The goal is to provide a mechanism that is similar in utility to what Connection Close does in QUIC. Code and string both, string has been super useful for debugging production issues. Multiple ideas for how to implement this, option 1 is to just use RST_STREAM. This has a problem where you can’t embed the code numbers, and those are not end-to-end and there is nothing in HTTP/3 that guarantees propagation across intermediaries. There is no error message and no error code, so RST_STREAM doesn’t really work. Alternatives, HTTP trailers, would need a field for code and string, works across intermediaries. Issues there, one of which is that trailers aren’t defined in CONNECT and we’d need to define for Extended CONNECT. Third alternative, not in the slides, current version of H3 datagram draft defines a “capsule” and we might want to do that. The reason I’d lean towards something like that as a more flexible option is that we already need some form of control metadata for something like session go away. That would be the option that I would be leaning most towards right now. Lucas: I think the capsule option sounds okay, I appreciate it’s fresh and I’d like to see some proposal there, but I can imagine it in my head. That seems better than defining yet another extension frame specific for this purpose. Alan: Follow up to Lucas - assuming that capsule is going to be a thing, how does one decide when to add an extension frame versus using something inside a capsule. What’s the guidance there? Victor: Capsule is end-to-end and extension frames are default hop-by-hop unless defined otherwise. David: Exactly that, whole reason for existing is that intermediaries forward them end to end along the same path, HTTP/3 extension frames are always hop-by-hop unless you want to specifically add semantics. Seems like capsules are extensible enough to just use them for everything. Alan: I think that works better for this use case of an error code and a reason. But the stream IDs are hop-by-hop, so something like GOAWAY can’t be in a capsule because intermediaries might need to rewrite stream IDs. David: If you have end to end stream ID space then you’re good, but you’re right that you can’t use the hop by hop stream IDs in a capsule. Victor: It sounds like we have general agreement to use capsule if it becomes a real thing, we’ll need to see what will happen at the next masque meeting. Lucas: New capsule background appears Issue 42 Victor: Spec requires 200, CONNECT is any 2xx. Proposal is to switch WebTransport to also do that to be consistent with how CONNECT is defined. silence Victor: Sounds like no opinions or objections, sounds like we have consensus for issue 42. Issue 47 Victor: How does Alt-Svc interact with WebTransport? Makes sense to assume that server implements HTTP/3 from scratch so doing TCP and then doing HTTP/3 on the second attempt doesn’t make sense. Does Alt-Svc have a place, does it affect pooled vs. dedicated connections. Lucas filed the issue, any comments? Lucas: As some background, it came into my head during the Singapore (BoF?), raised in W3C at the time because that was the only place and moved to IETF since it seems like an IETF thing, but I think some of it has been answered by our choice to pick HTTP/3 transport. An issue more for pooling and coalescing, maybe we should keep it around as we get some more deployment experience. The example for URL in WebTransport to open the thing, that implies that you know it’ll do HTTP/3 – you don’t need to fall back to Alt-Svc or anything like that. David: I think this ties into a few other conversations that we need to have, some of which are on the agenda for later in this meeting. Do we want to run a version of WebTransport over TCP. Perhaps we keep this open until we have more clarity on those. In a world where you can do both HTTP/3 and HTTP/2, if the JS has a way to say “no I want H3” then you can just assume if you haven’t seen Alt-Svc. Then we can decide if we want to mandate something or give clients/browsers some more leeway. Victor: Agree with David, let’s hold for later. Issue 48 Victor: Alan do you want to explain your proposal? Alan: Yeah. Current unidirectional streaming works where you send the type that indicates it will be WT uni stream, that defines the contents of the stream from then on, there’s a varint session ID and as soon as you parse that it converts to unframed. I found this cumbersome to implement since it’s different from other streams since they all have at least one frame on them (except maybe qpack), you can do something that defines a single frame and then you define it as a TV frame. Adds one more byte, you have stream type, then frame type, then maybe converts to unframed. Victor: Seems clear, no objection but we need to decide what to call that stream type, do we just call it WT uni stream? Alan: Yeah I guess it’s redundant, this came out as part of the discussion that a stream type followed by frames allows us to insert other frames in between the two at some point in the future. Victor: Priority could be one of those, I could imagine. Alan: Could be a sensitive topic for some people but yeah, something like that. Victor: Any objections? None, okay we have consensus to change it. Questions David: Before we move on, I was going to ask if anyone has questions for Victor? Alan: Looked in the repo, there are a bunch more issues that we didn’t discuss. What’s the plan? Victor: The reason I didn’t put most of those is: (1) there were a bunch that are editorial, (2) some of them looked like we discussed last time but no new proposals, nothing to do to move forwards, and (3) I forgot Lucas: As a co-author on H3 datagram, I’m keen to play with prototype of that, I did some work to see how hard it would be, but I have no interest in supporting old and new at the same time. It makes some of that a bit tricky, what’s the timeline on moving to the new H3 datagram. No answer is fine, but something for the next IETF, I’d like to understand what the roadmap would be. Victor: Personal intuition, we want to wait for the draft to stabilize a bit, I don’t want to implement old, new, and the final datagram and ship them all as an experiemnt. Most likely, I hope we’ll reach some form of consensus in the upcoming masque meeting, after which we can likely implement and ship in the Origin trial. David: I’d say we could move more quickly, latest version of H3 datagram has capsules and changes settings, those are the main changes, I’d say you could start relying on that in WebTransport from now on. Something something masque enthusiasm. Hoping to publish something that we can get more experince with it. Want to avoid pain. 10:15 AM WebTransport using HTTP/2, Eric Kinnear (20 minutes) https://datatracker.ietf.org/doc/html/draft-kinnear-webtransport-http2 Eric: Continuation of conversation at IETF 110. WebTransport over HTTP/2 is a protcol for times when HTTP/3 is not available; as mentioned at 110, Chrome sees QUIC unavailable in over 5% of cases. Agreed at the last meeting that we should have a fallback. Our choices: failure, bring-your-own-fallback, WebTransport over HTTP/2. HTTP/2 does not preclude you from bringing your own fallback. Overview draft has a list of things that you are required to have, as well as allowing you to require or prohibit specific features. We looked through the draft, and we can provide all of the mandatory requirements over HTTP/2. We may not always provide all optional features; e.g. datagrams are provided, but are not always unreliable. Works fine by default, but in latency-sensitive or bring-your-own-fallback cases, user can fail instead of getting HTTP/2. [three principles from the slides explained here] Questions Lucas: not a question, observation. Someone who supports both HTTP/3 and HTTP/2, extending HTTP/2 is harder than HTTP/3 because of technical assumptions and it would take a lot of effort to fit it into existing ecosystem. Eric: this makes a lot of sense. We tried to put in new frames that are as self-contained as possible. Dragana: how do you define fallback in terms of the API, and how do you define datagrams? Eric: we’re still figuring this out. One of the options is to let application wait until ready state and then check a property on the object. Jonathan: looking at the layering, in HTTP/3, we have datagram draft, and then there’s WebTransport. Is this an issue for consumers who don’t support QUIC? Eric: one of the issues we discussed before in httpbis, what do we do when datagrams or other HTTP/3-only features? We don’t intend to answer that in general. David: as a co-author of HTTP datagram draft, we intend to extend it from HTTP/3 to other HTTP versions. Bernard: as a follow-up, the API issue here is secondary to decision to ship HTTP/2 or not. Victor: the amount of cases where QUIC is blocked is very context-specific, for example in enterprise it is much higher Eric: this means that for a given user, they might be always blocked as opposed to everyone blocked some of the time Bernard: if you have the wrong firewall you can't use QUIC Lucas: in response to my earlier point, using capsule will make WebTransport over h2 easier to implement. Also, firewalls are hard to deal with so when they are present a fallback is necessary. Alan: two parts. One, David says capsule is coming to H2 as an extension frame. David: yes, I’ve not written this up or discussed in MASQUE, but it’s the easiest approach. Another aspect is that there’s a datagram capsule to send datagrams on stream data, which would allow you to send datagrams over H2. Alan: WebTransport over HTTP/2 is very flexible in terms of specific details, we just want it to exist. Another point is that there are non-Web use cases (like DC) where TCP is used over QUIC. Eric: to that point, if capsule is coming to HTTP/2, using it as a point for WebTransport makes sense. Jan-Ivar: as a clarification, at W3C we were discussing an attribute, we weren’t contemplating constructor arguments. Is the assumption that server always speaks H3, and only middleboxes block it? Eric: I think we don’t want to preclude H2-only connections. Victor: We were able to update some HTTP/2 implementation with some extensions as long as it uses SETTINGS, wasn’t that big of a deal. Lucas: I hit a separate issue with a broken HTTP/2 implementation the other day and it was a pain there, especially because I don’t own that stack. 10:35 AM Hums, Wrap up and Summary, Chairs & ADs (25 minutes) David: Based on this great discussion, there is interest in WebTransport over TCP so we're going to ask some hums to get a sense of the room. We'll confirm consensus on list. Question 0: Which of these two flavors of ice cream do you prefer? 0A: Vanilla - 7 0B: Chocolate - 7 Question 1: Do you believe that the WebTransport WG should start work on a version of WebTransport that runs over TCP? 1A: Yes, we should build this - 10 1B: No, we should not build this - 0 Question 2: Do you believe that the version of WebTransport over TCP should be over HTTP/2? 2A: Yes, use HTTP/2 - 9 2B: No, build a custom protocol over TLS/TCP - 2 Chairs asked people who responded 2B to discuss why they preferred this option and no one said anything. Question 3: Do you believe that the WebTransport WG should adopt draft-kinnear-webtransport-http2? 3A: Yes, adopt - 8 3B: No, do not adopt - 0 Closing comments David, Bernard: Will follow up on the list to confirm consensus. Encourage folks to go to GitHub and comment on the issues.