Re: Exercising Version Negotiation

[Christian Huitema <[e-mail]>]

On 3/27/2018 1:54 AM, Philipp S. Tiesel wrote:
>
>
>> On 26. Mar 2018, at 22:30, Ted Hardie <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> On Sat, Mar 24, 2018 at 11:30 AM, Christian Huitema
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>      
>>     Perhaps we should look at it differently. What do we really want to
>>     teach to the middle-boxes? I think the message should really be,
>>     "do not
>>     try to lock on a specific version number".  And doing that with
>>     just two
>>
>>     versions will not work. The middle boxes will just learn those two
>>     versions, and we will not be able to introduce a third one. We
>>     want to
>>     see plenty of mostly unpredictable versions proposed by clients,
>>     and we
>>     want these unpredictable version numbers to result in successful
>>     connections most of the time.
>>
>>
>> So, the key second part to this question is "what am I willing to pay
>> to teach the middleboxes this?"  Everyone in the thread agrees that
>> the basic currency is round trips, but we seem to be divided on what
>> the going rate is (in percentage of flows that should pay).
>>
>> I have a terrible idea about that, but it does shift the currency
>> from "round trips" to "additional connections".  The precis is: 
>> exercise version negotiation by opening additional connections that
>> use the functionality.  
>
> I think if you are connection regularly to certain endpoints, one could
> also use “the next connection” for greasing. 
>  - The server includes a “version alias frame” in the encrypted connection
>    that maps regular versions into experimental space
>  - The client caches this information and uses it on subsequent
> connections.
>
> This comes at the risk of accidentally getting involved into experiments, 
> but thus also tests parsing error handling ;-)
>
> Other than this, I guess the best  way to really exercise version
> negotiation
> is using experimental versions often. Google has already demonstrated
> that 
> supporting several versions in parallel is feasible, others should be
> able to
> do the same. If all the big players always have some experiments
> running that
> exercise version negotiation, ossifying around this will most likely
> become
> too expensive.

I think you are onto something there. If the server publishes something
like "I could also support V=XYZ as an alias for the current version",
the client could remember that and try it next time. This will teach
middle-boxes that it is OK to see various random values in the version
field, and that it is costly to drop packets just because they don't
understand the version.

-- Christian Huitema