Re: QUIC Version Negotiation Interim

[Lucas Pardue <[e-mail]>]

Hi Marten,


On Fri, 23 Apr 2021, 03:06 Marten Seemann, <[e-mail]> wrote:

> Thank you for the summary. Is there a recording of the meeting? Would have
> love to attend if it had been at a more suitable time.
>

The meeting was held on WebEx and it was recorded. The secretariat kindly
publish these for us to YouTube and that can take up to 10 working days [1].

I'll make a note to reply here once I see the video go live on YouTube.

Cheers
Lucas

[1] -
https://mailarchive.ietf.org/arch/msg/wgchairs/wNMi_HNzIb_VqIA8z2OCxMhKj5c/



> On Fri, Apr 23, 2021 at 01:34 Matt Joras <[e-mail]> wrote:
>
>> Hello all,
>>
>> As noted in previous mail, the draft minutes are available here[1]. A
>> high level summary of the meeting, as well as next steps, follows.
>>
>> About 25 people attended and David kicked us off with a short update
>> as editor. Some of the attendees spoke briefly to the ideas that they
>> had shared to the list since the last meeting. Watson presented the
>> sketch of an alternative mechanism to achieve version negotiation to
>> the existing draft[2]. This design was very interesting and provoked
>> much discussion. There was, after a time, agreement that such a scheme
>> would likely require a change to the QUIC invariants. While not
>> strictly impossible there doesn't seem to be much motivation in this
>> direction or for making a change of that magnitude at this stage.
>>
>> Much of the discussion focused on the notion of "compatible" versus
>> "incompatible" version negotiation and whether or not we require just
>> one, both, or neither. For definitions of these, please read sections
>> 2 and 3 of the draft[2].
>>
>> Regarding incompatible version negotiation, several people made
>> arguments that incompatible version negotiation is not needed in
>> practice today and we are unlikely to need it in the future. As the
>> main complexity of the current draft is mostly from incompatible
>> version negotiation, there is potentially a benefit from removing it
>> as a requirement.
>>
>> On the other hand, many people felt strongly that incompatible version
>> negotiation is definitely a requirement and they can foresee use cases
>> for it. No one present strongly opposed a design which includes
>> incompatible version negotiation.
>>
>> Similarly, some made the argument that compatible version negotiation
>> is also not a requirement. Nominally the same functionality is
>> achievable with a single QUIC version, transport parameters, and
>> extensions. There were many people who believe there is still value in
>> compatible version negotiation. No one present strongly opposed a
>> design which includes compatible version negotiation. There was a
>> general desire for clarity around when compatible versions should be
>> utilized versus simply specifying extensions.
>>
>> To help get a sense of the room as the session was coming to an end,
>> the chairs took a show of hands for version negotiation requirement
>> options.
>>
>> The chairs observed emerging consensus for supporting both compatible
>> and incompatible version negotiation. We also observed little interest
>> in alternatives to the design in the current draft[2]. Therefore the
>> proposal is to move ahead with the current draft and incorporate some
>> design improvements. Please comment if you disagree with this
>> proposal, the consensus call will last for one week until Thursday,
>> April 29th.
>>
>> Thanks,
>> QUIC Chairs
>> Lars, Lucas, Matt
>>
>> [1]
>> https://github.com/quicwg/wg-materials/blob/main/interim-21-04/minutes.md
>> [2] https://tools.ietf.org/html/draft-ietf-quic-version-negotiation-03
>>
>>