Subject: TP greasing and negotiating the use of extensions under development

From: Kazuho Oku <[email-masked]>
Date: Thu, 23 Apr 2020 09:48:02 +0900

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

---

From: Ian Swett <[email-masked]>
Date: Wed, 22 Apr 2020 21:06:42 -0400

I don't believe the intent was to make it hard for extensions to reserve a
contiguous range of TP IDs, but I agree that has happened.

As you said, I think we can live with this, but it is potentially
error-prone.  The greasing approach is already clearly documented, so I
don't have any suggestions to make it less error prone.

On Wed, Apr 22, 2020 at 8:48 PM Kazuho Oku <[email-masked]> wrote:

> 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.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 11:08:48 +1000

On Thu, Apr 23, 2020, at 10:48, Kazuho Oku wrote:
> 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.

Yeah, that seems like a fine outcome.  Extensions that are unstable enough to require the sort of N+rev numbering that you describe can take the hit.  In my experience, extensions (in TLS, primarily) are well-enough coordinated in deployment that they can use a single code point, though you can just pick a new temporary number when making breaking changes.

What's best about that outcome is that we don't have to change anything :)