Re: QUIC ossification

[Jana Iyengar <[e-mail]>]

On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <[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.