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

[David Schinazi <[e-mail]>]

Thank you Marten, much appreciated.

Editors, I think it would be great for us to discuss PRs in Brisbane to
land the changes in this thread into the specs.

David

On Tue, Mar 5, 2024 at 1:54 AM Marten Seemann <[e-mail]>
wrote:

> Hi David,
>
> My concern that two variants of the protocol (and a way to negotiate one
> of them) will end up complicating things more than necessary still stands,
> but this depends on the exact protocol mechanism that we still need to
> design.
>
> I don’t mean to block progress here, so I suggest we proceed with the
> rough consensus in the room during the interim, and see how the concrete
> solution turns out.
>
> Cheers,
> Marten
>
> On Tue, Mar 5, 2024 at 12:23 David Schinazi <[e-mail]>
> wrote:
>
>> Hi Marten, do you have any thoughts on my previous email?
>> Thanks,
>> David
>>
>> On Mon, Feb 26, 2024 at 6:25 PM David Schinazi <[e-mail]>
>> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>>>
>>>>