Re: [aqm] [tcpm] TCP ACK Suppression

Joe Touch <> Tue, 13 October 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4D2E1B45CC; Tue, 13 Oct 2015 07:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iUdCXtSo7_5x; Tue, 13 Oct 2015 07:55:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1ED71B45CA; Tue, 13 Oct 2015 07:55:28 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t9DEsx68006639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Oct 2015 07:55:02 -0700 (PDT)
To: David Lang <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Joe Touch <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 13 Oct 2015 07:54:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
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: Tue, 13 Oct 2015 14:55:31 -0000


On 10/11/2015 3:49 PM, David Lang wrote:
>> 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,

But you claim to need to drop the ACKs to avoid dropping other packets.
What's to say that 1) the ACKs won't end up getting dropped in your
system or 2) the ACKs won't get dropped further downstream?

Again, *you* don't know.

>> and increases
>> discretization effects in the TCP algorithms.
> This is where I disagree with you. The ACK packets are already collapsed
> time-wise.

Time is only one element of the discretization. The other is fate
sharing - dropping one aggregate ACK has the effect of dropping the
entire set of un-aggregated ones. The stream of unaggregated ACKs gives
TCP a robustness to drops, but you're now forcing a large burst of drops
for a specific packet type. That's the problem.

We've gone round this issue for a lot of messages, but the key point is
that this isn't a new idea, nor are the numerous considerations and

Ultimately, if you have too many packets from a protocol that reacts to
congestion, the correct solution is to provide that feedback and let the
ends figure out how to respond. That's the only solution that will work
when (not if) new messages or encrypted headers enter the picture.

These kinds of in-network hacks are what's really killing the ability of
the Internet to evolve.