WebTransport (webtrans) Working Group

CHAIRS: Bernard Aboba
David Schinazi

IETF 114
Date: Tuesday, July 26, 2022
Time: 10:00 - 12:00 Eastern Time (Session I)
Room: Freedom E/F
Minute Taker: Jake Holland
Jabber Scribe: Alan Frindell

Meeting link: https://wws.conf.meetecho.com/auth-service/openid/oauth2callback?group=webtrans
Notes: https://notes.ietf.org/notes-ietf-114-webtrans
Slides: https://docs.google.com/presentation/d/1GM5ScmnO4hmzXPpZ1CyRJctzrX1YD5p5kl0-sF7eFbc/

1. Preliminaries (Chairs, 15 min)
   Note Well, Note Takers, Agenda Bashing, Draft status

2. W3C WebTransport Update, Jan-Ivar Bruaroey (10 minutes)
   - Jake: this API will support congestion control for server as well?

   • Jan-Ivar: no, just for client-to-server, server will take care of itself.
   • Omer: It might not be useful to let the app set the congestion controller by name, rather than expressing the goal. (+1 to "low-latency" style). (David: please add it to )
   • Stuart: worried about the tendency to over-complicate things. It's possible to have low latency and high throughput simultaneously, it's not either/or. If you have enough bandwidth, there's no problem, but if you don't it gets very complex. Let's not overcomplicate it.
   • Alex: Surprised by this slide, not sure we want this exposed to people to choose without understanding
   • Luke: low-latency hint is pretty important, the key management is important for instance. If there's bufferbloat we get backed up.
   • Luke: also, ordering is important (on the prioritization). 8 levels is ok for warp, but for rush with a max of 8 priorities it won't be enough. This is about
   • Jonathan: low-latency means what, cubic vs. gcc?
   • Victor: there is a practical tradeoff between throughput and latency, this is one of the fundamental tuning properties and from that perspective setting latency targets makes sense
   • Ian: I also prefer CC advice, even just "prioritize latency" vs "prioritize thruput". Not sure what to do with CUBIC since it's always the wrong option, but advice
   • Cullen: whatever levels of controls are available here limit the options that are available, we should give them the controls they need. We have to design for the use cases for things like zoom etc with large numbers of users, not for average web designer who might not understand it.
   • Tommy: Sypathetic to Cullen, you want fine-grained control, and if names are available people will use it. Is there a reason we're specifying the properties of congestion control we want, instead of properties of the traffic (e.g. bulk transfer, realtime audio, etc.). We've seen this in e.g. taps, where you describe the use case
   • Mo Zanaty: WebRTC hit this too, we started with low complexity and now we have to add more. Should realize the app designers are faster than the browsers. Regarding priority: it's hard to know what to do with the numbers unless you know how they're used, is this hard priority vs. weighted fairness for instance. Weighted heavy streams might be a useful concept here vs. hard priority.
   • Eric: challenges with low latency vs. thruput is that you might have something that gives you both. Maybe best to list what you're most willing to compromise on, for instance maybe power would be worthwhile. Either go all the way to the top as tommy said, go to the top and describe what we're doing, or (or maybe both), go to the bottom and let people pick exactly the congestion controller and parameters yb name
   • David: please add these to the github issues: https://github.com/w3c/webtransport/issues/

3. Output of the WebTransport Capsule Design Team, Eric Kinnear (40 minutes)
   https://tools.ietf.org/html/draft-ietf-webtrans-http2
   - Mike: Does the capsule requirement imply that the underlying quic transport must support datagrams?

   • Eric: good question. I think we require if you have datagrams you must use them, but it's not clear how to signal it
   • Tommy: datagram support is via transport parameter in quic, and you separately have an h3 setting. Either webtransport will break in those cases or you need to tweak the language to say you use the capsule protocol.
   • Eric: but if you don't see both quic datagrams and h3 datagrams, does sit just reak?
   • Martin: you can have a stack of things that have a dependency chain, e.g. you can have h3 datagrams depend on quic datagrams. Want to caution that if you have something like an upgrade token that sits on top of that stack, you need to have all the prereqs and fails if anything isn't there so that you can build software rationally. So this is fine. I understand that to be a problem in some cases. We should not rely on implicit signaling here.
   • Martin Seeman: There's a use case of webtransport that doesn't require datagrams. You can just have "this feature not available"
   • Martin: what we're looking for is interop. If we have people who want to use without picking and choosing what you can use, that complicates how we build this. Implementing the possibility of receiving datagrams is relatively easy, and then you'd get interop, but building something when datagrams are optional is trickier
   • David as MASQUE enthusiast: In http doc we say you must support receiving datagrams in capsules. Do we want to say you must send over datagrams if available, or do you say you must support datagrams somehow? It's relatively easy to support datagrams.
   • Luke: I've deployed a quic stack without datagram support, the main problem is capabilities at w3c layer, if the api just lies with "i support unreliable datagrams". I definitely would like to avoid having to implement anything complicated with datagrams, there's no reason to use them in most cases.
   • Eric: to summarize datagram discusssion: either you have a requirement to support datagrams via any mechanism, or we allow implementations to just drop them on the floor. 2nd seems preferable, open issues to discuss?
   • Martin Seeman: h2 has an ordering guarantee in streams, in h3 you don't. How do we deal with that?
   • Eric: if you closed a stream before it's considered opened, you can leak that credit, and our answer is don't do that. We still are looking at whether
   • Alex: how does session-level max streams interact with connection-level max streams in h3?
   • Eric: similar to what happens with with application level data limit vs. stream level data limit. Anyone can consume them.
   • Martin S: Stream internally has byte ordering in h2, it looks like there's a race condition here.
   • Eric: Closing before being opened because of ordering will end up
   • Alan: Streams closed gracefully don't have this problem but reset ones do. Leaking it is bad and maybe we need a reliable reset capsule on a control stream session.
   • Martin: Not sure we need this capability, always a possibility that a bad session overwhelms the capacity of the session by using too many streams, maybe they just forgot to close them for instance. But we have to deal with it anyway, because you can have a connection entirely consumed bby webtransport an there's no way of doing other stuff on it. Maybe throw this in the "do it later" bucket.
   • Eric: next slide says something like this, you can't guarantee you can do a non-webtransport thing
   • Martin: you could reserve some streams, but it depends what the server is willing to allow. If server only gives a 3-stream budget it doesn't leave a lot of space. But I don't think this'll be a big problem, this is not an adversarial situation, it's about service operators not harming themselves accidentally.
   • Victor: observation: browser can impose a limit on top of the h3 limit
   • Eric: the reason is
   • Victor: some of the resource problems are not just server imposing resource problems
   • Alan: servers then have to deal with limits they can't see on the browsers, which is inconvenient.
   • Eric: (missed)
   • Martin S: QUIC had a config option 5 years ago because the same problem, solved it by allowing max stream id instead of max numer of streams

• Martin S: how does intermediary byte limit forwarding work?
• Eric: you need to send something sensible initially
• Martin: this'll bbe a gateway sitting in front of servers, in most cases they'll know something about those servers. It can generally advertise an initial limit that matches the servers it's fronting (or the minimum if it's got multiple backend servers). There's interesting complications when you have TCP on one side vs. when there's quic on both sides, in which case you can't blindly forward due to head of line blocking and the need to support all the space you're advertising as intermediary.
  • Eric: yes, good point
• Luke: usually flow control is usually limited ram, and there's an assumption here about having as much ram as your backend, but if you're on raspberry pi maybe not.
  • Eric: but we're not extending the spec here, we're giving guidance on pitfalls. It's up to the intermediary, at the end of the day.
  • Luke: (missed)
• Ian: agree thinking about this end to end not really gonna work. You might not need to say anything. Btw, intermediary to server might have a very small rtt in many deployments, and bdp might easily be different by an order of magnitude. Maybe there's a dragon there worth calling out.
  • Eric: yes, flow control is not really end to end, and intermediary is responsible for what they've advertised. But in practice it's fine.
• Martin: so ubildling an intermediary might be hard, but people do it anyway. Maybe just don't bother stating detailed guidance, leave it to the intermediaries to solve.
• Eric: the current intent is just to make it clear that you're the one holding the bag if you advertise a limit higher than your upstream, and that it's not end to end.
• Cullen: we can't just wish intermediaries away. The draft statement is good, you are dealing with intermediaries, and this is the answer, not just "figure it out yourself later".
• David: Eric taking the action item to capture some discussion in github issues (Eric: yep)

4. WebTransport over HTTP/3, Victor Vasiliev (40 minutes)
   https://tools.ietf.org/html/draft-ietf-webtrans-http3
   - David as individual: vote for MUST follow redirects, regarding 61

   • Victor: as implementor I prefer SHOULD NOT. Ran into a bunch of issues in websockets, there's a bunch of issues around CONNECT http requests. Current implementation does not.
   • David to room: thoughts from room?
   • Martin: current advice not helpful. Thinking about e.g. fetch would have redirects followed until action is required. Here because browsers generally follow redirects I'd hope redirects could work here as well, it's useful for moving resources around. I'd be on the MUST end, and anything in SHOULD/MAY space is terrible because not deterministic, but I'd err on the MUST end.
   • Mike: not clear what it means to follow a redirect on CONNECT. It makes more sense if trying to fetch a resource/perform an action. But if I'm trying to talk to you, what does it mean?
   • Luke: +1 to martin, it should be MUST or MUST NOT, as a server I have to know if browser will do it.
   • Cullen: +1 again, it has to be MUST or MUST NOT. I assumed it would be MUST, I think most implementers would assume so.
   • Martin T: This has a resource, which is webtransport endpoint, so I lean towar MUST here. While mike is right that CONNECT redirect in general is weird to have a redirect, but in this case we have a specific resource so it's less weird than normal CONNECT.
   • Jonathan: would be curious to know the weirdnesses with wesockets redirects
   • Martin T: it's complicated
   • David: can everyone live with MUST?
   • Victor: would prefer to discuss later and on list
   • David: Victor action item to get objectors to chime in
   • Victor: ack
   • Martin T: regarding issue 71: if peers are allowed to send frames before WEBTRANSPORT_SESSION frame, someone will get confused. Is there any reason?
   • Victor: not that we know of
   • Martin and Victor: seems like we shouldn't, it complicates implementation
   • David: for all frames including future extensions?
   • Martin: yes. This establishes what the session is, we want this definitive and first.
   • Alan: it should be the same, whatever we do for unidirectional as bidirectional. No compelling use case either, outside of GREASE or priority, so you might need a different kind of frame in the future to support them, but that's ok
   • Luke: do we have a different kind of thing for a header frame?
   • Mike: it's a little more complicated, since h3 allows for other frames to introduce in the future. When spec says a certain frame must be first, that's different from when headers must come first which is about sequencing
   • Martin T: request stream is a default, so unless this is first this will cause confusion since it's the thing that indicates it's not a request stream. If we allow other things we're complicating it just for future h3 features
   • Alan: you can have a frame up front, and then another frame later, we can punt this to the future when we have a compelling use case.
   • Victor: yes, we don't have a compelling use case, we can simplify implementations by taking this restriction
   • David: hearing from the room that same thing for unidirectional and bidirectional, and disallowing anything besides wt frame to start, any objections? (none) will write up resolution.
   • re issue 77 (resets/half-closed streams)
   • Mike: h3 has an error that boils down to "I didn't see enough of your request to act on it"
   • Victor: I think we don't need to spell it out
   • Eric: This also can be solved by explicit messge on control stream to indicate need to bill me for leaked stream. Not trivial to write text for this, but it would solve multiple problems.
   • Victor: you can't reference stream numbers, so maybe it wouldn't solve this
   • Martin: wrong, once you create the stream you can use it. H3 has this probblem, h2 doesn't.
   • Alan: (missed)
   • David: not specific to webtransport, this is bidirectional stream. if client opens bidir and resets, server could keep it open forever but it'd be silly. Don't think anything needs to happen in webtransport spec, h3 can handle it
   • Martin: this is wt-specific because when client opens a wt stream it happens in context of the wt session. When it happens on server side, it makes a stream the server can send on. Eric's suggestion was perfectly good, we can solve it here.
   • Alan: h3 error page probbabbly not what we want
   • David: hearing resolution that we should bite that bullet and make a reliable webtransport reset stream capsule, (no objections)
   • for issue 78 (closing options):
   • Victor: prefer proposal 1
   • Victor: need a timer if there's only 1 session on connection
   • Alan: webtranspport normally doesn't have a timer, right?
   • Victor: Yes
   • David: resolution for proposal 1 as Victor prefers?
   • Martin S: why prefer 1?
   • Victor: there is value in waiting for server to ack at application level it received capsule
   • David: what does client do with that?
   • Martin S: proposal 2 is closer to what we do in quic, set it closed an walk away
   • Martin T: value in ability to do it either way. Value in sending error message saying why the connection closed, from either side. Question is how you respond to seeing that. Both options have value here, "walk away" option is useful if you want to just drop it, but seeing the other side's error message is also valuable when you want it.
   • David: resolution, both are ok? (no obbjections)

5. Hums, Wrap up and Summary, Chairs & ADs (15 minutes)
   - issues to progress on list and github
   - david (out of time): might have an interim
   - bernard: discuss on list