--pgp-sign-Multipart_Tue_Sep_27_09:02:33_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "tes" == Thomas E Spanjaard <tgen@netphreax.net> writes:
>>>>> "cz" == Christos Zoulas <christos@astron.com> writes:

    cz> Currently altq can be used without a packet filter. Is it
    cz> desirable to keep that functionality?

I found the built-in classifier almost impossible to use.  The syntax
is brittle, and I couldn't understand from the documentation how rules
overlap and supercede each other.  I had to do everything by
trial-and-error which is hard when ``matches this rule'' means ``gets
75kbit/s rather than 50kbit/s''.  I made a lot of mistakes, and it was
months before I got my five-interface ruleset mostly cleaned up.
What's more, the code is orphaned, so if you keep it, you own it.

If people speak up who want to keep it, I hope they will be people who
have actually used this ugly, useless classifier, not just those
who've thought about it in an abstract way.

   tes> other ALTQ specifics (enabling, interfaces, etc). altq.conf
   tes> and altqd (or as you named it, altqctl) should only exist as
   tes> an ALTQ-only solution, i.e. when not using either ipf nor pf.

Keep in mind that in over two years no one has written any of the code
rototilling ALTQ as you suggest, least of all those blocking the
import of OpenBSD/FreeBSD ALTQ.  If you manage to redo all this, who
will maintain it, or will it bitrot like the ALTQ we have right now?

I think if you're going to diverge to the point of unmaintainability
from what FreeBSD and OpenBSD has, you need two things: (1) a good
reason for doing so, and (2) enough developer interest to keep your
ALTQ equal/ahead of the OpenBSD/FreeBSD one.  You need both things,
not just one or the other.  

Given the history of this problem, I think it couldn't be clearer that
we don't have (2).  We do have Peter Postma and some others before him
who've ported PF/ALTQ and produced something stable, but someone
interested in rototilling ALTQ _who is also interested in DOING it and
MAINTAINING it_, we clearly don't have.

I believe we also don't have (1)---if you actually take a look at the
PF/ALTQ API for enabling interfaces and loading queues, you will find
that it's a totally reasonable, well-defined, even impressive API that
can load and set things atomically using the PF ``ticket'' system, and
although it may share code with PF it operates entirely independently
of the PF firewall, and can be enabled and disabled independently of
PF.  I think it's important to distinguish between rewriting something
because it contains pieces of PF code that you want to eliminate for
some political reason, which I would call ``purging'' not separating.
And actual separation, where you want to use ALTQ without being forced
to use PF.  The PF firewall is already functionally separate from
ALTQ, even though they share some code, and I think the code sharing
is desireable rather than a problem, to the extent the API is as good
as something we designed ourselves, which it certainly is.

--pgp-sign-Multipart_Tue_Sep_27_09:02:33_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQzlC9InCBbTaW/4dAQIBUAP/UvFqAic3+wkl4pOJ2gNxQxHuJ4Oh9UxV
fGayndtbnW+eRclNlCMjxwUA1zE9WtpwZiLY0mabEcv+4nzxH7FfzAKt4CEYKqXc
EZKoPnlzcz5jTLAZRzLiCaLxXJIWYtcVox3fojCohO+ZxZVjIE6SPpCW2QP3zZhI
zIUcA8OGsmw=
=sBPc
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Sep_27_09:02:33_2005-1--