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/
Note Well, Note Takers, Agenda Bashing, Draft status
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
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)