Re: [Cake] Query on ACK

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave,


> On May 8, 2020, at 08:50, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Thu, May 7, 2020 at 11:36 PM Avakash bhat <avakash261@gmail.com> 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.

	Why would that be a problem? In that case ACKs did not bunch up (otherwise there would be backlog in the queue and it would forfeit its sparseness boost) and hence delivering the only ACK in a timely fashion should preserve the ACK clock, especially for non ABC-ACKs (https://tools.ietf.org/html/rfc3465) that relay on ACK count? Sure, if the single ACK had already matured a bit and immediately after sending it a fresher ACK would have been enqueued that looks suboptimal, but that race seems to exist no matter what? Now if the goal is to weed out ACKs to conserve bandwidth, sure not filtering ACKs is sub-optimal, but for the clocking?
Side-note, whoever invented the term "ACK-clocking" seemingly had a very fuzzy concept of what a clock is and what precision a clock can be expected to deliver ;)


Best Regards
	Sebastian

P.S.: As so often, I might simple be confused about the actual subtlety...


> 
> 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 <moeller0@gmx.de> 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 <avakash261@gmail.com> 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
>> Cake@lists.bufferbloat.net
>> 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