Issue with QueueDiscs

[Raffaello Secchi]

Hi,

I am interested in studying QueueDiscs but I came into an issue.

I attached a script that reproduces the issue with a RED QueueDisc in ns3.31 and its related graph.

Basically, when I install the QueueDisc in a node, its internal queue is mounted on top of the NetDevice queue.

As a packet arrives at the queue, the QueueDisc starts a run and pushes some packets down to the NetDevice. However, if the NetDevice queue is full, the packet is discarded.

This packet loss is interpreted as congestion feedback by TCP, which reduces its cwnd. This means that the queue never gets saturated and cannot apply its AQM algorithm. For example, the picture shows that the pattern of the RED queue size is regular, rather than random as it would be expected with RED.

Thank you in advance for any feedback on this,

Best Regards,

Raffaello

[Tom Henderson]

Hi Raffaello, there is a flow control mechanism to stop the queue disc
from dequeuing packets if the NetDevice queue is full. This section of
the documentation describes it:
https://www.nsnam.org/docs/release/3.31/models/html/queue-discs.html#implementation-details

If you develop a new NetDevice type, then you should follow how other
devices such as CsmaNetDevice have this object aggregated to them and
notify this interface about their state, so that the queue disc will
stop and run at the appropriate times.

- Tom

[Raffaello Secchi]

Thank you Tom for your prompt reply. I will definitely look into your suggested documentation.

My problem, however, is that QueueDisc ignores the return value from the underlying NetDevice and does not requeue the packet:

https://github.com/nsnam/ns-3-dev-git/blob/90cc0482a33a951970a3eeb7a9bc4cca7d23d4d0/src/traffic-control/model/queue-disc.cc#L1094

 

While the QueueDisc is stopped and no additional packets are dequeued, the packet that triggered the overflow is lost and TCP would back up as a consequence.

I'm working on a fix.

Best Regards,

Raffaello

[Raffaello Secchi]

The queuesize behaviour was not an error after all, it was just an unfortunate choice of queue parameters. Choosing different numbers for the queue size and RED thresholds params, the queue exhibits the expected behaviour (see picture attached).

My apologies (I come from the ns2 world after all :-) )

Raffaello