[Cake] COBALT implementation in ns-3 with results under different traffic scenarios

[Jonathan Morton]

>> This is possibly a correct result in your simulation!! - the periodic
>> throughput drop you are showing in cobalt at this bandwidth and rtt.
>> I'm happy to see cobalt kick in early on slow start but not happy to
>> see the periodic drop. Jon, do you have time for a code review?
> 
> I looked at it briefly, but the code structure is different enough that I need to sit down and study it carefully to figure out whether there are any relevant differences.
> 
> The throughput drops most likely occur because the TCPs become synchronised and remain so under AQM action.  You can see that the frequency of the system is lower in the later part of the COBALT run than in the Codel run, but the same as Codel in the earlier part where throughput drops don't occur.  But this shouldn't really occur with a Codel-based AQM (as COBALT is), because a single mark is sufficient to tell TCP to back off over one RTT.  An explanation might be if this implementation of COBALT isn't running down correctly when deactivated, so the mark frequency only rises while being turned on and off.  The run-down behaviour is a major intentional difference between COBALT and reference Codel.
> 
> I'll look at the code more closely with that in mind.

Okay, I've had a look - not quite line by line, but the parts I consider important for the behaviour seen so far.

There are a couple of small behavioural differences between your code and mine, which should be corrected if the model is to accurately reflect the prototype.  These are probably not relevant for the results shown so far, but are likely show up on more aggressive tests involving unresponsive traffic.

 - On queue overflow, a tail drop is used to resolve it.  While not technically part of COBALT, Cake performs head-dropping on queue overflow, doing so from the longest queue, and I consider that to be best practice.  This gets the message to the offending sender ASAP, without having to bubble up through the jammed queue first.  If the packets currently at the head of the queue are smaller than the one being offered, you might need to drop more than one to maintain the size invariant.

 - The hard-drop flag for BLUE is set at the top of the control-law function, and tested in order to bypass the Codel logic if already set.  This is not how the COBALT code operates; the BLUE logic should come last, and the Codel logic run unconditionally.

Everything else looks reasonably correct at first glance (though the amount of boilerplate is epic).  I would recommend verifying that CobaltQueueEmpty() actually gets called when appropriate though.  Without it, I suspect that the run-down logic won't work as intended.

 - Jonathan Morton