Re: QUIC ossification

[Jana Iyengar <[e-mail]>]

On Wed, Feb 13, 2019 at 8:09 PM Martin Thomson <[e-mail]> wrote:

> On Thu, Feb 14, 2019, at 15:00, Martin Duke wrote:
> > Similarly, setting aside IANA, is it sufficient for big players to accept
> > ANY version in the short term and treat it as v1, and also have their
> > clients propose totally random versions?
>
> That would (or maybe only could) prevent us from using the version field
> for anything other than v1.


Yes, agreed. There's no horizon for how long older versions circulate on
the Internet. We can't assign all versions to v1 for the "short term"
because we simply can't control when that term ends.
I don't think we need to specify how versions are assigned. We just need to
ensure that there are no collisions. We can use a wiki or IANA for this.

There's a problem this exposes though. v2 is defined as version == 2, and
we won't be able to use that for greasing v1. By extension, we won't be
able to use the IETF reserved versions. If we're going to do this right, I
would suggest that we separate on the wire version numbers from the QUIC
(abstract) versions entirely. I know this makes it a bit harder to reason
about from looking at packets on the wire, but that's exactly what we're
trying to accomplish -- it shouldn't be easy to reason about versions from
looking at packets on the wire.

Basically, I'm proposing that QUIC v1 be assigned a random number for its
version at RFC publication time. IANA can be used to reserve subsequent
on-the-wire version numbers for v1. Anyone who wants to use a different
version for v1 MUST request it from IANA first before using it in the wild.
QUIC v2 will similarly have a random value assigned to it at RFC
publication time.