acks at the time you have reached a point of dropping them significantly have filled the pipe, also.
What I saw here was that the first flow to really get going, and really get dropped, dominated over the others, because I thought it was consistently ending up in the priority queue. http://blog.cerowrt.org/post/ack_filtering/ Look, all I'm proposing is this idea be tried and tested. Cynically... since there's a new model coming out as the result of this work, it immediately turns into something a good paper can hing on. On Fri, May 8, 2020 at 8:20 AM Jonathan Morton <[email protected]> wrote: > > >> The ACK filter runs on enqueue, so if a queue has only ACKs in it, it > >> will never accumulate anything in the first place... > > > > but the side effect is that on dequeue, it flips it into the fast > > queue drr rotation, not the slow, so it can't accumulate > > as many acks before delivering the one it has left. > > > > Or so I thought, way back when.... > > The ack filter converts a stream of acks that might be treated as a bulk flow > into a sparse flow, which is delivered promptly. This is a good thing; an > ack should not be held back solely to see whether another one will arrive. > > I think of it as an optimisation to reduce delay of the information in the > ack stream, not solely as a way to reduce the bandwidth consumed by the ack > stream; the latter is a happy side effect. > > - Jonathan Morton -- Make Music, Not War Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
