Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <> Tue, 13 October 2015 19:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EDDCA1A8968; Tue, 13 Oct 2015 12:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7tAz_SveVkKG; Tue, 13 Oct 2015 12:36:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20B251A8965; Tue, 13 Oct 2015 12:36:12 -0700 (PDT)
Received: from ( []) by (8.13.4/8.13.4/Debian-3) with ESMTP id t9DJa1AG027663; Tue, 13 Oct 2015 12:36:02 -0700
Date: Tue, 13 Oct 2015 12:36:01 -0700 (PDT)
From: David Lang <>
To: Greg White <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: <>
Cc: "" <>, Joe Touch <>, "" <>, "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <>, Jonathan Morton <>, "" <>
Subject: Re: [aqm] [tcpm] 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, 13 Oct 2015 19:36:14 -0000

On Mon, 12 Oct 2015, Greg White wrote:

>> My contention is that since this is already happening, consolidating the ACK 
>> packets into stretched ACKs doesn't make this any worse, and it saves network 
>> bandwidth (and decreases latency to the extent that data is acked faster than 
>> waiting for the entire chain or original ACKs to get through, especially if 
>> that would take multiple transmit windows). As a result, thinning the ACKs is 
>> kinder to the network.
> I agree, *iff* they are not DupACKs signalling packet loss.  Do existing and 
> future cable modems take that subtle distinction into account?
> I presume that they are not discarding DupACKs or corrupting SACK in some way 
> (the whole point of specialized ACK handling is to ensure good TCP performance 
> after all), but since the algorithms are proprietary, for existing cable 
> modems I don't know.  I will contact the developers as well as run some tests 
> on a few modems to get a better idea (and maybe Mikael already has some data 
> from his recent testing he could share?).  For future modems, I can add an 
> explicit reference to RFC3449 in the DOCSIS 3.1 spec just in case implementers 
> aren't aware for some reason.

It should also say that AQM is needed on the downstream side to protect against 
transmit bursts.

The suggestion was posted early in this thread (but not in someting I can 
quickly find) that to harden the connection against the aggregate ACK being 
lost, it should be sent again in a separate transmit window.

I latched onto that and think the right thing to do is to duplicate the 
aggregate ACK that's created and put it at the beginning of the queue that 
remains after the current transmit window.

If there are more ACKs in the next transmit window, it will get aggregated into 
them and not cause any additional traffic.

If there are not any more ACKs in the next transmit window, and the first ACK 
was lost, it will replace it with the minimum of delay

If there are not any more ACKs in the next transmit window, and the first ACK 
was not lost, we are now transmitting a duplicate ACK, which may be interpreted 
as a signal to speed up tranmission (depending on the exact timing of the 
arrivials of these two ACKs). While this is not good, we already need to be 
protected from transmit bursts, so this is just another possible cause for such 

David Lang