Queue Disciplines and RED Queues

[Lynne Salameh]

Hi,

Sorry for the wide distribution, but I seem to be rather confused about the new Queue Discs that are replacing several queue types, including Red Queues in the upcoming release of ns-3.25. In my original setup, I have a bunch of PointToPoint net devices, which used RedQueues as their underlying queue.

With the new changes, it doesn’t seem like I can do that, rather I must use DropTailQueues for the net device, and use a Traffic Controller with a RedQueueDisc.

I had naively thought the setup above would behave exactly like my old setup, but in fact it doesn’t. It behaves like I have DropTailQueues and not RedQueues, which I guess is expected.

So, I guess my question is: what are queuing disciplines and how can I get my code to behave like I intend, i.e. PointToPoint net devices with RedQueues?

Cheers,

Lynne

[Stefano Avallone]

Hi Lynne,

thanks for raising this point.

Actually, the new traffic control infrastructure makes the ns-3 stack much more similar to the Linux stack, where RED, CoDel, etc. are queuing disciplines and device drivers usually have FIFO queues. The reason why it seems like you "have DropTailQueues and not RedQueues" is likely the large size of the netdevice DropTail queue, which neutralizes the benefits of using AQM algorithms (that's why BQL has been introduced in Linux -- btw expect to have BQL implemented in ns-3.26 ;-) ). We found that setting the size of the netdevice DropTail queue to 1 packet gives very similar results as with the old setup.

Cheers,

Stefano

[Lynne Salameh]

Thanks Stefano,

I have set my DropTailQueues to a size of one segment as you have suggested (for the net devices). But, as a followup, it seems the following is happening:

In the PointToPoint net device, if the enqueue causes a drop, is it correct that the packet is requeued? If so, then using the MaxTxDrop trace point of the net device is no longer accurate to reflect actual drops.

In the RedQueueDisc code, I am seeing the following behaviour:

The RED queue indicates that there are no drops and it is possible to enqueue a packet, then it calls the underlying DropTailQueue, i.e.

GetInternalQueue (0)->Enqueue (item);

But the check in DropTailQueue to see whether the bytes exceed the max take the current packet into consideration, which the RedQueue doesn't. I.e. I get a drop.

I'm not sure if this is the right behaviour.

Thanks,

Lynne

[Lynne Salameh]

Hi Steffano,

I think my second point is an actual bug. I am using the bytes mode of the queue, and in the RedQueueDisc Enqueue method we have this check:

if (nQueued >= m_queueLimit)

{

 ...

dropType = DTYPE_FORCED;

}

But the check in the underlying drop tail queue is:

if (m_mode == QUEUE_MODE_BYTES && (m_nBytes.Get () + item->GetPacketSize () > m_maxBytes))

{

}

In other words, although the first check indicates that we can in fact queue an item, the underlying queue actually drops it.

Cheers,

Lynne

[Stefano Avallone]

In the PointToPoint net device, if the enqueue causes a drop, is it correct that the packet is requeued?

Yes, that is what Linux does.

 

If so, then using the MaxTxDrop trace point of the net device is no longer accurate to reflect actual drops.

 This is a collateral effect of re-queuing that we discussed and decided to leave as is for now. A possibility would be to prevent netdevices from calling the drop trace if a queue disc is installed, but we aim to find a better solution for ns-3.26. In the meanwhile, you should be able to compute the actual drops as the number of drops reported by the mac layer minus the number of packets re-queued.

In the RedQueueDisc code, I am seeing the following behaviour:

The RED queue indicates that there are no drops and it is possible to enqueue a packet, then it calls the underlying DropTailQueue, i.e.

GetInternalQueue (0)->Enqueue (item);

But the check in DropTailQueue to see whether the bytes exceed the max take the current packet into consideration, which the RedQueue doesn't. I.e. I get a drop.

Please see my reply to your next email...

Stefano 

[Stefano Avallone]

On Thursday, March 17, 2016 at 6:39:37 PM UTC+1, Lynne Salameh wrote:

Hi Steffano,

I think my second point is an actual bug. I am using the bytes mode of the queue, and in the RedQueueDisc Enqueue method we have this check:

if (nQueued >= m_queueLimit)

{

 ...

dropType = DTYPE_FORCED;

}

But the check in the underlying drop tail queue is:

if (m_mode == QUEUE_MODE_BYTES && (m_nBytes.Get () + item->GetPacketSize () > m_maxBytes))

{

}

In other words, although the first check indicates that we can in fact queue an item, the underlying queue actually drops it.

Thanks for spotting this.

Actually, I think it is rather a bug of the old version (RedQueue), which allowed to exceed the queue capacity in byte mode: if nQueued, which is the amount of bytes currently stored in the queue and not taking into account the new packet, is less than m_queueLimit but nQueued+PacketSize exceeds the limit, the packet is enqueued, thus exceeding the limit.

The new code is correct in the sense that at least it does not allow to exceed the queue capacity (indeed, the underlying queue drops the packet). However, your observation is correct: the (nQueued >= m_queueLimit) check is likely wrong. I will open a bug with a proposed patch to see if other developers agree to fix it in time for ns-3.25.

Thanks,

Stefano

[Lynne Salameh]

Thanks Stefano for clarifying things. 

You're right about this bug existing in the old versions of RedQueue. I'm hoping this gets fixed in ns-3.25, mostly because, even though the packet gets correctly dropped, a developer will need to add trace points to catch drops in both the Queue class and the RedQueueDisc class to catch all drops correctly. Do you mind cc-ing me on the bug report?

In the mean time, I have locally modified my code to do the following:

- if (nQueued  >= m_queueLimit)

+ if (nQueued + item->GetPacketSize() >= m_queueLimit)

 

And it seems to work correctly.

Thanks a lot for your help!

Lynne

[Mohit P. Tahiliani]

On Friday, March 18, 2016 at 12:11:34 AM UTC+5:30, Lynne Salameh wrote:

Thanks Stefano for clarifying things. 

You're right about this bug existing in the old versions of RedQueue. I'm hoping this gets fixed in ns-3.25, mostly because, even though the packet gets correctly dropped, a developer will need to add trace points to catch drops in both the Queue class and the RedQueueDisc class to catch all drops correctly. Do you mind cc-ing me on the bug report?

In the mean time, I have locally modified my code to do the following:

- if (nQueued  >= m_queueLimit)

+ if (nQueued + item->GetPacketSize() >= m_queueLimit)

Hi Lynne,

Thanks for noticing it.

Would this be a better fix?

- if (nQueued  >= m_queueLimit)

+ if ((GetMode () == Queue::QUEUE_MODE_PACKETS && nQueued >= m_queueLimit) || 

+     (GetMode () == Queue::QUEUE_MODE_BYTES && nQueued + item->GetPacketSize() >= m_queueLimit))

Regards,

Mohit P. Tahiliani

[Lynne Salameh]

Hi Mohit,

Would this be a better fix?

- if (nQueued  >= m_queueLimit)

+ if ((GetMode () == Queue::QUEUE_MODE_PACKETS && nQueued >= m_queueLimit) || 

+     (GetMode () == Queue::QUEUE_MODE_BYTES && nQueued + item->GetPacketSize() > m_queueLimit))

 

Yes you're right. I totally forgot to account for the packet count mode. But note that I changed the second inequality to > rather than >=. We don't want to drop a packet that just manages to fit into the queue.

Cheers,

Lynne

[Stefano Avallone]

The last version of the patch is correct, thanks. I opened bug #2340 and will ask Tom to have a quick look at it.

Cheers,

Stefano