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

Hi Marten, do you have any thoughts on my previous email?
Thanks,
David

On Mon, Feb 26, 2024 at 6:25 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

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