**Session Date/Time:** 24 Mar 2022 13:30

# webtrans

## Summary

The webtrans working group met to discuss updates from the W3C WebTransport API, key issues concerning WebTransport over HTTP/3, and WebTransport over HTTP/2. Discussions included the W3C API status, implementation challenges, session pooling and resource limits for HTTP/3, and the use of capsules versus TLVs for HTTP/2, with a particular focus on the implications for intermediaries and end-to-end semantics. Decisions were made regarding graceful session termination, GoAway behavior, stream closure, and resource limits for pooling, while a new design team was formed to tackle the capsule unification for HTTP/2 and HTTP/3. Stream prioritization was acknowledged as primarily an API concern.

## Key Discussion Points

### W3C API Update (Will Law)

*   **Progress:** The WebTransport API specification is now a Working Draft (March 11, 2022).
*   **Timetable:** An optimistic timetable aims for Candidate Recommendation (CR) soon, with a Proposed Recommendation (PR) by July 31st, requiring at least two independent implementations.
*   **Implementation Blocker:** Chrome has shipped (M97), but Mozilla has not yet signaled a date for their implementation, challenging the July 31st PR target. The charter may be extended if needed.
*   **Milestones:** Adjusted to match the release process, with a new "Candidate Recommendation" milestone.
*   **Key Decisions (Resolved Issues):**
    *   Clients should not provide credentials when establishing a session.
    *   Blocking ports on `fetch`'s bad ports list.
    *   Adding smooth RTT variation to `WebTransportStats`.
    *   Adding `packetsLost` to `WebTransportStats`.
    *   Extra requirements on server certificate hashes.
    *   `WebTransportGetStats` additions: `expiredOutgoing`, `droppedIncomingDatagramsLost`.
    *   Stream stats will be individual `getStats` methods on each stream instance.
    *   Decisions around reliability, fallback, and constructor arguments (`requireUnreliable` vs. `requestReliable`).
    *   Content Security Policy (CSP) compatibility break with early Chrome versions for future stability.
    *   Datagram priority over streams: Changed to normative language ensuring user agents prioritize datagrams quickly, replacing an absolute "always go first" rule.
*   **Current Issues Under Debate:**
    *   Bike-shedding names for stream stats.
    *   Connection pooling: Default on or off, constructor configuration.
    *   Priorities between streams: Is this necessary, and does IETF intend to define a method that filters to the browser level?

### Priorities Discussion

*   **IETF Input Sought:** W3C asked for IETF input on stream prioritization.
*   **Schemes:** HTTP (8 levels) and WebRTC (4 levels) were mentioned as potential models.
*   **API vs. Wire Protocol:** General consensus that stream prioritization is largely an API concern (how web applications signal priorities to the browser), rather than a core wire-protocol problem for the IETF WebTransport WG, unless end-to-end signaling is strictly required.
*   **Application-Level Solutions:** It was noted that applications can use WebTransport streams/datagrams to signal priority themselves.
*   **Use Cases:** A use case for dynamically prioritizing newer over older media segments (e.g., video/audio) was presented, which might require more flexible control than a small fixed set of priorities. This would require browser support for client-side sending.
*   **Congestion Control:** Discussion touched upon desired control over congestion control algorithms (e.g., BBR, Google CC) and the potential for hints in the API.
*   **W3C Issue 62:** Participants were encouraged to comment on W3C issue 62 for further discussion on priority.
*   **Conclusion:** The WG reiterated its philosophy to focus on shipping a functional WebTransport and defer application-layer concerns or advanced features (like fine-grained congestion control) to future versions or extensions if current API/protocol capabilities prove insufficient.

### WebTransport over HTTP/3 and HTTP/2

*   **Overview Draft (Victor Vasiliev):**
    *   The overview draft needs updating to abstract common operations between HTTP/3 and HTTP/2 WebTransport implementations. A pull request is in progress.
*   **Graceful Session Termination (GoAway):**
    *   Need a mechanism for intermediaries (e.g., reverse proxies) to signal a graceful shutdown of WebTransport sessions. A `DRAIN_WEBTRANSPORT_SESSION` capsule was proposed.
    *   **Decision:** Alan Frindell will author a Pull Request for a `DRAIN_WEBTRANSPORT_SESSION` capsule.
*   **GoAway and WebTransport Session Creation:**
    *   HTTP/2 `GOAWAY` prevents new streams on the HTTP/2 connection but allows existing streams to finish. For WebTransport, this means no *new* WebTransport sessions can be created on the underlying HTTP/2 connection, but *existing* WebTransport sessions can still create their own streams. This behavior should be preserved for HTTP/3.
    *   **Decision:** Consensus to maintain this behavior: `GOAWAY` means no new WebTransport sessions, but existing sessions can continue creating their internal streams.
*   **Closing Connect Stream:**
    *   Current draft behavior: Closing the `CONNECT` stream automatically terminates everything in the WebTransport session. This was suggested to be revisited for potentially allowing internal streams to remain open.
    *   **Discussion:** Keeping the current semantics (closing `CONNECT` stream terminates everything) simplifies resource lifecycle management and is consistent with QUIC connection closure.
    *   **Decision:** Consensus to keep the current semantics where closing the `CONNECT` stream automatically terminates the WebTransport session.
*   **Alt-Svc Header Handling:**
    *   Question: How should `Alt-Svc` headers affect WebTransport?
    *   **Discussion:** `Alt-Svc` in a response should not impact an active WebTransport session. Broader `Alt-Svc` interactions with connections are typically handled by the HTTP working group.
    *   **Decision:** The WebTransport draft will consider `Alt-Svc` interactions outside its immediate scope, deferring to HTTP WG.

### Pooling and Resource Limits for HTTP/3 (Eric Kinnear)

*   **Goal:** Support multiple WebTransport sessions within a single HTTP/3 connection and allow coexistence with regular HTTP requests.
*   **HTTP/2 vs HTTP/3:** Less of an issue for HTTP/2 as each session is encapsulated in a `CONNECT` stream. HTTP/3 needs more specific mechanisms as WebTransport uses native H3 streams.
*   **Proposal:** Implement necessary resource limits to prevent one WebTransport session from unfairly dominating the H3 connection. No preclusion of future enhancements.
*   **Existing Flow Control:** H3 inherits stream-level flow control from QUIC (`MAX_STREAM_DATA`, `MAX_STREAMS`).
*   **Additional Needs:**
    *   **Maximum Session Count:** Limit the number of WebTransport sessions (e.g., via a `WEBTRANSPORT_MAX_SESSIONS` setting).
    *   **Maximum Streams per Session:** Limit the number of streams a single WebTransport session can open.
    *   **Maximum Data per Session:** Limit total data across all streams within a WebTransport session.
*   **Discussion on Max Data per Session:** This was deemed technically very challenging, potentially requiring significant architectural contortions or layer violations with QUIC.
*   **Decisions on Pooling:**
    *   **Limit total WebTransport session count via settings:** Consensus (e.g., a `WEBTRANSPORT_MAX_SESSIONS` setting).
    *   **Limit max streams per WebTransport session:** Consensus to *attempt implementation* by authoring a PR, acknowledging potential difficulties.
    *   **Limit total data per WebTransport session:** Consensus that this is too hard currently. The issue will be closed, and can only be reopened if a concrete, implemented design is presented to the WG.

### WebTransport over HTTP/2 (Eric Kinnear)

*   **Progress:** Many changes discussed at IETF 112 have been landed. The HTTP Datagram design team concluded, unblocking further work.
*   **Sending Frames Before CONNECT Response:**
    *   Current text: Frames can only be sent *after* receiving a 200 OK response to the initial `CONNECT` request.
    *   **Proposal:** Allow sending frames before the `CONNECT` response, subject to flow control. This reduces RTT and allows server-initiated streams to start sooner.
    *   **Decision:** Consensus to allow sending frames before the `CONNECT` response is received.
*   **Capsules vs. TLVs:**
    *   **Context:** HTTP Datagrams now define a `DATAGRAM` capsule. Current H2 WebTransport uses TLVs for its frames.
    *   **Proposal:** Switch to using capsules for H2 WebTransport frames.
    *   **Benefits:** Can reuse the `DATAGRAM` capsule. Potentially reuse `MAX_STREAMS` and `STREAMS_BLOCKED` capsules (if defined for H3).
    *   **Core Issue: End-to-end vs. Hop-by-hop:** TLVs were hop-by-hop. Capsules are conceptually end-to-end but can be converted by intermediaries (e.g., `DATAGRAM` capsule to native datagram). How does this affect stream-related control (which is inherently hop-by-hop)?
    *   **Discussion:**
        *   Intermediating stream constraints between H2 and H3 is complex; it might be better to treat H2 and H3 WebTransport as different protocol segments for an intermediary.
        *   The `end-to-end` property of capsules is the litmus test; if it's harmful for certain control frames, they shouldn't be capsules.
        *   While H2 TLVs are wire-format compatible, the semantic implications of a shared registry and end-to-end behavior need careful consideration.
    *   **Conclusion:** This is a complex issue requiring further focused work.

## Decisions and Action Items

*   **`DRAIN_WEBTRANSPORT_SESSION` Capsule:** Alan Frindell to author a Pull Request for this new capsule.
*   **GoAway Behavior:** Keep current semantics: `GOAWAY` prevents new WebTransport sessions, but existing sessions can continue creating new streams.
*   **Closing `CONNECT` Stream:** Keep current semantics: Closing the `CONNECT` stream automatically terminates the WebTransport session.
*   **WebTransport Pooling for HTTP/3:**
    *   **ACTION:** Eric Kinnear to author a PR for a `WEBTRANSPORT_MAX_SESSIONS` setting (or similar) to limit the total number of WebTransport sessions.
    *   **ACTION:** Eric Kinnear to author a PR for limiting the maximum number of streams per WebTransport session, with the understanding that implementation experience will determine feasibility.
    *   **DECISION:** The issue of limiting total data per WebTransport session will be closed as too complex for now, to be revisited only with a concrete, implemented proposal.
*   **HTTP/2 Frame Sending:** Allow sending frames before the `CONNECT` response is received. (Action: Eric Kinnear to update draft).
*   **Capsule Unification for HTTP/2 and HTTP/3:** A design team will be formed to explore the use of capsules for WebTransport over HTTP/2, addressing end-to-end vs. hop-by-hop semantics and unification with H3 capsule definitions.

## Next Steps

*   **Design Team for Capsules:**
    *   Chairs will send an email to the mailing list asking for volunteers for this design team.
    *   Eric Kinnear has volunteered to lead this design team.
    *   The team will aim for a rapid iteration, potentially leading to an interim meeting for discussion.
*   **W3C Issue 62 (Priorities):** Participants interested in stream prioritization should engage with W3C issue 62.
*   **Pull Requests:** Authors of PRs (Alan Frindell, Eric Kinnear) should proceed with drafting and submitting them.