Re: [Cake] Doubt regarding the Linux implementation of Cake

[Jonathan Morton <chromatix99@gmail.com>]

> On 29 Mar, 2017, at 20:34, vignesh kannan <vignesh2496@gmail.com> wrote:
> 
> I have also been following the discussions happening about Cobalt on the Bufferbloat mailing list. So I am having problems relating the two sources just mentioned above (the implementation and the discussion). According to my understanding of the Codel algorithm, the count variable (which keeps track of the number of packets dropped in the currently running dropping state) is never really decremented iteratively.
> 
> However the Cobalt implementation reduces count iteratively (in line 234 of the file cobalt.c) under certain circumstances and this is happening in the function named cobalt_should_drop( ) which is called to determine if Cobalt should drop the packet or dequeue it. It would be great if someone could throw light on what is exactly happening in this function and also a comprehensive explanation of Cobalt itself would be appreciated. 

An open question in Codel is exactly how best to choose the initial value of “count” when re-entering the dropping state after a relatively short period of not dropping.

I was unsatisfied with the usual approaches, which in the reference Codel implementation involve a rather opaque calculation, and in some variants involve a halving of the previous count value, both with a hard time cutoff before a full reset to 1.

What I do in Cobalt is, while in non-dropping state, to decrement count on the same schedule as it would increment in dropping state.  This completely eliminates the need for a hard time cutoff and seems like a natural solution to the problem.

I’m currently writing a series of articles for the Bufferbloat website on the algorithms Cake uses, including their performance relative to existing alternatives.

 - Jonathan Morton