IETF Logo Mail Archive

Re: [aqm] [tcpm] ACK Suppression

Greg White <g.white@CableLabs.com> Tue, 13 October 2015 18:34 UTC

Return-Path: <g.white@CableLabs.com>
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 60BE51A1BB0 for <aqm@ietfa.amsl.com>; Tue, 13 Oct 2015 11:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level:
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 ZR9A3Np4OnU3 for <aqm@ietfa.amsl.com>; Tue, 13 Oct 2015 11:34:35 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8902B1A1B5D for <aqm@ietf.org>; Tue, 13 Oct 2015 11:34:35 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t9DIYYfJ002195; Tue, 13 Oct 2015 12:34:34 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 13 Oct 2015 12:34:34 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 13 Oct 2015 12:34:32 -0600
From: Greg White <g.white@CableLabs.com>
To: Simon Barber <simon@superduper.net>, "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: [aqm] [tcpm] ACK Suppression
Thread-Index: AQHRAj8eR4DPZzA4hUGFHBrK8oQO6p5i/2IAgAAcYwCABgoXAIAAoVMA
Date: Tue, 13 Oct 2015 18:34:32 +0000
Message-ID: <D242A5FB.55083%g.white@cablelabs.com>
References: <mailman.1487.1444233956.7953.aqm@ietf.org> <1444247538.3556484@apps.rackspace.com> <alpine.DEB.2.02.1510072200590.8750@uplift.swm.pp.se> <7A2801D5E40DD64A85E38DF22117852C8812629D@wdc1exchmbxp05.hq.corp.viasat.com> <06C46DC6-854F-4CDE-8C7B-745F3362FA9E@gmail.com> <alpine.DEB.2.02.1510071411400.29851@nftneq.ynat.uz> <E2035448-E688-4EF3-8BF7-02132D72D511@cisco.com> <fa0080678adcd392a8dfa237cbd77e49.squirrel@erg.abdn.ac.uk> <alpine.DEB.2.02.1510082121550.2943@nftneq.ynat.uz> <alpine.DEB.2.02.1510090827240.8750@uplift.swm.pp.se> <561C7314.2030102@superduper.net>
In-Reply-To: <561C7314.2030102@superduper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.6.150930
x-originating-ip: [10.4.11.44]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5B70CB20EF0F564E9F0A95BBC83B1232@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/5DRtGr1ifASzMN2hlQKODFZY1zY>
Subject: Re: [aqm] [tcpm] 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: Tue, 13 Oct 2015 18:34:36 -0000

On 10/12/15, 8:57 PM, "aqm on behalf of Simon Barber"
<aqm-bounces@ietf.org on behalf of simon@superduper.net> wrote:

>The issue here is that the hosts don't know how the medium is going to
>do the clumping, so thinning the ACKs at the host may add additional
>delay.
>
> From what I understand from Greg's earlier message the cable modem must
>request uplink bandwidth in advance, so if it had to send multiple ACKs,
>it would send the first one, then request bandwidth the the additional
>ones that had arrived since the first one (please correct me if I'm
>wrong) - in this case collapsing/thinning the ACKs will reduce latency
>by one grant cycle.

You've got it right. Also, consider cases where there is other upstream
traffic.  AFAIK ACK thinning is only implemented along with ACK
prioritization.  One could imagine only doing prioritization, without
thinning.  In that case, if other upstream traffic were present, you may
be able to get some of the latency reduction benefits by allowing the
newly arrived ACKs to be sent as a burst in a grant that  had been sized
to carry some other packets, but then you are delaying the other traffic
by (at least) one grant cycle. Thinning in combination with prioritization
reduces ACK latency with less impact on other applications.

v2.23.0 | Report a Bug | By Email