[altq:1747] Re: BSD's diverging?

[Nicolas Christin <nicolas@cs.Virginia.EDU>]

On Wed, 8 Jan 2003, Kenjiro Cho wrote:

> pf/altq in OpenBSD-current is an attempt to separate packet schedulers
> from classifiers.   I have been thinking about this since the early days
> of the altq development.  A nice thing about pf/altq is that pf just
> tags an queue id to the mbuf and altq simply uses the queue id to
> select an queue.

Kenjiro,

Many thanks for your reply. This is very interesting, and I'm really
happy to see this somewhat relates to something I was wishing for in
another thread (see [altq:1737]).

> I'm hoping that a similar method can be applied to FreeBSD and NetBSD.
> FreeBSD has ipfw and NetBSD has pfil as a native packet filter so that
> they can use their own packet filter as a classifier for altq.

There is a port of pfil in FreeBSD-current (5.0). As for ipfw,
discussions that I could see on freebsd-net seemed to indicate some
"problems" with the API. I'm absolutely not sure what those "problems"
are, but the end result is that the FreeBSD guys may rewrite significant
portions of the API when they try to "fix it." Sorry for not being more
precise, this is something I stumbled upon while browsing some archives,
and I did not get more details. Maybe someone else (e.g., Luigi) can
shed some light on this. Regardless, if ALTQ is to use ipfw/ipfw2,
if the ipfw API changes, significant amounts of code may have to be
rewritten.

> Or, it could be easier to port pf to FreeBSD and NetBSD considering
> the amount of work to design different config parsers and interfaces
> with altq.

I whole-heartedly agree with this statement. It's my understanding (from
the manual pages only, since I don't have an OpenBSD system at hand at
the moment) that pf allows for quite a lot of flexibility. From what
I've seen in the CVS trees (and please correct me if I'm wrong), it
also looks like using pf significantly reduces the amount of ALTQ code.
Porting pf to the other BSDs sounds therefore like a good idea, but
given my limited amount of knowledge on the subject at the moment, I
have to say I don't know how much work is involved. Down the road I
would be very happy to help if this is a direction that is considered,
though.

> Another way to look at pf/altq is that it is a version for network
> operators rather than for researchers. pf/altq is a stripped-down
> version and has limited functionality. The OpenBSD people are very
> helpful to make altq/pf ready for non-research people.

IMHO, in a perfect world, that "stripped-down" version would be
perfectly suitable for the base distributions of the BSDs, while the
more researchy branch would be fine for KAME-snap.

Thanks,
-- 
Nick