IETF 110 WEBTRANS WG Minutes
Monday, March 8, 2021
08:00 - 10:00 Pacific Time
Session III, Room 3
Chairs: Bernard Aboba and David Schinazi

IETF 110 Info: https://www.ietf.org/how/meetings/110/
Meeting URL: https://gce.conf.meetecho.com/conference/?group=webtrans
Etherpad: https://codimd.ietf.org/notes-ietf-110-webtrans
Slides: https://docs.google.com/presentation/d/15u9F-YgP8mpE7gUYhfM5Bn7ZGa3AiG6GQIo2wFZgC_Y/

## Preliminaries, Chairs (10 minutes)
Note WellJabber Scribe, Etherpad Note Takers
Speaking Queue Manager (David Schinazi)
Agenda Bash

## W3C WebTransport Update, Will Law (10 minutes)
[Slide 7 onwards]
(https://datatracker.ietf.org/meeting/110/materials/slides-110-webtrans-ietf-110-webtrans-wg-01)
Summary of changes from W3C since November 16
Issues currently under debate
Request for the IETF: please finalize a scheme to be used, some preference was expressed for "https"

## WebTransport over HTTP/3, Victor Vasiliev (40 minutes)
https://tools.ietf.org/html/draft-ietf-webtrans-http3
Goal: Resolve issues blocking shipping interoperable version of WebTransport

### [Issue 23](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/23)
Proposal: use the same syntax as client-initiated bidirectional streams
Alan Frindell: Aren't client-initiated bidirectional streams identified by being a CONNECT request? Ah, they have a frame type.
Martin Thomson: Client ones look like they have a frame type, but don't. They have a frame "type", would this be the same?
Victor Vasiliev: The proposal here is that they should behave the same, will be modifying how they work in the next slides
Martin Thomson: Sounds reasonable
Alan: Do we want/need a way for everyone who wants to extend server-initiated bidirectional streams to solve this? Do we want all extensions to follow the same thing so that different extensions can be demultiplexed in the same way? Should there be guidance for extension writers so that we don't need to do this over and over for each HTTP extension.
David Schinazi: (as individual) Similar to how we have a document for how to use datagrams in HTTP/3, maybe what we need here is an incredibly short document that describes how you use server-initiated bidirectional streams in HTTP/3.
Victor: Not entirely sure a separate draft is required as long as we pick an approach that is compatible with further extensibility.
David: Makes sense, works if we tie it to a different setting from the WebTransport setting. Don't want others to need WebTransport to use their own extensions.
Ian Swett: I'm not completely sure you need to talk about Settings in all circumstances, this is more about how does one extend HTTP/3. If we do this, other folks will want to make a similar decision both because it's extensible and to be consistent with this. This is more about "it's best practice not to hog all the server-initiated bidirectional streams" and this is the obvious way to do so. If HTTP/3 wasn't already so far along, I'd suggest we shove it in right there. I don't think it really matters though, I think we can just move forward with a consistent design.
Martin: We don't really own HTTP/3 and we'd have to talk to the people who do, probably best for httpbis to define a generic document that says this. Would also describe what it means to use a client initiated bidirectional stream.
David: Doesn't the core HTTP/3 document describe how client-initiated bidirectional streams work? They carry frames and others can extend frames.
Martin: I think it currently says "carries requests" which are made of frames, so we'd want something to make it clear how general usage should work.
David: (as chair) I can take an action item to reach out to httpbis chairs to understand where this should live.
Alan: One more point that I raised on issue 23, has to do with the fact that unidirectional streams are identified by stream type and bidirectional streams are identified by a frame time. If you ignore that difference, they look the same at the beginning of the stream, and I take advantage of that. If anyone ever added a new frame type (?), that would break a nice symmetric implementation. It might be nice to reserve the unidirectional stream type number in the frame type space to allow for that sort of implementation. That could also be done in a separate issue.
David: Thanks, Alan. Let's have Bernard and myself circle back after talking with other chairs and that will be a great issue for that document wherever it lands.

### [Issue 26](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/26)
Victor: Previously said that you could have a datagram frame that went to the end of the stream (i.e. use Type-Value without Length) and avoid additional framing. Issue discussion highlighted that people don't agree that it can be omitted. Question here, if we don't have length, should we add it?
David: (as individual) Personally, I think this would be a useful HTTP/3 feature to have a frame length of zero mean that it goes to the end of the stream. Got turned down when adding it to HTTP/3 at some point, but we'd need to see if people were okay with doing that in HTTP/3 or if that's specific to WebTransport.
Ian: Not that strong of an opinion, although I thought we were going to use the Type Value form for this. Would be nice to put best practices in an httpbis document if we were doing it. This is a special case because if you don't understand what the type is your parser will immediately fail, so these are already special frames that are non-standard HTTP/3 frames.
Alan: Recognizing that either is possible, I do have an implementation where I had to go write code that handled frames without length. Was about 3 lines, not ridiculous. Might be a reason why you could start it with length zero. Pick one or decide on best practice.
Lucas Pardue: I'm kind of confused by this because if my implementation saw an extension frame that it doesn't recognize, it will try to skip that frame, but I'm not sure how I can ignore a frame where I don't know what it is if it doesn't have a length.
Victor: That's why we'd define a setting, you can't send the frame without the setting.
Lucas: If I don't set the setting and you send me one, then my connection is dead? The current HTTP/3 extension story is that we just ignore extension frames.
Victor: Fatal error to send the frame when both parties aren't sure that it's webtransport
Martin: To answer Lucas, there's provision for settings that change the way the protocol behaves. Here, you'd be saying that everything after that frame is something other than frames, etc. can bake that meaning into the setting. Seems workable.Alan's point about stream types and frame types is relevant here, as the bidirectional streams will be just stream types and not frame types.
Victor: I assume that speaks in favor of not using length here.
Martin: I don't think length gives you anything at this point. A length of zero doesn't help, since your parser is going to choke there anyways. Result is undefined either way, so you have to rely on the setting here.
Eric Kinnear: Having something that extends-until-it-doesn't is annoying when trying to implement some of these things, probably fine here, but wouldn't want to do this generically in all cases.
Alan: I like the idea that this is a different thing and that we don't overload having zero length since that can have other meaning for other frames.
David: My earlier comment about trying to do something generic doesn't work based on this conversation, so I'd support doing something WebTransport specific that works via the setting.
Martin: I don't think it's something we can avoid generically for bidirectional streams, but aside from that the frame stuff I think that's going to be on a per-frame type basis.

### [Issue 38](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/38)
Victor: Pick a URI scheme, please. Proposal: Use "https"No real reason to make a new one, as far as we can tell they're just HTTP resources, they do require a specific HTTP method but that's not new to some HTTP resources.
The main objection was that there were subtle differences in how it behaves around things like cookies and HTTP auth, specifically that it does not, but that's different from the concern around how these resources are identified.
Martin: I'd support "https", this seems pretty reasonable. Jonathan Lennox asked in Jabber why "ws" was a separate stream. "ws" and "wss" are examples of what not to do in this case. We should probably just treat it as a different method on the same HTTPS resource. That would be different if it were QuicTransport, but now that we've taken this path that's a much easier decision.
David: (as chair) Not seeing any opposition to going with "https" here, so unless someone wants to speak up now or on the list, I think we can assume consensus on this one and move forward.

### [Issue 10](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/10)
Victor: These are less critical for interop, but still important. Stream IDs -- reconfirming what we already have. We made a decision that WebTransport would not expose the stream IDs from QUIC. In QuicTransport it might have been okay, but for HTTP and especially if there are proxies in the middle, that makes no sense whatsoever. 
Wanted to reconfirm that we're not going to expose QUIC stream IDs as part of the protocol. 
Luke Curley: We made the original ticket, for context we wanted to know the ordering/creation date. That's not necessarily possible with HTTP/3 transport or pooling. We might need a custom way of doing that within WebTransport.
Victor: I was thinking if it was possible to preserve ordering without preserving the idea of the exact stream IDs, one question I have: when you're interested in ordering do you care about relative ordering or does this ordering need to have no gaps. 
Luke: Initially we did odd/even ones for different types of streams, and we used the fact that QUIC streams are increasing. Again, that's not possible because if there's a gap we won't know if it's an HTTP request. There's no way of knowing how many streams may have been created. We can just add a header on top of the request, and that may be acceptable, tell applications to assign their own stream IDs.
Jan-Ivar Bruaroey: I just wanted to make sure I understood that, I think ordering is going to be important in the API since I think framing is going to be hard for javascript developers to get right. One thing we get asked a lot is how to wrap websocket-like API onto WebTransport. Two ways: either wrap on transport itself or introduce head of line blocking on a request stream. It seems that preserving the ordering of what was sent is critical. I wanted to clarify if we were able to guarantee that order.
Victor: If you send on explicit streams, you're guaranteed that order will not be preserved, preserving ordering introduces head of line blocking.
Jan-Ivar: I was happy to find in the QUIC spec that stream IDs are always increasing. If we can carry that forward to the API, if you await a stream then the appearance is going to be in the order that they were sent.
Victor: I don't think this is true, you don't know if the ones in the middle are even related to you. Doesn't really make sense to assume that they're going to show up in the same order.
Jan-Ivar: It won't be blocking, if you get one that's newer than expected, then the receiver can create the underlying streams for the missing numbers and then populate them later.
David: If packets get lost, you can't assume that the ordering is enforced. I think you'd really diminish the benefits from QUIC if you had the API enforce the order, as that introduces head of line blocking, I'm sure there are applications that don't want that. 
Jan-Ivar: We're talking about API now, I think the API doesn't force the application to choose, you can choose what you want to do here. You can create dummy streams for any gaps that you see.
David: Given that we're not over HTTP/3 which is a multiplexed protocol, we're going to need a new namespace, as we're not going to expose that raw stream ID from QUIC to the application as that leaks information. So the question becomes, do we introduce a new thing into WebTransport and make a new namespace, or do we ask applications to make their own header and number them according to their requirements.
Martin: I think David covered most of it, unless you want to make the application aware of things that are not for it. You can't use the presence of stream 16 to assume that 12 exists and is for you. The other way around it is a notion of dedicated connection for the purposes of that application, then you can expose it because it knows that it's going to be a WebTransport stream for it. Let's push this onto the application for the header.
Bernard Aboba: I think it's worth having an issue, there's a number of cases where it's the application's responsibility. Another example, we decided to not make ACKs visible in the application, since people were unclear about whether or not they need to handle their own reliability (note: if you asked for unreliable, then yes you need to handle it yourself)
David: Who is going to document this? Bernard: Victor willVictor: Sure, I've got the action item
Jan-Ivar: The language that I found in the QUIC spec about streams of lower numbers meaning they're opened, is that not true?
Victor: They're opened but we don't know which WebTransport stream they'll be, or even if they're a WebTransport stream at all.
Jan-Ivar: Once you've received data and know what it is, an application could decide to open lower numbered streams.
Victor: If you do this, then you've introduced head of line blocking.If we require streams to go in order, then all future streams would be blocked.
David: It sounds like the feature you're asking for is "hey I received the client initiated stream and that stream told me that there's some other stream that I want to send on". If you want to send something without the client having spoken first, why not use a server-initiated stream?
Jan-Ivar: The model here is that when you create a stream, all the data inside it, then that data  has guaranteed ordering. If I split it across two streams, then I'm not guaranteed the ordered delivery of those streams. But it would be beneficial if we could surface them in creation order and I don't see how that would block anything. Framing is hard in javascript and stream IDs is an implementation of framing that we could benefit from. I'll work on clarifying how I don't consider that head of line blocking, but it would be nice to look at that in WebTransport.
David: This sounds interesting, can you write something up that we can discuss offline.
Luke: I think at a higher level this also applies to the next issue. In my use case, we're using QUIC for mobile platforms and then for Web support we're going to use WebTransport. There are a few QUIC features that we've been using which don't map well into WebTransport. Stream IDs and Reset are two of those things that don't map particularly well. Are we looking for QUIC or a subset of QUIC API-wise? 
Victor: My intuition is that it has to be a subset, I don't think we can do a 1:1 perfect mapping. Or if we could, I'm not sure it's worth it. QUIC has a lot of semantics and some of those semantics are dictated by the fact that QUIC is a transport protocol that has to handle transport issues. Our goal is to implement as much of QUIC as possible and expose as many of the semantics of QUIC, especially those that relate to unreliability and avoidance of head of line blocking.
Alan: Folks are telling us what they want from the transport, we are ignoring them and trying to build a batteries-not-included simplest version that's possible. If applications are saying that more things are possible if we tell them about the ordering that things were created, then I would be in support of building that into the protocol. 
Timothy Panton: I just wanted to say in the WebRTC world we came across the same problem and we solved it by introducing a lightweight protocol that slots in a header and allows the API to label a stream. That's turned out to be super useful, if something like that is possible without having too big an overhead, then I'd be in support of that.
Victor: It sounds like it's worth discussing this one more, not for the most immediate interop draft.

### [Issue 31](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/31)
Victor: Issue 31 is very similar. Do we want to expose RESET_STREAM?
Martin: I'd argue for the first option, declare that RESET_STREAM is not reliable. The only issue is that if someone is mixing WebTransport streams and request streams and one of them gets reset and the other one doesn't get through, then you have a weird stream that appeared and it can't tell what to do with it, but that's fine. In those cases, the endpoint that created the stream and reset it too quickly would have meant that the other side never heard about it.
Luke: From an application level, if I'm using WebTransport and I create a stream to write a bunch of data and then close it with an error code. It's a reasonable expectation that the error code will make it to the other side, especially if data was sent. It seems like an invitation to future problems if people expect those codes to be reliable but they aren't due to packet loss.
Victor: Is this specifically about the error code being reliable? 
Luke: I think so, the fact that a stream existed and the error code both would want to be reliable. Do we need the receiver to know that the stream ever existed if it never got data? If it didn't know what protocol it was for?
Martin: This is physics, if you use RESET_STREAM for this purpose, you don't get to learn about the code sometimes. The question is whether we build an additional facility into the protocol to support it, or the only way I can see of getting these through reliably is having a dedicated connection.
Victor: I would say that it is possible to just make it so that reset stream error codes always arrive, and that to some extent is a solution.
Martin: There is an option here that does work, that is to reserve RESET_STREAM error codes for WebTransport. There is some ambiguity if you have two tabs sharing a transport, and then each has its own WebTransport you still can't tell what's going on, but otherwise you'd be able to tell that it was for the WebTransport in question.
Victor: I feel like we should reserve some space for error codes just so we can distinguish from HTTP error codes regardless. 
Jan-Ivar: Yeah I just wanted to echo that I think we're going to have to find some way to make these APIs a little bit more predictable. I'm hopeful that we might be able to do so at the API leve, but it seems like this particular one, once you get a newer stream you might know that there was an earlier one that could have been reset that never existed. It sounds like the semantics are embedded in the protocol.
David: I think just conceptually and fundamentally, QUIC streams are not ordered. The fact that they have IDs that are sequential is an implementation detail. Neither QUIC nor WebTransport provide this capability to upper layers. If there's a need, it would be nice to have the use cases identified.

### [Issue 28](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/28), [29](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/29)
Bernard: I agree, we've encountered this in other things such as WebRTC, but you might want to have limits on the buffer.
Victor: Agreed. Need to limit the state required.

### [Issue 27](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/27)
Victor: Assume reverse proxy with backend that sends GOAWAY, how should this be indicated to the application/client that the session is being drained and will go away soon. Do we want to support this in WebTransport? 
Alan: I just want to say that it's very important that we find a solution to this problem, we have something very similar to WebTransport today and the application that uses it has a sequence of streams and we need a way to signal "please don't start any new work, but don't prevent the creation of new streams that are required to complete the transaction associated with that session". I could see using the CONNECT stream associated with that session to signal that.
Martin: I agree with Alan. The way that we've been conceptualizing GOAWAY is about requests, this is the next level down. I would imagine it would work such that GOAWAY at H3 layer says "no more requests, please", but within a WebTransport session you can still make new streams (not new sessions). Within a session you'd need a similar way to say "stop making new streams" and that could be on CONNECT. Not sure if that's needed or application can do it without additional support.

### [Issue 33](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/33)
Alan: I raised this issue after I implemented a lot of this last week, I found that in my implementation this was the only reason I had to track which streams belonged to which session within the transport stack. This meant that I had to keep an extra list of things, if the higher level already has that then it can handle it.
Victor: I can kind of see that argument. I definitely agree that the browser should reset the connect stream if the tab goes away. It's unclear if we should relax the requirement for non-browser implementations.
Luke: Only the creator of the stream knows that it's associated to the connection, it seems like however created it should close it when the connect stream is closed. 
Victor: Lucas makes a good observation that if you allow them to continue, it makes us less able to rely on CONNECT for control-stream semantics like GOAWAY, etc.

### [Issue 34](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/34)
Victor: How does the server let the client know that pooling WebTransports is not supported?
Alan: (missed this)
Bernard: I'd like to speak to option 2. Option 1 would be awkward especially if linked to other things like what stats you get.
Yutaka Hirano: I don't understand why the client needs to send the indiciation to the server, the client needs to wait for the first settings frame just to find out that the server supports WebTransport. I don't know that we'd need to have settings from the client to the server.
Victor: I think I agree with you, but this is something we need to think about more. We might be able to get rid of the client signal.
Dragana Damjanovic: You will need a client indication if it wants to use that transport or separate HTTP/3 connections and WebTransport connections to the same origin. If you don't indicate from the application that you want a separate connection, then you can pool them. If the server only wants to support one, it seems complicated to have a server that listens on the same port on the same origin but requires separate connections.
Victor: The reason I want to add a dedicated from the signal is that there are developers who want to allow that sort of thing.
Dragana: Then you'd need to indicate that you want to open that connection for HTTP/3 or WebTransport so the browser knows what to do. I can try to explain further on the issue.
Martin: Firmly against having a dedicated flag. The decision to use HTTP/3 means you're making an HTTP connection and there are a number of other ways for a server to say that it doesn't want other requests to happen. For example, we've got 421 to say "I've got a certificate but I'm not willing to answer requests for this origin", you could also put them on their own origin. I'd also second Yutaka's point about not needing this on the client side.
Victor: Sure, if you're sending HTTP requests you already know where you're sending them. But what about having two WebTransport sessions for the same client.
Martin: Key point here is resource management from a server perspective, having max sessions and maybe max streams per session would be a useful control here.
Eric: So this isn't even really QUIC vs. HTTP isn't more about controlling that endpoint and being able to choose what requests you respond to.
Martin: Can use 406 (405?) to say "method not supported", respond to what you want to handle.

### Datagram Flows
How to encode them? Come to MASQUE tomorrow.

## WebTransport using HTTP/2, Eric Kinnear (30 minutes)
https://tools.ietf.org/html/draft-kinnear-webtransport-http2

Some networks don't support QUIC (nee UDP) - what is a fallback? Web traffic can go back to TCP, what does WebTransport do?
Choices: fail, build your own fallback (on top of WebSockets?), or WebTransport over HTTP/2. So lets think about what WebTransport over HTTP/2 looks like. It looks similar but TCP/TLS means we lose some features or capabilities. Is this worth pursuing even if there is not feature parity?
Principle 1: it's okay to require an optional feature, make it clear when creating a session via the API. It might fail and you might need to provide your own alternative.
Principle 2: application needs to know what features are available in a given session. Adjust what you do based on features
Principle 3: Wherever possible WebTransport over H2, should be equivalent to WebTransport over H3.
Draft has been updated now that we've adopted the single draft.
So is this something worth doing, are the principles sound, is modelling it after HTTP/3 transport reasonable.
Bernard: WebTransport over H2 is the best solution for developers. TCP fallback is important because UDP blocking is particularly prevalent in Enterprise Networks (affecting as much as 15 percent of enterprise usage). The question is how to support fallback. Without WebTransport over H2, WebSocketStreams API (which provides a WHATWG Streams-based interface to WebSockets) could be the fallback. Unlike WebTransport over H2, which would allow an application to support fallback with a single API (WebTransport), two APIs would be needed. There are differences between WebTransport API and WebSocketStream API, so developers would need to create their own wrappers to support both APIs. So this is not as clean as WebTransport over H2, but it can work whenever WebSockets is supported, and at least both APIs are based on Streams. However, my understanding that WebSocketStream API, which was in Origin Trial, is not moving forward. If the only alternative to WebTransport over H2 is to require developers to write to two very different APIs (WebTransport and WebSockets API) that is difficult and will present challenges. For example, WebSockets API has known issues with backpressure. 
MT: Requirements are spot on. Bernard's point is similar to points that myself and colleagues have made. Have reservations about technical aspects of approach; can probably simplify things. Maybe pack all of it in one H2 stream, rather than intermixing with HTTP request streams. This is the right work to be doing but I'd like to see more discussion on the technical side of things.
David: From comments here and W3C there seems to be interest in this work. We want to reserve some time each session to discuss WebTransport over H2 (or TCP) at the end of each session, with a view to some future adoption. We want people to respond to gauge interest in this approach.
Yutaka: We're still working on WebSocketStream.
Jonathan: a little concerned that the failure rate of QUIC is low and that this code might not get well exercised. W3C probably need to help keep an eye on things.
David: my understanding that this is oriented more towards networks that don't support UDP rather than servers that don't want to support a UDP-baed WebTransport
Jonathan: web developers using their dev environment might not have traffic that is reflective of the Internet, there may be unanticipated surprising behavior
David: interest and no opposition to discussing this. Too early to judge whether to adopt. Please continue discusion on [GitHub](https://github.com/ekinnear/draft-webtransport-http2/) and future session. We'll probably have an interim session before the net IETF meeting, please look out for information on the list.

## Hums, Wrap up and Summary, Chairs & ADs (30 minutes)