[Asterisk-Users] Using Linux traffic shaping to prioritise SIP/IAX traffic?

[Wade Weppler]

Hi Alberto,

	Being a QOS newbie, your example was invaluable!  I'm testing your
example, and so far so good.

	Once I have something I'm happy with, I'll post it on my Asterisk
website:

	http://www.wwworks-inc.com/asterisk

Nice work Alberto, and thanks.

-wade

 
> On Tue, Jun 10, 2003 at 09:58:14PM +0200, Emanuele Pucciarelli wrote:
> > Il mar, 2003-06-10 alle 20:07, Stephen Davies ha scritto:
> >
> > > > When the "tos" option is set correctly (to "nodelay"), the default
> > > > queueing in recent kernels already does that, because the pfifo_fast
> > > > queue is used (if I recall correctly).
> > >
> > > But there is never any queue on my Linux box.  It all storms out of
> > > the ethernet interface and gets queued up in my cable modem which
> > > doesn't know anything about tos settings.
> >
> > That is not entirely correct.  There is an output queue, and pfifo_fast
> > is the default (see the LARTC Howto, 9.2.1.1).  But you are right when
> > you say you need something to slow down the data;the simplest  choice
> > should be addingthe Token Bucket Filter (9.2.2.2).
> >
> > But if the wondershaper already does it all, then it's probably better
> > to go with it... :)
> 
> You should read further into lartc.org, the linux traffic shaping
> capabilities are really wide and you can find lots of ways of doing what
> you want.
> 
> In your case, I guess the logical choice would be to use HTB, with two
> classes, let's say if your cablemodem is 512kbps, you can save 112kbps for
> voice and signalling (yes it's extreme but it's an example), and 400kbps
> for the data. Also, you can put the former with top priority to minimize
> latency.
> 
> Under those you can use sfq to make everything more fair, that helps a lot
> when saturating.
> 
> This is a very short script, I'm sure there is something like this on
> lartc or htb's website.
> 
> Something like this (completely untested, from memory so don't trust me):
> 
> # delete the existing qdisc
> tc qdisc del dev eth1 root 2>&1 > /dev/null
> 
> # init the htb qdisc
> tc qdisc add dev eth1 root handle 1: htb
> 
> tc class add dev eth1 parent 1: classid 1:5 htb rate 512kbit
> tc class add dev eth1 parent 1:5 classid 1:10 htb rate 112kbit prio 0
> tc class add dev eth1 parent 1:5 classid 1:20 htb rate 400kbit prio 2
> 
> # sfq for all of them
> tc qdisc add dev eth1 parent 1:5  handle 500: sfq perturb 10
> tc qdisc add dev eth1 parent 1:10 handle 100: sfq perturb 10
> tc qdisc add dev eth1 parent 1:20 handle 200: sfq perturb 10
> 
> 
> And now you need to set the filters up, which can be based on tc or using
> iptables' MARK target.
> 
> For instance:
> 
> # everything marked 10 in iptables go to 1:10 (the 112kbit)
> tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 10 fw \
> 	flowid 1:10
> 
> # everything marked 20 in iptables go to 1:20 (the 400kbit)
> tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 20 fw \
> 	flowid 1:20
> 
> 
> And then mark in iptables (i don't remember sip's port very well, and you
> should also add RTP stuff too):
> 
> # sip, mark 10
> iptables -t mangle -A PREROUTING -i eth2 -p tcp --destination-port 5060 \
> 	-j MARK --set-mark 10
> iptables -t mangle -A PREROUTING -i eth2 -p udp --destination-port 5060 \
> 	-j MARK --set-mark 10
> 
> # default, mark 20
> iptables -t mangle -A PREROUTING -i eth2 -d 0.0.0.0/0 \
> 	-j MARK --set-mark 20
> 
> In this case you could have used tc's native filters which are much faster
> than iptables, but also harder to setup, so if this is your first approach
> to this stuff I wouldn't recommend them (and don't worry, the speed
> difference is _not_ noticeable for that bandwidth).
> 
> 
> I hope this helps, however this is all untested, (ie. just wrote it) so
> please look into the docs to find out more.
> 
> 
> Thanks,
> 		Alberto
> 
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users