Re: Exercising Version Negotiation

[Roberto Peon <[e-mail]>]

What the user cares about is the quality of the experience. This is influenced by the number of times the version changes for them.
That is de-coupled from the number of versions deployed simultaneously across all users.
Thus, have x == 50%. Use as many versions as equally as possible. Sometimes use both.

So long as the rate of change on an individual user/IP basis is slow enough, the user won't see any real performance penalty or degraded experience.
As an example, I think that changing version negotiation on someone once a week would be pretty safe.

Agreed that we want to teach middle-boxes to not expect a specific version. Agreed we need a Goldilocks value (caveated with above). 
We also want to teach *clients* to not expect a single version. Ekr's suggestion of really deploying two versions makes it likely that most endpoint implementations (and not just middleboxes) would build the appropriate scaffolding to deal with versioning.
-=R

On 3/24/18, 4:31 AM, "QUIC on behalf of Christian Huitema" <[e-mail] on behalf of [e-mail]> wrote:

    On 3/23/2018 10:26 PM, Ryan Hamilton wrote:
    
    > 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.
    
    There is of course no way to exercise version negotiation without
    incurring a 1-RTT penalty. Following the "use it or lose it" paradigm,
    we know that if we do not use version negotiation for a while, various
    middle-boxes will "learn" that it is not needed and will start blocking
    VN packets, in the same way that various middle boxes block various ICMP
    packets today. Greasing VN has a cost. If we grease VN for X% of
    connections, X% of connections will suffer an additional 1-RTT delay.
    There is just no way around it.
    
    Let's assume that we will grease VN on X% of connections. How do we
    decide how much that X% is? If it is too low, middle-boxes will learn
    that blocking VN only affects a small fraction of connections. They will
    think that they can block it, and clients will probably react by
    retrying with a different version. Grease fails. If it is too high, too
    many clients suffer. So we need some kind of Goldilocks value, not too
    big, not too high, just right. Anything below 1% will probably be too
    low, but I don't know what would be too high. 5%? 10%? The trade-off is
    not very appealing.
    
    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.
    
    -- Christian Huitema