Re: [aqm] TCP ACK Suppression

Greg White <g.white@CableLabs.com> Wed, 07 October 2015 16:48 UTC

Return-Path: <g.white@CableLabs.com>
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 8B94A1B2EB6 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 09:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level:
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 mTCpgz7mimnf for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 09:48:55 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D215B1B2EA7 for <aqm@ietf.org>; Wed, 7 Oct 2015 09:48:54 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t97GmZe8016845; Wed, 7 Oct 2015 10:48:35 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 07 Oct 2015 10:48:34 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Wed, 7 Oct 2015 10:48:33 -0600
From: Greg White <g.white@CableLabs.com>
To: Richard Scheffenegger <rs.ietf@gmx.at>, Mikael Abrahamsson <swmike@swm.pp.se>, "Bless, Roland (TM)" <roland.bless@kit.edu>
Thread-Topic: [aqm] TCP ACK Suppression
Thread-Index: AQHRAAfaJ/73TrlDIUOGwELhN8Uffp5eqfGAgAFh4oCAAAl1AIAAK3+A///zLX2AAAwEgA==
Date: Wed, 07 Oct 2015 16:48:32 +0000
Message-ID: <D23AA25E.54A0C%g.white@cablelabs.com>
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>
In-Reply-To: <EF45C0B4E01A482ABC430D916827ED10@srichardlxp2>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-originating-ip: [10.5.0.27]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B4720F4603FC04489A9BF72725FB175E@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/kijeBhhrqsExafwjDqZsWJGk-Kk>
Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)" <wolfram.lautenschlaeger@alcatel-lucent.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 16:48:59 -0000

I'm not sure that would be the result in this case.  Here the CM has a
choice of sending (e.g.) 16 back-to-back ACKs, each for 2 segments, or one
ACK for 32 segments.  In either case, 32 segments worth of
acknowledgements will arrive at the sender at once.

-Greg

On 10/7/15, 9:57 AM, "Richard Scheffenegger" <rs.ietf@gmx.at> wrote:

>[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).
>
>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...
>
>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...
>
>Best regards,
>  Richard
>
>----- Original Message -----
>From: "Mikael Abrahamsson" <swmike@swm.pp.se>
>To: "Bless, Roland (TM)" <roland.bless@kit.edu>
>Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)"
><wolfram.lautenschlaeger@alcatel-lucent.com>; "Greg White"
><g.white@CableLabs.com>; <aqm@ietf.org>
>Sent: Wednesday, October 07, 2015 12:51 PM
>Subject: Re: [aqm] TCP ACK Suppression
>
>
>> 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
>>
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
>