Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Fri, 09 October 2015 18:52 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 A7F681B4A2D; Fri, 9 Oct 2015 11:52:10 -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 79TrS9ppEYcN; Fri, 9 Oct 2015 11:52:09 -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 87AE61B4A2A; Fri, 9 Oct 2015 11:52:09 -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 t99Iq4fv023556; Fri, 9 Oct 2015 11:52:04 -0700
Date: Fri, 9 Oct 2015 11:52:04 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <5618005A.8070303@isi.edu>
Message-ID: <alpine.DEB.2.02.1510091148450.3717@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> <alpine.DEB.2.02.1510081428470.3852@nftneq.ynat.uz> <5616E42D.5090402@isi.edu> <alpine.DEB.2.02.1510081517470.3852@nftneq.ynat.uz> <5616FAFA.5020707@isi.edu> <alpine.DEB.2.02.1510081647590.3852@nftneq.ynat.uz> <5618005A.8070303@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/gjbz5bkZ50HNsU5Qj2aF-BYsSGw>
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>
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: Fri, 09 Oct 2015 18:52:10 -0000

On Fri, 9 Oct 2015, Joe Touch wrote:

> 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.
>
> Joe
>
> ---
>
> 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

The temporal spacing is already lost.

> 2) *you* don't know where your mechanism will have an impact
>
> 	those clumped ACKs might be spaced out further
> 	downstream
>
> 	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

this discussion started in the context of AQM. AQM is needed in both directions, 
it's not a one-direction only thing.

> 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".

that's not the only consideration here. There's also the consideration that the 
ACK stream is already badly distorted.

As it turns out (as discussed on the other thread), the RFC actually recommends 
what we was proposed (with some additional nuances)

David Lang