Re: [aqm] TCP ACK Suppression

"Richard Scheffenegger" <rs.ietf@gmx.at> Wed, 07 October 2015 16:05 UTC

Return-Path: <rs.ietf@gmx.at>
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 664201ACD0D for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 09:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 jmnrXNdXtjEl for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 09:05:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730F61ACD09 for <aqm@ietf.org>; Wed, 7 Oct 2015 09:05:41 -0700 (PDT)
Received: from srichardlxp2 ([213.143.121.76]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mh5h7-1ZwjNN0IjZ-00MLeZ; Wed, 07 Oct 2015 18:05:32 +0200
Message-ID: <EF45C0B4E01A482ABC430D916827ED10@srichardlxp2>
From: "Richard Scheffenegger" <rs.ietf@gmx.at>
To: "Mikael Abrahamsson" <swmike@swm.pp.se>, "Bless, Roland \(TM\)" <roland.bless@kit.edu>
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>
Date: Wed, 7 Oct 2015 17:57:38 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Provags-ID: V03:K0:LzDes4jX/FnArkp06ocCwt2mCGvN3JYLHy+yjRzhBSc2KlWbWQ+ RLJX4B3lBJz9/7TL7UejTkEq4UcfEJWI4LlB0Xo7M4WVLwNd5G9Mcd2uhkq3FkvwVV7sbb3 XJJlM6obm9AS3fVmcFdF5EUp5i51uM63CKtO31cleMw3deswOtu6H49GIN9QFNNtMvA3eql lu2y12kSeD32EfwivQVJg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:R2dmd+/cBp8=:MTMeog3273TTpci7yZ58xu 8CP6lS9vvBu5ybJJheA77IVla+5nobc5KGOrHd32xz0LWt0sc24OEuXn1tfsHbqzrLXwrE7Fw gwtW1eAkgguAN56QDIq4/ADe8DcAldC2uQ9860jM7+ByK85Mo4FRAnW1YFmwlQFxo+LMN6S84 q/Og5LU1yYdozFHnPXz8xuzXEpD1Jw3WtMXqWQblXPQbN/pddvRC/hO9pbBCvld4O8tb5XHaz cdONzysRauBuxew+JLjTvjHW+0aeSas9oLltIzT9iBn4o8zZavVDCVLY3AhqJKJ3uw20Tz5hN 37X+bszwLdBuUiwx4I0L9KqAriXweAZzQdWRT2SabJ1OaTcharS6AOFkeWMLj93Uvesw7gTnI PBMRyB2j7YIG3vJFvTRtw/Tl19HDbDzErM2KGKHsOZV8++sRo1Ci6MdtBHfJRiT/DFIuypQod +KFo5zRHBYGoBNfX8vAWv7woDQ8ZCz9GKdoXZTijWfwYLFLY25xFWI/A7XevYEtYemj2MMFPE ac3+Ojd2EdSm2WNf0vAGNNlVh/rEVFg0Wu6FAE5DQO8yM2Ybg/0GtpBwktJ5hqfo+b0xSjW9g qBO4GmU0uPtnZDz+7XeMVjbXt10IyQmVEoEwllLZRvM4OpCZDa3BiNk25Ed+ECSXFJL1/2qQ1 ouVjFSck1sKcAAv9u8bG2u3Ty5cM7/r6C0PvWOk3uPp53Kk/7d+tNGe1/q38iSOUJTds4L4SI qypS7lk/4eY+UG3T5ZOpVMnLtWFrT/4nVIx/pRAqmAOg2jZwegqASzbEG5O0SPtwZxD0ysYYM ytcJ9HU
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/bNd3cv1hjNZIuBID6W7hi46ubF8>
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:05:43 -0000

[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>om>; "Greg White" 
<g.white@CableLabs.com>om>; <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