High RTT due to NetDevice Queue vs. Traffic Control Layer interaction

[Maria Eduarda Veras Martins]

Hi everyone,

I am currently working on implementing and validating TCP Prague in ns-3. My topology uses a DualQCoupledPiSquare AQM at the bottleneck to simulate an L4S scenario.

Initially, I observed unexpectedly high RTT values (around 68ms) even though my bottleneck link was configured with a 10ms propagation delay and the DualQ statistics showed the L4S queue was almost empty.

After investigating, I discovered that the underlying NetDevice queue (the default DropTailQueue) was accumulating packets. I believe this accumulation was the actual cause of the extra delay, effectively hiding the congestion from the Traffic Control layer where the DualQueue resides.

I managed to fix this by setting the NetDevice queue size to a single packet:

After this change, the RTT dropped to the expected ~22ms.

My questions are:

1. Is setting the device queue to "1p" a valid/recommended solution?

2. I'm slightly confused about the role distinction between the NetDevice queue and the traffic control layer. I noticed that ns3 allows installing complex queue disciplines (like RED) directly on the NetDevice. Could someone clarify why/when one would use a complex queue on the NetDevice versus using the traffic control layer? 

Thank you for any insights!

[Tommaso Pecorella]

TC is between IP and NetDevice, while the NetDevice is the MAC/PHY. You might have both in your system.

About the NetDevice in particular, the queuing system is typically rooted in the MAC specification and the hardware vendor solutions, so you should try to mimic the device you have.

Some NetDevice actually take advantage of a longer queue in the NetDevice, for examle WiFi can aggregate packets if its queue is large enough. Other NetDevice types might have little or no use of a longer queue.

Hence, the answer is: it depends on the NetDevice, and if it can leverage aggregation, or (for example) negotiate a longer channel occupancy.

In your specific case, it might even be a result: with your scenario it's better to have a very small NetDevice queue.