On Thu, May 7, 2020 at 11:36 PM Avakash bhat <[email protected]> wrote: > > Ok thanks so much for the clarifications. > That cleared it up quite a bit.
I note that there was something really subtle that could have been done to improve cake's ack handling, and for all I know it actually happened in the final codebase. so, please, go forth and duplicate the existing implementation, and ignore me, cause looking at this hairy code gives me a headache. anyway, to try and describe what I thought I saw an interaction with the scheduler back in the day. The ack-filter runs, deleting all but one packet from the ack queue, and delivers that. the scheduler runs, serves a bunch of other flows, then returns to the ack queue, which has accumulated a couple more packets, the ack-filter runs, deleting all but one packet from the ack queue, and delivers that, but doesn't exhaust its qauntum but now that flow is in the "fast" queue, and we service just a few other flows, and return to it, delete a couple, service one... and stay stuck in the fast queue. better, I thought, was once the ack filter exceeded the quantum of packets for that flow in that drr round, even if it only delivered one packet, that it should always return it to the bulk queue, because tons more packets would arrive in the interval between servicing all the rest of the flows, thus more of which could be safely removed, while maintaining a steadier clock for tcp. I've already seen cake remove over 25% of all ack packets with no harm to the other flows. So for all I know (and I'd have to look) it's already doing it this way. > > Thanks, > Avakash Bhat > > On Thu, May 7, 2020 at 12:37 PM Sebastian Moeller <[email protected]> wrote: >> >> I think that you will remove all redundant Backs in one go considerably >> advancing the new ACK in the queue. And more importantly, in most relevant >> modes cake will apply one queue per flow stochastically, so almost all >> packet's in a reverse ACK flow will be ACK with identical 5-tupel.... >> >> On 7 May 2020 08:44:59 CEST, Avakash bhat <[email protected]> wrote: >>> >>> >>> Thanks for the quick response. I also had a followup question. >>> >>> If the ack filter adds the new ack to the tail of the queue after removing >>> an ack from the queue, won't it be starving the ack? >>> The replaced ack was much ahead in the queue than the ack we replaced at >>> the tail right? >>> >>> Thanks, >>> Avakash Bhat >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake -- 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
