Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <david@lang.hm> Sat, 10 October 2015 22:03 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 7077D1B4955; Sat, 10 Oct 2015 15:03:07 -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 aYTffEFPq63Y; Sat, 10 Oct 2015 15:03:06 -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 E83591B4954; Sat, 10 Oct 2015 15:03:05 -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 t9AM2pBO032210; Sat, 10 Oct 2015 15:02:51 -0700
Date: Sat, 10 Oct 2015 15:02:51 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <5618AF0A.4010101@isi.edu>
Message-ID: <alpine.DEB.2.02.1510101439090.1856@nftneq.ynat.uz>
References: <5618005A.8070303@isi.edu> <70335.1444421059@lawyers.icir.org> <D23D8CA5.54DF5%g.white@cablelabs.com> <56183B49.4000506@isi.edu> <alpine.DEB.2.02.1510091511540.3717@nftneq.ynat.uz> <56183E93.1010308@isi.edu> <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz> <5618420E.9040609@isi.edu> <alpine.DEB.2.02.1510091628010.3717@nftneq.ynat.uz> <5618554F.3080103@isi.edu> <alpine.DEB.2.02.1510091716100.3717@nftneq.ynat.uz> <56185E44.9050702@isi.edu> <alpine.DEB.2.02.1510091910170.3717@nftneq.ynat.uz> <561891C3.90004@isi.edu> <alpine.DEB.2.02.1510092134190.15683@nftneq.ynat.uz> <5618AF0A.4010101@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/Q24dXbQh_IzPFXRUIdnWZk0cxnI>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [aqm] [tcpm] 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: Sat, 10 Oct 2015 22:03:07 -0000

On Fri, 9 Oct 2015, Joe Touch wrote:

> On 10/9/2015 10:58 PM, David Lang wrote:
>> RFC3449 doesn't completely address the current situation, but it
>> provides a very good place to start, and it seems to me that the
>> solitions it explores to address the conerns that it (and you) raise are
>> actually being addressed pretty completely. There are still some areas
>> to talk about (ECN interaction for example) and we wshould be talking
>> about those issues rather than arguing that the proposal violates holy
>> writ.
>
> I'm OK with the recommendations for the endpoints to modify their ACK
> behavior, but still am concerned that stripping out ACKs in the middle
> of the network is problematic for a number of reasons, only some of
> which are addressed in RFC3449 (which also recommends against deploying
> them in the general Internet, so if that's your justification then it's
> very clearly in direct opposition).

Remember that this can only take place when there is enough of a bottleneck that 
enough of a queue has built up that multiple ack packets are sitting in the 
queue waiting to be transmitted. Such a queue is only going to build up if the 
link is a bottleneck [1]. As I undertsand the current Industry Best Practice, 
unless you have ISPs deliberatly not upgrading (ala the Netflix fights), the 
core systems almost never queue and so such algorithms would never kick in.

So even if I could wave a magic wand and deploy this on every router, it would 
only have an effect in a few places. Endpoint links where the available 
bandwidth drastically changes are not the exclusive list of palces that this 
would effect, but I think it's pretty close.

David Lang

[1] the exception to this is when you have a hop where the transport quanomizes 
the data the way Wifi and Cell networks do, So if you have a half-duplex link 
like normal Wifi or a time-slot MAC like a Cell network in the middle of the 
path, this sort of thing could trigger there, but I'm not convinced that it 
would be a bad thing there. Full duplex Wifi links that can transmit 
continuously don't need this