[Bloat] benefits of ack filtering

[Juliusz Chroboczek]

> The better solution would of course be to have the TCP peeps change the
> way TCP works so that it sends fewer ACKs.

Which tends to perturb the way the TCP self-clocking feedback loop works,
and to break Nagle.

> In the TCP implementations I tcpdump regularily, it seems they send one
> ACK per 2 downstream packets.

That's the delack algorithm.  One of the stupidest algorithms I've had the
displeasure of looking at (a fixed 500ms timeout, sheesh).

And yes, it breaks Nagle.

> I don't want middle boxes making "smart" decisions

I agree, especially if they use transport-layer data to make their
decisions.

> Since this ACK reduction is done on probably hundreds of millions of
> fixed-line subscriber lines today, what arguments do designers of TCP have
> to keep sending one ACK per 2 received TCP packets?

I think it's about growing the TCP congestion window fast enough.  Recall
that that AIMD counts received ACKs, not ACKed bytes.

(And not breaking Nagle.)

-- Juliusz