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

[Jendaipou Palmei <jendaipoupalmei@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3368 bytes --]

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@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

[-- Attachment #2: Type: text/html, Size: 4000 bytes --]