Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <> Sun, 11 October 2015 22:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A5271B2E98; Sun, 11 Oct 2015 15:49:45 -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 v89X5Ykw8eeZ; Sun, 11 Oct 2015 15:49:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D57B1B2E9A; Sun, 11 Oct 2015 15:49:41 -0700 (PDT)
Received: from ( []) by (8.13.4/8.13.4/Debian-3) with ESMTP id t9BMnPZs008510; Sun, 11 Oct 2015 15:49:25 -0700
Date: Sun, 11 Oct 2015 15:49:25 -0700 (PDT)
From: David Lang <>
To: Joe Touch <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
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: "" <>, "" <>, "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <>, Greg White <>, 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: Sun, 11 Oct 2015 22:49:45 -0000

On Sun, 11 Oct 2015, Joe Touch wrote:

> On 10/11/2015 2:18 PM, David Lang wrote:
>> But you will notice that in both cases, I am in favor of reducing the
>> number of packets on the wire. Packets not send can't interfere with
>> other traffic.
> The degenerate case of this approach is a circuit. Take a look at
> Morris's 1997 ICNP paper to see what happens when you end up with one -
> or sometimes less than one - packet per round trip time.
> One of the reasons we use packets is to provide more timely,
> fine-grained feedback between endpoints. Aggregating them at the source
> or in the network (rather than at the receiver) can amplify reaction to
> packet loss (when the aggregate ACK is lost)

the issue of amplified reaction to packet loss is a valid one, but packet loss 
is still pretty rare, so the proposal of putting a duplicate stretched ack into 
the queue for the next transmit window when you aggregate packets in the current 
transmit window should largely mitigate this.

In addition, Since cablemodems have been doing this for 15 years, we should be 
able to get people to look at real-world traffic and tell us how much of a 
problem this is.

> and increases
> discretization effects in the TCP algorithms.

This is where I disagree with you. The ACK packets are already collapsed 
time-wise. Whatever timing they had when they were generated, the fact that they 
are all sitting in the same queue at the same time means taht that timing has 
been lost, Nobody is adding latency by trying to recreate the time spacing, so 
the discretization (or as I've been calling it quantitization) of the traffic is 
happening even if every ACK packet is sent.

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 am in no way advocating delaying any packet that could be sent, just combining 
those that have already been delayed.

We're talking about ACK packets here, but any protocol that sends short TCP 
packets is potentially fair game (TCP/SSH for example). If the packets are all 
sitting in the same queue, they should be able to be combined. This happens on 
the sending server if multiple writes to the socket happen before the packet has 
been sent, it should be able to happen on the network as well (further reducing 
overhead by sending the same data with fewer packets)

David Lang