Re: [aqm] TCP ACK Suppression

"Richard Scheffenegger" <> Wed, 07 October 2015 19:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E3CA1ACEAD for <>; Wed, 7 Oct 2015 12:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fTCzVLr-qljv for <>; Wed, 7 Oct 2015 12:10:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28AB81ACE9E for <>; Wed, 7 Oct 2015 12:10:50 -0700 (PDT)
Received: from srichardlxp2 ([]) by (mrgmx103) with ESMTPSA (Nemesis) id 0MexlN-1Zyy9Z2D4z-00Oa7Q; Wed, 07 Oct 2015 21:10:32 +0200
Message-ID: <39DD3F3C880D43E292DEDEFDA9C80ED6@srichardlxp2>
From: "Richard Scheffenegger" <>
To: "David Lang" <>, "Jonathan Morton" <>
References: <> <> <> <> <> <> <> <> <>
Date: Wed, 7 Oct 2015 21:02:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Provags-ID: V03:K0:4n3mTnKOen/O3/Jz8L40OsdvWvHHKfcHVbq+9zsnepeYZLYuZVl hnnzOkjjwrgYI19uyGByXSEwsVOCEXBMM0tnCexRx9ZebuX8TQSZBV/oTSaz7jjcansH4UV vVmuNhjMmjLXyUZp3aL67/O6xfEIT+LdDBO6V/uv4mlSDtck/brxbmFS+uSabUxlNujeFBC uLvH4Kdd+BkYslzLuqJuw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:p8ed1QVVEbk=:ctVgo2fdnZ206+KhI//l0Y De5zcfxUdPZVIhJL3xXtOp+0yF/zQrQ00xLB60POA7R2ODLfN86u5DgN566SxnEwXCxeqAekO wxjOGLgBObiAcij8kv5jDmcw6Na+NdQJunLZcaKAPqXGxKVbfNXkSZ4D2mwbrJh7BQEumwo+i FDjMXS2kwLCGeVFBYn/gYUIbMxQW9QLy5xn/JDHhY0jVYI9ctIYfkyYC+UrSEChigVJhUI556 cmwat3YXBCsTotBBP2EWvO9EcrMJ1zoAHrvq5KQ+ec7S36BoW5CIpI2i2PImFP2VxPXAFK1Xa D7icuFHuSBNuCiP8b0jG/6t6XjzWZ0TzWLxqYx8fAH/00HvrX0HyVnclrb9gnLWm3U6zPegkn T72j+C7KomPipFB8kFJB0RNWk7r8teC8otpCVGtEIhzOdodj4n+oXKHClAEUmJWL/ZTJNm71m icT42+DT4S34m37dfMOw76f2ENmcDaGGbO6cea9XrrsTFh/ZaXirDZZPdibl6hm2BUEWEr6T0 hYBgtwz1KuYgA+VD71Siasonah2jCbVbfTntNTWS91Zt8sahRaz10A3/7o2izVNojVj6zDZD6 fwl6rI9oAus1+Ly14RjGXgLo3+NmnBRvIM8fVx8uLms2uCvV5cJqewD7zpf+02qvvXmdVc2N8 jg/ub3HRlDnawlGbUeYF734MjUESd46jc6W/xJKXMfAX+M5IpPVQHJcdJyposB4VlP+jrC95z Uo3GElHFQR2kPlmQva8xoxOBp0VGtyvMlLsoSdn1VJ4z+S/J6cQYkG9+G8rVVZREcpxfxa0KV hCCNwmQ
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 19:10:52 -0000

[as one of the AccECN authors]

Hi David,

I believe you are convoluting a few things in the assumptions behind your 

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...

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.

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...

Best regards,

----- Original Message ----- 
From: "David Lang" <>
To: "Jonathan Morton" <>
Cc: <>rg>; <>
Sent: Wednesday, October 07, 2015 8:02 PM
Subject: Re: [aqm] TCP ACK Suppression


> 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.

but if you are getting all 32 acks at the same time, with no other packets
flowing, are you going to be able to do anything sane? do you mark every one 
the acks with ECN (sending a super-strong backoff message), or only mark one 
the acks (sending a weak backoff message)

David Lang


> _______________________________________________
> aqm mailing list