Minutes IETF113: webtrans
minutes-113-webtrans-00
Meeting Minutes | WebTransport (webtrans) WG | |
---|---|---|
Date and time | 2022-03-24 13:30 | |
Title | Minutes IETF113: webtrans | |
State | Active | |
Other versions | plain text | |
Last updated | 2022-03-29 |
minutes-113-webtrans-00
IETF 113 WEBTRANS WG Agenda Thursday, March 24, 2002 Session II, Grand Klimt Hall 2 13:30 - 15:30 UTC 09:30 - 11:30 US/Eastern Time Chairs: Bernard Aboba and David Schinazi ------ IETF 113 info: https://www.ietf.org/how/meetings/113/ Meeting URL: https://wws.conf.meetecho.com/conference/?group=webtrans Notes: https://notes.ietf.org/notes-ietf113-webtrans Slides: https://docs.google.com/presentation/d/1ZnQJSJEwCtqg6JP-Rdd31BF06YbWpS-g9yQFzHgMPBI/ 1. Preliminaries, Chairs (10 minutes) Note Well, Jabber Scribe, Note Takers (Marten & Bernard) Speaking Queue Manager Agenda Bash 2. W3C WebTransport Update, Will Law (5 minutes) Will: Good morning from California! Progress since Nov. 9: Now a Working Draft (latest is March 11, 2022) Main blocker: Need two independent implementations. Chrome has been in production since M97, but Firefox not ready yet. So July 31, 2022 seems optimistic for PR. Martin Thomson said in chat: “you aren’t going to get anything better from us on dates, sorry I think that we just got writable streams finalized, so we’re in a reasonable shape, but a small team with shifting priorities makes it hard to commit to a date” Progress on stats. Work in progress on fallback, datagram priority, CSP. In debate: stream stats, connection pooling, priority between streams Marten: Do you need two implementations of every feature? Will: No. Basic functionality is sufficient. Chrome has already shipped without full feature set support. Alan: With respect to priority, like HTTP scheme. Finding a way to adapt that would be good. Would we add signaling to the wire protocol, so browser could set priority on streams server is sending? Or only allow browser to set priority on streams it is sending? Victor: ? Martin: Agree with Victor. Application can do signaling over Webtransport. Extensible prioritization scheme scares me. ?? 3. WebTransport over HTTP/3, Victor Vasiliev (45 minutes) https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3 Victor: I am editor of overview and HTTP/3 draft (implemented in Chromium, interops with non-Google servers). Still lots of unresolved issue, esp. in overview draft. Wrote up a PR to add discussion of HTTP/3 and HTTP/2 in the overview draft. Encourage everyone to take a look at the PR. Some unresolved issues: do we need a draining mechanism for sessions? Reason why this is needed in protocol vs. application: the GOAWAY can be sent by endpoints *and* by intermediates / proxies. Proposal: add Capsule that can be inserted by everyone. Action item: Alan to do a PR. Issue 67: in HTTP GOAWAY means that old requests can finish, but no new requests. For WebTransport currently not defined. Does this only mean that no new WebTransport sessions should be created, or should new streams be forbidden as well. Alan: in HTTP/2 streams are not visible to the transport layer, so a GOAWAY would have no semantics. Therefore: no new sessions, but new streams on existing sessions are fine. Victor: Agreed. Issue 33: Current behavior: when CONNECT stream closes, everything in the session is closed, datagrams rejected etc. Alan suggested that we might want to keep internal streams open. With more impl. experience: closing everything is easier with respect to resource management / lifecycle. Also this mirrors more closely what would happen on HTTP/2. Eric: Agrees. This is kind of an implicit GOAWAY. Better to keep the control stream around, because how else would you send control messages. Magnus: ? Victor: Closing in any direction kills the session. Similar to CONNECTION_CLOSE in QUIC. Magnus: This depends on what the application protocol needs. Victor: Higher level application doesn't need to necessarily care if it's a pooled connection. Just one session disappeared. mt: In HTTP/2 closing the request stream prevents you from sending (and receiving (?)) any data. So everything is effectively orphaned at that point. David: speaks as MASQUE enthusiast. When the CONNECT stream is closed, you can't send any more datagrams. So closing should mean that you're done. Victor: We all agree that closing the request stream closes the session. Magnus: If you send all the data and then you hit close, is there the risk that the close arrives before the data. David: CLOSE_SESSION capsule is what you'd do. ? Victor: 3 ways: sending CLOSE_SESSION Capsule with status code. You can close the stream, and you can reset the stream. In QUIC, when you close the data, you don't care about the connection any more (other than retransmitting the CONNECTION_CLOSE). Next Issue: Issue 47 Alt-Svc. Currently WebTransport doesn't do anything with alt-svc header. There are 2 modes in which WebTransport can operate. It can operate in pooled mode or with a dedicated connection. We have to do it (?) for both. Does this even belong in the IETF draft, or W3C? mt: Easy part is alt-svc in your response. ???? There's something going on in the HTTP WG, let them sort it out. Victor: So let's just close this issue. mt: Agreed. Eric: Pooling: More than one WebTransport Session per HTTP/3 connection. Not an issue in H2, as each session is fully encapsulated in one connect stream. In H3, WebTransport should also coexist with regular H3 requests. There are different native H3 streams serving different purposes for this WebTransport session. Multiple sessions will use multiple streams. Proposal to provide resource limits, and don't do anything else. Proposal: we need to keep any WebTransport session to starve others from resources. Be careful not to preclude any future improvements to this. Resource limits: flow control inherited from QUIC. Remaining: maximum number of sessions, number of streams per session. Currently: we don't provide any limit on the number of WebTransport sessions. 2 ways to do this: HTTP_REQUEST_REJECTED or 429. We could say that this is sufficient, or we could take it further with little added complexity. Proposal: replace SETTINGS_ENABLE_WEBTRANSPORT with SETTINGS_WEBTRANSPORT_MAX_SESSIONS. 1 = no pooling, >1 = more sessions allowed Flow control details: limit total session count (as talked about), limit number of streams within the session, session-level flow control, stream-level flow control In QUIC we have MAX_* frames for that. WebTransport uses native QUIC streams, so we don't need to do anything for stream flow control. Total session count is solved with SETTINGS_WEBTRANSPORT_MAX_SESSIONS. So we only need to deal with streams within a session, and session flow control. WT_MAX_STREAMS and WT_MAX_DATA capsules could solve this. In H2 there's a proposal to do the same. Marten: Having connection level control on the WebTransport level seems like a layer violation. But maybe QUIC is all about layer violations... Eric: Have an aversion to keeping track of data you're allowed to send within a WebTransport session. David: Can you clarify? This can be done all at the WebTransport layer without reaching down into QUIC, right? Marten: You can read the data out of the stream and have all buffers at the WebTransport layer. But what if there are missing packets on the stream? David: my undersrtanding was that this was a completely separate flow control. Martin: Marten is right. Difficult to do this without major architectural contorsions. QUIC level flow control acting on the bytes, having a limit on the number of streams for WebTransport is useful. Would be useful to stop WebTransport from starving out all the other things. Eric: On slide 30, first two items make sense (limit session count, limit streams within a session), can punt the last one (limit session data, just use QUIC flow control). The one above it (limit total data) is very painful. Marten: MAX_STREAMS might also be difficult. mt: We can just provide the total number of streams. But we have to be careful with the accounting. Alan: let's separate out MAX_DATA. Cannibalizing by one session would be bad. But maybe it's too complicated and not worth implementing. Let's looks at streams for now. David as chair: limiting the total session count. There is consensus for that. Limiting MAX_STREAMS might be hard, but let's write a PR and see how it goes. Limiting MAX_DATA is probably too hard. Let's close the issue, and if someone has a design implemented, we can reopen the issue. Alan: not sure that it's possible to solve, but the group should spend more time exploring. Let's keep issues open till they're resolved. 4. WebTransport using HTTP/2, Eric Kinnear (45 minutes) https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2 Need to decide what to do with capsules. Need to discuss Martin's issue first (#38). It would be bad to send ??? frames, as it would cost one round-trip. Proposal: Allow sending any frames allowed by flow control. Datagram design time is complete. Previously we defined TLVs for every WT frame. Now with capsule we can register them in a different registry where we register capsules. What do we get from capsules. > bunch of capsules < There's a DATAGRAM capsule, so we don't need a WT_DATAGRAM. HTTP/3 can reuse the WT_MAX_STREAMS (+ BLOCKED). Reuse is good, shared registry, all good. Is the end-to-end-ianness a problem? Intermediary might allow WebTransport/H2 for clients in UDP-blackholed networks, but might want to speak WebTransport/H3 all the time. What is the expectation if the Capsules don't have large overlap? Does *every* endpoint now need to support the H2 capsules? Alan: Datagram capsules is end-to-end as a concept, but not on the wire. Will be converted by intermediaries to DATAGRAM frames. WT_RESET_STREAM and WT_STOP_SENDING can be translated to QUIC frames. Flow control is hop-by-hop. mt: ??? Right answer might be to not do any of that because it's too hard. Eric: As Alan pointed out, there is a way. Each capsule type can define the translation. But not sure if that gets us where we want. David: Agree with mt. Depending how you look at it everything looks different. Is WebTransport/H3 the same protocol as WebTransport/H2. By protocol I mean upgrade token. Let's say scneario with 2 H2 hops and an intermediary in the middle. All that the intermediary does is shove bytes between streams. But with H2 and H3 conceptually you don't have an intermediary any more. You have a server that terminates the one connection and establishes a new connection. This feels consistent. Should they have different upgrade tokens? Maybe yes. mt: What happens if the intermediary accepts a stream, but can't open the stream on the other end? What is it supposed to do now? I don't know. David: 50 shades of backpressure. If you have an intermediary, you have that problem, no matter what. mt: If it stays in the stream then no problem. If not, then yes. If it's just tunneling the byte stream back and forth everything is end-to-end. Protocol translation is where things get funny. David: use case for capsules mt: but they don't buy us any thing except for a lot of redundant length fields. Alan: Looks similar to the PUSH problem. Intermediary might also not any stream credit. Going between protocols is where problems occur. Lucas: Stream impedance already exists today. We could solve this with contexts (?). We could solve this with capsules. I don't see any problem that's bigger than what we have today. Eric: do we define things on the CONNECT stream. We could do this with a WebTransport capsule. There's ??? David: Agree with Eric. Reply to mt, what does it buy us? We might want to add a future frame later. Is it one or two IANA registries. We're defining one WebTransport over HTTP, and when you run it on H3 it's on steroids. mt: There's maybe a simpler way to build this, might not be so pleasant. If it can't guarantee end-to-end, then it doesn't offer it. The way we get things lifted up requires ??? Eric: Wondering if the effort is worth it. Using the Capsule is a way to get a different IANA registry. What's the Litmus test to determine if it should be a Capsule or not. David: We will be forming a design team. ## Priorities Luke: Alan: The easiest thing to go from FIFO to LIFO might be to just tell your scheduler (???). In MoQ we can get value by breaking them up and push them over QUIC streams. If you want to go as fast as possible, you need interaction you need closer ties with cc, loss recovery, latencies and feed this stuff into the application. Maybe WebTransport stats are enough for that? Are we going to think about a v2 version of the API? David: Scope this to the implications of WebTransport. Luke: In our server you can prioritize streams. Want to fully utilize conn and degrade cleanly. Kind of like LIFO but it's more complicated. There's control messages and stuff. We need a way to communicate priorities. That can be solved with an HTTP header. Victor: Comment on the w3c issue. 62. mt: That's something the application can do for itself. Signalling can be worked out on your own terms. Lucas: Extensible Priorities draft is just one signal. In practicality it should be combined with all the other information. Some might ignore it, some might combine it with other pieces of information. The browser world has a lot of constraints that other don't. QUIC doesn't specify how it's done, some people love it and some people hate it. We can still define this later. Cullen: LIFO doesn't necessarily work. In the video case this makes it better on semi-congested networks, but makes things works on really congested networks. We need something more flexible. Bernard (no hat): w3c now has a functioning version of WebTransport API and WebCodecs, so you can build this kind of stuff. Video upload scenario can be implemented right now. Downstream is more complicated. Server can do things like priority, without the WebTransport client needing to support that. So we can accomodate both scenarios, people should try it out. We didn't go down to the lowest level, and we decided that people don't need it. Only for RTP directly over QUIC. Stats are not intended to implement cc, just to see how the app is performing. Magnus: is it dynamic? Luke: Twitch is using Webtransport, but not WebCodecs. Prioritiation on the server side. When we create a stream, we know the priority. It's nice to have that functionality but not required. Re Bernard: if you want to create media in the browser, you can't control the priority then. We're thinking about this, send new media before old media. Bernard: would be interesting to see result. Alan: some people have really low latency video and might not be happy with the default cc that the browser is providing. Bernard: interested to see if you have any issues with BBRv1 in your implementation. Alan: I personally don't have any code, just based on discussion that happened on Wednesday. Luke: BBRv1, but there are some bugs in BBRv2 not fixed yet. Reno and Cubic don't have the same latency requirements. Asking browser to allow control over congestion controller might be too much to ask from a browser API, let w3c decide. Cullen: Information about congestion controller could be passed down. We're not at that point yet. Bernard: That's what's been proposed, an enum provided to the WebTransport constructor. Cullen: That seems adequate. Victor: enum to let you switch between different ccs. There's a proposal (where ???) to move cc out of the Linux kernel to user space. Question: is this really worth the engineering investment? Bernard: how do you configure that? let people see what works and what doesn't work. Somethink like SCReaM or Google CC might be interesting. Problem with pooling!