Re: [aqm] TCP ACK Suppression

"Bless, Roland (TM)" <roland.bless@kit.edu> Wed, 07 October 2015 16:57 UTC

Return-Path: <roland.bless@kit.edu>
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 C543A1B2ED8 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 09:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 w29skNO13NiA for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 09:57:53 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94E41B2ED3 for <aqm@ietf.org>; Wed, 7 Oct 2015 09:57:51 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1Zjs2D-0002XP-BR; Wed, 07 Oct 2015 18:57:45 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 40EDEB00DB0; Wed, 7 Oct 2015 18:57:45 +0200 (CEST)
To: Richard Scheffenegger <rs.ietf@gmx.at>, Mikael Abrahamsson <swmike@swm.pp.se>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se> <D2394BB6.548C5%g.white@cablelabs.com> <0A452E1DADEF254C9A7AC1969B8781284A7D9B66@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5614D4B8.5060403@kit.edu> <alpine.DEB.2.02.1510071246550.8750@uplift.swm.pp.se> <EF45C0B4E01A482ABC430D916827ED10@srichardlxp2>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
X-Enigmail-Draft-Status: N1110
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <56154F09.8030905@kit.edu>
Date: Wed, 7 Oct 2015 18:57:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <EF45C0B4E01A482ABC430D916827ED10@srichardlxp2>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1444237065.
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/NQxoSfN3cYG_uFHSFqJyhV-uZrQ>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, 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 16:57:54 -0000

Hi,

Am 07.10.2015 um 17:57 schrieb Richard Scheffenegger:
> [as individual]
> 
> Hi Mikael,
> 
> ACK thinning will interfere with the ACK clock of the sender; a good
> recipie to require much more buffering at the bottlneck hop of that
> session (since the sender will start bursting out TCP data packets at
> it's line rate, rather than the bottleneck link rate).

Yes, however, if I understood Mikael correctly, the 100 ACKs are waiting
to be transmitted anyway, so the cable modem link isn't able to provide
feedback at a higher rate, i.e., there is a choice of getting 100 ACKs
transmitted as burst (lets say an ACK train) or a single ACK for the
same amount of data. The effect for congestion control is probably the
same (sender sends out a burst) if the link is the only bottleneck and
the single ACK will not  get lost (i.e., you are throwing away lots of
redundancy that may help in case of packet loss affecting the ACK.

> So, if your goal is to have the sender send out TCP data segments at the
> bottleneck rate, you'd not want to ACK too many segments at once...

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).

> Of course, the drawback is your observation, that TCP (over Ethernet)
> typically requires 64 bytes of ACK per 2x 1448 bytes, or about 1:45
> uplink/downlink bandwidth).
> 
> Others have already pointed out some relevant RFCs in this thread too...

Regards,
 Roland