Explain compatibility for future QUIC versions

[marten-seemann]

The Register Target Connection ID capsule and the Virtual Connection ID capsule allow connection IDs of up to 255 bytes. This is because RFC 8999 allows up to 255 bytes, while RFC 9000 restricts them to 20 bytes.

The capsules also contain stateless reset tokens. However, stateless resets are not a concept defined in RFC 8999, they’re only defined in RFC 9000.

It seems like the hope when defining this extension is that once a new QUIC version that allows longer CIDs ships, it will still contain the concept of stateless reset tokens, with unchanged semantics and wire format. This might or might not hold true.

[tfpauly]

That's a good point, but I don't think we should make any change.

• If there is a new version that has the same CID lengths and reset token behavior as v1, we're good.
• If there is a new version that has longer CID length, but the same reset token behavior as v1, we're good.
• If there is a new version that has no reset token support, then we can just leave those as empty, and we're still good.
• If there is a new version that needs entirely different reset token semantics or format, then we define new capsule types when we get there for that version.

Would you agree?

[marten-seemann]

I agree with your summary. Should this document specify that the extension only works with QUIC versions that satisfy (1) - (3), but not (4)?

[tfpauly]

Yes, I think it would be good to add a line to explain that if the behavior of stateless reset changes or other requirements are added, we need new capsules.

[martinduke]

A few things that can be done here:

• a "Version Dependence" section (similar to QUIC-LB) that writes down exactly what assumptions beyond 8999 you are relying on
• The option for the client to specifically request version-specific services (like stateless reset)
• The proxy having a "version aware" mode where it does version-specific stuff, and a version-independent one that provides minimum services