Proposal to replace ACK block count with ACK length

"Deval, Manasi" <manasi.deval@intel.com> Mon, 11 June 2018 15:33 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 49D751277BB for <quic@ietfa.amsl.com>; Mon, 11 Jun 2018 08:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 D6QwfMNNIf6Q for <quic@ietfa.amsl.com>; Mon, 11 Jun 2018 08:33:45 -0700 (PDT)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 D96EC12D949 for <quic@ietf.org>; Mon, 11 Jun 2018 08:33:44 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2018 08:33:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.49,502,1520924400"; d="scan'208,217"; a="62198523"
Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga004.fm.intel.com with ESMTP; 11 Jun 2018 08:33:42 -0700
Received: from orsmsx163.amr.corp.intel.com (10.22.240.88) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 11 Jun 2018 08:33:42 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.50]) by ORSMSX163.amr.corp.intel.com ([169.254.9.20]) with mapi id 14.03.0319.002; Mon, 11 Jun 2018 08:33:41 -0700
From: "Deval, Manasi" <manasi.deval@intel.com>
To: IETF QUIC WG <quic@ietf.org>
Subject: Proposal to replace ACK block count with ACK length
Thread-Topic: Proposal to replace ACK block count with ACK length
Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xA==
Date: Mon, 11 Jun 2018 15:33:35 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWNjMzYzNmQtYzE5NS00Y2IzLWE2YmUtNGVkYjQyNzIyNmVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZmk1aXVVNTIrbnNBWHJSeTlPWVJ5YnZKXC9NVXN4aFd2eHZTRUMwQUsyTjlMR2Qxdklwb0RDOXE2QVFRSDNNRFAifQ==
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.200.100
dlp-reaction: no-action
x-originating-ip: [10.22.254.140]
Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B832414ORSMSX111amrcor_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/h5v6wZMFnetu-a-WKUtrTPXRvTU>
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: Mon, 11 Jun 2018 15:33:48 -0000

Hi All,

I was wondering why QUIC ACK header does not have a length field.

For example, while parsing the QUIC ACK, I find that an offload for segmentation or coalescing needs to identify an ACK interleaved between streams. As the ACK cannot be broken up and the chunk of ACK bytes needs to be moved as a block, reading the entire ACK to identify its length is a heavy lift.

Therefore, I'm proposing an ACK format with an ACK length instead of ACK block count.

What is the change?

*        ACK length is the first field, fixed length of 2 bytes.

*        ACK length is defined as the length of the entire ACK block, including the 2 byte ACK length.

*        ACK length replaces the ACK block count.

There is no change to Largest Acknowledged or ACK delay.



    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |        ACK Length             |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                     Largest Acknowledged (i) max 64 bit     ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           ACK Delay (i)                     ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          ACK Blocks (*)                     ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The advantages of the length field are:
-        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 -
o    If this is run on high end CPUs, the length helps identify the length for some SIMD modifications.
o   If this is a low end CPU, the multi-threading becomes more important for performance.
-        For the case where a receiver coalesce layer is augmenting the QUIC stack, I expect that it would separate the coalescing into stream frames, ACK frames and control frames. Availability of ACK length, simplifies this logic.
-        For a case where a transmit segmentation layer would like to make an intelligent decision on whether the ACK can be placed in a segment or not - it needs to know the size of ACK. Having to do a series of reads to identify the ACK size is inefficient.

Thanks,
Manasi