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 <[email protected]> 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: <[email protected]> > Date: Thu, Apr 22, 2021 at 10:22 AM > Subject: New Version Notification for draft-duke-quic-v2-00.txt > To: Martin Duke <[email protected]> > > > > 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 [email protected] 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 > > >
