[Bloat] [Make-wifi-fast] benefits of ack filtering

[David Collier-Brown]

On 03/12/17 10:44 PM, Dave Taht wrote:
> More generally, the case where you have a queue containing acks, stored
> up for whatever reason (congestion, media access, asymmetry), is a
> chance for a middlebox or host to do something "smarter" to thin them
> out.
>
> Acks don't respond to conventional congestion control mechanisms anyway.
>
> There is another case (that I don't support) where you would try to
> filter out acks on the fly without a queue (similar to how a policer
> works). The flaws of this approach are many, including tail loss,
> which the concept of filtering down (reducing?) a queue, doesn't have.

Taking a very high-level view of this discussion, the times you want to 
change a protocol or add a 'network optimizer" are when enough time has 
passed that the original requirements don't describe what you want any more.

In a previous life I did some work on the optimization (by remote 
proxying) of the SMB protocol used by Samba. It was very desirable, but 
at the cost of continuing to support a protocol that did the wrong 
thing, and kludging it with additional middleware.  In effect, making 
your new system dependent on a bug in the old one.

Eventually we said the heck with it, and sat Samba on top of a different 
protocol entirely, one which worked well over non-local links. That 
concentrate the impedance matching in Samba, not in code I had to 
maintain in synchronization with a bug (;-))

--dave

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain