IETF Logo Mail Archive

Re: Exercising Version Negotiation

"Philipp S. Tiesel" <phils@in-panik.de> Tue, 27 March 2018 08:53 UTC

Return-Path: <phils@in-panik.de>
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 8B1CA12D873 for <quic@ietfa.amsl.com>; Tue, 27 Mar 2018 01:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 6_yUZG2HTFYO for <quic@ietfa.amsl.com>; Tue, 27 Mar 2018 01:53:55 -0700 (PDT)
Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [IPv6:2001:bf0:c000::1:8]) (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 906D31270A0 for <quic@ietf.org>; Tue, 27 Mar 2018 01:53:54 -0700 (PDT)
X-Envelope-From: phils@in-panik.de
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w2R8rjZC026407 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Mar 2018 10:53:45 +0200
Received: from [193.175.74.233] (helo=[10.31.64.153]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <phils@in-panik.de>) id 1f0kLo-0005QC-Mc; Tue, 27 Mar 2018 10:53:04 +0200
From: "Philipp S. Tiesel" <phils@in-panik.de>
Message-Id: <036C9799-CF9A-4136-B467-0FCE2EBBD853@in-panik.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A369D3FE-C8FC-42EC-A1E1-3A3178BC5A3C"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: Exercising Version Negotiation
Date: Tue, 27 Mar 2018 10:54:31 +0200
In-Reply-To: <CA+9kkMDHQ94e2SBZ_kSEW2vnFy99V6zp7w9OPOXtGtxuODtFFQ@mail.gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>
To: Ted Hardie <ted.ietf@gmail.com>
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> <8ed89135-e878-473a-9c44-d3f1b9ce16b1@huitema.net> <CA+9kkMDHQ94e2SBZ_kSEW2vnFy99V6zp7w9OPOXtGtxuODtFFQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/nPNHr7iu9vDajZevl3yzugkT5Go>
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: Tue, 27 Mar 2018 08:53:57 -0000


> On 26. Mar 2018, at 22:30, Ted Hardie <ted.ietf@gmail.com> wrote:
> 
> On Sat, Mar 24, 2018 at 11:30 AM, Christian Huitema <huitema@huitema.net <mailto:huitema@huitema.net>> 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.   

I think if you are connection regularly to certain endpoints, one could
also use “the next connection” for greasing. 
 - The server includes a “version alias frame” in the encrypted connection
   that maps regular versions into experimental space
 - The client caches this information and uses it on subsequent connections.

This comes at the risk of accidentally getting involved into experiments, 
but thus also tests parsing error handling ;-)

Other than this, I guess the best  way to really exercise version negotiation
is using experimental versions often. Google has already demonstrated that 
supporting several versions in parallel is feasible, others should be able to
do the same. If all the big players always have some experiments running that
exercise version negotiation, ossifying around this will most likely become
too expensive.


AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

v2.23.0 | Report a Bug | By Email