Re: [Webtransport] Summary of today's interim and consensus call

I support the decision to add flow control to WebTransport, that is option
(C) or (D), and I think (D) is a very reasonable way to achieve this goal.

I'm a bit skeptical regarding (1) vs. (2), mainly because I'm not sure I
understand how client and server will negotiate support for pooling. This
is because pooling in this context means something slightly different
than SETTINGS_WEBTRANSPORT_MAX_SESSIONS > 1: Pooling here also means
sending HTTP/3 requests on the same QUIC connection. Or is the proposal to
redefine SETTINGS_WEBTRANSPORT_MAX_SESSIONS <= 1 to mean that the
connection can't be used for HTTP requests as well? What happens to
existing HTTP requests that might be in flight while the WebTransport
session is established?

Maybe I'm too pessimistic, but I'm a bit worried that browsers wouldn't
bother to support the flow control mechanism, and as a result it would be
largely unused (and untested). From a protocol design perspective, it might
be favorable to not split WebTransport into two distinct variants, one with
and one without flow control. With that argument, (1) might be preferable.

On Fri, 23 Feb 2024 at 09:56, David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> Hi WebTransport enthusiasts,
>
> Thanks to everyone who joined today's virtual interim meeting. Our main
> discussion point was flow control [1]. We discussed the following questions.
>
> First, we discussed four options:
> A) Do nothing
> B) Add “hints” suggesting flow control breakdown
> C) Add flow control to groups of QUIC streams
> D) Add flow control to WebTransport over HTTP/3
>
> Second, we discussed four potential approaches:
> 1) Adopt a flow control mechanism now; make it always mandatory.
> 2) Adopt a flow control mechanism now; make it mandatory for pooling
> (browsers won’t pool if the mechanism is not supported).
> 3) Defer flow control; ship the current version of the draft, ship an
> extension that would be prerequisite for pooling support in browsers later
> (gives us more time).
> 4) Do nothing (existing QUIC flow control is sufficient).
>
> We managed to reach consensus in the room that everyone could live with
> (D) and (2). What this means in more detail:
> * pooling means any time a WebTransport session shares resources with
> anything else in the same HTTP connection (anything else could be a second
> WebTransport session, or a regular GET request)
> * pooling can only be used when flow control is supported by both endpoints
> * flow control in WebTransport will use [2]
> * clients can choose to not implement flow control, then they MUST NOT pool
> * servers can choose to not implement flow control, then they MUST send
> a WEBTRANSPORT_MAX_SESSIONS setting with value <= 1 to disable pooling
>
> There is also more information available on the slides presented today [3]
> and in the minutes [4]. The recording of the session will also be posted on
> YouTube within a few days.
>
> As chair, I'm formally starting a WG consensus call to confirm this
> decision. If anyone objects to this outcome, please say so in reply to this
> email. This consensus call will last for roughly two weeks and will end on
> Friday March 8th, 2024 at 23:59 UTC.
>
> Thanks,
> David
>
> [1]
> https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3/issues/85
> [2] https://datatracker.ietf.org/doc/draft-thomson-webtrans-session-limit/
> [3]
> https://datatracker.ietf.org/meeting/interim-2024-webtrans-02/materials/slides-interim-2024-webtrans-02-sessa-webtrans-wg-virtual-interim-slides-04.pdf
> [4]
> https://datatracker.ietf.org/doc/minutes-interim-2024-webtrans-02-202402222100/
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>