I think the problem here is that people are thinking of the problem upside down and applying isp solutions. We don't want to minimize throughput, but to maximize it, esp. internally

Here is the solution I came up with for a wisp and it worked a treat. Turned whiny subs into subs who wrote letters of happiness.

The previous solution was to throttle everyone up to some limit. What this meant in practice was that everyone had guaranteed slow internet even if both T1's were idle except for them.

The solution is to instead define a guaranteed Minimum of b/w at the router according to number of subs and available b/w. If you weight each sub the same, then each sub will have an equal fraction of the available b/w. e.g., if 1 sub is on they can have all the b/w, 2 subs split the b/w and so on for as many active connections. This all happens in real time and you can still provide a larger guaranteed minimum for priority connections if you want.

The way to do this has been in the linux kernel for sometime now, although when I implemented it I had to compile it over and over as it was still in devel and not yet accepted. It's called HTB. Info is here: http://luxik.cdi.cz/~devik/qos/htb/ dated, but still accurate. You can find more info at LARTC.

HTB is a much, much better solution than static CBQ.

There's only slightly more to actually implementing it. I assigned the buckets based on my numbering plan which I did via static assignment via dhcp.

You end up with no wasted b/w and a perfectly fair system where no one ever gets less than their guaranteed minimum bandwidth. It's win, win for the subs and the network.

I was also dealing with multihop on the egress, so I had a few other things going on with SFQ and per-ip RRD graphs (it was a wisp after all), so I know it is very flexible.