[altq:1737] Re: How to limit kazaa 2.0 traffic ?

[Nicolas Christin <nicolas@cs.virginia.edu>]

On Fri, 20 Dec 2002, newbie wrote:

> There is some way - i need something doing content filtering and
> seeking for X-kazaa in the packet header . As far as i know altq
> doesn't do so :-( . Someone correct me if i am wrong .

If you mean application-level packet header, I can't think of any way
altq could do that. The classifier is based on IP source/destination
pairs, protocol number, TCP/UDP source destination ports, and DSCP
(formerly known as the TOS byte.)

> On the other hand it is possible to do various things to kazaa 2.0
> packets with other ways like using a snort program for example . Maybe
> combining snort and altq could do the trick ?

If you can get an external package, such as snort, to write something in
the DSCP depending on whether you have a kazaa packet or not,
then you should be able to use altq's to differentiate between different
DSCP's.

> Question to altq developers: are you going to implement tagging by
> content into altq ?

Personal opinion follows - I can't speak for the official altq
development team (i.e., Kenjiro). I think it would be a bad idea.
I'd much rather stick to the "UNIX way of things": do one thing and do
it well. altq is very good at queue management, but, in my opinion, it
shouldn't be a packet tagger - sure, there is a classifier in altq,
but to me, that's more a helper than something that should really
be in the package - we need it because some of altq's queuing
disciplines are flow-based, but I'd be content if the classifciation
part was done completely externally.

Separating marking and queuing is actually what the IETF
suggests: packet markers are not the same components as packet
schedulers/droppers. This allows for more modularity, and efficiency:
you only tag the packets once, at the entrance of the network, where
you presumably have more CPU time to deal with each individual packet.
The core of the network *can* perform re-marking if need be, but
shouldn't be burdened by running the flow/class mapper over again when
computational resources are scarce.

In short, running content-based marking within altq would seem like
"bloat" to me, and should be left to other primitives which don't do
queuing.

That and $1.10 may get you a cup of coffee.

Best,
-- 
Nick