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

[Markus Kittenberger]

Am 12.01.2010, 08:16 Uhr, schrieb Henning Rogge  
<(spam-protected)>:

> On Tue January 12 2010 01:32:46 Evan Witt wrote:
>> We are running a mesh network, with each node running Ubuntu 8, with a
>>  2.6.24-22-server kernel.
>>
>> What is the quickest and best way to prioritize the UDP packets?
> OLSRd does not handle any traffic queues, but it sets a priority TOS  
> field in the
> IP header to make it easier to sort the messages into a queue. I think  
> the
> Freifunk-Firmware contains a script to prioritize the OLSR packages.

btw. the Freifunkfirmware does not use this TOS flag,..

heres the main part of its QOS setup,.. (with some comments what (i think  
that) all the quite cryptical tc matches do)
it works under 2.4 kernel, but imho it should work with 2.6 aswell

-----------
for DEV in $DEVS;do
	#setup 3 sfq queues
         tc qdisc add dev $DEV root handle 1: prio
         tc qdisc add dev $DEV parent 1:1 handle 10: sfq perturb 10
         tc qdisc add dev $DEV parent 1:2 handle 20: sfq perturb 10
         tc qdisc add dev $DEV parent 1:3 handle 30: sfq perturb 10
         match olsr -> put into queue: 1
         tc filter add dev $DEV protocol ip parent 1: prio 1 u32 match ip  
protocol 17 0xff match ip dport 698 0xffff flowid 1:1
         #match all TCP packets which have the ACK bit set -> put into  
queue: 1
         tc filter add dev $DEV protocol ip parent 1: prio 2 u32 match ip  
protocol 6 0xff match u8 0x10 0xff at nexthdr+13 flowid 1:1
         #match dns -> put into queue: 2
         tc filter add dev $DEV protocol ip parent 1: prio 3 u32 match ip  
protocol 17 0xff match ip dport 53 0xffff flowid 1:2
         #match packet length < 256 (prefer interactive traffic) -> put  
into queue: 2
         tc filter add dev $DEV protocol ip parent 1: prio 4 u32 match u16  
0x00ff 0xff00 at 2 flowid 1:2
         #match any ip traffic -> put into queue: 3
         tc filter add dev $DEV protocol ip parent 1: prio 5 u32 match ip  
protocol 0 0x00 flowid 1:3
done
-----------
some more comments:

priorizing TCP ACKS is also nice, as if we drop them, we have to pay the  
retransmit of the packet


priorizing DNS is imho very clever, as dns has big problems with packet  
loss (and this can (combined with negative caching) be a big cause for  
unsatisfied users *G)


priorizing small packets in general is somewhat the only rule in above  
setup i would not recommend to reuse 1:1
it`s nice for interactive traffic like ssh, or voip, but as its a very  
genral rule it can match quite much traffic, and might use up full  
bandwith of a router (completely stalling everything else which goes into  
queue 3)

at least i would not put this match into same queue as dns (as we might  
drop dns if queue 2 uses up all bandwidth),.. i think without the  
limitations of a 2.4 kernel on a small router, there are better solutions,  
to prefer interactive traffic, without potentially stalling everything  
(except olsr and tcp acks) else,..

lg Markus