Re: [aqm] TCP ACK Suppression

Joe Touch <touch@isi.edu> Fri, 09 October 2015 18:59 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 4A2AA1B4A64; Fri, 9 Oct 2015 11:59:24 -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 n2Ux3YwP04Hk; Fri, 9 Oct 2015 11:59:23 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250061B4927; Fri, 9 Oct 2015 11:59:23 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t99Iwdeg022720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2015 11:58:40 -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> <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> <alpine.DEB.2.02.1510091148450.3717@nftneq.ynat.uz>
From: Joe Touch <touch@isi.edu>
Message-ID: <56180E5F.9030501@isi.edu>
Date: Fri, 9 Oct 2015 11:58:39 -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.1510091148450.3717@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/8_f7auG3EJaivUbZVDCh3aT0MEo>
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>, 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: Fri, 09 Oct 2015 18:59:24 -0000


On 10/9/2015 11:52 AM, David Lang wrote:
> 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.

You don't know that won't be restored downstream.

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

Needed, but you don't *know* it's deployed on both path directions. The
reverse path could be taking a different route.

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

It's not distorted at all - it's queued up and waiting its turn.

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

Assuming that you know what you can't know and assuming that you don't
care whether your actions affect what others have a right to assume.

Joe