Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Fri, 09 October 2015 04: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 833421B31A3 for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 21:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 B5TK0OS1ngZL for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 21:03:11 -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 E773F1B319E for <aqm@ietf.org>; Thu, 8 Oct 2015 21:03:10 -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 t99430QJ018060; Thu, 8 Oct 2015 21:03:01 -0700
Date: Thu, 8 Oct 2015 21:03:00 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Christian Huitema <huitema@microsoft.com>
In-Reply-To: <DM2PR0301MB06554D0E836BC2A8F67E12F2A8340@DM2PR0301MB0655.namprd03.prod.outlook.com>
Message-ID: <alpine.DEB.2.02.1510082055510.2943@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> <DM2PR0301MB065553C4CF55E7A6E5E23317A8340@DM2PR0301MB0655.namprd03.prod.outlook.com> <alpine.DEB.2.02.1510081731260.3852@nftneq.ynat.uz> <DM2PR0301MB06554D0E836BC2A8F67E12F2A8340@DM2PR0301MB0655.namprd03.prod.outlook.com>
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/yb-ZWB3BmbGd_OQLU0rsDpnAlPc>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "aqm@ietf.org" <aqm@ietf.org>, Joe Touch <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 04:03:12 -0000

On Fri, 9 Oct 2015, Christian Huitema wrote:

> On Thursday, October 8, 2015 5:43 PM, David Lang wrote:
>> ...
>> For example, in the fq_codel/cake development, we're finding that there are
>> some transports that bundle very large numbers of packets together to send
>> at one time in order to maximize the transport bandwidth. (for example, 4x4
>> wifi sends a LOT of data in one transmit timeslot). Treating that large
>> aggregate as a single packet seriously hurts fairness and latency on the next
>> hop. So 'pulling apart' this aggregate into the individual packets/streams and
>> making decisions based on the pieces ends up being a serious win in fairness
>> and latency.
>
> Define "bundle" please. If they are making sure that several IP packets are 
> sent back to back in a single Wi-Fi slot, then it is of course perfectly fine 
> for AQM to handle the IP packets one by one. Does 4x4 Wi-Fi do something else?

I don't remember the details from the discussion, but the combined bundle 
required extra steps to pull apart to get at the individual packets. IIRC, not 
doing so ended up with multi-MB chunks of data to be delivered, which blocked 
all other traffic while it was being delivered.

>> Suggesting that the queues that build up produce a special enough case to
>> consider thinning out the duplicate acks is a far cry from 'making a
>> recommendation that breaks other recommendations'
>
> That definitely contradicts the TCP specs. So it is very much in "don't go there" territory...

By 'not going there' you are crippling people's networks for the sake of 
following a spec. Rather than following the letter of the old spec, we should be 
looking at the reasons for it, and reasons to make exceptions. There is a long 
history of introducing new things that break the old way of doing things, from 
breaking "classful" network routing to Anycast, there are lots of things that 
"broke" the old way of doing things.

In this case there is more than a decade of people doing exactly what shouldn't 
even be considered.

I'll ask yet again, if acks have already been delayed so that they will be 
delivered at the same time as later acks, how much value do they actually 
provide? We need to compare whatever value this is against the cost of the 
misinformation that they provide, and the impact on other traffic.

David Lang