IETF Logo Mail Archive

Cost of parsing ACK frames in QUIC

"Deval, Manasi" <manasi.deval@intel.com> Thu, 10 May 2018 14:25 UTC

Return-Path: <manasi.deval@intel.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 DDF7F12EADE for <quic@ietfa.amsl.com>; Thu, 10 May 2018 07:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8yaSwRPlJ3hS for <quic@ietfa.amsl.com>; Thu, 10 May 2018 07:25:40 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 3C22512EAD0 for <quic@ietf.org>; Thu, 10 May 2018 07:25:40 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2018 07:25:39 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.49,385,1520924400"; d="scan'208,217"; a="39913301"
Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by orsmga007.jf.intel.com with ESMTP; 10 May 2018 07:25:39 -0700
Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 10 May 2018 07:25:39 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.62]) by ORSMSX155.amr.corp.intel.com ([169.254.7.38]) with mapi id 14.03.0319.002; Thu, 10 May 2018 07:25:39 -0700
From: "Deval, Manasi" <manasi.deval@intel.com>
To: IETF QUIC WG <quic@ietf.org>
Subject: Cost of parsing ACK frames in QUIC
Thread-Topic: Cost of parsing ACK frames in QUIC
Thread-Index: AdPoaJzXsjis3gTFQX6IIe0OpT4RMg==
Date: Thu, 10 May 2018 14:25:38 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B64E65D@ORSMSX111.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.200.100
dlp-reaction: no-action
x-originating-ip: [10.22.254.138]
Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B64E65DORSMSX111amrcor_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pGD2nWPCN0c3lgGbwZA5SVygBxA>
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:25:42 -0000

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