All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] general shaping recommendations
@ 2003-12-18 23:26 Damion de Soto
  2003-12-19  0:15 ` Martin A. Brown
  2003-12-22  3:00 ` Damion de Soto
  0 siblings, 2 replies; 3+ messages in thread
From: Damion de Soto @ 2003-12-18 23:26 UTC (permalink / raw)
  To: lartc

Hi everyone,

I am wondering, what is the best way to do some 'generic shaping' on a 
firewall/gateway box.
Currently, I'm just running a wondershaper variant on the WAN interface.
htb qdiscs for outbound, and ingress policer for inbound.

Now, assuming most traffic (except DNS requests etc) goes through the firewall, I 
could shape on the LAN side as well.

Should I put htb qdiscs on WAN as well as LAN and not use any ingress policers ?
or should I use them as well?

also,
with rules like this:
tc qdisc add dev ppp0 root handle 1: htb default 20
tc class add dev ppp0 parent 1:1 classid 1:1 htb rate 512kbit burst 6k
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 512kbit burst 6k prio 1
tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 460kbit burst 6k prio 2
tc class add dev ppp0 parent 1:1 classid 1:30 htb rate 409kbit burst 6k prio 2

Will the slower queues be able to borrow extra bandwidth from the faster ones (when 
they're not in use), or do I need to specify the ceiling parameter to allow that?
I'm a bit unsure of the default behaviour of the htb qdisc.

thanks


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear - A CyberGuard Company ---    ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

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

* Re: [LARTC] general shaping recommendations
  2003-12-18 23:26 [LARTC] general shaping recommendations Damion de Soto
@ 2003-12-19  0:15 ` Martin A. Brown
  2003-12-22  3:00 ` Damion de Soto
  1 sibling, 0 replies; 3+ messages in thread
From: Martin A. Brown @ 2003-12-19  0:15 UTC (permalink / raw)
  To: lartc

Damion,

 : I am wondering, what is the best way to do some 'generic shaping' on a
 : firewall/gateway box. Currently, I'm just running a wondershaper
 : variant on the WAN interface. htb qdiscs for outbound, and ingress
 : policer for inbound.

The wondershaper is well-designed for the standalone box connected to a
DSL link.  You can also use it (usually) very well on a masquerading box,
but if you want to do fancier things, you may wish to consider ditching
wondershaper entirely.

 : Now, assuming most traffic (except DNS requests etc) goes through the
 : firewall, I could shape on the LAN side as well.

In a conventional masquerading firewall situation,

  - shaping on the LAN interface will shape your usage of
    download bandwidth (inbound packets).
  - shaping on the WAN interface will shape your usage of
    upload bandwidth (outbound packets).

 : Should I put htb qdiscs on WAN as well as LAN and not use any ingress
 : policers ? or should I use them as well?

There's no reason not to use ingress policers if you wish.  I would
recommend, however, shaping on both the inbound and outbound traffic.

 : tc qdisc add dev ppp0 root handle 1: htb default 20
 : [ snip ] classid 1:1 htb rate 512kbit burst 6k
 : [ snip ] classid 1:10 htb rate 512kbit burst 6k prio 1
 : [ snip ] classid 1:20 htb rate 460kbit burst 6k prio 2
 : [ snip ] classid 1:30 htb rate 409kbit burst 6k prio 2
 :
 : Will the slower queues be able to borrow extra bandwidth from the
 : faster ones (when they're not in use), or do I need to specify the
 : ceiling parameter to allow that?

I'm fairly certain that the above is not what you desire.  When you
specify a "rate" in a class, that class will ALWAYS consume up to that
available amount of bandwidth before checking to see if the parent has any
bandwidth to lend.  So, you will want to change this.

I think this is probably closer to what you wish to do, although your
numbers may be different.

 [ snip ] classid 1:1 htb rate 512kbit burst 6k
 [ snip ] classid 1:10 htb rate 256kbit ceil 512kbit burst 6k prio 1
 [ snip ] classid 1:20 htb rate  96kbit ceil 460kbit burst 6k prio 2
 [ snip ] classid 1:30 htb rate  96kbit ceil 409kbit burst 6k prio 2

Look at the sum of the rates of the children classes, this is

class   1:10  1:20  1:30
$ expr   256 +  96 +  96
448

This means that if all three classes are going full bore, you'll use
448kbit.  When a class reaches its rate, it will try to borrow tokens from
the parent class (rateÎilQ2kbit).  The parent will dole out the tokens
to each child class which requests tokens in quantum increments.  Maybe
the diagram I drew will help you [0].

Once a child class (which is now exceeding "rate") reaches "ceil", it will
cease attempting to borrow tokens and will buffer/delay packets (this is
the shaping effect).

Nota bene: A child class will simply consume bandwidth until it reaches
           its specified rate.  Only after reaching the rate will the
           class begin to consult the parent class and (potentially) delay
           packets.

 : I'm a bit unsure of the default behaviour of the htb qdisc.

I don't know if my explanation will help, but check out my description of
the HTB model [1].  Be sure to read Martin Devera's description [2], and
also consider Stef Coene's documentation [3] and tests [4].  His tests
show how bandwidth is distributed/allocated under various
conditions--essentially these graphs provide a good way to understand the
behaviour of HTB.

-Martin

  [0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/diagram.html#d-general
  [1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb
  [2] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
  [3] http://www.docum.org/stef.coene/qos/docs/htb/
  [4] http://www.docum.org/stef.coene/qos/tests/htb/index.html

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

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

* Re: [LARTC] general shaping recommendations
  2003-12-18 23:26 [LARTC] general shaping recommendations Damion de Soto
  2003-12-19  0:15 ` Martin A. Brown
@ 2003-12-22  3:00 ` Damion de Soto
  1 sibling, 0 replies; 3+ messages in thread
From: Damion de Soto @ 2003-12-22  3:00 UTC (permalink / raw)
  To: lartc

Hi Martin,
> There's no reason not to use ingress policers if you wish.  I would
> recommend, however, shaping on both the inbound and outbound traffic.

If I'm running a web proxy on the gateway, then I would need ingress policer to limit 
the download bandwith for web requests.
How will the ingress policer on the WAN interface interact with the other egress htb 
classes on the LAN interface ?

> I'm fairly certain that the above is not what you desire.  When you
> specify a "rate" in a class, that class will ALWAYS consume up to that
> available amount of bandwidth before checking to see if the parent has any
> bandwidth to lend.  So, you will want to change this.
Ok, I see this and have fixed it.
So the wondershaper is wrong ?  it doesn't use the ceil values and creates rate 
values that sum up to a higher value than your ISP bandwidth.

>  [ snip ] classid 1:1 htb rate 512kbit burst 6k
>  [ snip ] classid 1:10 htb rate 256kbit ceil 512kbit burst 6k prio 1
>  [ snip ] classid 1:20 htb rate  96kbit ceil 460kbit burst 6k prio 2
>  [ snip ] classid 1:30 htb rate  96kbit ceil 409kbit burst 6k prio 2
> 
> Look at the sum of the rates of the children classes, this is
> class   1:10  1:20  1:30
> $ expr   256 +  96 +  96
> 448
Did you just guess at the ceiling numbers, or did you calculate them using some method?

> I don't know if my explanation will help, but check out my description of
> the HTB model [1].  Be sure to read Martin Devera's description [2], and
> also consider Stef Coene's documentation [3] and tests [4].  His tests
> show how bandwidth is distributed/allocated under various
> conditions--essentially these graphs provide a good way to understand the
> behaviour of HTB.

Thanks, I didn't realise there was a 'LARTC HOWTO' and a 'Traffic Control HOWTO'
The latter is much more useful and the diagrams are very helpful.


regards,

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear - A CyberGuard Company ---    ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

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

end of thread, other threads:[~2003-12-22  3:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-18 23:26 [LARTC] general shaping recommendations Damion de Soto
2003-12-19  0:15 ` Martin A. Brown
2003-12-22  3:00 ` Damion de Soto

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.