Re: [aqm] TCP ACK Suppression

Jonathan Morton <> Wed, 07 October 2015 17:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 329311ACD5B for <>; Wed, 7 Oct 2015 10:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mplW_AVF93Ke for <>; Wed, 7 Oct 2015 10:52:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89A2A1ACD5A for <>; Wed, 7 Oct 2015 10:52:58 -0700 (PDT)
Received: by lbwr8 with SMTP id r8so20050266lbw.2 for <>; Wed, 07 Oct 2015 10:52:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cXc85ajPgVqpu2wxVB4VZNKeaZJJis9fdELycF56tI4=; b=uHI0ETlkTisSRxnFSzmEgdk4ttYZwejyaBRQ+iPNzRNhqp5J9IJxAeFXFGvoAmOOs+ 1LX4MjfEfGeNtq/J9AgTPVCdqQtix+L5zBbDjWPJhk21cifrcT5VJ/JaXoatqAIXT6vC hxD8wVhEI8Vg//9gbuMJ4HTcK7sMokNvjIgrOEHNVEg0OBtKB7dYzWyr7v+7tHgJZevi gnWb9ZZ7C5BJ9DS8rIrRPHNFT7HmhdpDOvKV/tCZyq3lF7LZyXyCnTjsJ0UKcvar4Oty wvalCMkSdu5Iv8iUynYbOeMjUlU8Sre7j7Uc9M4fupFluhXpisVXhjsRmmtSSrXOrCwp 90HQ==
X-Received: by with SMTP id 21mr880998lfr.38.1444240376760; Wed, 07 Oct 2015 10:52:56 -0700 (PDT)
Received: from ( []) by with ESMTPSA id vz2sm6428205lbb.35.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Oct 2015 10:52:56 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Wed, 7 Oct 2015 20:52:53 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.2104)
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: Wed, 07 Oct 2015 17:53:00 -0000

> On 7 Oct, 2015, at 20:36, David Collier-Brown <> wrote:
> On 07/10/15 01:19 PM, David Lang wrote:
>> On Wed, 7 Oct 2015, Mikael Abrahamsson wrote:
>>>> Oh, I hope that this is an exception. Such kind of optimizations may cause a lot of trouble since a link layer device is interfering with transport layer semantics. We all know that exactly these kinds of interference eventually end up in problems with end-to-end transparency and deployment of new protocol options. At least it interferes with the ACK clocking expectation of some congestion control algorithms...
>>> Personally, I think you're going to see more and more of this. There are mulitple shared access medium where you're allowed to send only part of the time, and it's someone else who tells you when you may send.
>> it doesn't even require that someone else tells you when you may send. It can just be waiting for an available transmit timeslot (Wifi for example)
>> collapsing multiple ACKs that are going to be sent at once is almost always going to be a win.
> I quite agree, but if there is a congestion control implementation "in the wild" that assumes it will get a stream of acks, that one's going to need some work (:-))
> Anyone know if that's the case? The comment above suggest it may be...

It’s not “in the wild”, but this sort of thing is a headache for ELR.  It essentially means that it won’t be able to use AccECN for its feedback (since AccECN doesn’t allow reconstructing a complex 32-packet history of ECN codepoints from a single ACK), but must introduce some other mechanism to feed back the required data to the sender.

I’m leaning towards moving the ELR-aware congestion control algorithm to the receiver, and having the feedback simply be the requested cwnd; it’s the simplest and most compact solution I can think of, and would work for any congestion control scheme, not just ELR.  The sender may of course maintain its own idea of cwnd in the conventional way, and conservatively take the minimum of the two as effective; this would protect against naively greedy receivers.

I note that CUBIC doesn’t care how many acks it gets, since its scaling curve depends only on time so long as the data flow is not application-limited.  That’s good news for Linux, given the lack of ABC.  Do the BSDs and Windows use ABC?

 - Jonathan Morton