Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Fri, 09 October 2015 00:42 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 3C29F1B2EA2 for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 17:42:43 -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 5Pdt_PfhSQck for <aqm@ietfa.amsl.com>; Thu, 8 Oct 2015 17:42:41 -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 733081B2E9E for <aqm@ietf.org>; Thu, 8 Oct 2015 17:42:41 -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 t990gX1C017012; Thu, 8 Oct 2015 17:42:33 -0700
Date: Thu, 8 Oct 2015 17:42:33 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Christian Huitema <huitema@microsoft.com>
In-Reply-To: <DM2PR0301MB065553C4CF55E7A6E5E23317A8340@DM2PR0301MB0655.namprd03.prod.outlook.com>
Message-ID: <alpine.DEB.2.02.1510081731260.3852@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>
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/y3wJZZyGdrITnahn9r_RAGM3k30>
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 00:42:43 -0000

On Fri, 9 Oct 2015, Christian Huitema wrote:

> All that discussion is fun, but we should be careful to stay within the 
> respective group charters.
>
> As far as AQM is concerned, the question is whether the group wants to 
> standardize some kind of special handling of TCP ACK as part of queue 
> management. As far as the IETF rules are concerned, the answer is clearly NO 
> -- we cannot create an IETF recommendation that breaks other IETF 
> recommendations. Besides, such rules would not be very effective if the 
> transport protocol is encrypted, as for example QUIC, or SCTP over DTLS. AQM 
> should certainly not depend on end-systems not using encryption.

AQM should not depend on end-systems not using encryption.

But that doesn't mean that AQM should not take advantage of additional data that 
it can get from non-encrypted sessions.

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.

> As for TCP and other protocols, the question is whether they should pay more 
> attention to the volume of ACK and other control packets. The deployment of 
> queue management systems like FQ-CODEL actually creates an incentive to do 
> that, because a transport protocol that creates congestion on its uplink will 
> be automatically penalized. But that discussion belongs in TCPM and other 
> transport working groups, not AQM.

I can't say where the discussion needs to take place, but people need to realize 
that it's not just hurting itself. In fact it's probably not going to hurt 
itself the most.

most AQM systems tend to (at least slightly) prioritize acks, DNS responses, and 
other small packets because letting them get delayed has such a disproportionate 
impact on the overall throughput and user experience. As a result, the overload 
of ACKs is probably going to end up impacting other uses of the link instead.

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'

David Lang