[Olsr-users] How to prioritize OLSR UDP packets.

[(spam-protected)]

On 01/12/2010 05:26 PM, (spam-protected) wrote:
> The two tests that I made involved three (real) PCs. PC1 was connected
> to PC2 through an ethernet cable, while PC2 was connected to PC3 through
> an 802.11b 11Mbps link.
> 
> +-----+        +-----+        +-----+
> | PC1 |--lan1--| PC2 |--lan2--| PC3 |
> +-----+        +-----+        +-----+
> 
> Addresses:
> lan1: 10.0.0.0/24
> lan2: 172.16.250.0/24
> 
> PC1: 10.0.0.2
> PC2: 172.16.250.1 on ath0 (wireless) and 10.0.0.1 on eth0
> PC3: 172.16.250.101
> 
> I ran the following script on PC2:
[...]
> === Test 1 - UDP: ===
> I started two UDP servers on PC3, with the following commands:
> iperf -s -u -i 3 -p 4455
> iperf -s -u -i 3 -p 4456
> 
> Then on PC1, I issued the first stream:
> sudo iperf -u -c 172.16.250.101 -b 10M -p 4456 -t 600 -S 0x30
> getting a throughput of about 7.8Mbps, and then the second stream:
> sudo iperf -u -c 172.16.250.101 -b 10M -p 4455 -t 600 -S 0x10
> 
> I got a throughput of about 7.2Mbps on the first stream and of about
> 750kbps on the second stream.
> 
> I expected the first stream (that should have a lower priority) to starve.
[...]
> 
> So in the UDP case, the scheduler seems *not* to work.
> 
> 
> === Test 2 - TCP: ===
> Same setup and same scheduling script as above.
> 
> I started two TCP servers on PC3, with the following commands:
> iperf -s -i 3 -p 4455
> iperf -s -i 3 -p 4456
> 
> Then on PC1, I issued the first stream:
> sudo iperf -c 172.16.250.101 -p 4456 -t 600 -S 0x30
> getting a throughput of about 6.25Mbps, and then the second stream:
> sudo iperf -c 172.16.250.101 -p 4455 -t 600 -S 0x10
> 
> 
> The two streams, after about 5 seconds in which the first stream slowly
> lowers its bandwidth, get to a point in which the first stream has
> slightly more bandwidth than the second stream (3.2Mbps vs. 3Mbps).
> 
> Also here, I expected the first stream to starve.
[...]
> So also in the TCP case, the scheduler seems *not* to work.
> 
> Perhaps I did something wrong?

Instead, with the following script things work as expected (i.e. the low
priority stream goes in starvation when the high priority stream
starts), both in the UDP and TCP scenarios (if you want the details I
can provide them).

--- begin script ---
#!/bin/sh

DEV="ath0"
tc qdisc del dev $DEV root 2>/dev/null

tc qdisc add dev $DEV root handle 1: htb default 1
tc class add dev $DEV parent 1: classid 1:1 htb \
rate 6000kbit ceil 6600kbit

tc qdisc add dev $DEV parent 1:1 handle 2: prio bands 3

tc qdisc add dev $DEV parent 2:1 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 2:2 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 2:3 handle 30: sfq perturb 10

tc filter add dev $DEV protocol ip parent 2: prio 1 u32 \
match ip tos 0x10 0xff flowid 2:1
tc filter add dev $DEV protocol ip parent 2: prio 2 u32 \
match ip tos 0x20 0xff flowid 2:2
tc filter add dev $DEV protocol ip parent 2: prio 3 u32 \
match ip tos 0x30 0xff flowid 2:3
--- end script ---

The big drawback of the script is that you have to specify a rate which
should be slightly smaller than the actually available bandwidth.

On wireless links the available bandwidth can fluctuate very much (see
performance anomaly [1]), and so it should be periodically estimated.
Then, with a "tc change", the rate should be updated.

However, I would be very happy to be wrong :)
Bye,
Clauz

[1] http://www.comsoc.org/confs/ieee-infocom/2003/papers/21_01.pdf


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20100112/de07d1fa/attachment.sig>