Re: [aqm] TCP ACK Suppression

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 07 October 2015 10:51 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 7C44F1B2DCE for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 03:51:37 -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 QijmgFFMUJxY for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 03:51:35 -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 54ABB1B2DCC for <aqm@ietf.org>; Wed, 7 Oct 2015 03:51:35 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id D6EF4A1; Wed, 7 Oct 2015 12:51:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1444215093; bh=LsDffjdws9Q2U0xW6cyku6AvnDUpYm8kGYnNQFhUujE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lOE10dfNUcidYZIJf63PCw6EebcuaA3pqjGXKQSigtFHPkKn1/rH/cng4TMJdMr46 EAi3/oVwqtRw4hmzKwtgLdJhJsovhRQtoxJste/mDjnrr/kXSSUmMbl3R0sNgVkFNn kU6V8vuKlMheHYjUwfECrbFCeFn+2jNcY5w1sKx0=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CE37C9F; Wed, 7 Oct 2015 12:51:33 +0200 (CEST)
Date: Wed, 7 Oct 2015 12:51:33 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
In-Reply-To: <5614D4B8.5060403@kit.edu>
Message-ID: <alpine.DEB.2.02.1510071246550.8750@uplift.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>
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/W_MBavdiTxMXJENFhumIT44DYNE>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "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 10:51:37 -0000

On Wed, 7 Oct 2015, Bless, Roland (TM) wrote:

> Oh, I hope that this is an exception. Such kind of optimizations may 
> cause a lot of trouble since a link layer device is interfering with 
> transport layer semantics. We all know that exactly these kinds of 
> interference eventually end up in problems with end-to-end transparency 
> and deployment of new protocol options. At least it interferes with the 
> ACK clocking expectation of some congestion control algorithms...

Personally, I think you're going to see more and more of this. There are 
mulitple shared access medium where you're allowed to send only part of 
the time, and it's someone else who tells you when you may send.

So if you're sitting there with 100 ACK packets all nicely ACKing 
increasing values indicating no packet loss, and now you're allowed to 
send, why not just kill 99 of those ACK packets?

While I agree with you on principle, these kinds of mechanisms cut the 
amount of ACK traffic down by factor 15-30, meaning I can download at 250 
megabit/s and only have a few hundred kilobit/s of upstream ACKs, instead 
of 5-10 megabit/s of ACKs. That's a huge opimization for any kind of 
asymmetric and/or time slot access medium such as ADSL, LTE, DOCSIS, PON 
and I'm sure there are others.

Btw, what is the reason for TCP doing ACKs for every 2 packets in 
steady-state, even with window sizes in the hundreds of kilobytes or even 
megabytes? I would prefer if the TCP host stack sent fewer ACKs instead of 
trying to optimize this at the access routing device.

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