Re: New Version Notification for draft-duke-quic-v2-00.txt

[Lucas Pardue <[e-mail]>]

Hi Martin,

Thanks for writing this up.

Speaking as an individual, I have some naive questions. Is this document so
trivial that it would never change between revisions? Or is there a risk
that something like initial salt in there might need to rev? To rephrase,
would the document be better off starting with a different QUIC version
value before interoperability discovers a problem and we've blown that code
point? We can always develop such a document with a target code point in
mind for use if the doc were to get adopted and run through all due process.

Cheers
Lucas

On Thu, Apr 22, 2021 at 6:52 PM Martin Duke <[e-mail]> wrote:

> Hello QUIC,
>
> I believe it was MT that threatened to do this a long time ago, but to
> work through compatible version negotiation I wrote up a trivial QUICv2
> (below) that just changes the initial salts. This caused me to figure out a
> couple of things about VN that may have been obvious to others but not to
> me.
>
> TL;DR we made the right decision to keep both in the draft.
>
> 1. One very possible world is one where firewalls ossify on expecting v1
> in the first packet, but don't care about subsequent packets. Compatible VN
> is well-designed for this world, as Client Initials (and 0RTT, sadly) can
> be v1 essentially forever and subsequent packets can be whatever we want.
>
> 2. If all versions are compatible, choice of VN method is essentially up
> to the client, but not quite deterministically: it can pick either a likely
> supported version or an unlikely one. If unlikely, the server will either
> accept it or send a VN. If likely, the server MUST use compatible VN to
> change the version, since it can't send a VN packet that contains the
> initial version unless it doesn't have full support for it.
>
> Anyway, this v2 draft is available for your consideration if people want
> to quickly iterate a new version, and/or we need a vehicle for fixes to v1.
>
> Thanks
> Martin
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Thu, Apr 22, 2021 at 10:22 AM
> Subject: New Version Notification for draft-duke-quic-v2-00.txt
> To: Martin Duke <[e-mail]>
>
>
>
> A new version of I-D, draft-duke-quic-v2-00.txt
> has been successfully submitted by Martin Duke and posted to the
> IETF repository.
>
> Name:           draft-duke-quic-v2
> Revision:       00
> Title:          QUIC Version 2
> Document date:  2021-04-22
> Group:          Individual Submission
> Pages:          5
> URL:            https://www.ietf.org/archive/id/draft-duke-quic-v2-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-duke-quic-v2/
> Html:           https://www.ietf.org/archive/id/draft-duke-quic-v2-00.html
> Htmlized:       https://tools.ietf.org/html/draft-duke-quic-v2-00
>
>
> Abstract:
>    This document specifies QUIC version 2, which is identical to QUIC
>    version 1 except for some trivial details.  Its purpose is to combat
>    various ossification vectors and exercise the version negotiation
>    framework.  Over time, it may also serve as a vehicle for needed
>    protocol design changes.
>
>    Discussion of this work is encouraged to happen on the QUIC IETF
>    mailing list [e-mail] or on the GitHub repository which contains
>    the draft: https://github.com/martinduke/draft-duke-quic-v2.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>