# WEBTRANS Interim {#webtrans-interim} 2024-02-22 (or 2024-02-23) ## W3C Update {#w3c-update} Jan-Ivar Bruaroey (jib) Two things to discuss with IETF dependencies [Issue 411][1] - Keying material exporters Request to IETF to change the interface. Victor V: What this would do depends on what the application needs to do. jib: Not looking to design an API, just to agree on mechanism. david: There is a proposed design on the issue. [Issue 580][2] - DataRecvd state dependency jib: Holding streams available until data is received can be useful for implementing a form of partial reliability. victor: We have to tell the upper layers when the stream transitions from a state where you sent FIN, but you can still reset, and when there is no further prospect of being able to send a reset. Eric Kinnear: is the idea to add a new state, or expose the existing one? victor: rename the states perhaps - for h3 use DataRecvd and for h2 something else martin: discussion about distinction between h2 and h3 and what point things are considered "done" victor: takes action to open an issue on this (other note fork) \#580 Data Received State MT: For H3 you can abort retransmissions if packets are lost, but in H2 once you've committed data into the pipe there's no way to go back. Victor: In H2, you can also still write ahead of flow control, so it's not entirely meaningless, but potentially still less effective. MT: Promise resolution on writes would happen once data has been committed to the network, so a client that respects backpressure would not have anything outstanding from a flow control perspective. Some clients just ignore that, of course. Have previously made decision to not drive this from acknowledgements, etc. More work required to specify exactly what this would mean for each mapping. Action: Victor to file issue to track that work on the IETF side. ## MAX\_STREAMS and Flow Control {#max_streams-and-flow-control} A: Do nothing B: Hint (server sends either MAX\_TOTAL or MAX\_PER\_SESSION+MAX\_HTTP) C: QUIC-level partitioning D: An additional layer of flow control at the WT session level Lucas: Something mandatory is what I would desire. Hints don't seem to work because you can't guarantee that a new implementation would work. David: QUIC changes means opening up the design space. Expediency suggests doing things in WT. Lucas: Doing it here seems better. Maybe in the future we can take this into the transport layer. Martin: Do the work here, not QUIC. Make it mandatory. Victor: Take either 1 or 2 of the options (mandatory or mandatory conditional on pooling). Which of those options determines what I think about the A/B/C/D choice. Eric: Doing it here is fine. If QUIC builds a mechanism that we could use, we can revise WT to pick that up. Some value in sharing mechanisms between h2 and h3. Having it mandatory, especially for intermediaries, is useful. That means that you can guarantee that participants will respect your limits. Bernard: Agree to do this work here. Preference is only to make it mandatory if pooling. Martin: Argues for 1 over 2. HTTP needs to share with WT. Eric: in terms of 1 vs 2, I'm in a similar place. Having it be mandatory is not a huge lift Victor: more in support of 2 than 1 because its easier for implementers, especially those that don't want pooling. From practical point of view, option one might not work because there are already deployments of existing spec without this complication David: are you saying browsers wouldn't update? Victor: more about the servers. David: browsers have ability to deprecate Victor: subject to web compat Alan: do we have a good understanding of what pooling means. Is it only WebTransport or is it HTTP too David: my understanding, any time the WebTransport session has something else on the connection Alan: ok. weh nwe talk about what browsers have implemented, nobody has implemented pooling? David: as far as I am aware Bernard: I beleive you're correct David Alan: not sure how many server implementations of WebTransport there are. Do those people have WebTransport *and* QUIC implementations. Bernard: some have earlier implementaions Alan: that's true for ours Victor: there is a definition. once we create a WebTransport session it has it's own connection. What would happen when we allow pooling, step 1 is having a generic create HTTP/3 connection. Then we'll try and negotiatite WebTransport with pooling. If server says yes we can mark that. On servers, there is a way to enforce no pooling. There are some control streams still but they don't particularly affect flow control Eric: when talking about previous versions, there's a huge amount that's different. I'm not sure I would let old versions have too much influence of decisions we make. Victor's point about server making decisions about what to accept. Can limit pooling or flow control to 1 still. Not sure its a huge factor in ddeciding if this should be mandatory or not. Victor: actually only 2 backwards-incompatible changes. Long story of vendors introducing APIS, adding a new version that adds more complexity, and then not being able to unship the simpler thing. David: as individual, on topic of servers disabling pooling, pretty straightforward to put server on separate hostname. But that still might consume credits, nevermind... David: I've heard support for 1 and 2, doesn't seem like clear winner. Let's change gears to talk about proposals again. Any strong feelings? Victor: if mandatory: B and then A. If it is , then B and D is fine. () Bernarnd: I agree with Victor, if non-mandatory B and D. Otherwise A. Victor: I want to clarify about complexity. Previously, the only way to do unreliable data was WebRTC. Requires lot of services and parts. People find RTCDataChannel unsatisfactory. WebTransport motivation was largely to define something simpler and to have increased server-side diversity. Would liek to avoid repeating situation with RTCDataChannel Eric: on one hand good to reduce complexity. One reason people use WebSockets is that it's there. And a big part of that is becuase there is server diversity. WebSocket is also there because it doesn't do things that are as complex as other things. Not sure there is that much complexity difference between B and D. Server cares about flow control becuase it also needs to care about number of clients etc. I think we've established option A is not suitable. I think where we land is that D is the best option. C is nice architecturaly but lets not try to be perfect. David: sense that if we want pooling, D is looking like a winner Alan: I'm not going to disagree. Don't want A. Don't think C is the right thing today. In terms of complexity and success of WebTransport - I don't think flow control is a barrier. Shouldn't be visible to developers, only the folks on this call. I think Eric is the only person that implemented this and he says its not too hard. Maybe if we pick D, it will force the others to implement it and we can understand if they foudn it hard or not Eric: to speak to implementation - we have prototypes, not finished HTTP/3 stuff. That said, wrt flow control there are complexities but some of those things have to be handled anyone. The same thought is required for this as the rest of the stuff. David: sense I'm getting is everyone could live with D and some would like it. So assuming option D, looking at slide 41 (timeliness) - is 2 plus D livable Victor: I could live with ti. But wrt server implementations, some people say its ok to make HTTP/3 more complex because there's only like 10 people that would implement. There's like 100 WebSocket implementations. HTTP/3 is harder anyone because of QPACK, as I've historically complained. Eric: amending prior comment. I had a slight preference for 1, but if we land on 2 plus D, that's ok Bernard: I like 2 plus D as well. There's a few server implementations that don't do pooling. So we wouldn't upset them by making flow control mandatory Victor: comment on complexity. Not only comes from sending frames and doing accounting - instead you now have QUIC buffer and WebTransport on top needs to interact. There are are compolications with stream state management that might not be apparent, the more I think about it there are some rough edges Alan: curious what option 1 is if you weren't pooling, just set a big number? David: on receiver can set "infinite" but complication on the sender. Requires buffering or management to respect peer's limit Eric: can't unilaterally opt-out. Problem exists with or without pooling though. Option 2 doesn't make life drastically easier. But if we discover its drastically painful to implement, that's part of the IETF process. Alan: feeling is we shouldn't ship this without some interoperable implementations of pooling. David: we won't WGLC until we're ready Lucas: restricitng to hostnames can be difficult David: we can use a setting! David: we will send 2 plus D for a consensus call to the list. ## AOB {#aob} End of session. Hallway discussion about QUIC over streams and WebTransport over HTTP/2 ## Chaff {#chaff} [1]: https://github.com/w3c/webtransport/issues/411 [2]: https://github.com/w3c/webtransport/issues/580