Quick question about PF and ALTQ

[Girish Venkatachalam]

On 18:49:37 Nov 11, Peter Boosten wrote:
> Thanks for your answer, although that's not quite what I'm looking for:
> 

Okay. Find my answer below.

> I know it's possible to 'shape' the traffic with altq, so it's possible in
> theory to shape certain kind of traffic to almost nihil. Smart devices
> like packetshapers (and even some proxy appliances like Blue Coat) have
> separate categories for streaming media, so I was wondering if PF and altq
> could do the same.

Well I have no idea about appliances or commercial software. 

I can however tell you what I know. I have never tried these things but
I can tell you what I have understood.

First and foremost you can only shape outgoing traffic. You cannot do
QoS with incoming traffic. You might be able to manipulate things a
little but you have far more power when it comes to deciding how you
want others to receive packets from you.

This is the basic idea. You can only do traffic shaping with egress
traffic. Not with ingress traffic.

Now, pf + altq can do very sophisticated traffic shaping.

There are three categories of queuing disciples supported by pf.

a ) class based queuing (cbq)

b ) priority based queuing (priq)

c ) hierarchical fair service curve (hfsc)

Each of these mechanisms have pros and cons and you have to pick one of
them based on your requirements.

The configuration for basic QoS management consists of three steps.

1) The altq statement ( which interface to work on , how much bandwidth
you want to play around with and also the queuing discipline (one of
the above)

2) You have to define the "queue" rules to determine how the total
bandwidth in the above line has to be split amongst the various
categories. Typically they are split into multiple queues based on port
numbers but other possibilities also exist. For instance you will want
to allocate bulk of the bandwidth for important mail traffic and
browsing but you want to restrict p2p and other protocols. It is the
"queue" lines that also determine what to do when there is congestion. 
 (IOW most of the tweaking happens here :)

3) Next step is to use the pf filter rules to allocate which queues to
use for handling which traffic

I shall illustrate with an example. This is not my own. I am taking it
from the pf man page.

  1)  altq on dc0 cbq bandwidth 5Mb queue { std, http, mail, ssh }

  2) queue std bandwidth 10% cbq(default)
     queue http bandwidth 60% priority 2 cbq(borrow red) \
           { employees, developers }
     queue  developers bandwidth 75% cbq(borrow)
     queue  employees bandwidth 15%
     queue mail bandwidth 10% priority 0 cbq(borrow ecn)
     queue ssh bandwidth 20% cbq(borrow) { ssh_interactive, ssh_bulk }
     queue  ssh_interactive bandwidth 50% priority 7 cbq(borrow)
     queue  ssh_bulk bandwidth 50% priority 0 cbq(borrow)

 3)  block return out on dc0 inet all queue std
     pass out on dc0 inet proto tcp from $developerhosts to any port 80
\
           keep state queue developers
     pass out on dc0 inet proto tcp from $employeehosts to any port 80 \
           keep state queue employees
     pass out on dc0 inet proto tcp from any to any port 22 \
           keep state queue(ssh_bulk, ssh_interactive)
     pass out on dc0 inet proto tcp from any to any port 25 \
           keep state queue mail

As you can see the first line is the altq directive. You have defined a
list of queues (std, http, mail, ssh) and also mentioned that you want
to use class based queuing.

Then the queue rules determine how individual queues should share the
bandwidth amongst themselves. But we are not quite done yet.

The most critical step is the filter rules that determine when to queue
traffic and which queue to assign to.

That happens in 3). 

It should be self explanatory.

Please note that we have used "pass out" which corresponds to my main
idea of determining how traffic leaves our network.

Once data arrives on the interface, it is already too late to do QoS
manipulation.

This is not completely true (you can do bandwidth throttling) but at
least relatively speaking this idea appears to be correct.

> 
> Your solution works, however you'll have to know what sites are being
> visited in order to block them entirely.
> 

Hope the above explanation suffices.

Can you clarify your needs a bit more?

Thanks.

Best,
Girish