Re: Interested in {Create an in-kernel API for "packet classes"}

[David Young <dyoung%pobox.com@localhost>]

On Thu, Apr 10, 2008 at 06:12:48PM +0200, Ermal Lu?i wrote:
> On Thu, Apr 10, 2008 at 8:35 AM, Darren Reed <darrenr%netbsd.org@localhost> 
> wrote:
> > Indradip Ghosh wrote:
> >
> > > Hello Mentors,
> > > This is Indradip, a Grad student at University of Texas at Arlington.
> > >  I am interested to work on the project {Create an in-kernel API for
> > > "packet classes"} .
> > > My proposal is as follows:
> > >
> > >
> >  ...
> >
> >  See my comments to Anish's idea...and to summarise...
> >
> >  To validate the project accomplishing a packet class API that is
> > independant
> >  of pf, it needs to be used by another consumer - ipfilter is a good
> > candidate -
> >  to prove that you've got the API right and not just a divided API for pf.
> 
> One thing that i struggle with. Does this mean that you need to modify
> all the drivers to tag/label their packets?!
> 
> Or does it mean resurrecting old ALTQ classifier to have a generic way
> of doing this and extend it to handle 802.11 or other classes?!

A packet filter is the label producer: PF or IP Filter will classify
packets and apply labels.  ALTQ and the network interfaces (PPP,
ethernets, et cetera) are label consumers: they examine the labels, which
help them to decide which traffic category/queue to place the packets in.

Note that ALTQ may be both a consumer and a producer of labels, since
it both classifies and queues.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24