Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Fri, 09 October 2015 19:48 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 089131A87B3; Fri, 9 Oct 2015 12:48:52 -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 NJ06X92ixTJu; Fri, 9 Oct 2015 12:48:47 -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 BDA771A8794; Fri, 9 Oct 2015 12:48:47 -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 t99JmdAv023919; Fri, 9 Oct 2015 12:48:40 -0700
Date: Fri, 09 Oct 2015 12:48:39 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <56180E5F.9030501@isi.edu>
Message-ID: <alpine.DEB.2.02.1510091230050.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> <alpine.DEB.2.02.1510091148450.3717@nftneq.ynat.uz> <56180E5F.9030501@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/tSJUQNNhVZ6Ay7ToUMRl70weMbI>
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 19:48:52 -0000

On Fri, 9 Oct 2015, Joe Touch wrote:

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

it can only be restored by further delaying the arrival of the ACKs (you can't 
send an 'fixed' ACK before you receive the one that was delayed (I'm trying to 
avoid the phrase 'Delayed ACK' to avoid confusion)

This will have further detrimental effects on your throughput.

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

AQM is needed on any bottleneck link. If the link isn't a bottleneck, the data 
rate isn't too high.

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

the temporal spacing of the ACKs is lost. They won't be sent out at spaced 
intervals, they will be sent out in a burst at line speed (whatever that is).

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

Actually, the router does know that the ACK stream is being quantitized. It's 
doing the quatitization (wifi aggregation,  DOCSIS on cable, satellite transmit 
slots, LTO Cell networks, or AQM queue selection)

What it can't know is if anything else would try to slow traffic further by 
trying to delay ACKs more to restore spacing (RFC3449 talks about the problems 
of doing this and recommends against it).

So the only thing remaining is what assumptions other things have the right to 
make. Given how common wireless (Wifi and Cell) networks are, anything that 
makes an assumption that ACKs are flowing back as the traditional wired networks 
handled them is broken today.

If some RFC needs to be updated to make everyone recognize this, then the RFC 
needs to be updated.

But people actually working with servers and the real Internet are seeing these 
effects today.

David Lang