Re: QUIC ossification

[Martin Duke <[e-mail]>]

Just to close the loop on the transport parameter concern: changing the
salt probably solves the problem. You can't read the TPs unless the
implementer has processed the new version document.

I like how the version # discussion is progressing, please keep at it.

On Wed, Feb 13, 2019, 6:33 PM Jana Iyengar <[e-mail] wrote:

> I'm with Martin Duke in that even if we trust the IETF process to produce
> a v2 quicly (sorry), middleboxes could just as simply do "version == 1 or
> 2".
>
> I agree with Christian that we don't need *everyone* to do this; a few
> heavy hitters ought to be enough to dissuade middleboxes from ossifying a
> few versions.
>
> I'm intrigued by the "version of the month" idea, which is perhaps similar
> to David Benjamin's idea of running a QUIC version per Chrome cycle.
> Perhaps big sites (Google, Facebook, anyone else) could periodically
> publish their new equivalent versions on a wiki, and clients could keep up
> with them?  Is there a more concrete proposal here?
>
>
>
> On Wed, Feb 13, 2019 at 6:18 PM Christian Huitema <[e-mail]>
> wrote:
>
>> On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:
>>
>> Hi, Roberto,
>>
>> On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <[e-mail]> wrote:
>>
>>> Better that they have to explicitly block than they accidentally block?
>>>
>>
>> Well, right, but I'm not sure why someone accidentally blocking
>> (especially QUICv1) is less likely to do that because we created a
>> registry.
>>
>> But I asked Christian a question just before the IAB telechat today, so I
>> should probably wait to give him a chance to explain what he was thinking.
>>
>>
>> OK, back to basics. The middle-boxes will only not do something if it
>> hurts them. Blocking a little guy or blocking some experiment will not hurt
>> them, because there will be few complaints. Blocking Google or some other
>> big site, on the other hand, yes that could hurt -- calls to support line,
>> complaints from ISP who bought the box, etc. So the version will only not
>> ossify if the big players grease it in a meaningful way, or change it
>> frequently.
>>
>> There are two plausible ways there. One would be a "version of the
>> month", with at least a change in the clear text encryption key. The other
>> would be "versions for extensions", tied to for example the negotiation of
>> new transport parameters. In both cases, having something like an IANA
>> registry for the version number would help.
>>
>> -- Christian Huitema
>>
>