Re: QUIC ossification

[Roberto Peon <[e-mail]>]

As others have intimated in some form or another, you can also use multiple numbers to express “version 1”.

For instance, pick 64 (or some similar constant) random numbers, and call them all version 1.
-=R

From: QUIC <[e-mail]> on behalf of Jana Iyengar <[e-mail]>
Date: Tuesday, February 19, 2019 at 3:10 PM
To: Martin Thomson <[e-mail]>
Cc: QUIC WG <[e-mail]>
Subject: Re: QUIC ossification

On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
I don't think that there is much value in using two version numbers to refer to the same protocol.  But even if we did, as long as we didn't establish any pattern in doing so, that couldn't be used against us.  So I might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no strong need to do anything special with the first version.  Any attempt to profile QUIC will be done with full knowledge of the version number we pick, so randomness doesn't serve any real purpose.  Subsequent versions might need to use a randomized value, but we can make that decision then.

I figured that making all version assignments random instead of special-casing 0x1 made it simpler to reason about and uniform to code for, but I actually don't care about the IANA assignment for v1 for the reason you note. v1 will be one specific bit-pattern on the wire to start of with, and that can just as well be 0x1. It still does segregate the space, but we can't do anything about it anyways - it'll be 0x1 or some other random number getting special treatment.

The problem of course being that as long as v1 remains, we might find places that no other version does.  The QUIC "magic number" will be whatever we pick, and we can't prevent someone from fixating on that..  We'll convince those people in the same way they will be convinced to open up UDP for QUIC version 1: by making a QUIC version 2 worth enabling.

That was the entire point of having alternate and preferred versions to 0x1. If we have downgrade protection in place, and if there are those who try alternate version numbers for v1, that gives us what we need at the endpoints. I believe that there would be interest at some major vendors to do this at some endpoints. Presumably, we can convince Google to do something, since it has been bit by mbox ossification in the past. I am operating on the premise that we have buy in from a few major providers.

IANA is for me a publication venue where these alternate versions are published and other clients/servers interested in keeping the ecosystem from ossifying can use these alternate versions as well.

I completely get the don't segregate thing.  But to - I think - Mikkel's point about experimentation without permission, I do think that squatting is a perfectly sound approach in a space this big.  TLS people do it in a much smaller space.  As long squatters pick random values, they do so infrequently, and they get IANA registrations for codepoints relatively soon afterwards, the risk of collision is low.  Randomness here is useful - but primarily as a collision-avoidance technique.  The TLS extension codepoint 26 is a great example of why.  Keeping the bar on registrations low (FCFS is a reasonable policy) would also have the effect of making the pool of apparent versions larger, which might be more effective than any other strategy we might employ.

I'm totally fine with experimentation without permission, and using random to avoid collision. My point was entirely about using alternate on-wire version numbers for v1. Nothing here about new or experimental versions.