# IETF 111 WEBTRANS WG Agenda
          Friday, July 30, 2021
          12:00 - 14:00 Pacific Time
          Session I, Room 1
          Chairs: Bernard Aboba and David Schinazi
          
          IETF 111 info: https://www.ietf.org/how/meetings/111/
          Meeting URL: https://ws.conf.meetecho.com/conference/?group=webtrans
          Etherpad: https://codimd.ietf.org/notes-ietf-111-webtrans
          Jabber:  https://jabber.ietf.org/jabber/logs/webtrans/2021-07-30.html
          Slides:
          https://datatracker.ietf.org/meeting/111/materials/slides-111-webtrans-ietf-111-webtrans-wg-slides
          
          ## Preliminaries, Chairs (10 minutes)
          Minutes: Mike Bishop
          
          ## W3C WebTransport Update, Will Law (10 minutes)
          
          There are media protocols looking at going directly over QUIC.
          Why not WebTransport?  Are there API gaps?
          
          Request we resolve:
          - Priorities between streams, datagrams, etc.
          - Error code spaces that should be surfaced
          
          ## WebTransport over HTTP/3, Victor Vasiliev (40 minutes)
          https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3
          
          New -01 draft post-110, notably has type-value (no length) frames and
          no requirement to wait for handshake to complete (requires buffering).
          
          Martin:  What if people don't want to buffer?
          Victor:  Stream gets closed, would have to restart.
          
          Issue discussion:
          #10: Need a consistent stream ID across proxies?  Think we decided no,
          but can't find that written down.
          
          No objection in room.  Speak up in the next week if you object.
          
          #31: PR#40 should resolve; allocated error code subspace within H2 and
          H3 space. Error code transport is best effort across intermediaries.
          
          Agreement in room that best effort is sufficient.
          
          #34: MAX_WT_SESSIONS seems to be the conclusion on the issue.
          
          Alan:   This is an option, but it seems like the most complex of our
          options. Masque doesn't have this. How critical is it to have a limit?
          Victor: Not critical, but some people want only one session per
          connection.
          Martin: Resource management can get tricky with multiple sessions on
          the same connection. Should have a limit of some kind. So should Masque.
          Luke:   Using connection-level stats to make decisions about session. We
          currently refuse all extra sessions; would be nice to tell browser
          up-front.
          Alan:   Not necessarily objecting, but this seems similar to H3
          MAX_PUSH_ID. Is this max simultaneously or max ever?
          Luke:   For us, simultaneous. A new one later is fine.
          Alan:   If it's max concurrent, you run into reordering concerns.
          Victor: Let's design that on the issue.
          
          Victor will write PR for MAX_WT_SESSIONS.
          
          #32: When do we close for invalid IDs?
          
          Alan:   Fine, some obvious connection error cases. Be careful of
          reordering, though.
          MT:     Are we requiring or allowing a connection error? #1 we can
          require, #2 perhaps we can just allow.
          
          MUST close for #1, MAY close in 2-3.
          
          #39: Setting; has a PR, please review.
          
          #40: Allocated error codes for stream; please review.
          
          #41: Error codes for session. Modeled off QUIC CONNECTION_CLOSE; see
          PR#60. Uses Capsules, which will likely wind up inside DATA frames.
          
          Alan:   Do you also need something like GOAWAY's stream IDs to allow
          for draining, or will that be a separate capsule?
          Victor: Probably a separate capsule; there's an issue for GOAWAY.
          Lucas:  Is this more like CONNECTION_CLOSE or a RESET_STREAM -- who's
          asking for the error message?
          Victor: Application might want to reliably communicate error message.
          David:  Capsule encoding is changing, but capsules aren't gone. Using
          capsules is fine.
          
          No objection to general idea in room.
          
          #42: What status code accepts session? PR#58 says 2XX; please review.
          
          #48: Make unidirectional streams use frames; no PR yet.
          
          #50: Connection throttling. Should we have text about this, or leave it
          to API?
          
          MT:     Everyone should limit connections, but servers are less able
          to identify when connections are from the same client.  Needs further
          study. Recommend that it happens, but don't build specific mechanism here.
          
          No further comments, so Victor will write proposal.
          
          #54: Datagram context IDs; currently not needed, but potential for
          extensions.
          
          David:  Clarification that there's always a context, but there can be
          either a single context or multiple.
          MT:     Let's just say we don't currently use contexts. Why would we?
          David:  Example for WT is priorities.
          MT:     No way to expose in W3C API; let's just leave this alone. Question
          whether context IDs are useful.
          David:  We're skewing into H3-Datagrams -- take that to Masque.
          
          Discuss on issue, refer design of H3 Datagram contexts to Masque.
          
          ## WebTransport using HTTP/2, Eric Kinnear (40 minutes)
          https://datatracker.ietf.org/doc/html/draft-ietf-webtransport-http2
          
          Integrating into H2 versus riding over H2? H3 has new frames and stream
          types, uses H3 datagrams, etc. H2 does multiplexing, forces ordering
          and reliability, etc.
          Leads to introducing new H2 frames.  WT_DATAGRAM frame that looks like
          an H3 datagram.  WT_STREAM frame semantically equivalent to HEADERS,
          but can be sent by server.  Effectively integrated into H2, meaning this
          requires changes to H2 instead of an H2 implementation off-the-shelf.
          
          Four new frames introduced, bringing some H3 semantics to H2. MT adds
          that this changes state machine, which gets awkward.
          Conceptually, this is not QUIC over TCP.
          
          #25: Follow Masque on how to transport datagrams
          
          Currently, that means CONNECT body is a capsule stream, and there's a
          DATAGRAM capsule type.
          
          Should streams be defined inside capsules?  If so, it makes H1 support
          easier, and maybe HTTP/2 streams are an optimization.
          
          Is proxying through generic H2 intermediaries a requirement?
          
          ### Layered vs. Integrated
          
          MT:     In Masque, we decided to layer on top of HTTP and
          opportunistically use native transport features where available. That way,
          you have a baseline that works, with some possible upgrades. Don't want
          to spend effort on HTTP/2 implementation; QUIC flow control is relatively
          simple, and reimplementing that might be easier than messing with the
          HTTP/2 stack.
          Ian:    Strong support for running over HTTP/1.  Experience with protocols
          that over-integrate with H2, and that makes deployment more difficult
          in a general-purpose proxy. QUIC over reliable stream, or QUIC/TCP,
          has valuable use cases.
          Eric:   If you were doing QUIC over TCP, would you also do H3 over TCP?
          Ian:    Not currently.
          Victor: Used to think we should bring H2 state machine to H3 for WT;
          less enthusiastic now. Old presentations for WT had four protocols: H3,
          H2, QUIC, WebSocket. WS never really advanced; no practical interest. But
          now that sounds more appealing.
          Eric:   Not the same; we chose to build on top of HTTP, not on top of
          raw transport protocols.
          Victor: Don't want to remove HTTP, but pointing out that this idea didn't
          have interest before.
          Luke:   Legacy systems have HOLB; we want to get rid of that using
          WT. H3 will cover 95% of our users. What's our simplest way to serve
          the remaining 5%? Don't want to rewrite HTTP/2 stack; be as simple
          as possible.
          Eric:   Also points to other QUIC use-cases that would like a ready-made
          fallback.
          Alan:   Is H2's resource management adequate for WT? Sounds like most
          people don't want to tinker with their H2 stack.
          Victor: We're shipping non-pooled first, and resource management matters
          more with pooling. TCP also used intra-datacenter, and other cases UDP
          is blocked.
          
          Lots of support for on top of HTTP, rather than inside HTTP/2.
          Would people be willing to write up, help implement?
          
          Alan:   First step is producing a document; MT took an early stab.
          Would consider implementing at next Hackathon.
          Mike B.:Is there much different from being inside CONNECT body vs. native
          H2? H3 difference is real.
          MT:     Slight difference in encoding efficiency, but it's unclear which
          way that goes.
          Alan:   High RPC use cases might see a performance impact. It's unclear
          anyone cares. Could build extension later if useful.
          Ian:    If we think 95+% will use H3, do we really care about H2 perf
          if it's "acceptable"? If you want perf over TCP, consider H1.
          
          Strong support for moving to a layered approach.
          
          ### CONNECT-*?
          
          WT and Masque are both using some version of CONNECT -- Extended CONNECT,
          CONNECT-UDP, CONNECT-IP, etc. How to reconcile?
          
          MT:     CONNECT with :protocol is probably cleaner. Care about being
          able to use a URL that indicates the resource rather than the target,
          but any of these will work.
          David:  +1, will discuss on Masque list.
          Victor: Extended CONNECT is consistent with WebSockets; represents
          resources on the wire. WT should not change; Masque can do what it wants.
          Lucas:  Having tried both, I call them all "CONNECT streams"; doesn't
          matter.
          MT:     Some people in HTTPbis have an allergic reaction to extended
          CONNECT; make sure HTTP list is involved.
          Mike:   Is RFC 8441 Standard or Experimental?
          MT:     Standard; we're fine.
          
          ## Hums, Wrap up and Summary, Chairs & ADs (20 minutes)
          
          David: Consensus in the room to unify on having WebTransport-over-TCP
          built atop HTTP semantics, with version-specific optimizations. We'll
          confirm that on the list.