Re: [aqm] TCP ACK Suppression

Rick Jones <rick.jones2@hpe.com> Fri, 09 October 2015 00:36 UTC

Return-Path: <rick.jones2@hpe.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA80C1B2E8E for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 17:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 vSkIJasL9yH6 for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 17:36:32 -0700 (PDT)
Received: from g1t6220.austin.hp.com (g1t6220.austin.hp.com [15.73.96.84]) (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 A63641B2E88 for <aqm@ietf.org>; Thu, 8 Oct 2015 17:36:32 -0700 (PDT)
Received: from g2t4689.austin.hpicorp.net (g2t4689.austin.hpicorp.net [15.94.10.175]) by g1t6220.austin.hp.com (Postfix) with ESMTP id CF6701A6 for <aqm@ietf.org>; Fri, 9 Oct 2015 00:36:31 +0000 (UTC)
Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g2t4689.austin.hpicorp.net (Postfix) with ESMTP id 828E73A for <aqm@ietf.org>; Fri, 9 Oct 2015 00:36:31 +0000 (UTC)
To: aqm@ietf.org
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5616DCD9.8@isi.edu> <alpine.DEB.2.02.1510081428470.3852@nftneq.ynat.uz> <CAK6E8=ePXkK4-=As2QQJCZjOyK7-NvC2njiYrsLzGEsqqFDJxg@mail.gmail.com>
From: Rick Jones <rick.jones2@hpe.com>
Message-ID: <56170C0F.2010404@hpe.com>
Date: Thu, 08 Oct 2015 17:36:31 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAK6E8=ePXkK4-=As2QQJCZjOyK7-NvC2njiYrsLzGEsqqFDJxg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/jP1MnVT2eVu1KWwuHxU8ostPqos>
Subject: Re: [aqm] TCP ACK Suppression
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 00:36:34 -0000

On 10/08/2015 02:52 PM, Yuchung Cheng wrote:
> I would like to add that GRO also cause stretched ACKs (acking up to
> 64KB), and GRO is crucial to reduce cycles for +10Gbps transfers on some
> architectures.

And they go back even further than GRO (or LRO) appearing in Linux. 
They go all the way back to the mid/late 1990s when HP-UX 11 and Solaris 
2 started shipping their cousin (Mentat origin) stacks with ACK 
avoidance heuristics in them.  Perhaps even before, but that is the 
earliest I know of.

GRO, TSO, CKO etc have come into being from the fields made fertile by 
the combination of ever increasing link speeds, never increasing de jure 
Ethernet MTUs, no longer increasing processor core frequency, and paying 
customer demand for performance.

happy benchmarking,

rick jones