>>>>> "dm" == Dave McGuire <mcguire%neurotica.com@localhost> writes:
dm> Can anyone tell me if ALTQ works on the sparc64 port?
yes, it works on sparc64 as well as it does anywhere, last I checked
which was a while ago (NetBSD 3.0, FreeBSD 6.2). I can bittorrent and
give away free crappy wireless to neighbors, while still using text
editors over ssh, even on crappy slow american dsl with sub-megabit
upstream. so, ALTQ is doing something.
It does not work very well, though. I'm using HFSC, and I find that
queues ``freeze'', stop scheduling any packets and then quickly reach
their maximum size and start dropping. 'pfctl -Fq ; /etc/rc.d/pf
reload' will unstick them, so i run it every five minutes from cron
and survive that way. The problem exists on alpha and sparc64,
freebsd and netbsd. I don't think there are any commits to the meat
of altq in nearly a decade, just to classifier cruft around it.
The number of HFSC queues it can handle is too small to do any real
link sharing, much less the type of ``microflow policing'' (where there
is, albeit not a queue, at least a policer _per flow_) as cisco 6500
can do. ALTQ HFSC can only do 30 - 60 queues, so here we have two
queues per person in the house plus a couple extra.
It can only queue on physical interfaces. It is impossible to do
receive-side policing as you can do with Linux and Cisco, which is
obviously not proper since it relies on TCP congestion control and
leaving clumpy gaps between downstream packets, but can help a lot
better than nothing for people that don't have a colo to shape their
traffic before it passes over their DSL. It's impossible to do
outbound queueing within an 'upperlimit' envelope on a vlan interface
or a gre tunnel---you can only do it on the physical
interface---however, at least classifier tags are copied during tunnel
encapsulation and from vlan to parent, so you can classify on one
interface and apply altq to another.
And I think ECN is not implemented, but am not sure about that. If
you could get it fully working, ECN would be very meaningful for
bittorrent where according to the 'pfctl -v -sq' stats it's common
with sub-megabit upstream to lose a third or half of packets, even
when using RED and increasing queue size 10 - 100x until it does not
fill.
finally peecee routers in general are only suited for very small jobs,
especially with ALTQ running because it stamps on any interrupt
coalescing which is the only way peecees can handle high throughput.
I use it just for DSL. but I think you will not get, like 100mbit
through it, even of big packets. This is too bad because I think QoS
has potential usefulness in DDoS mitigation (ex CoPP on Cisco), but in
practice I find that I can filter DDoS, yes, but I cannot classify it
into harmlessness. It is more analagous to the process-switched
CBQ-style QoS in Cisco, not the hardware CoS-map QoS where there are 4
or 8 queues inside each interface asic. I don't think it could work
for shaping a gigabit of traffic, for example, if you wanted to make
sure that it was evenly divided among customers during congested
times.
Another two poitns that I never fully looked into. At least
in PF, classifying on diffserv CP is not available. The PF classifier
does give access to those bits, but presumes you want to treat those
bits as TOS and does some weird bitwise arithmetic on them, instead of
checking for simple equality. A diffserv architecture including token
bucket policers (not just classifiers!) to set the bits, and
classifiers to match the bits for equality, doesn't exist. in this
area common practice, much less RFCs, have unfortunately left ALTQ
behind.
second, back to realistic ``make my DSL not suck'' applications of
ALTQ....What's really needed IMHO, is a way to accept an incoming flow
as ``don't know the real class yet'' class and make a 'keep state' row
for it, then keep looking at TOS on only the outgoing packets in the
flow, and if you ever see one with TOS lowdelay (in the old mask/or
bitwise style, not in the new simple-equality diffserv style), move
this flow into a different 'keep state' in which everything is
interactive class. Through this mechanism the PF statefulness would
associate the upstream TOS marks with downstream classification
decision. The goal here would be to separate ssh with a tty
allocated, from ssh scp or pipe ssh. Already ssh kindly marks
lowdelay TOS on flows where it's allocated a tty, but TOS does not
make it through the internet---each autonomous system is
allowed/expected to police flows and mark/rewrite DSCP bits for their
own internal use, and they are already doing this---so you need to
look at TOS on the packets flowing up from your site ONLY, and ssh
cannot start marking those packets until it does all the crypto and
realizes from in-band data that the session has a tty. At that point,
PF has already locked down your 'keep state'. so we are far from
being able to do this with present tools.
Attachment:
pgpT053kPl3Wi.pgp
Description: PGP signature