Traffic shaping on small network.

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

Traffic shaping on small network.

Paco Esteban
Hi,

I've an ALIX board running 5.6-stable acting as a router/firewall on a
small network.
It does its job perfectly and it's easy to manage. So thanks to all devs
for that.

Some time ago I played a bit with traffic shaping on this box, but
did not have the time to test it properly and left that disabled on
pf.conf
Now I've enbaled it again and, although everything seems to work just
fine, I don't understant what is happening regarding queues

The box has an vr(4) interface connected to a ADSL modem that provides
roughly 14Mbps/910Kbps (down/up) thought pppoe.
I've set up some queues on pppoe0 interface (I use $gw_if in rules).
There are also basically 3 subnets behind this box. One for wired net,
one for wifi net and one I called torrent net which, as you may expect,
has a torrent box handling P2P downloads.

This is my queue definition:

queue q_root on $gw_if bandwidth 850K
  queue q_dns parent q_root bandwidth 50K, min 25K
  queue q_pri parent q_root bandwidth 200K, min 100K
  queue q_dow parent q_root bandwidth 80K, max 210K
  queue q_def parent q_root bandwidth 520K default

And the match rules that apply:

match out on $gw_if inet proto { udp, tcp } from any to <special_servers> port 19302:19309 set queue(q_pri, q_pri) set prio (7,7)
match out on $gw_if inet proto { tcp, udp } from $gw_if to { x.x.x.x, y.y.y.y } port domain set queue q_dns set prio (5,5)
match out on $gw_if inet proto tcp from any to any port { 80, 443 } set queue(q_def, q_pri) set prio (3,6)

match out on $gw_if from $torrent_net nat-to ($gw_if) set queue(q_dow, q_dow) set prio (0,0)

Basically I want google hangouts traffic to be priorized as much as
possible, then  DNS resolutions. Torrent traffic comming from a specific
subnet should work, but at low prio and should never exeed 210Kbps on
the up link. In fact all traffic from this subnet is low prio (that's
why I put the queue "tag" on the nat rule).
Http and https traffic goes to default queue, with ACKs to priority.

Packets are correctly assigned to their respective queues. I can see
counters go up on systat and pfctl -vvsq. All works as expected till here.

The things I don't understand are:

The sum of all sub-queues when I try to saturate the uplink is greater
than the bandwidth defined for "q_root". I see values near 900Kbps or
sometimes near 910Kbps (which is physical limit, not my manually
defined limit).

When I saturate the link with traffic going out on "q_pri", "q_dow" and
"q_def" the only rule that is always applied is the "max 210K" for
"q_def". The other queues seem to share the bandwith in a "best-effort"
manner.

Maybe I'm messing things up ... I don't know.

I can live without traffic shaping here. I can make the network quiet if
I need all the uplink to make a video-call, but I really want to
understand how this works.
After reading pf.conf(5) and Chapter 7 on "The Book of PF" (3rd edition)
I thought I got it, but clearly I did not.

So, any good soul could waste some time trying to explain all this ?

Cheers,

--
Paco Esteban.
GnuPG key: 0x44CA735E

Reply | Threaded
Open this post in threaded view
|

Re: Traffic shaping on small network.

Daniel Melameth
On Wed, Dec 10, 2014 at 4:30 AM, Paco Esteban <[hidden email]> wrote:

> The box has an vr(4) interface connected to a ADSL modem that provides
> roughly 14Mbps/910Kbps (down/up) thought pppoe.
> I've set up some queues on pppoe0 interface (I use $gw_if in rules).
> There are also basically 3 subnets behind this box. One for wired net,
> one for wifi net and one I called torrent net which, as you may expect,
> has a torrent box handling P2P downloads.
>
> This is my queue definition:
>
> queue q_root on $gw_if bandwidth 850K
>   queue q_dns parent q_root bandwidth 50K, min 25K
>   queue q_pri parent q_root bandwidth 200K, min 100K
>   queue q_dow parent q_root bandwidth 80K, max 210K
>   queue q_def parent q_root bandwidth 520K default
>
> And the match rules that apply:
>
> match out on $gw_if inet proto { udp, tcp } from any to <special_servers> port 19302:19309 set queue(q_pri, q_pri) set prio (7,7)
> match out on $gw_if inet proto { tcp, udp } from $gw_if to { x.x.x.x, y.y.y.y } port domain set queue q_dns set prio (5,5)
> match out on $gw_if inet proto tcp from any to any port { 80, 443 } set queue(q_def, q_pri) set prio (3,6)
>
> match out on $gw_if from $torrent_net nat-to ($gw_if) set queue(q_dow, q_dow) set prio (0,0)
>
> Basically I want google hangouts traffic to be priorized as much as
> possible, then  DNS resolutions. Torrent traffic comming from a specific
> subnet should work, but at low prio and should never exeed 210Kbps on
> the up link. In fact all traffic from this subnet is low prio (that's
> why I put the queue "tag" on the nat rule).

Per henning@/http://marc.info/?l=openbsd-misc&m=140127924031145&w=2,
"prio is ignored when bandwidth shaping is on" so this is useless
here.

> Http and https traffic goes to default queue, with ACKs to priority.
>
> Packets are correctly assigned to their respective queues. I can see
> counters go up on systat and pfctl -vvsq. All works as expected till here.
>
> The things I don't understand are:
>
> The sum of all sub-queues when I try to saturate the uplink is greater
> than the bandwidth defined for "q_root". I see values near 900Kbps or
> sometimes near 910Kbps (which is physical limit, not my manually
> defined limit).

Set a max on your root queue.

> When I saturate the link with traffic going out on "q_pri", "q_dow" and
> "q_def" the only rule that is always applied is the "max 210K" for
> "q_def". The other queues seem to share the bandwith in a "best-effort"
> manner.
>
> Maybe I'm messing things up ... I don't know.
>
> I can live without traffic shaping here. I can make the network quiet if
> I need all the uplink to make a video-call, but I really want to
> understand how this works.

Your best bet is to define your bandwidth requirements appropriately
in your queues.  If you need a specific amount of bandwidth for a
quality video call, define an appropriate minimum for the queue.

> After reading pf.conf(5) and Chapter 7 on "The Book of PF" (3rd edition)
> I thought I got it, but clearly I did not.
>
> So, any good soul could waste some time trying to explain all this ?

Reply | Threaded
Open this post in threaded view
|

Re: Traffic shaping on small network.

Paco Esteban
On Wed, 10 Dec 2014, Daniel Melameth wrote:

> On Wed, Dec 10, 2014 at 4:30 AM, Paco Esteban <[hidden email]> wrote:
> > Basically I want google hangouts traffic to be priorized as much as
> > possible, then  DNS resolutions. Torrent traffic comming from a specific
> > subnet should work, but at low prio and should never exeed 210Kbps on
> > the up link. In fact all traffic from this subnet is low prio (that's
> > why I put the queue "tag" on the nat rule).
>
> Per henning@/http://marc.info/?l=openbsd-misc&m=140127924031145&w=2,
> "prio is ignored when bandwidth shaping is on" so this is useless
> here.

Yes, I remember that thread. I posted there too. Just forgot to remove
the prio parts. I just did and tested again. Same results.

It's funny though that prio and hfsc are mixed on "The book of PF"
examples. Even when the techical reviewer is henning@

> > The sum of all sub-queues when I try to saturate the uplink is greater
> > than the bandwidth defined for "q_root". I see values near 900Kbps or
> > sometimes near 910Kbps (which is physical limit, not my manually
> > defined limit).
>
> Set a max on your root queue.

Ok, I'll try. But, again, it is confusing how some examples on both
pf.conf(5) and "The Book of PF" are written.

Cheers,

--
Paco Esteban.
GnuPG key: 0x44CA735E

Reply | Threaded
Open this post in threaded view
|

Re: Traffic shaping on small network.

Paco Esteban
On Wed, 10 Dec 2014, Paco Esteban wrote:

> > Set a max on your root queue.
>
> Ok, I'll try. But, again, it is confusing how some examples on both
> pf.conf(5) and "The Book of PF" are written.

Ok, that was it. I needed to set the max on root queue. Now the numbers
match the queue definitions. I've tried with and without prio and
results are nearly the same as henning@ said on thet other thread.

I'll make some tests with different values to play with it.

So, the way I see it, the max on root queue is mandatory. At least with
small links like upload channel on an ADSL connection.
If you don't set it, it hits the physical limit and no shaping happens at
all. (that is what I was trying to avoid setting the bandwith on root
queue in the first place ... )

Cheers,

--
Paco Esteban.
GnuPG key: 0x44CA735E