TP greasing and negotiating the use of extensions under development

[Kazuho Oku <[e-mail]>]

Hi,

TL;DR: I would like to confirm that our stance is to make it hard for QUIC
extensions to reserve a contiguous range of Transport Parameter IDs, as we
have intentionally created a gap for every 31 TP by defining greasing as 31
* N + 27 where N is an integer. Extension authors should be aware of that,
when trying to use different TP IDs to identify the draft versions of their
extensions.

Long story:

Recently, there has been a discussion among people implementing the delayed
ack extension, regarding how to check if peer has implemented the same
draft version of that extension.

At the moment, the delayed ack extension is at version -00, uses TP:
0xDE1A. A wire-incompatible change is expected in -01. Endpoints need a way
of identifying which version of the delayed ack extension the peer speaks.

The most trivial way of having a versioning scheme for a QUIC extension is
to use different TP IDs for each revision of the drafted extension.

However, it is a bit difficult to specify a range of code points (i.e.
0xde1a00nn), and say that nn would be the revision number of the draft,
because there are greasing TPs for every 31 TP number.

In case of 0xde1a00nn, the first nn that would hit the greasing number
would be nn=19. That's not too bad. But depending on how each extension
chooses the base number, nn could be something like 5, 1, or 0.

This is not a terrible problem at all. Extension authors can skip greasing
TPs. But we need to make sure that they will do that.

--
Kazuho Oku