Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <david@lang.hm> Sun, 11 October 2015 03:46 UTC

Return-Path: <david@lang.hm>
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 A898B1A1F70; Sat, 10 Oct 2015 20:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 D261i896sE9x; Sat, 10 Oct 2015 20:46:08 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A311A1EF1; Sat, 10 Oct 2015 20:46:07 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t9B3jtY7001120; Sat, 10 Oct 2015 20:45:55 -0700
Date: Sat, 10 Oct 2015 20:45:55 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <F62FF3E5-EC9E-4534-B005-2A987C63C41D@gmail.com>
Message-ID: <alpine.DEB.2.02.1510102042280.1856@nftneq.ynat.uz>
References: <5618005A.8070303@isi.edu> <70335.1444421059@lawyers.icir.org> <D23D8CA5.54DF5%g.white@cablelabs.com> <56183B49.4000506@isi.edu> <alpine.DEB.2.02.1510091511540.3717@nftneq.ynat.uz> <56183E93.1010308@isi.edu> <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz> <5618420E.9040609@isi.edu> <alpine.DEB.2.02.1510091628010.3717@nftneq.ynat.uz> <5618554F.3080103@isi.edu> <alpine.DEB.2.02.1510091716100.3717@nftneq.ynat.uz> <56185E44.9050702@isi.edu> <alpine.DEB.2.02.1510091910170.3717@nftneq.ynat.uz> <561891C3.90004@isi.edu> <alpine.DEB.2.02.1510092134190.15683@nftneq.ynat.uz> <5618AF0A.4010101@isi.edu> <alpine.DEB.2.02.1510101439090.1856@nftneq.ynat.uz> <alpine.DEB.2.02.1510101525170.1856@nftneq.ynat.uz> <F62FF3E5-EC9E-4534-B005-2A987C63C41D@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="680960-712473157-1444535161=:1856"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/n0Hi3j0AMwv9OYziJXJSrqCjPEY>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Joe Touch <touch@isi.edu>, "mallman@icir.org" <mallman@icir.org>, "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] [tcpm] 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: Sun, 11 Oct 2015 03:46:09 -0000

On Sun, 11 Oct 2015, Jonathan Morton wrote:

>> On 11 Oct, 2015, at 01:28, David Lang <david@lang.hm> wrote:
>>
>>> So even if I could wave a magic wand and deploy this on every router, it 
>>> would only have an effect in a few places. Endpoint links where the 
>>> available bandwidth drastically changes are not the exclusive list of palces 
>>> that this would effect, but I think it's pretty close.
>>
>> Also, since it costs CPU to go through the queue looking for ACK packets to 
>> try and combine, it is a feature unlikly to be enbled on high speed devices. 
>> It would probably only be enabled when the savings in the reduced number of 
>> ACKs that would be transmitted is significant enough to be worth the effort. 
>> Endpoint devices for home users where there is probably also a highly 
>> asymmetric link are a very clear win. Core routers are almost never going to 
>> be a win.
>
> In the case of wifi, aggregation and huge per-TXOP overheads mean that the 
> cost of sending multiple acks instead of just one is negligible.  It’s simply 
> not worth performing any sort of compression or consolidation except for 
> (losslessly reversible) aggregation, because the gains pale into 
> insignificance next to that unavoidable overhead.

the cost in that txop of sending multiple acks instead of one is minor, but does 
sending those multiple acks mean that there are data packets that have to wait 
for the next txop?

But I actually view this as a tragedy of the commons situation. Sending the 
extra packets doesn't hurt you, but it does mean that you are using more airtime 
than you need, and that hurts everyone (including, eventually, you)

Anything that we can routinely do to minimize the length of the transmission 
should be done.

David Lang