>>>>> "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.
Description: PGP signature