No IANA version registry

[larseggert]

6. Version Negotiation

I am surprised that there is no IANA version registry

[larseggert]

I think the wiki at https://github.com/quicwg/base-drafts/wiki/QUIC-Versions should be the basis for a registry here, given that it reserves some ranges.

[MikeBishop]

Do you believe those registrations should be enshrined in the RFC, or simply submitted to IANA to seed the registry?

[gloinul]

I support using the transport document for to create an IANA based version registry and its ranges. However, I think the proprietary registrations from the WIKI can just as easy be submitted at time of registry creation as the values are FCFS.
The IETF draft range maybe should be mentioned in the IANA consideration. However, the range is way larger than any single draft document can use. So it can fit multiple draft names.

[martinthomson]

I'll take this and write up a FCFS policy. As for draft versions, I think that we can limit the range we take to the last 10 we used. 0xff00001d needs protection, and maybe some of those preceding it, but no deployments of 0xff000000 exist.

[DavidSchinazi]

It would be nice for the new registry to include the currently deployed Google QUIC versions if possible. In particular Q043, Q046, Q050 and T051 represent significant global traffic today.

[martinthomson]

@DavidSchinazi, do you mind if I ask for an updated list when the time comes? @afrind, that probably goes for you too.

[DavidSchinazi]

That's a good idea

[larseggert]

I would keep the 0xff000000 range as is - we can reuse if we do a v2, and we don't know how many revs we will need

[gloinul]

A question, shouldn't this registry actually be in Invariants? Version field is an invariant and not specific to V1.

[larseggert]

That's what I thought, too. (I actually looked there as well when @StewartBryant flagged this in his review of -transport.)

[martinthomson]

It is considerably easier to reference the general registry guidance and definitions in this document rather than find a way to reference or port them.

[larseggert]

Fair point. Maybe a paragraph in -invariants explaining that a version registry exists and that it is defined in -transport would be good though?

[gloinul]

@larseggert from my perspective, to define it in -transport and just reference it from Invariants clearly can be made to work. The only issue that might arises in the future is for example when QUIC v1 is declared historic. Then the registry rules become historic despite they being current for any other version. So from a RFC life cycle perspective the version registry aligns with invariants.

[larseggert]

Do registries automatically become historic when the RFCs that define them do? I didn't know that.

[StewartBryant]

As part of deprecating or declaring an RFC historic instructions regarding the registry can be issued. Note that just because an RFC is historic it does not necessarily mean that no one is still using it and it is safe to recover its code points.

[gloinul]

No, the registries do not become historic. The issue, is that if you would declare QUICv1 obsolete in QUICv2, then you can't reference the RFC for draft-ietf-quic-transport as that is obsolete for the registry rules when you register the QUICv2 identifier. Thus, you need to copy them to v2. And assuming that we might have several in force QUIC versions this can jump around. By placing the registration rules in invariants this issues would be avoided. As that RFC will only be updated due to need to change invariants or these specific rules.

[larseggert]

I don't think QUIC v2 would necessarily obsolete v1, FWIW.

[StewartBryant]

No, but Magnus’ approach sounds the best one. However I did raise the issue of whether, like IP, the QUIC versions should be an IANA registry.

[gloinul]

@larseggert probably not, but maybe QUICv4 will obsolete v1. I do expect that the obsoleting version specifying documents are more likely than invariant becoming obsoleted. Clearly both approaches can be made to work, there are slightly different trade-offs what may need to happen down the line.

[mjoras]

For Facebook, we have never used a draft version for our traffic. Our strategy is that we use different versions that are essentially aliases to draft versions. So far that has consisted of:

0xfaceb000 (variously draft-9 or draft-17)
0xfaceb001 (draft-24)
0xfaceb002 (draft-27)
0xfaceb00e-f (experimental versions)

Since old clients take a while to upgrade, we support the -1 version for a few months before just disabling it and letting clients fallback to TCP. As for why we do this, it's because we want to retain control over mvfst <-> mvfst interactions without potentially messing up public clients. In the future I think we'd plan on keeping with this strategy and moving forward e.g. to 0xfaceb003 next time we want to iterate the version.

[janaiyengar]

I think this one is reasonably resolved with #4345. Marking this proposal-ready.

[LPardue]

@gloinul we think that this can be resolved by merging the associated PR #4345, does that seem ok to you?

[gloinul]

Yes, I am fine with the PR.

[LPardue]

@martinthomson please land the associated PR when you are ready.

[LPardue]

Closing this now that the IESG have approved the document(s).