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
