Confusion regarding tcp bandwidth fairness and some issues

154 views
Skip to first unread message

Nazmul Alam

unread,
Nov 2, 2016, 3:00:40 AM11/2/16
to ns-3-users
Hello,
I am new to ns3 and trying to use it for tcp bandwidth sharing fairness measurement.
I am using 1...n wifi clients, connected to an Ap, which is connected to a server over a router.
while slowly increasing the number of nodes, the bandwidth seems to equally shared between wifi clients.
But when I am trying with 4 nodes, flow monitor gives me 1 node with very very low bandwidth sharing (10% of R) and this inconsistency increases as the number of node increases. All nodes are sending data to the server.

What can be the cause of this inconsistency?

My application is BulkSendHelper (Source) and PacketSinkHelper (Sink), with MaxBytes set to 0 for the source. Wifi RemoteManager is set to ConstantRateWifiManager with DsssRate11Mbps and standard is set to 80211b. Clients are positioned using GridPositionAllocator and all of them are using ConstantPositionMobilityModel.

Following issues are observerd:

1. Running the simulation for 30 wifi client gives me the following error message -
Command [...] has exited with code 3

2. My wifi ConstantRateWifiManager is configured with DssRate11Mbps and Csma channel is configure with 100Mbps but it can only achieve 1.5 Mbps throughput with only 1 client. Am I missing something?

Any suggestion or direction will help me a great deal.
Thanks in advance.

Tommaso Pecorella

unread,
Nov 3, 2016, 8:03:40 PM11/3/16
to ns-3-users
Hi,

this kind of problems has been discussed a number of times, and (as the posting guidelines suggest) without the code we can not say much.

Your problem could be originated by node synchronization, lack of AQM in the AP, node positions, packet size, ns-3 version, etc.
Shortly put, analyze with care your scenario.

T.

Nazmul Alam

unread,
Nov 4, 2016, 12:57:14 AM11/4/16
to ns-3-users
Thank you for your reply.
I am really trying to figure out by myself.
Thank you again.
Message has been deleted

Tommaso Pecorella

unread,
Nov 5, 2016, 8:57:31 AM11/5/16
to ns-3-users
Hi,

your code works even with 35 nodes in 3.26. Please upgrade your ns-3 or give us a clear example of the problem.

About the other question, please check this link: https://www.switch.ch/network/tools/tcp_throughput/

T.

On Friday, November 4, 2016 at 6:38:05 AM UTC+1, Nazmul Alam wrote:
Hi,
My code is attached. I have no clue why increasing the node (nWifi > 26) causing the crash (I am using ns-3.25) and still having the issue mentioned previously.
the topology is

Wireless
*     *      Csma (100Mbps)
C    AP ====== Router ====== Server
                                    Csma (100Mbps)

Even with DsssRate11Mbps the effective throughput of one node sending data to the server is ~1.4Mbps. Where the bottleneck might be?
(btw, increasing tcp mss to 1450 pushes the throughput (tx) to ~2.4 Mbps)

Thanks in advance.

Nazmul Alam

unread,
Nov 7, 2016, 2:50:00 AM11/7/16
to ns-3-users
Hi,
I figured out why the previous code was crashing. Using the gdb, I saw that it was due to a rare case where high node # was causing one of the flow to have rxPackets to be zero thus reaching division by zero. This does not happens if there is atleast one rxPacket. Simple error checking solved it.

About tcp throughput I knew about the link you sent me, actually I was hoping to see closer results but in simulation it was giving me too much offset result. It appears to be fixed by changing the platform. In windows the variance of txthroughput between the nodes were too much. In ubuntu it seems to be more accurate (closer to the theoretical values).

But I am still confused about the maximum throughput achieved by a single node. The wifi is using DssRate11Mbsp and csma is using 100Mbps. Using the ConstantRateStationManager the maximum achievable rate is between ~1.4Mbps(using mss = 536 bytes) - ~2Mbps (using mss = 1472 bytes) which is still smaller than half of 11Mbps. Any suggestions? 

Thank you for your valuable suggestions and directions so far.

Tommaso Pecorella

unread,
Nov 7, 2016, 7:51:10 PM11/7/16
to ns-3-users
Hi,

I'm happy you made progress.
About the lousy TCP performance, the point is: TCP sucks. It wasn't designed to use the links at 100%, it was designed for fairness and reliability...
That's why using multiple TCP connections at once can improve your throughput :)

Cheers,

T.

Nazmul Alam

unread,
Nov 8, 2016, 4:43:24 AM11/8/16
to ns-3-users
Thank you for your comments.
Reply all
Reply to author
Forward
0 new messages