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

[Jendaipou Palmei]

Hello Jonathan,

We have made the changes in the code as suggested.

Here is the diff after making the changes:

https://github.com/Daipu/COBALT/commit/033db330287e2072bad94ac441f8aed774678a7d

Additionally, we have also updated the values of 'Pincrement' and
'Pdecrement' (parameters of BLUE) in ns-3 to match the ones used in the
Cake implementation in Linux.

Does the diff look correct?

Thanks and Regards,
Jendaipou Palmei
Shefali Gupta

On Sun, Nov 25, 2018 at 11:52 AM Jendaipou Palmei <jendaipoupalmei at gmail.com>
wrote:

> Thanks a lot for taking out time to review our code, Jonathan.
>
> We'll make the changes according to your suggestions and produce new plots.
>
> Thanks, Dave for the feedback. Yes, we will run the simulations with
> fq-codel once we fix the code as suggested by Jonathan, and also run
> simulations with higher bandwidths as you suggested.
>
> I'll upload the source code of the programs in the same repo, and give you
> the link.
>
> Regards,
> Jendaipou Palmei
> Shefali Gupta
>
> On Sat, Nov 24, 2018 at 8:29 AM Jonathan Morton <chromatix99 at gmail.com>
> wrote:
>
>> >> 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
>>
>>
>
> --
> Yours Faithfully,
> Jendaipou Palmei
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20181127/a5c0cba2/attachment.html>