* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Webtrans Status Pages

WebTransport (Active WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2020-Mar-06 —  

IETF-110 webtrans minutes

Session 2021-03-08 1700-1900: Room 3 - webtrans chatroom


minutes-110-webtrans-00 minutes

          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
          ## 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]
          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)
          Goal: Resolve issues blocking shipping interoperable version of
          ### [Issue
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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)
          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)

Generated from PyHt script /wg/webtrans/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -