ALTQ-Bandwidth management is not working as expected

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

ALTQ-Bandwidth management is not working as expected

scatman.b
Hi everyone,

Problem:
Bandwidth management is not working as expected; instead of streaming data
inbound with 237 Kb/sec without bandwidth management, it drops to 29 Kb/sec
(tendency falling) with enabled bandwidth management

Test environment:
OpenBSD 3.7 or 3.8 (both tested); Pentium 3 or
Athlon XP (both tested), PF, ALTQ, PPPOE-Interface,
DSL 2000

Guessed fault:
ALTQ wasn't understood by me?!?

Story:
I'm trying to get bandwidth management to work with openbsd
for 6 weeks now. I read several posts, howtos and manuals.
I tried all supported schedulers. To isolate the problem I reduced
my original complexity to priq as scheduler. (Afterwards this
should change.) The Isolation brought the assumption the problem could
be me and my understanding about altq. So I'm asking you now.

pf.conf:
---pf.conf---
### MACROS & TABLES ###
#
#Define all interfaces
#
ext_if="pppoe0"
int_if="pcn0"

#
#Define privileged network address sets
#
nets_priv = "{ 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 }"

### OPTIONS ###
#
#Default behavior
#
##Define default response for block filters
set block-policy drop
##Define statistics logging on
set loginterface $ext_if

### TRAFFIC NORMALIZATION ###
#
#Filter traffic for unusual packets
#
scrub in all

### QUEUEING ###
#
#Bandwidth management
#
##Define upstream parent queue (24Kb * 0,95 Overhead)
altq on $ext_if priq bandwidth 22Kb queue { up_default up_web up_quick }
##Define downstream parent queue (256Kb * 0,95 Overhead)
altq on $int_if priq bandwidth 243Kb queue { dn_default dn_quick }

##Define upstream child queues
queue up_default priq(default)
queue up_quick priority 7 priq

##Define downstream child queues
queue dn_default priq(default)
queue dn_quick priority 7 priq

### TRANSLATION ###
#
#NAT for the external traffic
#
nat on $ext_if from $int_if:network to any -> ($ext_if)

#
#Redirections
#
##Redirect FTP clients to FTP proxy WITHOUT FIREWALL
rdr pass on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021

### PACKET FILTERING ###
#
#Default filter
#
block log all

#
#Loopback interface traffic
#
pass quick on lo0 all

#
#Filter and queue external interface traffic
#
##Deny incoming or outgoing priviliged network address sets
block in quick on $ext_if from $nets_priv to any
block out quick on $ext_if from any to $nets_priv
##Allow incoming traffic to ftp proxy; keep the state
pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state
##Allow incoming ping request to router; keep the state
pass in on $ext_if inet proto icmp from any to $ext_if icmp-type 8 code 0
keep state
##Assign upstream traffic to queues; keep the state
pass out on $ext_if keep state queue(up_default up_quick)

#
#Filter and queue internal interface traffic
#
##Allow incoming traffic from internal network; do not keep the state
pass in on $int_if from $int_if:network to any
##Assign outgoing traffic from other interfaces to queues for downstream; do
not keep the state
pass out on $int_if from any to $int_if:network queue(dn_default dn_quick)

#
#Deny spoofing
#
antispoof for $ext_if
antispoof for $int_if
---pf.conf---

Thank you for your assistance,
Benjamin

--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f|r Mail, Message, More +++

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

Chris Cappuccio
altq is looking at kilobits per second and you're probably looking at kiloBytes
per second

(237Kb/sec / 8bits/Byte=29KB/sec)

[hidden email] [[hidden email]] wrote:

> Hi everyone,
>
> Problem:
> Bandwidth management is not working as expected; instead of streaming data
> inbound with 237 Kb/sec without bandwidth management, it drops to 29 Kb/sec
> (tendency falling) with enabled bandwidth management
>
> Test environment:
> OpenBSD 3.7 or 3.8 (both tested); Pentium 3 or
> Athlon XP (both tested), PF, ALTQ, PPPOE-Interface,
> DSL 2000
>
> Guessed fault:
> ALTQ wasn't understood by me?!?
>
> Story:
> I'm trying to get bandwidth management to work with openbsd
> for 6 weeks now. I read several posts, howtos and manuals.
> I tried all supported schedulers. To isolate the problem I reduced
> my original complexity to priq as scheduler. (Afterwards this
> should change.) The Isolation brought the assumption the problem could
> be me and my understanding about altq. So I'm asking you now.
>
> pf.conf:
> ---pf.conf---
> ### MACROS & TABLES ###
> #
> #Define all interfaces
> #
> ext_if="pppoe0"
> int_if="pcn0"
>
> #
> #Define privileged network address sets
> #
> nets_priv = "{ 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 }"
>
> ### OPTIONS ###
> #
> #Default behavior
> #
> ##Define default response for block filters
> set block-policy drop
> ##Define statistics logging on
> set loginterface $ext_if
>
> ### TRAFFIC NORMALIZATION ###
> #
> #Filter traffic for unusual packets
> #
> scrub in all
>
> ### QUEUEING ###
> #
> #Bandwidth management
> #
> ##Define upstream parent queue (24Kb * 0,95 Overhead)
> altq on $ext_if priq bandwidth 22Kb queue { up_default up_web up_quick }
> ##Define downstream parent queue (256Kb * 0,95 Overhead)
> altq on $int_if priq bandwidth 243Kb queue { dn_default dn_quick }
>
> ##Define upstream child queues
> queue up_default priq(default)
> queue up_quick priority 7 priq
>
> ##Define downstream child queues
> queue dn_default priq(default)
> queue dn_quick priority 7 priq
>
> ### TRANSLATION ###
> #
> #NAT for the external traffic
> #
> nat on $ext_if from $int_if:network to any -> ($ext_if)
>
> #
> #Redirections
> #
> ##Redirect FTP clients to FTP proxy WITHOUT FIREWALL
> rdr pass on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
>
> ### PACKET FILTERING ###
> #
> #Default filter
> #
> block log all
>
> #
> #Loopback interface traffic
> #
> pass quick on lo0 all
>
> #
> #Filter and queue external interface traffic
> #
> ##Deny incoming or outgoing priviliged network address sets
> block in quick on $ext_if from $nets_priv to any
> block out quick on $ext_if from any to $nets_priv
> ##Allow incoming traffic to ftp proxy; keep the state
> pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state
> ##Allow incoming ping request to router; keep the state
> pass in on $ext_if inet proto icmp from any to $ext_if icmp-type 8 code 0
> keep state
> ##Assign upstream traffic to queues; keep the state
> pass out on $ext_if keep state queue(up_default up_quick)
>
> #
> #Filter and queue internal interface traffic
> #
> ##Allow incoming traffic from internal network; do not keep the state
> pass in on $int_if from $int_if:network to any
> ##Assign outgoing traffic from other interfaces to queues for downstream; do
> not keep the state
> pass out on $int_if from any to $int_if:network queue(dn_default dn_quick)
>
> #
> #Deny spoofing
> #
> antispoof for $ext_if
> antispoof for $int_if
> ---pf.conf---
>
> Thank you for your assistance,
> Benjamin
>
> --
> 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
> +++ GMX - die erste Adresse f|r Mail, Message, More +++

--
"Attacks always get better; they never get worse."
  -- "Old NSA saying"

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

knitti
In reply to this post by scatman.b
On 11/7/05, [hidden email] <[hidden email]> wrote:

> ### QUEUEING ###
> #
> #Bandwidth management
> #
> ##Define upstream parent queue (24Kb * 0,95 Overhead)
> altq on $ext_if priq bandwidth 22Kb queue { up_default up_web up_quick }
> ##Define downstream parent queue (256Kb * 0,95 Overhead)
> altq on $int_if priq bandwidth 243Kb queue { dn_default dn_quick }
>
> ##Define upstream child queues
> queue up_default priq(default)
> queue up_quick priority 7 priq
>
> ##Define downstream child queues
> queue dn_default priq(default)
> queue dn_quick priority 7 priq

apart from what chris said, I don't see the point in inbound queuing on
a ADSL line, after all, don't you queue just _after_ the bottleneck (the DSL
link)? so if you want to shape your inbound traffic, shouldn't it be
on the other
side (which you don't control)?


--knitti

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

scatman.b
In reply to this post by scatman.b
Thank you for your reply,

but unfortunally the values and units are right. This also shows in a real
slower webbrowsing capacity, when bandwidth management is enabled.

> altq is looking at kilobits per second and you\'re probably looking at
kiloBytes per second

>
> (237Kb/sec / 8bits/Byte=29KB/sec)
>
> [hidden email] [[hidden email]] wrote:
> > Hi everyone,
> >
> > Problem:
> > Bandwidth management is not working as expected; instead of streaming
> > data inbound with 237 Kb/sec without bandwidth management, it drops to
> > 29 Kb/sec (tendency falling) with enabled bandwidth management
> >
> > Test environment:
> > OpenBSD 3.7 or 3.8 (both tested); Pentium 3 or Athlon XP (both
> > tested), PF, ALTQ, PPPOE-Interface, DSL 2000
> >
> > Guessed fault:
> > ALTQ wasn\'t understood by me?!?
> >
> > Story:
> > I\'m trying to get bandwidth management to work with openbsd for 6
> > weeks now. I read several posts, howtos and manuals.
> > I tried all supported schedulers. To isolate the problem I reduced my
> > original complexity to priq as scheduler. (Afterwards this should
> > change.) The Isolation brought the assumption the problem could be me
> > and my understanding about altq. So I\'m asking you now.
> >
> > pf.conf:
> > ---pf.conf---
> > ### MACROS & TABLES ###
> > #
> > #Define all interfaces
> > #
> > ext_if=\"pppoe0\"
> > int_if=\"pcn0\"
> >
> > #
> > #Define privileged network address sets # nets_priv = \"{ 127.0.0.0/8
> > 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 }\"
> >
> > ### OPTIONS ###
> > #
> > #Default behavior
> > #
> > ##Define default response for block filters set block-policy drop
> > ##Define statistics logging on set loginterface $ext_if
> >
> > ### TRAFFIC NORMALIZATION ###
> > #
> > #Filter traffic for unusual packets
> > #
> > scrub in all
> >
> > ### QUEUEING ###
> > #
> > #Bandwidth management
> > #
> > ##Define upstream parent queue (24Kb * 0,95 Overhead) altq on $ext_if
> > priq bandwidth 22Kb queue { up_default up_web up_quick } ##Define
> > downstream parent queue (256Kb * 0,95 Overhead) altq on $int_if priq
> > bandwidth 243Kb queue { dn_default dn_quick }
> >
> > ##Define upstream child queues
> > queue up_default priq(default)
> > queue up_quick priority 7 priq
> >
> > ##Define downstream child queues
> > queue dn_default priq(default)
> > queue dn_quick priority 7 priq
> >
> > ### TRANSLATION ###
> > #
> > #NAT for the external traffic
> > #
> > nat on $ext_if from $int_if:network to any -> ($ext_if)
> >
> > #
> > #Redirections
> > #
> > ##Redirect FTP clients to FTP proxy WITHOUT FIREWALL rdr pass on
> > $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
> >
> > ### PACKET FILTERING ###
> > #
> > #Default filter
> > #
> > block log all
> >
> > #
> > #Loopback interface traffic
> > #
> > pass quick on lo0 all
> >
> > #
> > #Filter and queue external interface traffic # ##Deny incoming or
> > outgoing priviliged network address sets block in quick on $ext_if
> > from $nets_priv to any block out quick on $ext_if from any to
> > $nets_priv ##Allow incoming traffic to ftp proxy; keep the state pass
> > in on $ext_if inet proto tcp from any to $ext_if user proxy keep state
> > ##Allow incoming ping request to router; keep the state pass in on
> > $ext_if inet proto icmp from any to $ext_if icmp-type 8 code 0 keep
> > state ##Assign upstream traffic to queues; keep the state pass out on
> > $ext_if keep state queue(up_default up_quick)
> >
> > #
> > #Filter and queue internal interface traffic # ##Allow incoming
> > traffic from internal network; do not keep the state pass in on
> > $int_if from $int_if:network to any ##Assign outgoing traffic from
> > other interfaces to queues for downstream; do not keep the state pass
> > out on $int_if from any to $int_if:network queue(dn_default dn_quick)
> >
> > #
> > #Deny spoofing
> > #
> > antispoof for $ext_if
> > antispoof for $int_if
> > ---pf.conf---
> >
> > Thank you for your assistance,
> > Benjamin
> >
> > --
> > 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
> > +++ GMX - die erste Adresse f|r Mail, Message, More +++
>
> --
> \"Attacks always get better; they never get worse.\"
>   -- \"Old NSA saying\"

--
Highspeed-Freiheit. Bei GMX superg|nstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate f|r nur 4,99 Euro/Monat*  http://www.gmx.net/de/go/dsl

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

scatman.b
In reply to this post by scatman.b
Thank you for your reply,

yes, your right so far. For a single user "inbound" bandwidth management
makes no sense. In terms of network management only "real" outbound
bandwidth management makes sense: If the packets still arrived, why throwing
them away?

After all, in my case we have 4 users paying the line and sharing it. So
sharing should be fair. This could be done with some cbq or hfsc "inbound"
bandwidth management (outbound bandwidth management on the internal
interface). But whatever scheduler I use, the result is still the same as in
my example with priq. So reduced example complexity and started asking for
help.

> On 11/7/05, [hidden email] <[hidden email]> wrote:
> > ### QUEUEING ###
> > #
> > #Bandwidth management
> > #
> > ##Define upstream parent queue (24Kb * 0,95 Overhead) altq on $ext_if
> > priq bandwidth 22Kb queue { up_default up_web up_quick } ##Define
> > downstream parent queue (256Kb * 0,95 Overhead) altq on $int_if priq
> > bandwidth 243Kb queue { dn_default dn_quick }
> >
> > ##Define upstream child queues
> > queue up_default priq(default)
> > queue up_quick priority 7 priq
> >
> > ##Define downstream child queues
> > queue dn_default priq(default)
> > queue dn_quick priority 7 priq
>
> apart from what chris said, I don\'t see the point in inbound queuing on a
ADSL line, after all, don\'t you queue just _after_ the bottleneck (the DSL
link)? so if you want to shape your inbound traffic, shouldn\'t it be on the
other side (which you don\'t control)?
>
>
> --knitti

--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f|r GMX Partner: http://www.gmx.net/de/go/partner

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

Lars Hansson
In reply to this post by scatman.b
On Mon, 7 Nov 2005 15:34:38 +0100 (MET)
[hidden email] wrote:

> ### QUEUEING ###
> #
> #Bandwidth management
> #
> ##Define upstream parent queue (24Kb * 0,95 Overhead)
> altq on $ext_if priq bandwidth 22Kb queue { up_default up_web up_quick }

22Kb? That's a bit low, i'd say. This will indirectly slow down your downloads.
Tried making it larger?

---
Lars Hansson

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

Stuart Henderson
In reply to this post by knitti
--On 09 November 2005 02:22 +0100, knitti wrote:

> apart from what chris said, I don't see the point in inbound queuing
> on a ADSL line, after all, don't you queue just _after_ the
> bottleneck (the DSL link)? so if you want to shape your inbound
> traffic, shouldn't it be on the other
> side (which you don't control)?

Ideally, yes, but queuing after the bottleneck still has some effect on
protocols which wait for ACKs (tcp, for example).

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

scatman.b
In reply to this post by scatman.b
Thanks for your reply,

first of all, I'm using a ADSL line with 192 KBit/sec (24 Kb/sec) upstream
and 2048 KBit/sec (256 Kb/sec) downstream (DSL 2000 in Germany).

What I originally wanted to do, was to fairly queue this bandwidth between
four users. So each user will have its assurred bandwidth for up and
downstream, but can borrow whats left.

So I builded a cool configuration using cbq as scheduler. But it resulted in
a throttled downstream as described before (instead of ~237 Kb/sec
downstream, I got ~29 Kb/sec).

So I though it could be something wrong with my understanding of cbq and I
tried hfsc with the same result. So I thought of wrong queue allocation and
looked at it with pfctl, but the right queues where used.

So I started thinking of kernel land, user land problem and switched from
the user land ppp to the kernel land pppoe implementation. No effect.

So I stripped down my configuration to priq with the minimum number of
queues and got the same results.

Now, I'm slowly going crazzy.

> On 11/9/05, Benjamin Heckmann <[hidden email]> wrote:
> > [...] unfortunally the values and units are right. This also shows in
> > a real slower webbrowsing capacity, when bandwidth management is
enabled.
>
> Are you after a much slower capacity then? In my experience, most people
use altq to maximise the utilisation of the bandwidth they get.
> I\'m sure that people are also using it to clamp down on (e.g.
> quarantined or non-paying) users.
>
> What sort of ADSL line are you using? So far, I\'ve never come accross one
that deals with less than 64kbps (a few years ago) or 128 kbps.
> That might explain why you\'re getting lower throughput than expected.
>
> Perhaps you can further specify what goals you are trying to achieve and
with what means you want to achieve them.
>
> Also, not scrubbing your pppoe(4) device to use a lower MTU, may give you
rather long waiting periodes when browsing for some sites.
> Although it deals more with actually getting a connection rather than
connection speed, the following line did wonders for me:
>
> scrub out on $ext_if max-mss 1440
>
> Cheers,
>
> Rogier
>
> --
> If you don\'t know where you\'re going, any road will get you there.

--
Highspeed-Freiheit. Bei GMX superg|nstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate f|r nur 4,99 Euro/Monat*  http://www.gmx.net/de/go/dsl

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

Stuart Henderson
--On 09 November 2005 11:48 +0100, [hidden email] wrote:

> first of all, I'm using a ADSL line with 192 KBit/sec (24 Kb/sec)
> upstream and 2048 KBit/sec (256 Kb/sec) downstream (DSL 2000 in
> Germany).

You confuse Kb and KB. KB = kilobyte, Kb = kilobit.

> What I originally wanted to do, was to fairly queue this bandwidth
> between four users. So each user will have its assurred bandwidth for
> up and downstream, but can borrow whats left.

192Kb/s servicing acks for 2048Kb/s doesn't leave much to spare, you
will have to do this quite carefully. You might find it's better not to
partition users, and just base on protocol (perhaps high-priority for
ssh, NTP, DNS, ACKs, medium-priority for http requests and ftp control
sessions, low-priority for all others).

Just work on upstream for now, and leave the downstream uncontrolled.
You can always add it later when you are more familiar with altq.

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

Lars Hansson
In reply to this post by scatman.b
On Wed, 2005-11-09 at 11:48 +0100, [hidden email] wrote:
> first of all, I'm using a ADSL line with 192 KBit/sec (24 Kb/sec) upstream
> and 2048 KBit/sec (256 Kb/sec) downstream (DSL 2000 in Germany).

That's your problem right there. PF doesnt deal with bytes/sec, only
bits/sec.
Where you have 24 and 256 you should have 192 and 2048.

---
Lars Hansson

Reply | Threaded
Open this post in threaded view
|

Re: ALTQ-Bandwidth management is not working as expected

scatman.b
In reply to this post by scatman.b
Hi everyone,

Closing Problem:
Bandwidth management is not working as expected; instead of streaming data
inbound with 237 Kb/sec without bandwidth management, it drops to 29 Kb/sec
(tendency falling) with enabled bandwidth management.

Fault:
It's a shame, but "Kb" means "Kilobit" and not "Kilobyte". I was so focused
on the handling of the different schedulers, I didn't get this simple
mistake. Sorry!

Solution:
Take your original values from your ADSL provider, e.g. DSL 2000 with 2048
Kb (=> means Kilobits)
downstream and 192 Kb (=> again Kilobits) upstream.

Thanks for your assistance,
Benjamin

--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f|r GMX Partner: http://www.gmx.net/de/go/partner