Re: [aqm] TCP ACK Suppression

David Lang <david@lang.hm> Wed, 07 October 2015 17:19 UTC

Return-Path: <david@lang.hm>
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 11B0E1A038C for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 10:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 g_m6DzhEBJzF for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 10:19:35 -0700 (PDT)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44FC1A035F for <aqm@ietf.org>; Wed, 7 Oct 2015 10:19:34 -0700 (PDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t97HJMfD003787; Wed, 7 Oct 2015 10:19:22 -0700
Date: Wed, 07 Oct 2015 10:19:22 -0700
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Mikael Abrahamsson <swmike@swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1510071246550.8750@uplift.swm.pp.se>
Message-ID: <alpine.DEB.2.02.1510071015430.29851@nftneq.ynat.uz>
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>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/pOrMQRGHXv5CgqnsHsE1170V498>
Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, "Bless, Roland (TM)" <roland.bless@kit.edu>, "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 17:19:39 -0000

On Wed, 7 Oct 2015, Mikael Abrahamsson 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.

it doesn't even require that someone else tells you when you may send. It can 
just be waiting for an available transmit timeslot (Wifi for example)

collapsing multiple ACKs that are going to be sent at once is almost always 
going to be a win.

David Lang