Re: Getting to consensus on packet number encryption

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 02 May 2018 03:48 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 7182A12D7F5 for <quic@ietfa.amsl.com>; Tue, 1 May 2018 20:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Wr7gvnqy1ygX for <quic@ietfa.amsl.com>; Tue, 1 May 2018 20:48:38 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 DC40412421A for <quic@ietf.org>; Tue, 1 May 2018 20:48:37 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id b14-v6so4821087ybk.1 for <quic@ietf.org>; Tue, 01 May 2018 20:48:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2KQs59fxEVlQGKfcCFrrqD7KO7L2ndMvfoXjNVgCgtA=; b=dN3hnTJ7mZiggda5YtfauYa7WTv06hUMO5E/NI2aRz/IYy5v6Dee07bzaKrO4Kfv// lZIAeims0uzL6yJSmtcduY9f7TjeAJ/mEu9sAjEQEkp2339mw9gbcwusMiH8uuwD04ex H7LB1Axm1T/HoxtPLCwAEFdCcGJroatkN3XczJiUECsqrQB4LiApsADSiZHPTe28rMJE HCWXoQNPUQ4QIBEmBcGN0KUhaHeB0jtyYfowuOEDB3Q38VCryjaEFmfiMP5k7jVBCj68 l7ETH5JLVKp4rJGt160uG+FdM/JfoQTVEJYQC3ucgNjPXDY79XyU6ik4nr1ONTkyIm+P c5KQ==
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=2KQs59fxEVlQGKfcCFrrqD7KO7L2ndMvfoXjNVgCgtA=; b=VUTQEnGu4cYxR0pPjKnRtUz3jjK2ttxUGO+MDJwGTRclHMNMk1KEt5ajsfokHhkO+f B7bZ/4wtmrwhK6eGt92QHXdm91ePgDdNrt+arGVwS4MFwZHvlCqvroPBX9KZtraKVNEG Q7tFaHyiv+5M808mvry+aVCL+ZPt9wmB672I7TuV5f4OVTbUhbN10m4oX+4t3BID9A8N 7vuTJwX8Cv+zsYsM9wPN92lKr7pDUwYPZguFa3CneJOJY0b8qappsClLYJ1VlrDShaX/ Sa/0Q2SFVyCd6kKZeXOe7Ly7e0ntYq1bzEEIReKo1TgrXe43hkRHpmAKa/yJJQdqLWC4 Yevw==
X-Gm-Message-State: ALQs6tDSkR/p8/rRh9AF8JPhNjVPGfGNh3t9IJs8b6yla0HYOmmbE+0l tJ6HH1HpiA1otTHbNJFzW89/dikqZiSifDwpWSg=
X-Google-Smtp-Source: AB8JxZqlNx/Ej0kw9MPwmePiPU029Z4CL8QFGC23UNCbgdGBIebbvQ/KF6npvKFKYPoLFqXUQfdwWXS+ch1ehap2Mt8=
X-Received: by 2002:a25:e08:: with SMTP id 8-v6mr4997356ybo.71.1525232916739; Tue, 01 May 2018 20:48:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Tue, 1 May 2018 20:48:36 -0700 (PDT)
In-Reply-To: <MWHPR21MB0638014E783CE63F5D30DE38B6810@MWHPR21MB0638.namprd21.prod.outlook.com>
References: <CANatvzwCYrOZULG3iVmDFp97nr=M5=Gufo8TZjOGQVFUpsn0bQ@mail.gmail.com> <CAAedzxqDcPXJUE83KVnDiU23PvqDcTCrc6rRMw09FexjJA-Y6Q@mail.gmail.com> <CANatvzwjYE6EdvFtOXJMVQnutbVQ4YY+=XsQFzKwHzqWzZ4U+w@mail.gmail.com> <d32ade7b56bf4651952659307c08893b@usma1ex-dag1mb5.msg.corp.akamai.com> <CANatvzwHtCn8rLB8npf3i7PGyYZhVDRd2uojh5hv3uxtFPEsSA@mail.gmail.com> <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch> <CACpbDcdfF9w3qqrH1eB0sGU_4vheD9aMP5EXnp1o3Y19N19NUg@mail.gmail.com> <e8b4931a-3931-5b8d-8dad-3ca1939d5542@huitema.net> <CAKcm_gPaj3o-VTdA_0+Kk+nTcVJrYcs_BMyOiDGXKub3gB=GLg@mail.gmail.com> <MWHPR21MB063869878060E850137210FEB6820@MWHPR21MB0638.namprd21.prod.outlook.com> <20180501121906.GA5742@akamai.com> <F63059EA-BA14-4886-A4FB-AA5F04AC164B@akamai.com> <BY2PR15MB07757EAB6A818F1D8D8CCED9CD810@BY2PR15MB0775.namprd15.prod.outlook.com> <CA+9kkMCpxve3CKhQk45YKbvyOyQ6kvzyhpJhrTq1UM-QM+ms2Q@mail.gmail.com> <89893592-7135-4C24-BE1E-4B0FFD1A2E97@trammell.ch> <CA+9kkMCUTRrM9SPEz=Q5GDgU7whryZ1cRdj-O3=GP=-vOr-X+A@mail.gmail.com> <ba56bca23f5747e5abdfec137de37481@usma1ex-dag1mb5.msg.corp.akamai.com> <MWHPR21MB0638014E783CE63F5D30DE38B6810@MWHPR21MB0638.namprd21.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 01 May 2018 22:48:36 -0500
Message-ID: <CAKKJt-e6WsXpvTRELUSCMRQJBgAsRFHPh9SHO6sH_LHEYY1VmQ@mail.gmail.com>
Subject: Re: Getting to consensus on packet number encryption
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, Ted Hardie <ted.ietf@gmail.com>, "Brian Trammell (IETF)" <ietf@trammell.ch>, "Salz, Rich" <rsalz@akamai.com>, Benjamin Kaduk <bkaduk@akamai.com>, IETF QUIC WG <quic@ietf.org>, Roberto Peon <fenix@fb.com>
Content-Type: multipart/alternative; boundary="00000000000033bc18056b30f6b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/u3c6MaJfG9rWzyiIH6LdydfJV5E>
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: Wed, 02 May 2018 03:48:40 -0000

Speaking as a curious observer with no hat on ...

On Tue, May 1, 2018 at 1:59 PM, Praveen Balasubramanian <
pravb=40microsoft.com@dmarc.ietf.org> wrote:

> Yeah this doesn’t have to be unilateral and is a negotiation. Either side
> is free to terminate the handshake and fall back to TCP if it doesn’t want
> to support the transforms being offered in the negotiation. This works
> perfectly fine for the intra-DC use cases.
>

So, please help me understand whether I'm tracking this.

Most of the time, QUIC connections are expected to traverse something like
the public Internet, so a bunch of participants want PNE as an
anti-ossification thing in this case.

Sometimes, QUIC connections would traverse only a controlled network path
(which I THINK is the point of the conversation about datacenters), for
server-to-server connections. Some participants would like to avoid any
overhead they can avoid in those situations, and don't see any need for
PNE, only additional (single-digit percentage) costs, and would like to
negotiate not using PNE for those connections.

Is that about right, so far? Assuming so ...

Is it correct that those connections are using TCP today, and are seeing
sufficiently good performance with TCP to make additional overhead look
problematic?

Is it correct that if an implementation doesn't want to use QUIC with PNE
overhead, Plan A would be to refuse the QUIC connection and fall back to
TCP?

Thanks in advance for clues ...

Spencer