Re: QUIC ossification

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Christian,

On Thu, Feb 14, 2019 at 1:08 PM Christian Huitema <[e-mail]>
wrote:

>
>
> On Feb 14, 2019, at 8:12 AM, Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
> Hi, Christian,
>
> Thanks for the reply (which made perfect sense to me, and was helpful to
> me), but I was also asking the question below (which may have not popped
> out as the thread continued). So, backing up to this note:
>
> On Wed, Feb 13, 2019 at 12:02 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> Hi, Christian,
>>
>> On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema <[e-mail]>
>> wrote:
>>
>>> How about an IANA registry of version numbers, tied to the extension
>>> process?
>>>
>>
>> Asking as an individual - ISTM that QUIC might go through version numbers
>> quickly enough to make a registry for version numbers a Good Thing, but
>> could you help me understand how this helps discourage middleboxes blocking
>> everything but QUICv1?
>>
>> I'm sure I'm missing something here ...
>>
>
> I had guesses about why you suggested a registry, but I was guessing, and
> thought it better to ask what you were thinking.
>
>
> Communication between implementations. The point was already made in the
> thread. Rotation was easy in gQuic because there was only one
> implementation. If we want rotation between multiple teams, an IANA
> registry does that.
>

Ah. That helps.

I was thinking about it from the other perspective - there's an IANA
registry for QUIC versions because new ones appear so often, and if you
want to block stuff off your network when you have no idea what it is, feel
free to block stuff that's not in the registry, but the versions being
added in the registry are specified and people are trying to use them, so
sooner or later, you'll get tired of changing your firewalls to accept new
versions.

The point elsewhere in the thread about having a few large traffic sources
using multiple versions was also helpful.

Spencer

I think rotation will also require clients to maintain a cache of the last
> version supported by a server. The synchronization process could work like
> this:
>
> 1) client implements the new version, keeps proposing the old one.
>
> 2) server implements the new version, documents it in list of supported
> versions in transport parameters.
>
> 3) client connects to server with old version, notices that new version is
> supported, remembers that.
>
> 4) client uses new version for next connection.
>
> -- Christian Huitema
>