> 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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat