Uneven scheduling of packets when more than 2 clients (WiFi)

[Jeremy Mack]

Hello,

I am simulating a Wifi (802.11b) network using ns-3.16.  When I have more than 2 clients for a single AP the throughput becomes very unevenly distributed between the clients seen in the flow monitor results below.

Flow ID: 1 Src Addr 10.1.1.1 Dst Addr 10.1.1.2

Tx Packets = 19967

Rx Packets = 19175

Throughput: 1035.15 Kbps

Flow ID: 2 Src Addr 10.1.1.1 Dst Addr 10.1.1.3

Tx Packets = 19967

Rx Packets = 8039

Throughput: 434.005 Kbps

Flow ID: 3 Src Addr 10.1.1.1 Dst Addr 10.1.1.4

Tx Packets = 19967

Rx Packets = 6363

Throughput: 344.616 Kbps

Flow ID: 4 Src Addr 10.1.1.1 Dst Addr 10.1.1.5

Tx Packets = 19967

Rx Packets = 6339

Throughput: 343.308 Kbps

Flow ID: 5 Src Addr 10.1.1.1 Dst Addr 10.1.1.6

Tx Packets = 19967

Rx Packets = 6317

Throughput: 342.109 Kbps

 

I had the data rate set to 2mbps downlink for each client which means I have 5 onoffapplications set up on my AP.  WiFi should split up the time between the 5 clients so they are equally provided the same throughput. If I only have 2 clients the algorithm performs as expected and divides the throughput equally among the clients seen below. Not sure if there is a problem with how I set up the network or if there is a setting I need to change to increase the fairness of the scheduling.

Flow ID: 1 Src Addr 10.1.1.1 Dst Addr 10.1.1.2

Tx Packets = 19967

Rx Packets = 19967

Throughput: 1082.26 Kbps

Flow ID: 2 Src Addr 10.1.1.1 Dst Addr 10.1.1.3

Tx Packets = 19967

Rx Packets = 19967

Throughput: 1082.25 Kbps

 

I have attached a test code to try and reproduce the problem. If you set “Morethan2clients” equal to true, the number of clients = 5, otherwise it is 2.

Thanks

[Tommaso Pecorella]

The short answer is: UDP sucks.

The long answer is: with 5 clients you're hitting the saturation point. As a consequence, packets are dropped by the AP queues. Mind, not by the channel, by the outgoing queue in the AP. If you don't have an appropriate active queue management algorithm (e.g., RED), packets will be dropped pretty much regularly.

Unfortunately, it is not possible to change the actual queueing policy in the WiFi MacLow (it's DropTail). Check WifiMacQueue and its MaxPacketNumber attribute.

About why the 1st client is always the favourite... no idea. However, the bandwidth is shared evenly if you don't hit the saturation.

Hope this helps a bit,

T.

[Tommaso Pecorella]

PS: upgrade to 3.19. Your script works in 3.19 without modifications. So you don't have excuses.

T.

[Jeremy Mack]

Thanks for the reply Tommaso,

So the solution would be to not hit the saturation point. How do I calculate the saturation point? Also the attached simulation was written just to show the problem, my actual simulation is very large and uses Brian Panneton's WiFi directional antenna patch, which took me while to get working with 3.16.

[Tommaso Pecorella]

Hi,

if you ported it to 3.16, it shouldn't be hard to go for 3.19. However it's still some work, so you may as well skip it.

About how to find if you're in saturation, I'd say to calculate the application throughput and stay below the WiFi datarate. However with directional antennas it's not that easy.

A practical solution is: when you start loosing packets and having increasing delay... then you're in saturation. It's a bit empirical, but it's not so "wrong". After all, saturation is exactly this: when the device bandwidth is less than the traffic you're feeding into it.

The problem may arise when you have bursty traffic. A burst may as well saturate the output buffer for a short period of time, but that's anther story (and it shouldn't happen so easily with OnOff applications.

Cheers,

T.

[adel]

Hi

I have the same problem with ns3.19. I use ieee802.11a(54Mb/s rate)  with 5 users but the problem arise from the third second . the application rate is 33mb/s i also try with different rate adaption                                         

UE	id	RxBits	Time
	0	3915776	2
	1	3555328	2
	2	3907584	2
	3	4390912	2
	4	3538944	2
	0	20291584	3
	1	696320	3
	2	688128	3
	3	696320	3
	4	712704	3
	0	23085056	4
	1	8192	4
	2	8192	4
	3	0	4
	4	8192	4
	0	23076864	5
	1	16384	5
	2	24576	5
	3	16384	5
	4	0	5

[Tommaso Pecorella]

Hi,

no idea, sorry. I know there are some lingering bugs around, so try with ns-3-dev.

Cheers,

T.

[adel agamy]

Thanks , i will try
 

[Sebastien Deronne]

Hi,

Did you try setting various random seeds?

In average, over a large number of runs, it should provide much more fairness.

As Tommaso said, it is certainly due to the queuing policy.

A new queuing policy would be welcome, especially when working at much higher data rates (802.11n) for which I am also experiencing large variations.

Regards,

Sébastien.

[adel agamy]

Hi, Sébastien

Yes i run with different seeds and increase the queue size as quick solution. Can tell me  how to add a new queue policy(red...etc) in Wifimacqueue instead of the current policy

Regards
Adel

 

[Sebastien Deronne]

As Tommaso said, it is not possible to change the actual queueing policy in the WiFi MacLow.

Did you try changing the starting time with a slight difference for each node?

[adel agamy]

I mean from where i can start to add new queuing policy to model.  Yes i tried