[aqm] TCP ACK Suppression

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 06 October 2015 07:23 UTC

Return-Path: <swmike@swm.pp.se>
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 40FD21B387F for <aqm@ietfa.amsl.com>; Tue, 6 Oct 2015 00:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.238
X-Spam-Level:
X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 XSJX3_m85Foj for <aqm@ietfa.amsl.com>; Tue, 6 Oct 2015 00:22:59 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21F11B387C for <aqm@ietf.org>; Tue, 6 Oct 2015 00:20:29 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 44AC7A2; Tue, 6 Oct 2015 09:20:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1444116027; bh=cDihH4FdP0d5FKCMmg9LvgaPhyTgIpBt9wAN3YXapU8=; h=Date:From:To:Subject:From; b=c+i0Ry76lhZ/B0iOJihNnC7FsgAFjxnsdJlbjMHGsccs5MViI9Fg1yEnF0sisf1i+ W+0X7sg2kwT4PSgPNgeuHJtyvPhsxdbH91ue1qoRnluShHERBbE+UuwhBe2X+5mMch jz7OwCTgrZQLJ59+05m3lM+mHfw17y0FYDkGZ9NQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3BF18A1 for <aqm@ietf.org>; Tue, 6 Oct 2015 09:20:27 +0200 (CEST)
Date: Tue, 06 Oct 2015 09:20:27 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: aqm@ietf.org
Message-ID: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/XJ4SemDwXB2SPYWO7CKSLcX0IQE>
Subject: [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: Tue, 06 Oct 2015 07:23:01 -0000

Hi,

after noticing that some TCP ACKs on my home DOCSIS connection were not 
making it to their destination, I after some interaction with cable 
Internet people, I found this:

http://www.cedmagazine.com/article/2006/12/docsis-sub-throughput-optimization

"TCP ACK Suppression (TAS)"

"TCP ACK Suppression overcomes the TRGC limitation without actually 
affecting the DOCSIS specification or involving the CMTS. It improves 
downstream TCP transmissions by taking advantage of TRGC and only sending 
the last ACK it receives when its data grant becomes active. Thus, the 
number of TCP ACKs is fewer, but the number of bytes acknowledged by each 
TCP ACK is increased."

So the DOCSIS modem basically looks at all the ACKs in the queue at the 
time of transmission (DOCSIS uses a "grant" system to tell a modem when 
it's allowed to transmit on the shared medium), and then basically deletes 
all the redundant ACKs (the ones who are just increasing linearly without 
indicating packet drop) and keeps the highest ACK only.

Now, this kind of mechanism, how should it be treated when it comes to 
AQM? This mechanism is basically done at de-queue, when a number of 
packets are emptied from the queue at one time, which is then allowed to 
fill up again until the next transmit opportunity arises.

Or is this a non-problem because it's likely that any AQM employed here 
would use the buffer fill right after a transmit opportunity has finished 
(for those that consider buffer fill as a variable), which would mean that 
most likely the TCP ACK purging had already occured so this mechanism 
doesn't influence the AQM in any significant manner anyway?

Just as a data point from my home connection, I have 250/50 (down/up) and 
when downloading at 250 megabit/s, the upstream traffic is reduced by 
approximately 20x, so instead of sending 10 megabit/s (or so) of ACKs, I 
see approximately 500 kilobits/s of ACKs.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se