Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <david@lang.hm> Sun, 11 October 2015 21:18 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 E1F921B2DBC; Sun, 11 Oct 2015 14:18:44 -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 SxriNMKJ5vut; Sun, 11 Oct 2015 14:18:42 -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 D32581B2C13; Sun, 11 Oct 2015 14:18:42 -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 t9BLISnX008079; Sun, 11 Oct 2015 14:18:28 -0700
Date: Sun, 11 Oct 2015 14:18:28 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Joe Touch <touch@isi.edu>
In-Reply-To: <5619F00A.2040009@isi.edu>
Message-ID: <alpine.DEB.2.02.1510111358310.2053@nftneq.ynat.uz>
References: <5618005A.8070303@isi.edu> <70335.1444421059@lawyers.icir.org> <D23D8CA5.54DF5%g.white@cablelabs.com> <56183B49.4000506@isi.edu> <alpine.DEB.2.02.1510091511540.3717@nftneq.ynat.uz> <56183E93.1010308@isi.edu> <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz> <5618420E.9040609@isi.edu> <alpine.DEB.2.02.1510091628010.3717@nftneq.ynat.uz> <5618554F.3080103@isi.edu> <alpine.DEB.2.02.1510091716100.3717@nftneq.ynat.uz> <56185E44.9050702@isi.edu> <alpine.DEB.2.02.1510091910170.3717@nftneq.ynat.uz> <561891C3.90004@isi.edu> <alpine.DEB.2.02.1510092134190.15683@nftneq.ynat.uz> <5618AF0A.4010101@isi.edu> <alpine.DEB.2.02.1510101439090.1856@nftneq.ynat.uz> <alpine.DEB.2.02.1510101525170.1856@nftneq.ynat.uz> <F62FF3E5-EC9E-4534-B005-2A987C63C41D@gmail.com> <alpine.DEB.2.02.1510102042280.1856@nftneq.ynat.uz> <5619F00A.2040009@isi.edu>
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/crz-X49LiFAY2nPDNzL6zeSXXOg>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>, "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, Greg White <g.white@CableLabs.com>, Jonathan Morton <chromatix99@gmail.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] [tcpm] 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: Sun, 11 Oct 2015 21:18:45 -0000

On Sat, 10 Oct 2015, Joe Touch wrote:

> On 10/10/2015 8:45 PM, David Lang wrote:
>> But I actually view this as a tragedy of the commons situation. Sending
>> the extra packets doesn't hurt you, but it does mean that you are using
>> more airtime than you need, and that hurts everyone (including,
>> eventually, you)
>
> So, basically, you appreciate the tragedy of the commons when it's your
> tragedy and their commons, but not the other way around?
>
> (using 'sed')
>
> s/sending the extra/altering the transport/
>
> s/using more airtime/altering E2E semantics/

I actually disagree that there is a significnt difference in the actual E2E 
semantics between sending a single stretched ACK and sending the full number of 
ACKs back-to-back. The "transmit burst" issue will happen in either case.

But you will notice that in both cases, I am in favor of reducing the number of 
packets on the wire. Packets not send can't interfere with other traffic.

If ACK packets are delayed to the point that additional ACK packets have caught 
up with them, they are not providing the rate signalling signal that you are 
looking for.

Question: Does anyone know if current server TCP stacks implement the TCP byte 
counting that RFC3449 talks about?

David Lang