Re: QUIC Version Negotiation Interim

[Matt Joras <[e-mail]>]

Hello,

There was only meta discussion during this call, so we will consider that a
consensus on the previous proposal.

Thanks,
QUIC Chairs


On Thu, Apr 22, 2021, 11:34 AM 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
>