Re: [aqm] TCP ACK Suppression

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 07 October 2015 07:23 UTC

Return-Path: <swmike@swm.pp.se>
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 392AC1A1B3E for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 00:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 NKOESSwE1khm for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 00:23:34 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25721A1A4A for <aqm@ietf.org>; Wed, 7 Oct 2015 00:23:33 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2BF7FA1; Wed, 7 Oct 2015 09:23:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1444202611; bh=0XIkXEigANSlWTDzTg766UbfdIE65pl8ceruxW9t3mk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nRINnZ7+Ptw3Yiyf7lklJ/ehNFRueKZhd6tWSgsb32reGTOu5eZWfWP9v5a0PzVM0 PXzHUyZLYvIEy1uTTD8qPRIYhO3hfys1tPbvrCHCqDdx5s/X0Ut8hzUgXoOM7JouLV 4e7lvyKfz0jd1NCJ4bUq67oB0wj4S8DMRbrp8xYg=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2245E9F; Wed, 7 Oct 2015 09:23:31 +0200 (CEST)
Date: Wed, 7 Oct 2015 09:23:31 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Greg White <g.white@CableLabs.com>
In-Reply-To: <D2394BB6.548C5%g.white@cablelabs.com>
Message-ID: <alpine.DEB.2.02.1510070905050.8750@uplift.swm.pp.se>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/BPIRSYo0Ran6eOATmQQ7SfWdc4A>
Cc: "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: Wed, 07 Oct 2015 07:23:36 -0000

On Tue, 6 Oct 2015, Greg White wrote:

> Mikael,
>
> Specialized upstream TCP ACK handling (which can include both
> prioritization and suppression) is a recommended feature in the DOCSIS
> specification.  The details of the implementation are left to the
> manufacturer, but I don't expect that it is actually done at dequeue
> (packet processing at dequeue is expensive in cable modems).  Rather, I
> expect that devices identify ACKs at enqueue, and retain (separate from
> the main service-flow queue) a single ACK for each TCP session.  Then,
> upon receiving a grant, the ACK queue is flushed first, followed by
> packets from the main queue.

Sounds reasonable. From my packet dumps it looks like (this is DOCSIS3.0) 
I most of the time get one ACK per 1-4ms, but sometimes I get several ACKs 
per 0.1 ms. It seems to me that the ACK suppression algorithm suppresses 
16 ACKs and then lets the next one through as most of the time, the number 
of bytes that each ACK is ACK:ing is 24616 which divided by 17 is 1448, 
which seems to match nicely with TCP payload size. So in my case, it seems 
it lets 1 packet through, drops 16, lets one packet through, drops 16 etc. 
Sometimes it seems to drop 32 packets though (see packet 1350 below), 
guess it works in iterations of 16 anyway.

http://swm.pp.se/acksuppression-151007.png

> The CM is not permitted to issue bandwidth requests for more data than it
> has available to send, so bandwidth requests would need to already have
> ACK suppression taken into account.  For this reason (and the above), I
> doubt that the CM would include suppressed ACKs in its queue depth and
> queuing latency estimation.

Ok, so the ACK suppression would happen before the BW request is sent out, 
and after the request is sent out, there is no adding to it? I'm just 
thinking what the reason is that I seem to be seeing several ACKs during 
the same grant (I am guessing that multiple packets seen within 0.1ms is a 
single BW grant). Can CM ask for additional grant during the wait for a 
grant, or CM can only have a single outstanding grant at any given time?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se