Markdown Version | Session Recording

Session Date/Time: 26 Jul 2022 14:00

webtrans

Summary

The WebTransport working group session at IETF 114 covered updates on the W3C WebTransport API specification, discussions and proposed resolutions from the Capsule Design Team for WebTransport over H2 and H3, and several open issues for the WebTransport over H3 specification. Key discussions revolved around congestion control APIs, stream prioritization, flow control mechanisms for capsules, and various H3 stream semantics. Several issues were resolved, with others deferred to the mailing list for further input.

Key Discussion Points

W3C WebTransport API Progress Update (Jan-Ivar Bruaroey)

• Progress: Published a new working draft (June 23rd). A charter extension is underway for an additional year.
• Revised Timeline: Aiming for Candidate Recommendation by end of September (requiring API stability) and Proposed Recommendation by end of year (requiring two independent implementations). Call for review in February, publication by April.
• Milestones: Three remaining issues for initial implementation, 10 open issues for Candidate Recommendation (6 ready for PR).
• Recent Decisions:
  • Added per-stream stats (bytes written, sent, acknowledged for duplex streams).
  • Reduced datagram priority algorithm to normative guidance, leaving details to implementation.
  • Added datagram stats (dropped too big, dropped incoming, lost outgoing) as a subdirectory of getStats.
  • WebTransport constructor now supports requireUnreliable boolean (defaults to false), allowing applications to specify a preference for UDP. A read-only property exposes the chosen transport.
  • Connection pooling still defaults to false.
• Current Issues of Debate:
  • Congestion Control API: Discussion on providing constructor-level configuration. Two main proposals:
    1. Highly abstract input (e.g., throughput (default) vs. low-latency).
    2. API to expose names of available congestion control algorithms, allowing specific selection.
    • Extensive discussion highlighted the complexity of low-latency vs. throughput, potential for pathological behavior, and the need for experts' input. Concern was raised about over-complicating for average developers versus providing fine-grained control for expert applications (e.g., Zoom, WebEx, Twitch). IETF members were strongly encouraged to provide input on the W3C GitHub issue.
  • Datagrams vs. Streams and Relative Prioritization: Discussion on ordering vs. bandwidth allocation. Observations indicate ordering requires strict (not weighted) levels. Use cases include per-frame media, high-level control channels, real-time A/V, and background downloads. Proposals include:
    1. Exposing at least 8 resettable priority levels (matching browser behavior), assuming active JavaScript involvement.
    2. Providing an upfront API for specifying fixed levels (requested by Warp, Chrome to investigate int32 number of levels).
  • Expose Stats for JavaScript: Debate on what stats are needed for JavaScript to build RTP-like real-time protocols (client-to-server A/V). Primarily for datagrams or connection level. Current datagram stats detail loss. Looking for input on necessary stats (e.g., RTT, packet departure/arrival, ECN, ACK info) and experimental data.

Capsule Design Team for H2 and H3 (Eric Kinnear)

• Objective: Define a consistent approach for capsules across WebTransport over H2 and H3, especially for shared concepts like datagrams.
• Datagram Capsule (Exploding):
  • Proposal: Require anything that can be sent as a native feature (e.g., H3 datagram) must be sent as a native feature. If native feature is not available (e.g., H2), it is sent as a capsule on the H2 stream. This avoids implementations needing to handle the same conceptual data in multiple encapsulation forms.
  • Discussion: Clarified that the WEBTRANSPORT upgrade token implies capsule support. If the underlying transport (Quick) does not support datagrams (e.g., no transport parameter), WebTransport datagrams will not function. The consensus was to require datagrams if available and treat WebTransport without datagrams as a limited (or broken for datagram-dependent applications) scenario.
• Capsule Protocol Header Field: The WEBTRANSPORT upgrade token implies that capsule support exists.
• Flow Control:
  • Max Sessions: Proposed WEBTRANSPORT_MAX_SESSIONS setting replaces ENABLE_WEB_TRANSPORT. Setting to zero disables WebTransport; otherwise, it specifies the maximum number of concurrent sessions.
  • Stream Limits within a Session (MAX_STREAMS): Proposed a MAX_STREAMS capsule to limit streams within a WebTransport session, addressing the issue of one session consuming all H3 connection-level stream budget.
    • Discussion: Acknowledged an issue where streams closed before being fully opened (e.g., due to reset) could leak stream credits if not carefully accounted for, especially in H3 due to potential out-of-order delivery.
    • Debated the necessity of this protocol-level limit versus client-side browser management.
  • Byte Flow Control (MAX_DATA): Proposed not to add additional complexity for byte flow control beyond H3's native mechanisms. The existing H3 connection and stream-level flow control provides sufficient knobs, and further complexity is not justified without proven need.
  • Intermediaries: Flow control is conceptually terminated at each intermediary (hop-by-hop). Intermediaries are responsible for the limits they advertise and must manage buffering. This simplifies the protocol definition but places responsibility on intermediary implementers.

WebTransport over H3 Issues (Victor)

• Status Update: Overview draft merged. Minor updates to the H3 spec (e.g., clarify GOAWAY handling, session teardown). Roughly half of the 10 remaining issues are editorial or near PR.
• HTTP Redirects:
  • Issue: RFC 9205 requires explicit guidance on HTTP redirects for CONNECT requests. Browser behavior currently does not automatically follow them.
  • Discussion: Strong preference for either MUST or MUST NOT to ensure determinism. Many implementers expressed an assumption of MUST follow redirects, citing the utility for resource management and consistency with other HTTP requests. Concerns were raised about the semantic weirdness of redirects for CONNECT and past issues with WebSockets.
  • Resolution: No consensus in the room. Discussion deferred to the mailing list.
• Stream Frame Ordering:
  • Issue: For bidirectional WebTransport streams, should any frames be allowed before the WEBTRANSPORT_SESSION frame? Unidirectional streams effectively forbid this already.
  • Discussion: Arguments for disallowing any preceding frames for consistency with unidirectional streams and to simplify implementation. Allowing other frames could lead to confusion or incorrect parsing by HTTP/3 endpoints assuming a request stream.
  • Resolution: Resolved to disallow any frames before the WEBTRANSPORT_SESSION frame for both unidirectional and bidirectional streams for consistency and implementation simplicity.
• Stream Reset before Peer Associates:
  • Issue: A WebTransport data stream can be reset before the peer knows it's a WebTransport stream or can associate it with a session, potentially leading to a "half-open" stream and resource leaks.
  • Discussion: While H3 has general mechanisms for dealing with incomplete requests, this is more specific to WebTransport's session context. A suggestion was made to introduce a reliable control stream message (a "reset capsule") to explicitly account for such resets.
  • Resolution: Resolved to add a reliable control stream message (e.g., a "reset capsule") to explicitly account for streams that are reset before the peer fully associates them with a WebTransport session.
• WebTransport Session Closure:
  • Issue: Lack of clear specification on how WebTransport sessions are closed. Two proposals: 1) Send close capsule, FIN, peer responds with FIN. 2) Send close capsule, FIN, STOP_SENDING. Both imply a timer for teardown if the peer doesn't respond.
  • Discussion: Value in waiting for application-level acknowledgment (Proposal 1) vs. immediately indicating no further interest (Proposal 2). Quick's CONNECTION_CLOSE provides precedent for a definitive unilateral close. It was suggested that both options might be valid depending on application needs.
  • Resolution: Resolved to document both methods for session closure, allowing either side to send a close capsule and FIN independently. The receiver can then choose to respond with a FIN or STOP_SENDING based on its intent to process further data.

Decisions and Action Items

• W3C WebTransport API:
  • IETF members are strongly encouraged to provide input on the W3C GitHub issues, especially for the Congestion Control API and Prioritization API.
• Capsule Design Team for H2 and H3:
  • Decision: H2 will use capsules. H3 will use capsules and share with H2 where appropriate.
  • Decision: Capsules will always use native features if possible (e.g., H3 datagrams must be sent as H3 datagrams). If a native feature is not available (e.g., H2), a capsule is used.
  • Decision: The WEBTRANSPORT_MAX_SESSIONS setting will replace ENABLE_WEB_TRANSPORT, allowing more granular control over session limits.
  • Decision: H3 will include a stream count limit within a session (MAX_STREAMS capsule).
  • Decision: No additional byte flow control complexity will be added beyond H3's native flow control.
  • Decision: Intermediary flow control for WebTransport is hop-by-hop. Intermediaries are responsible for advertised limits and buffering.
  • Action Item (Eric Kinnear): File a GitHub issue for continued discussion on whether datagram support is mandatory for WebTransport sessions.
  • Action Item (Eric Kinnear): File a GitHub issue for further discussion on stream count limits (MAX_STREAMS) within a session.
  • Action Item (Eric Kinnear): Send links to the two relevant Pull Requests (H2 and H3 capsule changes) to the mailing list for review.
  • Action Item (Chairs): Initiate a formal consensus call on the capsule design team PRs once they are ready and reviewed.
• WebTransport over H3 Issues:
  • Action Item (Victor): Continue discussion on HTTP redirects for WebTransport over H3 on the mailing list, actively seeking input from those who expressed objections.
  • Decision: For WebTransport over H3 bidirectional streams, the WEBTRANSPORT_SESSION frame MUST be the first frame on the stream, disallowing any other frames before it for consistency and simplified implementation.
  • Decision: A reliable control stream message (e.g., a "reset capsule") will be added to the WebTransport over H3 specification to explicitly account for streams that are reset before the peer fully associates them with a WebTransport session.
  • Decision: Both methods for WebTransport session closure (send close capsule + FIN; peer responds with FIN; OR send close capsule + FIN + STOP_SENDING) will be documented as valid options, with clarified semantics.

Next Steps

• The working group is encouraged to review the Pull Requests related to the Capsule Design Team's output and provide feedback on the mailing list.
• Further discussion on the HTTP Redirects issue for WebTransport over H3 will continue on the mailing list.
• Editors will continue to work on other open issues and PRs for the H3 specification.
• The chairs will assess progress on the remaining issues and PRs, and potentially organize an interim virtual meeting if a face-to-face discussion would be beneficial before the next IETF meeting.