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

[Dave Taht <dave.taht@gmail.com>]

On Tue, Dec 4, 2018 at 7:02 AM Jonathan Morton <chromatix99@gmail.com> wrote:
>
> > On 4 Dec, 2018, at 12:31 pm, Jendaipou Palmei <jendaipoupalmei@gmail.com> wrote:
> >
> > We have uploaded the plots for the 'count' variable of COBALT (with a segment size of 1500 and 1000 bytes).
> >
> > Link: https://github.com/Daipu/COBALT/wiki/Cobalt-Drop-Count
> >
> > We have not yet implemented ECN feature in COBALT, so packets are currently dropped instead of being marked.
> >
> > Are these the plots that you were referring to?
>
> More-or-less, yes, though these actually show an internal state variable of the Codel algorithm rather than the actual number of marks/drops per time interval.  I was hoping to see similar graphs for the reference-Codel and PIE runs, since we can gain more insight from that, and PIE doesn't have an internal "count" variable that corresponds with Codel.  Nevertheless, the view into "count" behaviour is interesting in itself, and I'd like to see the corresponding graphs from reference Codel.
>
> An artefact visible in these graphs is an apparent lack of sampling while not in the dropping state.  Thus you seem to have a gradual ramp from 0 to 1 count over the several seconds interval between activations, though in fact the variable is discrete.  It would be better to show that transition more precisely.
>
> For study, it is also often helpful to zoom in on small time intervals to see the dynamic behaviour of the algorithm, particularly during the transition from slow-start to steady-state, where there is seemingly a big difference between reference Codel and COBALT.

I'm loving the slow start result.

>
> Another interesting graph to produce for each algorithm and traffic type is the instantaneous throughput of each flow.  This offers insight into the relative fairness of each algorithm, and might help to explain the anomaly seen with 1000-byte packets and COBALT.  Usually this graph also reveals, through the shape of each throughput curve, which CC algorithm is in use - currently I'm guessing NewReno.  CUBIC and CTCP, which are also in common use, would behave differently.

a file showing the timestamp of each drop would be easier to post process.

>
>  - Jonathan Morton
>


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740