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
- Exercising Version Negotiation Eric Rescorla
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Eric Rescorla
- RE: Exercising Version Negotiation Mike Bishop
- Re: Exercising Version Negotiation Spencer Dawkins at IETF
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Eric Rescorla
- Re: Exercising Version Negotiation Subodh Iyengar
- Re: Exercising Version Negotiation Subodh Iyengar
- Re: Exercising Version Negotiation Subodh Iyengar
- Re: Exercising Version Negotiation Ian Swett
- Re: Exercising Version Negotiation Subodh Iyengar
- RE: Exercising Version Negotiation Lubashev, Igor
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Ryan Hamilton
- RE: Exercising Version Negotiation Lubashev, Igor
- Re: Exercising Version Negotiation Eric Rescorla
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Christian Huitema
- RE: Exercising Version Negotiation Mike Bishop
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Ted Hardie
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Ryan Hamilton
- Re: Exercising Version Negotiation Roberto Peon
- Re: Exercising Version Negotiation Philipp S. Tiesel
- Re: Exercising Version Negotiation Christian Huitema