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.i...@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" <swm...@swm.pp.se> >To: "Bless, Roland (TM)" <roland.bl...@kit.edu> >Cc: "LAUTENSCHLAEGER, Wolfram (Wolfram)" ><wolfram.lautenschlae...@alcatel-lucent.com>; "Greg White" ><g.wh...@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: swm...@swm.pp.se >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
