RE: Proposal to replace ACK block count with ACK length
Praveen Balasubramanian <pravb@microsoft.com> Fri, 15 June 2018 22:10 UTC
Return-Path: <pravb@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 88F25130E77 for <quic@ietfa.amsl.com>; Fri, 15 Jun 2018 15:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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] 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 0WiHjMBw5CNE for <quic@ietfa.amsl.com>; Fri, 15 Jun 2018 15:10:25 -0700 (PDT)
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710098.outbound.protection.outlook.com [40.107.71.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA80130E6D for <quic@ietf.org>; Fri, 15 Jun 2018 15:10:24 -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:X-MS-Exchange-SenderADCheck; bh=VGO/5yCv0nk4CX3AIaBAIc9UY+WxwJ0o7eqINJkgdh8=; b=TXsXVCZgQeALQMg8HQEP58Gq99HbBx8sjQw19/QP2+eXCrS0NQkzuMxN7EG58PLuVViTqNsLXg8eYwdxpcfVH0YlKMs6B7P7MOjSFeIohtN2fQ2wnXAJZsyje2+pblmQraxhcCJT40IvHVe9UvTuiZerrFhsxNpx+PjIHeE6Bww=
Received: from MWHPR21MB0638.namprd21.prod.outlook.com (10.175.141.139) by MWHPR21MB0783.namprd21.prod.outlook.com (10.173.51.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.14; Fri, 15 Jun 2018 22:10:23 +0000
Received: from MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::85d1:84f:573e:7afb]) by MWHPR21MB0638.namprd21.prod.outlook.com ([fe80::85d1:84f:573e:7afb%5]) with mapi id 15.20.0884.010; Fri, 15 Jun 2018 22:10:23 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>, "Deval, Manasi" <manasi.deval@intel.com>
CC: Jana Iyengar <jri.ietf@gmail.com>, QUIC WG <quic@ietf.org>
Subject: RE: Proposal to replace ACK block count with ACK length
Thread-Topic: Proposal to replace ACK block count with ACK length
Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFON0uAAA2Oe4AABJAbAAC4BBWAAAAXlWA=
Date: Fri, 15 Jun 2018 22:10:23 +0000
Message-ID: <MWHPR21MB0638068EFA850328793E55F6B67C0@MWHPR21MB0638.namprd21.prod.outlook.com>
References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <CACpbDcdxzRxeiN93kKoj__vo2TERm4QZKqaesL=jr4wQUN1gXA@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <CABcZeBOjjRrX+AsXdgcUKpL=ciL8U_U1+WVAhQv-ZjwGxkQxYw@mail.gmail.com>
In-Reply-To: <CABcZeBOjjRrX+AsXdgcUKpL=ciL8U_U1+WVAhQv-ZjwGxkQxYw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:8:491e:330a:610c:ec8b]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0783; 7:r+VsOcHeccTJcncx0iRtHE7ffL2JdBNB5jewsdC3NFxtmEhUyZlRKeulwf+ZZCEXrvxQLqEZevMtTRvFJHXMUiuGV8lYR5WPF0N/BdHY8CfBB+LloJ78/M0MJrg743zy4Ye2r+NdMc3Pk/6kJo3ODn20CaYjyYoNXw7rYy8yKaorhV0DtOLpbYgrGzspQCpZPrXYx+aRDJQa3siTAt0EfCKGMxskAqaSeAvt679H420Nz6rr2Ud9yJ3qbZL/OSpb
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 162d5402-919d-46dd-28fa-08d5d30cca67
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MWHPR21MB0783;
x-ms-traffictypediagnostic: MWHPR21MB0783:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <MWHPR21MB078399FBB368A3404ED0A93FB67C0@MWHPR21MB0783.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(788757137089)(21748063052155)(228905959029699);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR21MB0783; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0783;
x-forefront-prvs: 0704670F76
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(396003)(39380400002)(39860400002)(199004)(189003)(19609705001)(106356001)(236005)(53936002)(105586002)(10290500003)(478600001)(4326008)(25786009)(5660300001)(68736007)(86612001)(186003)(476003)(486006)(2900100001)(97736004)(39060400002)(6246003)(86362001)(3660700001)(33656002)(9686003)(229853002)(76176011)(2906002)(6116002)(446003)(6306002)(6506007)(53546011)(561944003)(7736002)(99286004)(8936002)(102836004)(54896002)(3280700002)(81166006)(81156014)(8676002)(7696005)(790700001)(11346002)(10090500001)(5250100002)(8990500004)(14454004)(54906003)(74316002)(93886005)(55016002)(110136005)(22452003)(46003)(6436002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0783; H:MWHPR21MB0638.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: IGEU0q8+1+vZ2uI4fsttKdP3gDSE+dgnOrU7GRs9CJgI+CZU1B2NQO9VkLA8gJ7dzYoWm3YAdFtY67ncL2IpzQ/LLVWnVCWabWa4+qva/qB+u7m2bf10aFIKAKWpYBUzjmkKoLGl6D1gYb/hmhVevQlbrn6GEbD9/wRB9Loa3+fIGNibUM3xo/vEM40vQ1Ts
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0638068EFA850328793E55F6B67C0MWHPR21MB0638namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 162d5402-919d-46dd-28fa-08d5d30cca67
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2018 22:10:23.0959 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0783
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/E6m0cbGyxcOQveWf_ntfjip8jnI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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, 15 Jun 2018 22:10:28 -0000
I agree as well since this can help reduce per packet processing overhead. ACKs are going to be the second most common frame type so no objections to special casing. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, June 15, 2018 9:11 AM To: Deval, Manasi <manasi.deval@intel.com> Cc: Jana Iyengar <jri.ietf@gmail.com>; QUIC WG <quic@ietf.org> Subject: Re: Proposal to replace ACK block count with ACK length I agree with Manasi here. This change would allow ack frame parsing to be more self-contained, which is an advantage for the parser and also potentially for parallelism (because you can quickly find the frame and then process it in parallel). -Ekr On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi <manasi.deval@intel.com<mailto:manasi.deval@intel.com>> wrote: In general, varints require some specific logic for parsing. To skip over any header, I have to read every single varint. As the code sees Stream and ACK headers most frequently, that is my focus. The Stream frame has a length in its third field. ACK parsing, however, needs 6 + 2*num_blocks reads to identify length. There are two reads each for ‘largest acknowledged’, ‘ACK delay’ and ‘ACK block count’. The pain point is the total number of cycles parse an ACK. If I am processing 10M pps, where 10% - 30% of the packets have a piggybacked ACK, these cycles becomes a significant bottleneck. Thanks, Manasi From: QUIC [mailto:quic-bounces@ietf.org<mailto:quic-bounces@ietf..org>] On Behalf Of Jana Iyengar Sent: Monday, June 11, 2018 3:11 PM To: Deval, Manasi <manasi.deval@intel.com<mailto:manasi.deval@intel.com>>; QUIC WG <quic@ietf.org<mailto:quic@ietf.org>> Subject: Re: Proposal to replace ACK block count with ACK length You're right that we no longer have the ability to skip an ACK frame, and this crept in when we moved to varints. I believe your problem though is generally true of most frames not just ACKs, since ids, packet numbers, and numbers in all frames are now all varints. To skip any frame, you'll need to parse the varint fields in those frames. If you have logic to process and skip varints, then skipping the ack block section is merely repeating this operation (2*num_block+1) times. Do you see specific value in skipping ACK frames over the other control frames? On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com<mailto:dtikhonov@litespeedtech.com>> wrote: On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote: > - Moving the ACK length to the front of the ACK allows the > flexibility of either reading the entire ACK or reading the > first 16 bits and skipping over the length. This is a useful > feature for the case where ACK processing is split into > multiple layers. Depending on the processor this is run on, > there are different advantages - Just a note. In my experience, the cost of parsing an ACK frame is negligible compared to the cost of processing an ACK frame: that is, poking at various memory locations to discard newly ACKed packets. - Dmitri.
- Re: Proposal to replace ACK block count with ACK … Mikkel Fahnøe Jørgensen
- Re: Proposal to replace ACK block count with ACK … Eric Rescorla
- Re: Proposal to replace ACK block count with ACK … Kazuho Oku
- RE: Proposal to replace ACK block count with ACK … Nick Banks
- Re: Proposal to replace ACK block count with ACK … Ian Swett
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- Re: Proposal to replace ACK block count with ACK … Mikkel Fahnøe Jørgensen
- Re: Proposal to replace ACK block count with ACK … Ian Swett
- Re: Proposal to replace ACK block count with ACK … Mirja Kühlewind
- Re: Proposal to replace ACK block count with ACK … Marten Seemann
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- Re: Proposal to replace ACK block count with ACK … Eric Rescorla
- Re: Proposal to replace ACK block count with ACK … Ian Swett
- RE: Proposal to replace ACK block count with ACK … Mikkel Fahnøe Jørgensen
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- Re: Proposal to replace ACK block count with ACK … Marten Seemann
- Re: Proposal to replace ACK block count with ACK … Kazuho Oku
- Re: Proposal to replace ACK block count with ACK … Marten Seemann
- Re: Proposal to replace ACK block count with ACK … Kazuho Oku
- Re: Proposal to replace ACK block count with ACK … Ian Swett
- Re: Proposal to replace ACK block count with ACK … Eric Rescorla
- Re: Proposal to replace ACK block count with ACK … Kazuho Oku
- Re: Proposal to replace ACK block count with ACK … Eggert, Lars
- Re: Proposal to replace ACK block count with ACK … Christian Huitema
- Re: Proposal to replace ACK block count with ACK … Kazuho Oku
- Re: Proposal to replace ACK block count with ACK … Marten Seemann
- Re: Proposal to replace ACK block count with ACK … Martin Thomson
- Re: Proposal to replace ACK block count with ACK … Jana Iyengar
- RE: Proposal to replace ACK block count with ACK … Praveen Balasubramanian
- Re: Proposal to replace ACK block count with ACK … Eric Rescorla
- Re: Proposal to replace ACK block count with ACK … Mikkel Fahnøe Jørgensen
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- Re: Proposal to replace ACK block count with ACK … Dmitri Tikhonov
- Proposal to replace ACK block count with ACK leng… Deval, Manasi
- Re: Proposal to replace ACK block count with ACK … Jana Iyengar
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- Re: Proposal to replace ACK block count with ACK … Subodh Iyengar
- Re: Proposal to replace ACK block count with ACK … Deval, Manasi
- RE: Proposal to replace ACK block count with ACK … Deval, Manasi
- Re: Proposal to replace ACK block count with ACK … Mirja Kühlewind