Re: [aqm] TCP ACK Suppression

David Lang <> Wed, 07 October 2015 21:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 778A91B310B for <>; Wed, 7 Oct 2015 14:28:43 -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 t4P_LJh8015w for <>; Wed, 7 Oct 2015 14:28:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A88491B310A for <>; Wed, 7 Oct 2015 14:28:34 -0700 (PDT)
Received: from ( []) by (8.13.4/8.13.4/Debian-3) with ESMTP id t97LSP1c005478; Wed, 7 Oct 2015 14:28:25 -0700
Date: Wed, 7 Oct 2015 14:28:25 -0700 (PDT)
From: David Lang <>
To: Richard Scheffenegger <>
In-Reply-To: <39DD3F3C880D43E292DEDEFDA9C80ED6@srichardlxp2>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <39DD3F3C880D43E292DEDEFDA9C80ED6@srichardlxp2>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <>
Cc: Jonathan Morton <>,,
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: Wed, 07 Oct 2015 21:28:43 -0000

On Wed, 7 Oct 2015, Richard Scheffenegger wrote:

> [as one of the AccECN authors]
> Hi David,
> I believe you are convoluting a few things in the assumptions behind your 
> comment...
> First, as of now, ACKs are non-ECT; and even if they were marked as ECT by 
> the receiver, and subsequently marked CE by the network device when they get 
> bundled and thinned (which, by the way, may be the signal required for AckCC 
> RFC5690), that would not affect the rate of the data sent to the receiver...

fair enough.

> The issue with ACK thinning has most to do with causing a burst of data 
> segments that get sent all at once, requiring increased buffering later in 
> the network.

The point here is that the ACKs are going to all arrive at the same time anyway, 
so it doesn't matter if 32 ack packets arrive at wire speed, or just one packet 
arrives that acks all the data, in either case the data that is held up waiting 
for acks is going to be sent at the same time (if anything, avoiding the delay 
in receiving and processing the extra acks would decrease latency)

> And how the ECN-mark fraction or exact sequencing of the data segments is 
> conveyed back to the sender by the receiver, can be independent of ACK 
> thinning (you may want to read through one suggestion to have better ACK loss 
> protection while still being able to fully reconstruct the exact sequencing 
> of ECN markings in revision 
> (section 3.3.4).
> So, you have two issues - one of timing (ACK clock eliciting new data to 
> send), and one of loss of signal fidelity to deal with, when devices bundle 
> up ACKs, or thin out ACKs...

The issue here isn't that anything delays acks in order to bundle or thin them 
out, but that other criteria result in the acks sitting in one queue at some 
point in time. If they are already together like that, it makes sense to thin 

David Lang