Understanding relationship between RED Queues and DropTail Queues.

[Tommaso Bonato]

Hello,

I am using a simple incast scenario to better understand NS-3 and also develop new congestion control algorithms.

I am trying to install a simple RED Queue in order to have some logic on how to add ECN mark to some packets.

I have managed to get it installed and working but as far as I can understand, there is also the DropTail queue which is on the NetDevice. 

The problem with that is that my RED queue stays basically empty until the DropTail queue gets full and only then I start seeing some packets building up on the RED queue. 

The problem is that, until that moment, the red queue was empty and hence no ECN mark could be added. 

I have read somewhere the suggestion of setting the DropTail queue as size 1p but it doesn't seem to have the effect I was hoping.

Am I missing something?

[Tom Henderson]

Tommaso, inline below.

Yes, this is the intended behavior. Set the DropTail queue size to '1p'
and enable BQL. We have an unfinished 'flent' application, the
documentation of which explains this more clearly. See the last
paragraph of the 'Design' section in this documentation:

https://gitlab.com/tomhenderson/ns-3-dev/-/blob/fcfc2067f74be353b707c1457dd5fddb604772fd/src/applications/doc/flent.rst

I think that a real system must work the same way; packets that are in
the device queue will not be marked, so keep that queue as short as
possible (but not empty).

- Tom

[Tommaso Bonato]

Thanks! I will try it out. Could you expand on why we need to enable (BQL)?

[Tom Henderson]

Actually, with 1p queue, I don't think enabling BQL will matter, but with larger device queue sizes, it will lower the queue occupancy; please see "Effect of BQL on latency with small queue size" in this document for more information.

https://gitlab.com/tomhenderson/ns-3-dev/-/blob/fcfc2067f74be353b707c1457dd5fddb604772fd/src/network/doc/queue-limits.rst

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/e187ae9a-52bd-44ff-a49a-f23c5884f8ebn%40googlegroups.com.

[Tommaso Bonato]

Thanks again!

I was able to run some tests but I am still not getting the expected performance. Ideally, once I have a RED queue, I would expect the actual net device queue size to have no effect BUT I see a huge difference if I set it to 1 or 1000 for example. In the first case, with a TCP incast, I start seeing many packets being retransmitted because of timeout while with the larger net device queue size, I see very few because (I think) the device is able to hold many more packets before being stopped.

Am I still missing something? I will add I am using NS-3 3.30 but it shouldn't matter by looking at the release notes of newer versions.

[Tom Henderson]

I suggest that you enable the DynamicQueueLimits log component and also the log component around whatever device queue you have, to understand what is going on.

- Tom

To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/9a32f355-8c0d-4da1-8d62-9cb3a31dd747n%40googlegroups.com.