> On 29 Mar, 2017, at 20:34, vignesh kannan <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
