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

[Jendaipou Palmei <jendaipoupalmei@gmail.com>]

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

Hello Jonathan,

Thanks for your feedback.

As suggested, we changed the NIC buffer size to 1 packet for the simulation
and also tried these different buffer sizes: 10, 50 and 75.

The default NIC buffer size in ns-3 is 100 packets.

Additionally, we also enabled BQL and tried.

We see that the link utilization gets significantly affected when we keep
the NIC buffer size small.

The results are put up on the following link:

https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Different-NetDeviceQueue-size

Thanks and Regards,
Jendaipou Palmei
Shefali Gupta

On Sun, Dec 9, 2018 at 6:51 PM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 9 Dec, 2018, at 10:37 am, Jendaipou Palmei <jendaipoupalmei@gmail.com>
> wrote:
> >
> > By hidden queues, do you mean the NIC buffers? ns-3 has a Linux-like
> traffic control wherein the packets dequeued by a queue discipline are
> enqueued into NIC buffer.
>
> That's right.  Linux now uses BQL, which (given compatible NIC drivers)
> limits the number of packets in the NIC buffers to a very small value -
> much smaller than is evident from your data.  If you were to measure the
> end-to-end RTT of each, I'm certain you would see this effect dominating
> the mere 50ms latency you're trying to model.
>
> Ideally, AQM would applied to the hardware queue anyway.  For simulation
> purposes, I recommend reducing the NIC buffer on the bottleneck interface
> to 1 packet, so that the simulated AQM's effects are easiest to measure.
>
>  - Jonathan Morton
>
>

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