Re: [aqm] TCP ACK Suppression

[Mikael Abrahamsson <[e-mail]>]

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: [e-mail]