How bandwidth is allocated to concurrent users

bandwidthnetworking

Let's say a server is connected to internet through limited bandwidth, and more than 1 user try to download a file from that server simultaneously.

If we ignore the bandwidth limitation at the user side, may I know how the server side bandwidth will be allocated to different users? If there are 2 concurrent users trying to download the same file, will the bandwidth be divided evenly among the users, so each user get 0.5 of the bandwidth?

I've tried the following setup:-

I've connected 2 client PC with Windows XP OS to a switch. From the switch, I connect it to a server PC through a fixed bandwidth of 2mbps. Then, I run iperf in all 3 PC at the same time. The client PC run iperf in client mode, and the server PC run iperf in server mode.

Both the client PC send data to the server PC at the same time.

Then, I found that the server PC get ~500kbps from client PC1 and ~1450kbps from client PC2.

Both the client PC are connected to the switch using 1gbps ethernet connection. Both are using the same type of cable. Both are using the same OS. The settings for iperf are also the same.

I don't understand why there is such a big difference between the bandwidth allocated to client PC1 and client PC2. I would like to know how bandwidth is allocated to concurrent users who are trying to access the server at the same time.

Thanks.

Best Answer

There is no one answer. For the most simplest of TCP services, each client will attempt to grab data as fast as it can, and the server will shovel it to the clients as fast as it is able. Given two clients of combined bandwidth exceeding the bandwidth of the server, both clients will probably download at speeds of roughly half the server's bandwidth.

There are a LOT of variables in this that make this not quite true in real life. If the TCP/IP stacks of the different clients are differently able to handle high streaming connections, that by itself can affect bandwidth even if the server has infinite bandwidth. Different operating systems or server programs handle streaming speed ramp-up differently. Latency has an effect on throughput, where large latency connections can be significantly slower than low latency connections even though both connections can stream (in absolute values) the same amount of data.

A case in point, downloading kernel source archives. I've got very fast bandwidth at work, in fact it exceeds my LAN speed so I can saturate my local 100Mb connection if I get the right server. Watching my network utilization chart while downloading large files I can see some servers start small, 100Kb/s, slowly ramp up to high values, 7Mb/s, then something happens and it all starts over again. Other servers will give me everything immediately when I start downloading.

Anyway, items that can cause actual bandwidth allocation to differ from absolute equality:

TCP/IP capabilities of the client and server relationship
TCP tuning parameters on either side, not just capabilities
Latency on the line
The application-level transfer protocols being used
The existence of hardware specifically designed for load balancing
Congestion between clients and the server itself

In regards to your test-cases, what likely happened is that one client was able to establish a higher datastream rate than the other, perhaps by getting there first. When the other stream started it was not allocated sufficient resources to gain full speed parity; the first stream got there first and got most of the resources. If the first stream ended the second would likely pick up speed. In this case, the speed experienced by the clients was determined by the Server OS, the application doing the streaming, and the TCP/IP stack of the Server. Also, if the network card supported it, the TCP Offload Engine of the network card, if present and enabled.

As I said, there are a lot of variables that go into it.

Slow-ramp bandwidth usage: Slow ramp bandwidth usage chart

Related Solutions

Linux – Fair bandwidth repartition between multiple users

Since you're using Debian Linux, you can do it quite simple. You can use this script for "fair" repartition on the bandwidth:

#Put here your Internet-interface instead of eth1
ext_iface=eth1
eiface_addr=192.169.158.150

###############Remove shaper rules###############################3
iptables -t mangle --flush

tc qdisc del dev $ext_iface root 2> /dev/null > /dev/null

iptables -t mangle -D POSTROUTING -o $ext_iface -j shape-in 2> /dev/null > /dev/null
iptables -t mangle -F shape-in 2> /dev/null > /dev/null
iptables -t mangle -X shape-in 2> /dev/null > /dev/null

##############Adding shaper rules###################################
tc qdisc add dev $ext_iface root handle 1:0 htb default 10
tc class add dev $ext_iface parent 1:0 classid 1:1 htb rate 100mbit ceil 100mbit

tc class add dev $ext_iface parent 1:1 classid 1:5 htb rate 100mbit ceil 100mbit prio 0
tc class add dev $ext_iface parent 1:1 classid 1:10 htb rate 48mbit ceil 48mbit prio 0

tc qdisc add dev $ext_iface parent 1:5 handle 5: pfifo limit 5
tc qdisc add dev $ext_iface parent 1:10 handle 10: pfifo limit 10

iptables -t mangle -N shape-in
iptables -t mangle -I POSTROUTING -o $ext_iface -j shape-in

#Priority for pings
iptables -t mangle -A shape-in -p icmp -j MARK --set-mark 5

#Priority for Server Access
iptables -t mangle -A shape-in -s $eiface_addr -j MARK --set-mark 5

#Othet packets (user\'s internet traffic)
iptables -t mangle -A shape-in -m mark --mark 0 -j MARK --set-mark 10

tc filter add dev $ext_iface parent 1:0 prio 0 protocol ip handle 5 fw flowid 1:5
tc filter add dev $ext_iface parent 1:0 prio 1 protocol ip handle 10 fw flowid 1:10

Note that the users will get 48/n channel and there is two Mbs left for a reserve.

Linux – NIC bonding can’t go above 1 Gbps

Load balancing across links in a port aggregation group is not done strictly per frame. The switch and the server both use a methodology taking some combination of source mac address, destination mac address, source and/or destination tcp or udp port, etc. into account to prevent out of order packet delivery for a single session.

You might find you'll see the performance you expect if your run multiple iperf sessions on different listening ports with each client connection to a different session...depending on the load balancing methods being employed.

Best Answer

Related Solutions

Linux – Fair bandwidth repartition between multiple users

Linux – NIC bonding can’t go above 1 Gbps

Related Topic