All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] nesting htbs
@ 2005-06-09 10:37 Edward Smith
  2005-06-09 23:02 ` Andy Furniss
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Edward Smith @ 2005-06-09 10:37 UTC (permalink / raw)
  To: lartc

Hello all,
 I am running a coop satellite link for my aviation company here in
Iraq.  (silly blog www.stardotstar.org).  I am running tc with htb
with good success so far.  I am working on improving it though and
need some help.  Currently I have just 4 classes, syn/ack/ping,
webchat, http, and then other.  We are really happy with how this has
improved our ability to call home from our rooms and do video chat.
  However, I would like to do a better job of making sure that each
IP is getting a fair share because it seems like sometimes one video
or audio chat bullies another one into slowing down and one guy is
having a great video and audio feed while someone elses audio only is
suffering.  I've seen some references to wrr and also to making a
class for each IP.  There doesn't seem to be much current documention
on wrr, so I'm trying to set up nested htbs.  Here are my questions:

1. Which makes more sense, to nest my 4 classes of traffic inside of a
class for each IP, or to make a class for each IP in each of my 4
classes.  I'm leaning towards the latter so that someones web traffic
can't borrow from the interactive traffic classes.

2.  I've done a test, and can't get any traffic into the nested
classes.  Here is my code:

#1:20 LOW DELAY--CHAT DATA
#includes the minimize delay FW TOS
tc class add dev ${UPDEV} parent 1:1 classid 1:20 htb rate 200kbit
ceil ${UPCEIL}kbit burst 6k prio 1
tc filter add dev ${UPDEV} protocol ip parent 1: pref 20 u32\
       match ip tos 0x10 0xff flowid 1:20
tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 5 fw
classid 1:20
tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 6 fw
classid 1:20
tc qdisc add dev ${UPDEV} parent 1:20 handle 120: sfq perturb 10
nextclass 00
for clientip  in `cat /etc/ethers |  awk '{ print $2 }'`;
do
       tc class add dev ${UPDEV} parent 1:20 classid 1:${nextclass}
htb rate  ${CLIENTRATE}kbit ceil ${CLIENTCEIL}kbit
       tc filter add dev ${UPDEV} protocol ip parent 1:20 prio 1 u32 \
               match ip src ${clientip} flowid 1:${nextclass}
       tc qdisc add dev ${UPDEV} parent 1:${nextclass} handle
${nextclass}: sfq perturb 10  #not sure if this is necessa
ry
       ((nextclass++))
done

I'm missing something, but not sure what.  This code works as far as
classes goes, just the filtering doesn't get traffic into the nested
classes.  I'm on 2.6.11 gentoo.  Sorry about the wrapping, I'll look
into setting nowrap on gmail.

Thanks!

Edward
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] nesting htbs
  2005-06-09 10:37 [LARTC] nesting htbs Edward Smith
@ 2005-06-09 23:02 ` Andy Furniss
  2005-06-10 11:03 ` Dariusz Dwornikowski
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Andy Furniss @ 2005-06-09 23:02 UTC (permalink / raw)
  To: lartc

Edward Smith wrote:
> Hello all,
>  I am running a coop satellite link for my aviation company here in
> Iraq.  (silly blog www.stardotstar.org).  I am running tc with htb
> with good success so far.  I am working on improving it though and
> need some help.  Currently I have just 4 classes, syn/ack/ping,
> webchat, http, and then other.  We are really happy with how this has
> improved our ability to call home from our rooms and do video chat.
>   However, I would like to do a better job of making sure that each
> IP is getting a fair share because it seems like sometimes one video
> or audio chat bullies another one into slowing down and one guy is
> having a great video and audio feed while someone elses audio only is
> suffering.  I've seen some references to wrr and also to making a
> class for each IP.  There doesn't seem to be much current documention
> on wrr, so I'm trying to set up nested htbs.  Here are my questions:
> 
> 1. Which makes more sense, to nest my 4 classes of traffic inside of a
> class for each IP, or to make a class for each IP in each of my 4
> classes.  I'm leaning towards the latter so that someones web traffic
> can't borrow from the interactive traffic classes.

I would do the latter also. I would have just one interactive class and 
give it a rate that is say 3/4 of the ceil, the bulk classes can still 
borrow the unused.
> 
> 2.  I've done a test, and can't get any traffic into the nested
> classes.  Here is my code:
> 
> #1:20 LOW DELAY--CHAT DATA
> #includes the minimize delay FW TOS
> tc class add dev ${UPDEV} parent 1:1 classid 1:20 htb rate 200kbit
> ceil ${UPCEIL}kbit burst 6k prio 1
> tc filter add dev ${UPDEV} protocol ip parent 1: pref 20 u32\
>        match ip tos 0x10 0xff flowid 1:20
> tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 5 fw
> classid 1:20
> tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 6 fw
> classid 1:20


> tc qdisc add dev ${UPDEV} parent 1:20 handle 120: sfq perturb 10
> nextclass 00

You don't need this as it's not a leaf.

> for clientip  in `cat /etc/ethers |  awk '{ print $2 }'`;
> do

If clientip is local because you are NATing than it won't work because 
traffic will have the real ip here.

To work around you could use marks. As you already use them for some 
things you may want to use --or-mark and u32 to match them eg.

iptables -A POSTROUTING -t mangle -p icmp -j MARK --set-mark 0x0100

and so on for traffic types using high byte then use low byte and 
--or-mark for addresses

iptables -A POSTROUTING -t mangle -s 192.168.0.1 -j MARK --or-mark 0x0001

Then filter top level with a mask like

tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match mark 
0x0100 0xff00 flowid 1:20

and leaf levels

tc filter add dev eth0 parent 1:20 protocol ip prio 1 u32 match mark 
0x0001 0x00ff flowid 1:200

That assumes you really need iptables for marking traffic type - if you 
could use tc filters for that, then just use iptables for the addresses.


>        tc class add dev ${UPDEV} parent 1:20 classid 1:${nextclass}
> htb rate  ${CLIENTRATE}kbit ceil ${CLIENTCEIL}kbit
>        tc filter add dev ${UPDEV} protocol ip parent 1:20 prio 1 u32 \
>                match ip src ${clientip} flowid 1:${nextclass}
>        tc qdisc add dev ${UPDEV} parent 1:${nextclass} handle
> ${nextclass}: sfq perturb 10  #not sure if this is necessa
> ry

I wouldn't put sfq on interactive - I would add a bfifo so I could set 
and play with the buffer lengths.

Andy.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] nesting htbs
  2005-06-09 10:37 [LARTC] nesting htbs Edward Smith
  2005-06-09 23:02 ` Andy Furniss
@ 2005-06-10 11:03 ` Dariusz Dwornikowski
  2005-06-13 14:25 ` Andy Furniss
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Dariusz Dwornikowski @ 2005-06-10 11:03 UTC (permalink / raw)
  To: lartc

On Fri, 10 Jun 2005 00:02:42 +0100
Andy Furniss <andy.furniss@dsl.pipex.com> wrote:

> Edward Smith wrote:
> > Hello all,
> >  I am running a coop satellite link for my aviation company here in
> > Iraq.  (silly blog www.stardotstar.org).  I am running tc with htb
> > with good success so far.  I am working on improving it though and
> > need some help.  Currently I have just 4 classes, syn/ack/ping,
> > webchat, http, and then other.  We are really happy with how this has
> > improved our ability to call home from our rooms and do video chat.
> >   However, I would like to do a better job of making sure that each
> > IP is getting a fair share because it seems like sometimes one video
> > or audio chat bullies another one into slowing down and one guy is
> > having a great video and audio feed while someone elses audio only is
> > suffering.  I've seen some references to wrr and also to making a
> > class for each IP.  There doesn't seem to be much current documention
> > on wrr, so I'm trying to set up nested htbs.  Here are my questions:
> > 
> > 1. Which makes more sense, to nest my 4 classes of traffic inside of a
> > class for each IP, or to make a class for each IP in each of my 4
> > classes.  I'm leaning towards the latter so that someones web traffic
> > can't borrow from the interactive traffic classes.
> 
> I would do the latter also. I would have just one interactive class and 
> give it a rate that is say 3/4 of the ceil, the bulk classes can still 
> borrow the unused.
> > 
> > 2.  I've done a test, and can't get any traffic into the nested
> > classes.  Here is my code:
> > 
> > #1:20 LOW DELAY--CHAT DATA
> > #includes the minimize delay FW TOS
> > tc class add dev ${UPDEV} parent 1:1 classid 1:20 htb rate 200kbit
> > ceil ${UPCEIL}kbit burst 6k prio 1
> > tc filter add dev ${UPDEV} protocol ip parent 1: pref 20 u32\
> >        match ip tos 0x10 0xff flowid 1:20
> > tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 5 fw
> > classid 1:20
> > tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 6 fw
> > classid 1:20
>

so marking is thing that i need for limiting NATed uploads to internet ?
when limiting downloads i do not need marking ?

am i right ?



-- 
*Dariusz 'tdi' Dwornikowski | Gentoo | admin at pozman.pl     |
*[JID]:tdi@gentoo.pl|[gg]:2266034|[IRC]:#gentoo-pl@freenode   |
*[MAIL]:tdi@pozman.pl|[WWW]:www.tdi.pozman.pl                 | 
*Serwery,administracja,webapps - www.ProAdmin.com.pl          |
*Fingerprint:43E21CC46DAFD2F754E91547D59B39F56AAA4B5F         |
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] nesting htbs
  2005-06-09 10:37 [LARTC] nesting htbs Edward Smith
  2005-06-09 23:02 ` Andy Furniss
  2005-06-10 11:03 ` Dariusz Dwornikowski
@ 2005-06-13 14:25 ` Andy Furniss
  2005-06-13 14:36 ` Andy Furniss
  2005-06-15 11:55 ` Ed W
  4 siblings, 0 replies; 6+ messages in thread
From: Andy Furniss @ 2005-06-13 14:25 UTC (permalink / raw)
  To: lartc

Dariusz Dwornikowski wrote:

> so marking is thing that i need for limiting NATed uploads to internet ?
> when limiting downloads i do not need marking ?
> 
> am i right ?

Yes as long as you are shaping downloads by shaping egress on the lan 
facing interface.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] nesting htbs
  2005-06-09 10:37 [LARTC] nesting htbs Edward Smith
                   ` (2 preceding siblings ...)
  2005-06-13 14:25 ` Andy Furniss
@ 2005-06-13 14:36 ` Andy Furniss
  2005-06-15 11:55 ` Ed W
  4 siblings, 0 replies; 6+ messages in thread
From: Andy Furniss @ 2005-06-13 14:36 UTC (permalink / raw)
  To: lartc

Andy Furniss wrote:

> 
> 
> If clientip is local because you are NATing than it won't work because 
> traffic will have the real ip here.
> 
> To work around you could use marks. As you already use them for some 
> things you may want to use --or-mark and u32 to match them eg.
> 
> iptables -A POSTROUTING -t mangle -p icmp -j MARK --set-mark 0x0100
> 
> and so on for traffic types using high byte then use low byte and 
> --or-mark for addresses
> 
> iptables -A POSTROUTING -t mangle -s 192.168.0.1 -j MARK --or-mark 0x0001
> 
> Then filter top level with a mask like
> 
> tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match mark 
> 0x0100 0xff00 flowid 1:20
> 
> and leaf levels
> 
> tc filter add dev eth0 parent 1:20 protocol ip prio 1 u32 match mark 
> 0x0001 0x00ff flowid 1:200
> 
> That assumes you really need iptables for marking traffic type - if you 
> could use tc filters for that, then just use iptables for the addresses.

Something I've only just noticed from a comment in the code - htb can 
use mark without the need for lots of filters.

You only need one empty filter on the root (maybe you can still nest) like -

tc filter add dev eth0 parent 1:0 protocol ip prio 1 fw

and then if you arrange for your classes to be the same minor numbers as 
the marks it will behave like using classify.

You need to set the major number of your htb (1 in example above) in the 
top 16 bits of the mark.

There is also a netfilter pom-ng patch IPMARK that will set marks based 
on ipaddress.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] nesting htbs
  2005-06-09 10:37 [LARTC] nesting htbs Edward Smith
                   ` (3 preceding siblings ...)
  2005-06-13 14:36 ` Andy Furniss
@ 2005-06-15 11:55 ` Ed W
  4 siblings, 0 replies; 6+ messages in thread
From: Ed W @ 2005-06-15 11:55 UTC (permalink / raw)
  To: lartc


> I wouldn't put sfq on interactive - I would add a bfifo so I could set 
> and play with the buffer lengths.


I agree.  I think SFQ might reorder packets?  It sometimes seems to 
cause some difficult to trace gremlins on my VoIP stuff, which might be 
due to packet re-ordering?

Best to stick with a bfifo I think

Ed W
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2005-06-15 11:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-09 10:37 [LARTC] nesting htbs Edward Smith
2005-06-09 23:02 ` Andy Furniss
2005-06-10 11:03 ` Dariusz Dwornikowski
2005-06-13 14:25 ` Andy Furniss
2005-06-13 14:36 ` Andy Furniss
2005-06-15 11:55 ` Ed W

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.