Re: Exercising Version Negotiation

[Ted Hardie <[e-mail]>]

On Sat, Mar 24, 2018 at 11:30 AM, Christian Huitema <[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.

In this model,  a client with a successful open connection to server $foo
knows what versions it supports and can construct a flow that will incur
version negotiation.  Periodically, it will open such a flow, successfully
negotiate a version after paying the RTT, then ask for a small set of
resources which it already has.  It can throw them out at the end, as they
will not impact application functionality (since this is all on the main
flow).  If it is in a constrained environment (low available bandwidth,
battery, etc.), it can skip the whole thing.

Middleboxes will thus see some number of flows that exercise version
negotiations, but the impact to the application running QUIC is small.  The
impact on the network is variable to the tuning of the rate.

Some potential objections:

The middlebox operators will read the spec and decide they can ignore these
flows entirely.
While this is possible, nat variability will mean middleboxes at later
stages of the path may not see these as on the same 5-tuple, and so
ignoring them will be hard.

This is too expensive in client and server resources, since the data will
be tossed.
This is subject to tuning, so the expense can be managed.  You could also
decide to use the second connection to retrieve newly needed resources, if
the application is appropriate to that, but deciding when that is
appropriate is fairly difficult.

What connection id do you use for this?
Personally, I'd use a new one, but if we start looking at connection
replacement strategies more generally, we can throw this into the mix.

As I said this is a bad idea, given the potentially wastefulness, but
hopefully it will unstick a better one.

Ted