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

[Marten Seemann <[e-mail]>]

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