RE: Getting to consensus on packet number encryption

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 01 May 2018 17:11 UTC

Return-Path: <ilubashe@akamai.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 44D7B124D6C for <quic@ietfa.amsl.com>; Tue, 1 May 2018 10:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 5HmAfvyKTEfk for <quic@ietfa.amsl.com>; Tue, 1 May 2018 10:11:12 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9BF1A12DB6D for <quic@ietf.org>; Tue, 1 May 2018 10:11:11 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w41H52k5012847; Tue, 1 May 2018 18:11:06 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=OXlKVkrrEGARS4MF03su8+LjTDeG15/WflHlOZu7TS4=; b=QXj0hXA9R25q8koEGGU1lriUYVPHvY6eAcGAsmN5UCk/QtHsTJgeAUfhqYS7O8Y+KkTs ShOQ5QqNUIIYjVsUuEwedvH9e7smVIRhKm/n5f/bp9B3hpxNf9UQc7xBYdbUo7+Y30e+ +qLFqF36+bvb/k5QcvkpEWd1vmIpWFNzt38AvcWZP0VFqY716mxkDNhR8loTPOWWv4LF bUpTUa7Aa10MssmrZgXI11rpNcrSbNUC7oQ9dSocol65G08/vJLcboD/UKe/5UDjJ+6A W+JM3Ch4jxGnQm7TgImTh92jRLdy3bA9dTALlWw7jOJqN2qsoR+5DHOsw0Pod7I2YkdR dw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2hmr65yf9a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 May 2018 18:11:06 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w41H1l7H011951; Tue, 1 May 2018 13:11:05 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 2hmm9uwrq4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 01 May 2018 13:11:05 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 1 May 2018 13:11:04 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1365.000; Tue, 1 May 2018 13:11:04 -0400
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Roberto Peon <fenix@fb.com>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
CC: IETF QUIC WG <quic@ietf.org>
Subject: RE: Getting to consensus on packet number encryption
Thread-Topic: Getting to consensus on packet number encryption
Thread-Index: AQHTy9GWvgm/QKk890OIh9EYaPY3H6PwqlkAgAC4ugCAAARcAIAAG5CAgAAFCQCAAACJgIAAEVgAgACR+YCAB09lAIAFXyIAgAVK+oCAAJlSAIABxdSAgACOHYCAB/ExAIACo7YAgACiMICAAADPgIAAIs8AgAAm/YCAABEygIAABpIAgAAK6ACAAK10MIABK7IAgACzcYCAAHHMgIAEe1cAgAABEACAABWHgIAA8UgAgAABeQCAAC8lAP//zCFQ
Date: Tue, 01 May 2018 17:11:03 +0000
Message-ID: <bf9c39f6d92449289abd7995bbfff0db@usma1ex-dag1mb5.msg.corp.akamai.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>
In-Reply-To: <BY2PR15MB07757EAB6A818F1D8D8CCED9CD810@BY2PR15MB0775.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.2]
Content-Type: multipart/alternative; boundary="_000_bf9c39f6d92449289abd7995bbfff0dbusma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-01_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=964 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805010166
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-01_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=883 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805010166
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rsa3Ukhdg_mJ0b7meRLGMl7HtSs>
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, 01 May 2018 17:11:15 -0000

Wait, the entire purpose of PNE is to make flow linking during connection migrations harder.  A server in an "open colo" talking to another server in an "open colo" is a perfect example when PNE is not needed.

The "uniformity and simplicity of implementation" makes sense, but we certainly did much weirder things (like a new transport) to gain performance.  Praveen's point is that a large portion of communication is between devices that are not mobile.  If PNE has a non-negligible cost (for example, HW acceleration requires more ASIC and is costlier), is "uniformity and simplicity" gained by the lack of the extra option worth it?

Another way of putting this is that QUIC's advantage over TCP is especially evident for the 90th percentile of connections, and these are likely not to be fixed server-to-server connections (within a DC or even between "open colos").  Any extra cost of QUIC over TCP (extra CPU-per-bit or server-cost-per-bit) will make it less likely that QUIC will be adopted for server-to-server connections.  Is the adoption risk and the extra costs risk worth the simplicity gained by not having an extra option?


  *   Igor


From: Roberto Peon [mailto:fenix@fb.com]
Sent: Tuesday, May 01, 2018 11:13 AM
To: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>; Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>; Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Getting to consensus on packet number encryption

Also, Prism.

-=R


Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org<mailto:rsalz=40akamai.com@dmarc.ietf.org>>
Date: 5/1/18 5:25 AM (GMT-08:00)
To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org<mailto:bkaduk=40akamai.com@dmarc.ietf.org>>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org<mailto:pravb=40microsoft.com@dmarc.ietf.org>>
Cc: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
Subject: Re: Getting to consensus on packet number encryption

    > I disagree that we need any more data for not doing PNE in the datacenter. Why would we add an extra encrypt-decrypt step for no obvious benefit?

I am concerned that people will mis-interpret the meaning of a datacenter, and think that a bunch of servers, or even a rack, in an open colo space is a "datacenter."  Computers keep getting faster.