[Bloat] benefits of ack filtering
Juliusz Chroboczek
jch at irif.fr
Wed Nov 29 13:28:16 EST 2017
> Recently Ryan Mounce added ack filtering cabilities to the cake qdisc.
> The benefits were pretty impressive at a 50x1 Down/Up ratio:
If I read this posting right, you're only measuring bulk performance.
What about interactive traffic, when there's only one or two data segments in
flight at a given time
> I'd rather like to have a compelling list of reasons why not to do
> this!
I haven't looked at Cake in detail, and I haven't put much thought into
ACK filtering, but off the top of my head:
- not risking breaking any of the TCP-related algorithms that depend on
ACKs arriving in a timely manner (AIMD, Nagle, Eifel, etc.),
especially in the case of just one segment in flight;
- not contributing to the ossification of the Internet by giving an
unfair advantage to TCP over other protocols;
- limiting the amount of knowledge that middleboxes have of the
transport-layer protocols, which leads to further ossification;
- avoiding complexity in middleboxes, which leads to a more brittle
Internet;
- not encouraging ISPs to deploy highly asymmetric links.
This is not my area of expertise, and therefore I don't feel competent to
have an opinion, but I think that before you deploy ACK filtering, you
really should consider the worries expressed above and whatever other
worries more competent people might have.
-- Juliusz
More information about the Bloat
mailing list