Re: [aqm] TCP ACK Suppression

Jonathan Morton <> Wed, 07 October 2015 20:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60CD21B2FE6 for <>; Wed, 7 Oct 2015 13:08:10 -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 5GGYg4TE4hBM for <>; Wed, 7 Oct 2015 13:08:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D936E1B2FE4 for <>; Wed, 7 Oct 2015 13:08:08 -0700 (PDT)
Received: by lbwr8 with SMTP id r8so23947322lbw.2 for <>; Wed, 07 Oct 2015 13:08:07 -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=ujbKHePbIkeVnVIve0wiD83TNeoGyc+F4I0fMrtfvR4=; b=HQn69MWnglcANK6BGmOIBe2Wjn9OOXV8lhLZksOgqhwcSuel4XkSD/uewvze4KLnn+ gfVRAH5t+RBiX42LBFv0WFMij9inuloEl4DjN7bbjPKp4k3xEEzsZkCc1yJv2M4qtjPR Q04J8eYB/M8fk4MfEiQ1fPmt2Slw4n8vdB/az5CnquM+d8591FOueMNCg0CjhnORg9e4 s/0EzGIGnWIC8hGZcVJj5gMe3DJo/U4lqqTUefLPZkA3Qwh3nmTqnWttraBIEyWB7aOJ j987phcbxLdlo0WVa9ha5CH++BVcMQ8UX2GWy/mRl2weyW1AbRjLZaLPD9mSZKQ19OTk nGLg==
X-Received: by with SMTP id lg10mr1571708lbc.74.1444248487089; Wed, 07 Oct 2015 13:08:07 -0700 (PDT)
Received: from ( []) by with ESMTPSA id jf4sm5163579lbc.23.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Oct 2015 13:08:06 -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 23:08:03 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: David Lang <>
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 20:08:10 -0000

> On 7 Oct, 2015, at 21:05, David Lang <> wrote:
>>> 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 of the acks with ECN (sending a super-strong backoff message), or only mark one of the acks (sending a weak backoff message)
> Also, how can you tell how many acks you 'should' get? what happens if the 1500 byte packets get combined into 9000 byte jumbo packets for the final hop? how many acks 'should' you get?

Let me turn that around:

What should a node which aggregates 1500-byte packets into jumbo frames set the ECN field to on the resulting jumbo packet, if the ECN fields of the original packets had different values?  I’m having some trouble imagining a scenario where such destructive aggregation is permitted, except for TCP proxies which should act as endpoints anyway.  GSO, in particular, requires the headers to be identical in that respect, ensuring that the original packets can be reconstructed (assuming they are MSS sized).

 - Jonathan Morton