Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Thu, 08 October 2015 21:32 UTC

Return-Path: <david@lang.hm>
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 083A71ACE9F for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 14:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A8jVP9CmRQ8t for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 14:32:02 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC191ACE80 for <aqm@ietf.org>; Thu, 8 Oct 2015 14:32:02 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t98LVv2N015495; Thu, 8 Oct 2015 14:31:57 -0700
Date: Thu, 8 Oct 2015 14:31:57 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <5616DCD9.8@isi.edu>
Message-ID: <alpine.DEB.2.02.1510081428470.3852@nftneq.ynat.uz>
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>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/h1T7cNJ8Bkuyj5UMpphdMktWfvQ>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "aqm@ietf.org" <aqm@ietf.org>
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:32:04 -0000

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.

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?

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?

David Lang