NEW IDEAS

[Bill Marquette]

On 9/8/06, Rajkumar S <rajkumars at gmail.com> wrote:
> On 9/8/06, Max Laier <max at love2party.net> wrote:
> > On Thursday 07 September 2006 20:21, KES wrote:
> > > Archie Cobbs <archie at dellroad.org> wrote:
> > > >>KES wrote:
>
> > > >> How about 'ALTQ' node? or may be 'queue' node
> > > >> for packets scheduling
>
> > The problem is, how do you classify your traffic for queueing?  i.e. where
> > and how do you decide whether to put a given packet into queue A or B?
>
> Is it possible to have a netgraph hook for pf also? Some thing like
>
> queue in  on dc0 from 192.168.0.0/24 to 192.168.0.1
>
> Where the packet will be passed to a netgraph node with full state
> information about the TCP stream. If the packet is dropped in netgraph
> then it's as good as a block, other wise it's a pass.

You can just delete the state using a pf ioctl - although that
interface needs to be slightly modified so you can delete an
individual state.

> The idea is to have some sort of userspace processing for things like
> blocking p2p. I can already take packets from ethernet interfaces, but
> getting packets from pf has some advantages like:
>
> Ability to select which packets I want to pass to userspace
> Take advantage of tcp reassembly and state tracking of pf.
>
> The state tracking is important because that can help in identifying
> patters that span multiple packets in userspace easily. The pf
> netgraph node can set tags as well as assign the packet to a
> particular queue, for example slow down kazaa.
>
> I am not sure how much of this is feasible or even desirable, but just
> thinking out loud.

I've had other things to work on, so this has kind of stagnated
(especially seeing as there's no userland tool to make use of it yet),
but take a look at:
http://www.pfsense.org/~billm/patches/billm-expose-queues.patch
which in combination with the ability to update a given state would
allow you to reclassify state entries.  The idea behind it, is to
track the queue assigned in the state entry instead of the rule that
created that state entry (it includes a pfctl hack - and I do mean
hack - to display the queue number assigned to the state).  There are
some obvious flaws in it...but they more or less exist in pf today
(queue 1 is no longer a high priority queue after rule reload, but a
low priority queue...guess what happens to your flow - assuming of
course I actually understand the packet flow through altq enough).

--Bill