Re: QUIC ossification

["Martin Thomson" <[e-mail]>]

On Mon, Feb 18, 2019, at 19:36, Jana Iyengar wrote:
> Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an 
> additional version for v1? If we do, then what is the on-wire 
> representation for v2? If we don't, then we have to segregate the 
> space. To avoid this problem, I suggested that we randomize everything. 
> It's not that hard: IANA can easily assign a version to us at RFC 
> publication time much in the same way as they would to anyone 
> requesting an additional on-wire version for v1 in the future.

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.

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.

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.