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

["aswani kumar" <aswani521%gmail.com@localhost>]

Is somebody still working on this project?  I searched for the
webpages of gsoc 2008 but couldnt find any useful information. I am
interested in working on this project.
>
> On Thu, Apr 10, 2008 at 9:09 PM, David Young <dyoung%pobox.com@localhost> 
> wrote:
>>
>> 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.
>
> Oh i thought it as applying some default labels that could be matched
> in firewalls/filterers/classifiers. Like wireless drivers labeling
> their standard priorities and you could match those on the
> filterer/classifier or extracting by default 802.1p classes as labels.
>
> So this is the case of unifying the tagging/labeling way across the kernel.
> As a note, i really would like if it could be done as pf does it with
> strings since it is more natural to be configured. Furthermore, it is
> ready and just needs to be extracted from pf and applied to anything
> else consuming tags.
> The only problem is optimizing the tags zone to have some fast
> matching on strings.
>
> Ermal
>
>>
>>  Dave
>>
>>  --
>>  David Young             OJC Technologies
>>  dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24
>>
>
>



-- 
Nerella, Venkata Aswani Kumar
MS Computer Science