Re: Rechartering QUIC for Post Version 1 Work

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Matt,

On Tue, Jan 26, 2021 at 8:08 PM Matt Joras <[e-mail]> wrote:

> Hi all,
>
> Some responses inline about the example listing, extension tracks,
> multipath, and qlog.
>
> On Tue, Jan 26, 2021 at 5:21 PM David Schinazi <[e-mail]>
> wrote:
>
>> Thanks for your reply, Lucas. Responses inline.
>>
>> On Tue, Jan 26, 2021 at 4:56 PM Lucas Pardue <[e-mail]>
>> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for the feedback. I've responded in-line, and some of that text
>>> responds to points Ian raised too.
>>>
>>> On Tue, Jan 26, 2021 at 9:54 PM David Schinazi <[e-mail]>
>>> wrote:
>>>
>>>> I'm supportive of the overall direction of this rechartering, with some
>>>> concerns though:
>>>>
>>>> 1) multipath is not mentioned in this charter - based on the
>>>> conversations we've had over the past months, I think we should be explicit
>>>> about whether multipath is in or out of scope
>>>>
>>>
>>> The intention was that the new charter would allow the group, as the
>>> focal point for QUIC-related things, to consider work such as multipath
>>> QUIC. The guidance for discussion of multipath is still the same as Lars'
>>> sent to the WG in November [1]. To borrow a bit of that, we still feel it
>>> premature to adopt an proposal as a work item.
>>>
>>
>> I see your point, I'm OK with not precluding multipath as long as the
>> guidance from November still holds. But then again, a recharter could be
>> seen as invalidating prior charter-related decisions so being explicit
>> could be useful here.
>>
>>
>> There's an interesting contrast between this point and your second point.
>>> It seems there's a balance between being specific and appearing not open to
>>> new ideas.
>>>
>>
>> From my perspective, multipath was important enough of a topic to warrant
>> its own interim a few months back which isn't true of any of our extensions
>> - so I guess that's where I'd draw the line in terms of mentioning
>> something or not?
>>
>
> In my view codifying any particular position on multipath in the charter
> is problematic (as we've experienced with the existing charter) and could
> be seen as a firm commitment to adopting those work items immediately along
> with the rechartering. The proposed text gives us the flexibility to adopt
> and prioritize multipath work as we see fit without implying that it is
> immediately necessary.
>

That's probably true, but it's worth pointing out that removing any mention
of multipath from the charter also sends a message (it's not just what the
charter says now, but what the deltas are). But, moving on ...

Please allow me to up-level a bit (and this may also be relevant for my
comment a few minutes ago, about other groups specifying QUIC usages that
at some point start to require QUIC extensions).

Where I thought we were after November on multipath, was that the chairs
(and the working group) wanted to have conversations about proposed
multipath work in the QUIC working group, but didn't want to have anything
that looked like a commitment to adopt a proposal before people presented
their implementation and deployment experiences.

(Any of the chairs can correct me on that, of course, including you)

Would saying something like that help with multipath, or partially reliable
HTTP (as Roberto asked about), or <insert random proposed extension here>?

Best,

Spencer