Re: [aqm] TCP ACK Suppression

Joe Touch <> Fri, 09 October 2015 17:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E1C951B2C3C; Fri, 9 Oct 2015 10:59:32 -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 cW1-Dag_9N_x; Fri, 9 Oct 2015 10:59:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 050D51B2C1E; Fri, 9 Oct 2015 10:59:32 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t99HwpN0005976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2015 10:58:52 -0700 (PDT)
To: David Lang <>
References: <> <> <> <> <> <> <> <> <>
From: Joe Touch <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 9 Oct 2015 10:58:50 -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 <>, "" <>, "" <>,
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: Fri, 09 Oct 2015 17:59:33 -0000

Dave in particular wanted some specific reasons this is a bad idea as
presented. Here is my summary.

The rest of this discussion should happen on TCPM.



1) *you* shouldn't be using a mechanism that destroys information for others

	whether the timestamps or ACK stream spacing has any
	meaning is for the receiver - not you - to decide

2) *you* don't know where your mechanism will have an impact

	those clumped ACKs might be spaced out further

	even if you have a rule of "I'll only gather 3 ACKs",
	you can't know if another box - including yours -
	downstream might gather those composite ACKs further

3) you claim this might be safe *if* AQM is widely deployed

	but *you* don't appear to be making that determination
	*before* deploying your approach

	also, AQM is in the opposite direction, and unless
	you deploy this with enough state to track the fact
	that your box is seeing traffic in both directions,
	you shouldn't be turning it on at all

As others have noted, the SHOULD of ACK requirements can be exceeded,
but only with careful consideration of the potential impact. That
careful consideration does not consist of "I turned it on and I didn't
hear anyone scream".