Re: [aqm] TCP ACK Suppression

Greg White <> Tue, 06 October 2015 16:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 532AA1ACE12 for <>; Tue, 6 Oct 2015 09:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Xll7hwVeUTc for <>; Tue, 6 Oct 2015 09:35:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EA3461ACE52 for <>; Tue, 6 Oct 2015 09:35:27 -0700 (PDT)
Received: from (kyzyl []) by (8.14.7/8.14.7) with ESMTP id t96GZPq0005170; Tue, 6 Oct 2015 10:35:26 -0600
Received: from ( by (F-Secure/fsigk_smtp/407/; Tue, 06 Oct 2015 10:35:25 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/
Received: from ([::1]) by ([::1]) with mapi id 14.03.0224.002; Tue, 6 Oct 2015 10:35:24 -0600
From: Greg White <>
To: Mikael Abrahamsson <>, "" <>
Thread-Topic: [aqm] TCP ACK Suppression
Thread-Index: AQHRAAfaJ/73TrlDIUOGwELhN8Uffp5eqfGA
Date: Tue, 6 Oct 2015 16:35:22 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [aqm] TCP ACK Suppression
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Oct 2015 16:35:39 -0000


Specialized upstream TCP ACK handling (which can include both
prioritization and suppression) is a recommended feature in the DOCSIS
specification.  The details of the implementation are left to the
manufacturer, but I don't expect that it is actually done at dequeue
(packet processing at dequeue is expensive in cable modems).  Rather, I
expect that devices identify ACKs at enqueue, and retain (separate from
the main service-flow queue) a single ACK for each TCP session.  Then,
upon receiving a grant, the ACK queue is flushed first, followed by
packets from the main queue.

The CM is not permitted to issue bandwidth requests for more data than it
has available to send, so bandwidth requests would need to already have
ACK suppression taken into account.  For this reason (and the above), I
doubt that the CM would include suppressed ACKs in its queue depth and
queuing latency estimation.

AQM in DOCSIS also happens at enqueue.  The spec is silent on whether the
upstream TCP ACKs are subject to AQM packet drop, but it would be
compliant for them (i.e. the one ACK per session) to be protected.


On 10/6/15, 1:20 AM, "aqm on behalf of Mikael Abrahamsson"
< on behalf of> wrote:

>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:
>"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
>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
>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:
>aqm mailing list