IETF Logo Mail Archive

RE: Cost of parsing ACK frames in QUIC

Nick Banks <nibanks@microsoft.com> Thu, 10 May 2018 14:50 UTC

Return-Path: <nibanks@microsoft.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 1EC0A1241FC for <quic@ietfa.amsl.com>; Thu, 10 May 2018 07:50: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_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 bj7L68r4_8yV for <quic@ietfa.amsl.com>; Thu, 10 May 2018 07:50:00 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09BA12EB0A for <quic@ietf.org>; Thu, 10 May 2018 07:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QxXVLQGqriFqcNREJMwzwtWIEUSzoj3YeuvwgknNndU=; b=H8EN/zSDK2uPbiK+jS0oxzA3Y3Bhs0thmJIbUzWkW2jD/F5HuUI8fED1BravZNjnhMibhGwcDlqdtbYoGQECxyiCNBnDCrB2omuu0yyF2gZHKxa86SdJ+9rm6wUB1ew2AsT2R9mYLwaLv4q0xTdRxr9btgELZdHAlUmGBbtS5AI=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1047.namprd21.prod.outlook.com (52.132.128.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.3; Thu, 10 May 2018 14:49:58 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::ac02:3f79:af:e239]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::ac02:3f79:af:e239%2]) with mapi id 15.20.0776.004; Thu, 10 May 2018 14:49:58 +0000
From: Nick Banks <nibanks@microsoft.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "Deval, Manasi" <manasi.deval@intel.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Cost of parsing ACK frames in QUIC
Thread-Topic: Cost of parsing ACK frames in QUIC
Thread-Index: AdPoaJzXsjis3gTFQX6IIe0OpT4RMgABMS+AAAANEdA=
Date: Thu, 10 May 2018 14:49:58 +0000
Message-ID: <DM5PR2101MB0901149C9E14440DF9CEE269B3980@DM5PR2101MB0901.namprd21.prod.outlook.com>
References: <1F436ED13A22A246A59CA374CBC543998B64E65D@ORSMSX111.amr.corp.intel.com> <CAN1APdcfmAsM-CBGzFEicBWf6Ck2uRhOmoiooo7d3EPDTjwt7g@mail.gmail.com>
In-Reply-To: <CAN1APdcfmAsM-CBGzFEicBWf6Ck2uRhOmoiooo7d3EPDTjwt7g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-10T14:49:56.8437086Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8::256]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1047; 7:2D/rA+ASZdQlBLK0B7qfrpTwoWrj/acJFncli5LpXX3HYHwak++m5x3/nVSwWMPnnXaFpKtGelEpQP2GV38yquttRE2UGHAzqBSq7p+poKdylDwTZZHHyxrGKRRXYEnM7+KaIW2c3HBi1691KnVaF4mZg/np57TuTEDYC+D3/J+nqbAMvAI3VUhAK6WcLkd2kjiTrS/6dlJPWlKppYEpLd2ZzK8wlYiXQz0mFTxDbwbzdA0lheSRKs4uMuwt9Qn+; 20:+DefrBcXThYTDBmaKekPsjH/l/u5a/pMBe84hILp2OsjtEqTW/2MTTAIC++VcyyLVHGzfZp6C3KcZMabPL8DHQ8KHZxJqHMT2lwPMegYc9cIHnVmFpReVmOnxg07zKPXOX8aapW1elOj2vjDH0EYgHrnc1qorucU4dSnPW91B40=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB1047;
x-ms-traffictypediagnostic: DM5PR2101MB1047:
x-microsoft-antispam-prvs: <DM5PR2101MB1047C6BD9F8FC6D47097A99FB3980@DM5PR2101MB1047.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155)(228905959029699);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231254)(2018427008)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR2101MB1047; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1047;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(39380400002)(39860400002)(189003)(199004)(53754006)(86362001)(74316002)(106356001)(55016002)(54896002)(5250100002)(6306002)(5660300001)(59450400001)(19609705001)(10090500001)(2900100001)(22452003)(14454004)(7696005)(97736004)(99286004)(110136005)(236005)(9686003)(53936002)(105586002)(10290500003)(3660700001)(81156014)(790700001)(476003)(7736002)(2906002)(6116002)(316002)(486006)(8676002)(6246003)(39060400002)(33656002)(446003)(86612001)(6436002)(8936002)(478600001)(3280700002)(6346003)(186003)(8990500004)(102836004)(6506007)(11346002)(76176011)(229853002)(68736007)(53546011)(81166006)(25786009)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1047; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com;
x-microsoft-antispam-message-info: pD5LZV6sNr/DvTCWxeM/fqjciPorNakGMpa+kCEbB/K+pdKpSIkXb0qjLkqh5GhVuY0gMMebnlT+Ac/bLv/gULUQXQfgv3m5WAxFX19FNUAm/HWrh3EO0Gh6KjWwYlqpV0hdSFQsqMgx6sirCELXtPtYsKBDfroWR0ez78oHmKH64jC1tU7EXXdjPuHlAPZM
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901149C9E14440DF9CEE269B3980DM5PR2101MB0901_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 1c556ccb-1b52-48c0-f0b2-08d5b6854d14
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c556ccb-1b52-48c0-f0b2-08d5b6854d14
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 14:49:58.2006 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1047
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Mcbc_l1oGY0ncovy_19sheh-Vb4>
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: Thu, 10 May 2018 14:50:03 -0000

I’m don’t agree that you need to make two passes on a packet when processing ACK frames. If you have successfully decrypted the packet and you got to the point of processing ACK frames, then any other error that would later encounter while processing the packet would likely be considered a protocol violation, would it not? If so, then you would terminate the entire connection.

That being said, on the topic of being a bit more expensive to process ACK frames in general, QUIC has made a decision to generally prefer smaller wire encoding over CPU costs, where appropriate. If you have a suggestion to change the encoding that doesn’t increase the wire format cost, we could take a look at it.

- Nick

From: QUIC <quic-bounces@ietf.org> On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Thursday, May 10, 2018 7:44 AM
To: Deval, Manasi <manasi.deval@intel.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Cost of parsing ACK frames in QUIC

While this may be true, please note that QUIC also requires that the entire packet is valid before it does anything that modifies the state of the receiver.

This means that you generally have to do two passes of the packet to ensure that the packet is valid. In the first pass you can then store data for the optimistic case of a single ACK frame.

That said, arguments about fast(er) processing still apply, but it is no longer limited to only ACK frames.



On 10 May 2018 at 16.25.50, Deval, Manasi (manasi.deval@intel.com<mailto:manasi.deval@intel.com>) wrote:
Hi All,

The QUIC header definitions tend to use as few bits as possible by implementing the policy to use variable size fields. The result of this policy would be that each receiver needs to do a two part lookup to identify the field and this needs to be implemented serially in order to parse the whole frame time.

For example, in a case where no packets were dropped, a sender may receive an ACK for a single block. If a code path were trying to determine the size of an ACK, they would have to read 8 fields to determine the size of ACK.

A client only sees a few ACKs. Majority of the ACKs are seen on the server side. It would be good to simplify this scheme so ACK processing can be accelerated with SIMD instructions would be good.

Thanks,
Manasi

v2.23.0 | Report a Bug | By Email