Re: [aqm] TCP ACK Suppression

Joe Touch <touch@isi.edu> Thu, 08 October 2015 21:47 UTC

Return-Path: <touch@isi.edu>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC331AD1FE for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 14:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzGuwgIRDv0o for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 14:47:01 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136CA1AD0D3 for <aqm@ietf.org>; Thu, 8 Oct 2015 14:47:01 -0700 (PDT)
Received: from [10.123.86.139] (usc-secure-wireless-206-139.usc.edu [68.181.206.139]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t98LkOXm028947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 8 Oct 2015 14:46:25 -0700 (PDT)
To: David Lang <david@lang.hm>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5616DCD9.8@isi.edu> <alpine.DEB.2.02.1510081428470.3852@nftneq.ynat.uz>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <5616E42D.5090402@isi.edu>
Date: Thu, 08 Oct 2015 14:46:21 -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: <alpine.DEB.2.02.1510081428470.3852@nftneq.ynat.uz>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/G8plV_yYfpW1DZMc4EC_Ogwo8gU>
Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "aqm@ietf.org" <aqm@ietf.org>, touch@isi.edu
Subject: Re: [aqm] TCP ACK Suppression
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2015 21:47:02 -0000


On 10/8/2015 2:31 PM, David Lang wrote:
> On Thu, 8 Oct 2015, Joe Touch wrote:
> 
>> On 10/7/2015 12:42 AM, LAUTENSCHLAEGER, Wolfram (Wolfram) wrote:
>> ...
>>> Is this topic addressed in some RFC already?
>>
>> It's a direct violation of RFC793, which expects one ACK for every two
>> segments:
>>
>> 4.2 Generating Acknowledgments
>>
>>   The delayed ACK algorithm specified in [Bra89] SHOULD be used by a
>>   TCP receiver.  When used, a TCP receiver MUST NOT excessively delay
>>   acknowledgments.  Specifically, an ACK SHOULD be generated for at
>>   least every second full-sized segment, and MUST be generated within
>>   500 ms of the arrival of the first unacknowledged packet.
> 
> actually, this is only a violation of the SHOULD section, not the MUST
> section.

When you violate a SHOULD, you need to have a good reason that applies
in a limited subset of cases.

"it benefits me" isn't one of them, otherwise the SHOULD would *always*
apply.

> And if the Ack packets are going to arrive at wire-speed anyway (due to
> other causes), is there really an advantage to having 32 ack packets
> arriving one after the other instead of making it so that the first ack
> packet (which arrives at the same time) can ack everything?

If the first ACK confirms everything, you're giving the endpoint a false
sense of how fast the data was received. This is valid only if the
*last* ACK is the only one you retain, but then you'll increase delay.

Unless you know that the endpoint supports ABC and pacing, yes, there's
a very distinct advantage to getting 32 ACKs rather than 1. It also
helps with better accuracy on the RTT calculation, which is based on
sampling (and you've killed 97% of the samples).

> And if there is such an advantage, does it outweight the disadvantages
> that the extra ack packets cause by causing highly asymmetric links to
> be overloaded and drop packets?

Why is it so bad to drop packets? Cumulative ACKs will still work
properly in the presence of the losses. If you make reasonable progress,
you have to determine whether the lost ACKs should make you slow down.

AFAICT, this isn't horrible if you KNOW something specific about the
other end (ABC + pacing), but how can you know? In a closed deployment,
maybe. But this IMO is over-optimizing TCP for a very specific environment.

TCP isn't supposed to be the most efficient in EVERY corner case. It's
supposed to *always work* in EVERY corner case.

Joe