Re: QUIC ossification

[Christian Huitema <[e-mail]>]

 

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

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 
>