IETF Logo Mail Archive

Re: Exercising Version Negotiation

Ryan Hamilton <rch@google.com> Fri, 23 March 2018 22:27 UTC

Return-Path: <rch@google.com>
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 558BB12E035 for <quic@ietfa.amsl.com>; Fri, 23 Mar 2018 15:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 LiFMmofM-Gva for <quic@ietfa.amsl.com>; Fri, 23 Mar 2018 15:27:01 -0700 (PDT)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A87412D94D for <quic@ietf.org>; Fri, 23 Mar 2018 15:27:01 -0700 (PDT)
Received: by mail-yb0-x22e.google.com with SMTP id z5-v6so4599872ybo.10 for <quic@ietf.org>; Fri, 23 Mar 2018 15:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yva8eUPMszxqhTWnFi4Ldk460AEqyi1eOKkgeQAEn74=; b=cLSM/2Fdne5hNnxeen6SxNGml3Dod3yD1VgvAHoqYv/pKjDmnCpGpMS91s0PDIzf8Y 9r6t5a52+wBBOsFXVm1OI0FsMV9OlWlpfkI0ipcNwkJNq1cBBSOB1GLsL1z95ykIhZGV BzyilT+FAY7MziUmsCrDlgPEkVJYUTR2VOmQGbk1mj2PXaxpRtLP6IDXPKmZgFpzU6P+ n07y/8R+vrdC8OK5lSkoZ+32Tvyk68hF03jjCVECgQvkEdw6mWuSK9/NnCO3s3k0Jhgy YFUrmkoksvJORMMEwmmIikpRx5pDdsxej26qLQXb8+KF1xorO0ZiSj4oqL+WwZNaDyEk HSJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yva8eUPMszxqhTWnFi4Ldk460AEqyi1eOKkgeQAEn74=; b=LOA9rEC0XU/HlQlyPRTYujAj35tY4tHCQCS59tUcdR4n7fpgcX9uSQRAzRkpYbN9t9 Cw9R0/xJdduODlfX5G6CXjQo7ppyHzWv80EwoMJt/mNvU5+57H0VZy0SFBzXu0qBwJsZ SNRm6IetPWAc8TBRrVGY1Z7DqzzwXfwXh8XW5A2ygQ8PCmJB0coFvG1dHpnVWbbCIjov i/sTqurYG+uBVOGVyRv2wko38xNxQLFMWBEWF9M69Q5xREzvxynVW9PqFA8vvk4U1jRs dxCRtkVNTV+J3UxaEpH4UNWbExovadFSDmr27EgQ3JtNblDhSN6uTMlMi8gz0U7xU7lf iRQQ==
X-Gm-Message-State: AElRT7EoelN+Nu5xrSr4sGcOZfX8T6FVKgkNwTUXfVFzrWX1Iosw1Qxm v2dO497BzmpPjR5AchWc1v8zPzl3458kjDR+DqxHnm4G
X-Google-Smtp-Source: AIpwx48Wt4jgDKLQhVWWrBULV/0P993MWC0JxU6pPkG6ce2IM4WvR7Wec0D19rn1et+L6m0f+quMyxapvtDjuE0wZaY=
X-Received: by 2002:a25:aea2:: with SMTP id b34-v6mr2404115ybj.443.1521844020329; Fri, 23 Mar 2018 15:27:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:98c5:0:0:0:0:0 with HTTP; Fri, 23 Mar 2018 15:26:59 -0700 (PDT)
In-Reply-To: <9A92D490-1F4F-457D-9209-C19E154E4881@fb.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>
From: Ryan Hamilton <rch@google.com>
Date: Fri, 23 Mar 2018 15:26:59 -0700
Message-ID: <CAJ_4DfSNA0wMnvzxSy1bHU5VTdKujP6oZAtwn8DUNwnX97yLDQ@mail.gmail.com>
Subject: Re: Exercising Version Negotiation
To: Roberto Peon <fenix@fb.com>
Cc: Eric Rescorla <ekr@rtfm.com>, IETF QUIC WG <quic@ietf.org>, Mike Bishop <mbishop@evequefou.be>
Content-Type: multipart/alternative; boundary="0000000000003d096305681beca0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cphJ3w8dbl_ylpIwHa3x5OpVfL0>
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: Fri, 23 Mar 2018 22:27:03 -0000

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.

On Fri, Mar 23, 2018 at 2:00 PM, Roberto Peon <fenix@fb.com> wrote:

> Wouldn’t it be best to do all 3 combinations? ☺
>
> -=R
>
>
>
> *From: *QUIC <quic-bounces@ietf.org> on behalf of Ryan Hamilton <rch=
> 40google.com@dmarc.ietf.org>
> *Date: *Friday, March 23, 2018 at 1:20 PM
> *To: *Eric Rescorla <ekr@rtfm.com>
> *Cc: *IETF QUIC WG <quic@ietf.org>, Mike Bishop <mbishop@evequefou.be>
> *Subject: *Re: Exercising Version Negotiation
>
>
>
> On Fri, Mar 23, 2018 at 1:48 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Thu, Mar 22, 2018 at 8:53 PM, Ryan Hamilton <rch@google.com> wrote:
>
> Agreed. As specified, I don't see how the server would be induced to send
> a version negotiation packet in this case. Ekr, perhaps you can provide
> some sample flows. If the server supports versions A and B, and the client
> supports versions A and B, then it doesn't matter which version the client
> prefers. In either case, the server supports the version the client is
> attempting to speak and will not send a version negotiation packet.
>
>
>
> I'm not suggesting that you flip the preferences, but rather that the each
> side configure itself with one version for a given connection. This is
> obviously trivial for a client. For the server, you can just hash the
> client's IP address to get a stable choice.
>
>
>
> ​Ah, I misunderstood what you meant by, "We would then suggest to people
> that they somewhat randomize their preferences (e.g., 99% of the time
> prefer v1+i, 1% of the time prefer v1-i)."
>
>
>
> How would you envision this working with Alt-Svc advertisements? Would the
> server advertise support for both versions but only support a single one,
> or would it advertise only the single version?
>

v2.23.0 | Report a Bug | By Email