# IETF 108 WEBTRANS WG Meeting
          *Monday, July 27, 2020*
          *14:10 - 15:50 UTC*
          
          Virtual Room 1
          Chairs: Bernard Aboba and David Schinazi
          Agenda: https://datatracker.ietf.org/doc/agenda-108-webtrans/
          MeetEcho: http://www.meetecho.com/ietf108/webtrans/
          Jabber Room: webtrans@jabber.ietf.org
          Slides:
          https://docs.google.com/presentation/d/1cr_4jtUCYTkoJQl4jEWT9LKJfZkkYM1W3MW8s2bz47Y/
          
          ## Preliminaries, Chairs
          14:10 – 14:20 (10 minutes)
          
             Note Well
             Virtual Bluesheets
             Jabber Scribe, Etherpad Note Takers
             Speaking Queue Manager (David Schinazi)
             Agenda Bash
             W3C WebTransport Update
          
          Jabber Scribe: Spencer Dawkins
          Note Takers: Lucas Pardue, Amelia Andersdotter and Eric Kinnear
          
          ## WebTransport Use Cases, Will Law
          14:20 - 14:30 (10 minutes)
          
          ### Presentation
          Update on advancements in W3C, timelines, and use cases.
          Have gathered use cases from many different sources and pruned them.
          Examples: Machine Learning (translation, security camera analysis),
          Multiplayer gaming, low-latency streaming (unidirectional broadcast,
          bidirectional WebRTC-like), cloud game streaming, server-based video
          conferencing, remote desktop, time synchronized multimedia web comms,
          IoT sensor and anayltics, PubSub Models (data tickers, messages)
          Use cases may be candidates for QuicTransport or Http3Transport, or both
          Can use cases be solved sufficiently well by existing technologies,
          extending existing technologies? If a new technology is needed is this
          best handled by QuicTransport or Http3Transport?
          Encourage WebTransport to do a few things well rather than attempt to
          cover all possible things.
          Encourage collaboration between IETF and W3C WG
          
          
          ### Discussion
          
          Lucas: About collaboration between IETF and W3C, some folks are familiar
          with both groups but tend to stick to the IETF more than other groups. How
          would you recommend people first reach out?
          
          Will: Chairs will coordinate on a more formal update process so that if
          people miss meetings they can get updates.
          We can invite people to the other group's meetings, hoping for something
          regular and scheduled, will hammer that out with Bernard and David
          
          Lucas: It would really help if things come back to the mailing list,
          even if there's duplication, better to help people avoid missing things
          
          Will: Certainly, want to avoid email overload, but will also seek help
          from folks familiar with the IETF. Also keeping use case document open
          if folks have additional use cases they'd like to raise. Will share
          links and you can file an issue on GitHub as well.
          
          From jabber:
          Mirja
          +1 for a joint IETF/W3C meeting for this :-)
          
          wseltzer
          And your W3C-IETF liaisons are here to help :)
          
          ## WebTransport Overview and Requirements, Victor Vasiliev
          14:30 - 14:50 (20 minutes)
          https://tools.ietf.org/html/draft-vvv-webtransport-overview
          
          ### Presentation
          
          Document goal is to assist coordination between IETF and W3C on design
          of the WebTransport API.
          Draft has been adopted as a WG document,
          please review existing issues on [GitHub
          repo](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues),
          open new ones if anything is not covered.
          
          GH issue
          [#1](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/1):
          stream IDs
            Developers would like to know in what order streams arrived.
            Stream IDs used to be in the draft but were removed due to some hard
            problems: proxying, and information disclosure.
          
          GH issue
          [#2](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/2):
          stream resets
            No consistent stream reset semantics across HTTP versions. Port H3's
            STOP_SENDING to H2? Or just go with H2 style?
          
          GH issue
          [#3](https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/3):
          streams, messages
            WebTransport offers streams of bytes and messages. No capability for
            streams of messages, do we want to ffer this?
          
          There are TODOs in the draft: state machine description depends on #2,
          missing section on priorities
          
          ### Discussion
          
          Bernard: it is important to get clarity on the state machine. We used to
          have a state machine diagram in the API document, which we had to update
          as QUIC evolved. So support updating it. Note that the state machines
          of QuicTransport and Http3Transport are different.
          Victor: two machines, one for transport, one for stream. Transport
          machine we might wwant to extend if we get 0-RTT support.
          
          Yutaka: Regarding messages and byte streams, websocket allows infinite
          size messages, which prevents us from optimization. I don't want to
          introduce such a messaging schema.
          Victor: I agree, personally for #3, since none of our protocols support
          messaging we should just stick with streams. If applications want message
          delineation they can do it themselves
          Yutaka: Thank you
          
          Harald: Do you know what happens if we don't define messages is that we
          will use streams as messages.
          Victor: That's one of the supported ways in which you can operate QUIC
          Bernard: That's how WebTransport provides reliable/unordered transport.
          David: It's possible for the application layer to do this: question
          for WG? Is this a feature to build into WebTransport, or do we
          provide supports for streams and leave the rest as an exercise for
          the application?
          Harald: The focus on bytes is harmful because you end up retransmitting
          stuff as parts of messages in a way which is not optimal. Would rather
          have messages in the protocol itself.
          
          Erik: Having messages has more flexibility for applciations to do
          things. I would prefer these not to be sent in the same packet, in order
          to support FEC.
          Victor: Would Datagram satisfy that problem?
          Erik: I guess so
          Victor: When talking messages, we mean ones that are reliable and span
          multiple packets. If you're willing to use Datagram we can solve those
          problems with some text e.g. anti affinity
          
          Ben Schwartz: I wanted to point out that the WebSocket spec and protocol
          have things in them like binary vs text framing. So it is not just
          enough to create a messaging stream and call it a drop in replacement
          for WebSockets. Wants to remind people that the HTTP/2 WebSocket draft
          also naturally applies to HTTP/3, continues to provide the in order
          behaviour. Let's develop the cleanest protocol we can think of and rely
          on W3C to design an API that helps people migrate.
          Victor: Thanks for the reminder about text vs binary
          David: Browsers aren't going to drop WebSocket support anytime
          soon. Having people still use WebSocket is still an option
          Bernard: What is it important to be compatible with, the WebSockets API
          or the Websockets Protocol? Peter Thatcher built a shim that demonstrated
          the WebSockets API over WebTransport. Also, there is a new API (WebSocket
          Streams) that also uses the Websockets Protocol that is similar to the
          WebTransport API (not message based). Important to be clear what we're
          trying to do.
          
          Ian: Wanted to say that the idea of messages is interesting but it seems
          like there's a few different sets of use cases: ordering vs. head of
          line blocking is desired, putting a message substrate on top of a stream
          does provide head of line blocking but does not make it that easy to
          do out of order delivery because it's hard to find the boundaries of
          messages. Clear requirements on what we need here would be helpful.
          
          Jana: Ian said mostly what I wanted to say. Recommend very lightweight
          streams, could be messages, can have a "begin" and "end" bit for a stream,
          if you have that as part of a message it can all fit in a packet if
          lightweight enough. Design WT streams to be lightweight then you get
          flexibility. ??? will be difficult.
          
          From jabber:
          Magnus Westerlund too: Well SCTP is a transprot protocol that support
          reliable messages, both in and out of order.
          Philipp Tiesel: I definitely second the preference for message streams
          over byte streams
          
          
          ## WebTransport using HTTP/2, Eric Kinnear
          14:50 - 15:05 (15 minutes)
          https://tools.ietf.org/html/draft-kinnear-webtransport-http2
          https://github.com/ekinnear/draft-webtransport-http2/
          
          ### Presentation
          
          Since IETF 107: great feedback, created some [GitHub
          issues](https://github.com/ekinnear/draft-webtransport-http2/issues/),
          updated to a 01 draft
          Concepts:
            Http2Transport provides bidirectional streams that either endpoint
            can initiate. QUIC can do this today. Coexistence with QUIC...
            H2 is missing some things that H3 has: unidirectional streams, Datagrams
            and especially unreliable ones. Clarify how much we care about ordering
            and HoL, who do we expose this to the user i.e. express this via the API
          Aside: Eventually need to decide if we want to spec a QUIC equivalent
          over TCP without HTTP/2.
          
          GH issue
          [#3](https://github.com/ekinnear/draft-webtransport-http2/issues/3):
          new streams without additional roundtrips
            New streams need a CONNECT, requiring one RTT. Do we need a routing
            stream and then stream. H2 might not be present across every hop,
            can we provide an equivalent for each mapping. The question is we we
            want to sovle this problem to open streams quickly.
          
          GH issue
          [#5](https://github.com/ekinnear/draft-webtransport-http2/issues/5):
          unidirectional streams
            Do we want to use half-closed streams (to align with H2's extant state
            machine)? Or simply prevent endpoints from sending data by layering
            the requirement on top in WebTransport? Establishing different types of
            streams requires metadata - does that impact our choices when mapping
            HTTP/3 vs QUIC.
          
          GH issue
          [#6](https://github.com/ekinnear/draft-webtransport-http2/issues/6):
          datgrams
            Reliability: Apps need to know what they requested vs what they
            got. Some options for this: dedicated datagram stream, new frame,
            WTHEADERS per datagram. Be good to think and challenge assumptions.
            Flow control: new frame makes it easier to reason about, interesting
            things can happen when reliable links drop data, outcome may lead us to
            somewhere that we are more comfortable making large changes to protcol.
          
          Stream IDs:
            Resonating with Victor's earlier points. Consistency is key. Goals
            probably prevent us from relying on the stream IDs from anything
            underneath this layer.
          
          ### Discussion
          
          Ian Swett: I think a lot of these questions are really good. How many
          do we need to answer in order to get a technical direction?
          
          Eric: Good question - the first half of this presentation is much of what
          Victor already talked about and we need to collectively decide as a group
          where we want to go. Many of the other things are just implementation
          issues, and we can only decide on those after we decide on the particular
          direction. The big question for today is what the layerings are that we
          want, and what the destination is that we're heading towards. I defer
          to the chairs (David and Bernard) for their thoughts on this.
          
          Bernard: Victor has a presentation later that might touch on these. Any
          thoughts, David?
          
          David: I would not count on the chairs - we lack the authority to decide
          what the priorities are, it needs to be decided through consensus. But
          perhaps we should focus on the presentations we have, and perhaps the
          opportunities for collaboration with W3C.
          
          Bernard: We may need to spend more time. Interim meetings might be needed.
          
          
          
          ## WebTransport over QUIC, Victor Vasiliev
          15:05 - 15:20 (15 minutes)
          https://tools.ietf.org/html/draft-vvv-webtransport-quic
          
          ### Presentation
          
          QuicTransport has a URI scheme
          QuicTransport has an origin trial in Chrome 84-86 -
          https://web.dev/quictransport (QUIC draft 27, draft-29 starting Chrome 85)
          Great Transport Zoo:
            - QuicTransport
            - Http2Transport
            - Http3Transport
            - FallbackTransport (no draft currently)
          
          Want one QUIC-based transport so we can have unrelaible datagrams,
          one TCP-based transport for fallback.
          Decision to support QuicTransport or HttpTransport, or both?
          Slide 44 has Victor's intuition on which would be best for some use cases.
          Advantage of HTTP transport comes from multiplexing, e.g. in a browser
          when a connection exists in a pool reuse it rather than spin up a new
          independent QUIC or TCP connection. However, a dedicated connection can
          be beneficial so this could be controlled at the API layer.
          
          ### Discussion
          
          Ben: slide 44 shows an implication that a dedicated transport is more
          appropriate for use cases with tight performance requirements, at least
          that is my read, this is a speed thing
          Victor: not necessarily speed, better access to transport properties
          such as congestion control
          Bernard: some use cases are p2p, so don't apply to HTTP
          Ben: if performance of multiplexing is a problem, you can chose not to
          multiplex. But if you do multiplex, then a single congestion control
          algorithm can be used to manage both WebTransport and HTTP.
          Victor: interesting point. There is an argument that on the same
          connection that you can do meaningful prioritization
          
          Jonathan Lennox: for HttpTransport is it anticipated that at least
          the client would have to support the HTTP state machine e.g. follow a
           redirect
          Victor: I'll talk about that on the next slide
          
          Ted: going back to what Ben said. I agree with him but have the opposite
          reaction to slide 44. When I look at HTTP and load balancing, I might
          have use cases where I don't want that, because the application has its
          own means for things such as caching. For a use case that doesn't need
          properties provided by the web (such as a datagram request/response
          protocol like what is used in games or DNS), there is a good argument
          for providing QuicTransport that doesn't require them to use the web.
          
          ### Presentation resumes
          
          Advantages of HTTP transports
            - Shared metadata, can reuse HTTP headers and status codes e.g. origin,
            location + 3xx status, forwarded (useful for load balancing),
            :path/:authority/:scheme
            - Counterpoint: similarity of HTTP can lead to wrong expectations.
          
          Disadvantages of HTTP transports
            - Requirements for HPACK and QPACK
            - Multiplexing and socket pools makes things hard in browsers
            - Need to define interaction with existing HTTP mechanisms, especially
            something like Alt-Svc - how to decide when to switch between HTTP
            transports and QuicTransports
            - Pooling and flow control can lead to DoS, example given related to
            stream concurrency
            - Stats are easier to define with dedicated connections
          
          Implementation experience
            - QuicTransport
              - Implemented in Chrome, various server implementations, easy to
              implement on an existing python library
            - HttpTransport
              - Implementations at Apple and Facebook, no in-browser clients yet
          
          Use cases
            - Both options satisfy WebTransport requirements: datagrams and streams
            - Other aspects make each individual transport a better fit
              - HTTP-based options help operators of large server setups
              - Implementers work on niche platforms where it is useful to
              minimise complexity and implementation requirements, so preference
              for QUIC-based option
          
          Beyond wire protocol
            - What URL scheme? Determines whether WebTransport and HTTP are
            same-origin
            - High level concerns: cookies, HTTP auth, TLS client certs, Alt-svc
            and socket pools
          
          Next steps
            - Current discussion is between two options "only QUIC", "only HTTP"
            - Need more input, continue discussion on list, potential focus of
            an interim?
          
          ### Further discussion
          
          Yutaka: I didn't mention on mailing list, I am not opposed to having
          both QuicTranport and HttpTransport
          
          David: interested in folks that have opinions on which protocols they
          want to build, so we can start making progress
          
          Phillip Tiesel: question whether the transports are end-to-end or if
          proxies can convert protocols
          Victor: possibly. Converting between H2 and H3 is
          straightforward. Converting H3 and QUIC is harder because we'd need to
          describe how to map things like metadata. If metadata is available to
          both, we'd need to understand why there is an advantage to defining both.
          
          Erik: it would seem preferable to avoid having all four and avoid the
          pressure to implement all 4. It would be easier/more flexible to use
          reuse headers etc so the H2/H3 model seems better. Ben's mention of a
          profiled HTTP seems like a option.
          Ben: I wonder how hard it would be to expose the WebTransport semantics
          in ??? raw framing
          Victor: it would not be that hard
          Ben: we should make it possible to implement as either endpoint without
          having to implement a full HTTP stack. For example, I could write a simple
          Http3Transport client that could even speak to a full HTTP server that
          is also an Http3Tranport.
          Ted: I tend to think it is entirely possible to define such a profile
          for a client. But I don't think there a good chance that it will *only*
          go into an environment that would treat it special/ any different
          to any other HTTP client. Build on a bare transport would avoid
          this. ??? middleboxes
          
          From jabber:
            Ben: can we profile down Http3Transport for Webtransport-only use cases
            e.g. minimise required methods i.e. make it possible to implement a
            WebTransport-only server
            Eik: Upside to muxing: lots of those apps (IoT/streaming/etc) also
            make HTTP API calls today and may continue to do so. Downside to muxing
            with H2/H3: some non-spec-compliant clients/servers will (continue to)
            make bad assumptions about multiple requests sharing a connection and
            having connection-associated state.
          
          ## WebTransport over HTTP/3, Victor Vasiliev
          15:20 - 15:35 (15 minutes)
          https://tools.ietf.org/html/draft-vvv-webtransport-http3
          
          ### Presentation
          Rolled into previous segment
          ### Discussion
          Rolled into previous segment
          
          ## Wrap up and Summary, Chairs & ADs
          15:35 - 15:50 (15 minutes)
          
          Bernard: Please help in answering these questions by continuing discussion
          on the list. An interim meeting may be in order.
          David: Will take a lot of these questions to the list. Interim will also
          be discussed on the list.
          
          Thank you everyone!