[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