Re: Exercising Version Negotiation

[Roberto Peon <[e-mail]>]

This is roughly what I'm thinking:

auto versions = std::vector<std::string>();

int day = date_as_unix_epoch_in_ms() / ms_in_day;

int day_mod = (day + hash(client_ip)) % 3;

switch (day_mod) {

  case 0:

    versions.push_back("v+");

    break;

  case 1:

    versions.push_back("v-");

    break;

  case 2:

    versions.push_back("v+");

    versions.push_back("v-");

    break;
}

With such a scheme, the client would incur an extra RTT on a new connection once a day.

-=R

________________________________
From: QUIC <[e-mail]> on behalf of Ryan Hamilton <rch=[e-mail]>
Sent: Friday, March 23, 2018 3:26:59 PM
To: Roberto Peon
Cc: Eric Rescorla; IETF QUIC WG; Mike Bishop
Subject: Re: Exercising Version Negotiation

Maybe. :) I'm just trying to get my arms around a concrete proposal. For example, if the server always advertises both versions, but only supports 1 version based on hash(client IP), and those client typically prefer the other version, then they'll incur an extra RTT on every connection, which seems undesirable. But I'm not sure if that's the proposal.

On Fri, Mar 23, 2018 at 2:00 PM, Roberto Peon <[e-mail]<mailto:[e-mail]>> wrote:

Wouldn’t it be best to do all 3 combinations? ☺

-=R



From: QUIC <[e-mail]<mailto:[e-mail]>> on behalf of Ryan Hamilton <rch=[e-mail]<mailto:[e-mail]>>
Date: Friday, March 23, 2018 at 1:20 PM
To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>, Mike Bishop <[e-mail]<mailto:[e-mail]>>
Subject: Re: Exercising Version Negotiation



On Fri, Mar 23, 2018 at 1:48 AM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

On Thu, Mar 22, 2018 at 8:53 PM, Ryan Hamilton <[e-mail]<mailto:[e-mail]>> wrote:

Agreed. As specified, I don't see how the server would be induced to send a version negotiation packet in this case. Ekr, perhaps you can provide some sample flows. If the server supports versions A and B, and the client supports versions A and B, then it doesn't matter which version the client prefers. In either case, the server supports the version the client is attempting to speak and will not send a version negotiation packet.



I'm not suggesting that you flip the preferences, but rather that the each side configure itself with one version for a given connection. This is obviously trivial for a client. For the server, you can just hash the client's IP address to get a stable choice.



​Ah, I misunderstood what you meant by, "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)."



How would you envision this working with Alt-Svc advertisements? Would the server advertise support for both versions but only support a single one, or would it advertise only the single version?