Re: Exercising Version Negotiation

[Ryan Hamilton <[e-mail]>]

Version Negotiation adds 1-RTT to the connection attempt, so I don't think
that's practical for 50% of connections.

On Thu, Mar 22, 2018 at 9:19 AM, Roberto Peon <[e-mail]> wrote:

> Love it. This is a great idea!
>
> I'd suggest being more agressive with deployment,  e.g. recommend that
> servers negotiate speaking version +1 to more like 50% of the clients, and
> swap guid/ip mappings to have clients formerly using +1 switch  to -1 and
> vice versa weekly or so.
>
> -=R
>
>
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: Eric Rescorla <[e-mail]>
> Date: 3/22/18 5:05 AM (GMT-08:00)
> To: IETF QUIC WG <[e-mail]>
> Subject: Exercising Version Negotiation
>
> Following up on the discussion at the mic, I do think it is useful to
> exercise the VN function, but I don't think it's useful to have those
> versions be different, because that creates perverse incentives.
>
> Here's what I suggest instead: create two versions (we can call them QUIC
> v1+i  and QUIC v1-i), each with its own code point [0]. They should be
> essentially identical except for two trivial differences, intended to
> ensure that if you screw up version negotiation, you get failed interop.
>
> - The constant in the handshake salt (5.2.2)
> - The HKDF expansion constants
>
> I suggest we handle each of these by just inverting the bits.
>
> We would then suggest to people that they somewhat randomize their
> preferences (e.g., 99% of the time prefer v1+i, 1% of the time prefer
> v1-i). This will almost always result in matching versions, but will
> occasionally result in a mismatch, thus forcing us to test VN.
>
> -Ekr
>
> [0] Obviously we can do this for draft versions. We just say that the two
> versions are
> ff0000XX and ffffffXX.
>
>
>
>
>
>
>