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

Hi Marten,

In the room on Thursday, even though it seemed like the majority of folks
prefered (2), there were some folks who preferred (1) over (2) but everyone
could live with (2) whereas some folks said they couldn't live with (1)
because they really didn't want to implement flow control and didn't want
to use pooling. Additionally, the browser implementers in the room said
they would be implementing flow control, and the chairs said we'd want to
confirm that flow control works in the real world before publishing the
documents. Given this information, can you also live with (2) ?

Your point about how to negotiate support for pooling is worth discussing
though, I think we might need to build an explicit mechanism here. If this
consensus call succeeds, we'll open a separate issue about how pooling is
disabled, and we'll make sure it's discussed in Brisbane.

Thanks,
David

On Fri, Feb 23, 2024 at 2:38 AM Marten Seemann <martenseemann@gmail.com>
wrote:

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