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 >
- [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression LAUTENSCHLAEGER, Wolfram (Wolfram)
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Clark Gaylord
- Re: [aqm] TCP ACK Suppression Steve Bauer
- Re: [aqm] TCP ACK Suppression Francini, Andrea (Andrea)
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression Rick Jones
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Dave Taht
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Simon Barber
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang