Re: [aqm] TCP ACK Suppression

Greg White <g.white@CableLabs.com> Thu, 08 October 2015 21:30 UTC

Return-Path: <g.white@CableLabs.com>
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 85F811ACEB3; Thu, 8 Oct 2015 14:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level:
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 EUww2etkIZIY; Thu, 8 Oct 2015 14:30:56 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 610011ACEB2; Thu, 8 Oct 2015 14:30:56 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t98LUsl3001225; Thu, 8 Oct 2015 15:30:54 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 08 Oct 2015 15:30:54 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Thu, 8 Oct 2015 15:30:51 -0600
From: Greg White <g.white@CableLabs.com>
To: Joe Touch <touch@isi.edu>, "Francini, Andrea (Andrea)" <andrea.francini@alcatel-lucent.com>, Steve Bauer <bauer@mit.edu>
Thread-Topic: [aqm] TCP ACK Suppression
Thread-Index: AQHRAAfaJ/73TrlDIUOGwELhN8Uffp5eqfGAgAFh4oCAAEK1AIAARdaAgAHwaYD//5xegA==
Date: Thu, 8 Oct 2015 21:30:50 +0000
Message-ID: <D23C3C50.54B94%g.white@cablelabs.com>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <CAFxEvqouQv-xkLWXxxBTw5swSFazWSb_Hak3ZOmnBSeQbE20hw@mail.gmail.com> <1BFAC0A1D7955144A2444E902CB628F865B0C249@US70TWXCHMBA12.zam.alcatel-lucent.com> <5616DFBF.9000204@isi.edu>
In-Reply-To: <5616DFBF.9000204@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.6.150930
x-originating-ip: [10.4.11.13]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C20114802BBFA347A4C0FB4C0D1FB25F@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/VW6d9n87vUbYb3ie74UP7oU14V4>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "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:30:57 -0000

On 10/8/15, 3:27 PM, "Joe Touch" <touch@isi.edu> wrote:

>CC'ing TCPM on my responses to this thread...
>
>On 10/7/2015 8:50 AM, Francini, Andrea (Andrea) wrote:
>> How about the effect of ACK suppression on the growth of the
>> congestion window, for TCP sources where the trigger for window growth
>> is the arrival of an ACK, not the number of bytes it acknowledges?
>> 
>> The Appropriate Byte Counting (ABC) option
>> (https://tools.ietf.org/html/rfc3465) was addressing a similar issue
>> with delayed ACKs, but it looks like it is no longer available in Linux
>> (http://www.spinics.net/lists/netdev/msg225164.html).
>
>Even with ABC, killing off some of the ACKs would result in sender
>bursts because you're interfering with ACK clocking -- unless ABC were
>coupled with some sort of rate pacing.
>
>Note also that when you kill off intermediate ACKs you're increasing the
>round-trip delay. The sender can't start sending what you ACK until the
>ACK arrives; if you kill off earlier ACKs, then the later ACK will (by
>definition) arrive later.


As discussed previously in this thread, the specific case where this has
been deployed does not suffer from these problems.



>
>This is bad on many levels.
>
>Joe