Re: [aqm] ACK Suppression

Jonathan Morton <chromatix99@gmail.com> Wed, 07 October 2015 20:57 UTC

Return-Path: <chromatix99@gmail.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 3AB261B30CC for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 13:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 BmMzy2K3kBfj for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 13:57:27 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEB71B30C4 for <aqm@ietf.org>; Wed, 7 Oct 2015 13:57:26 -0700 (PDT)
Received: by lbos8 with SMTP id s8so25220620lbo.0 for <aqm@ietf.org>; Wed, 07 Oct 2015 13:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UQOT7EuYztm4tOBWys0u89gLWbqqa2rEZoFcVbN7+aI=; b=M3z0nmMQlZ29uAOn44DRW+6BwJ2z8WQyIrK7lnIoR+c1yhsihD0/hLKv7K0jZAhZlU wXZGwQt+stQgPjhpfnD4cOCYfi5lRgFCWUj8KGKX9Vgw8o5UH9iss8MFh16OKd02kTr8 6arIuVcWtWJoXdS+UnlSBDBI256c3V0t8BsAurOzmFsS/E5eySOpKSJZ53f81gcZ2orW X7MMGx6PuC+9GUylD6o7SHDg82n++AuV3rRuhn3h+KduEsPMmwwRaFKq9TXmKNaeqF8v zH/ADnV+1y1y33BJVevASnC5fLFxk0LwraAmbC7wBoGtEhV2EIshKVpouQUcFg6EhVZn 8GUg==
X-Received: by 10.112.133.42 with SMTP id oz10mr1733796lbb.62.1444251444933; Wed, 07 Oct 2015 13:57:24 -0700 (PDT)
Received: from bass.home.chromatix.fi (176-93-46-50.bb.dnainternet.fi. [176.93.46.50]) by smtp.gmail.com with ESMTPSA id r196sm6666679lfg.39.2015.10.07.13.57.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Oct 2015 13:57:24 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <7A2801D5E40DD64A85E38DF22117852C8812629D@wdc1exchmbxp05.hq.corp.viasat.com>
Date: Wed, 07 Oct 2015 23:57:19 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <06C46DC6-854F-4CDE-8C7B-745F3362FA9E@gmail.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>
To: "Agarwal, Anil" <Anil.Agarwal@viasat.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/APxVlMZXJ_EvB5a3X_Mi5xcc4vs>
Cc: "dpreed@reed.com" <dpreed@reed.com>, "aqm@ietf.org" <aqm@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: [aqm] 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: Wed, 07 Oct 2015 20:57:28 -0000

> On 7 Oct, 2015, at 23:40, Agarwal, Anil <Anil.Agarwal@viasat.com> wrote:
> 
>> Since the cable modem link will lead to clumped ACKs the difference between sending 100 ACKs vs. 1 ACK is probably not that big...
>> (except w.r.t. reliability).
> 
> The difference may not be big in the spacing of new packets that a sender will send, unless the sender implements some sort of pacing or if the return link is very thin.

> But with ABC, there will be a difference in the amount of cwnd increase at the sender.

There is also a potential difference for detecting packet loss in the forward direction.  It’s entirely possible that thinning would cause a DupAck condition to be recognised only after three MAC grants in the reverse direction have elapsed, rather than one.  Receivers are REQUIRED to send an ack for every received packet under these conditions, but that would be subverted by the modem.  AckCC would not induce this effect, because the receiver would still produce the extra acks as required.

Packet loss causes head-of-line blocking at the application level, which is perceived as latency and jerkiness by the end-user, until the lost packet is retransmitted and actually arrives.  Hence the addition of two MAC grant delays (60ms?) may make the difference between an imperceptible problem and a noticeable one.

 - Jonathan Morton