Re: Exercising Version Negotiation

Christian Huitema <huitema@huitema.net> Sat, 24 March 2018 11:30 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3E21250B8 for <quic@ietfa.amsl.com>; Sat, 24 Mar 2018 04:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24dzi-pgTqTk for <quic@ietfa.amsl.com>; Sat, 24 Mar 2018 04:30:46 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD001201F2 for <quic@ietf.org>; Sat, 24 Mar 2018 04:30:46 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ezhNi-0004YT-Vk for quic@ietf.org; Sat, 24 Mar 2018 12:30:43 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ezhNh-00037d-9d for quic@ietf.org; Sat, 24 Mar 2018 07:30:41 -0400
Received: (qmail 24476 invoked from network); 24 Mar 2018 11:30:38 -0000
Received: from unknown (HELO [10.8.50.80]) (Authenticated-user:_huitema@huitema.net@[80.195.152.82]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 24 Mar 2018 11:30:38 -0000
To: quic@ietf.org
References: <CABcZeBMv5BqZOtgVA2wfqaaGCd94gcNPB9bTXkrvNXXRveU8wA@mail.gmail.com> <CAJ_4DfQ6zqVeUUF7XcoT110kVcP1BJFEtqVR-+FN5XD2UuRMMA@mail.gmail.com> <CABcZeBMVNy151rFntLutSPtctPsd2Ei3Qy-ChuEXVMVpz4pgdQ@mail.gmail.com> <SN1PR08MB1854DD71FDCB9FBA48DD26E9DAA90@SN1PR08MB1854.namprd08.prod.outlook.com> <CAJ_4DfQxcxNGNP9CW3poPqnFgUsrNy269dO2Lf0dvWBFKKsSHg@mail.gmail.com> <CABcZeBNfw6MjjgeqQct11g6Kf=4xy+zVZiBRMwwzhtKB2rWHZg@mail.gmail.com> <CAJ_4DfRCNRHajNfFdedg6O54mjydWt+ooRESJZQ5L0sZmcwmXg@mail.gmail.com> <9A92D490-1F4F-457D-9209-C19E154E4881@fb.com> <CAJ_4DfSNA0wMnvzxSy1bHU5VTdKujP6oZAtwn8DUNwnX97yLDQ@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <8ed89135-e878-473a-9c44-d3f1b9ce16b1@huitema.net>
Date: Sat, 24 Mar 2018 11:30:37 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAJ_4DfSNA0wMnvzxSy1bHU5VTdKujP6oZAtwn8DUNwnX97yLDQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: Exercising Version Negotiation
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.27)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5vtqSrOEZoBlpEDkriGoOZd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVisKUGuJp3J7XY2E9rQH9l3c7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYrchEYbvvKlQTMyZGUVvKSfB37dDi7Jds 6rv/k1oWn+xz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqutd2F/yaZGqnwJYwSpQ91YE7tCqypI5WX0qWh4YQLAf5bQmGZfE7ZuQ mpq1ikLNbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXekflWG4A3HDBzBq/sLmCzQKHY 6H+wSCoVvwvquzDDiP1kW3XKN6SjV/ce7POAEs6Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/h6KEDj-kHY1rjZ36CRnV3rLWITI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Mar 2018 11:30:48 -0000

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