Re: QUIC ossification

[Jana Iyengar <[e-mail]>]

Roberto -- yes, that's basically what I'm proposing too, just one variant
of how to go about doing it dynamically over time.

On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <[e-mail]> wrote:

> 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]> 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.
>
>
>