# 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.