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

[Martin Thomson <[e-mail]>]

FWIW, I share Marten's concerns.

I know that some people won't care about added complexity in browsers, but I do.

On Tue, Mar 5, 2024, at 20:54, Marten Seemann 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
> -- 
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport