Is there a way for the router to figure out how much available bandwidth it has automatically, and can I write traffic shaper rules in terms of fractions of available uplink and downlink bandwidth?

Or, is there a sane way of doing the following that I am missing?

Given a network topology with a RouterBoard plugged into a DSL or cable modem on one side, and a bunch of computers and SIP phones on the other, I would like to design automated traffic shaping rules, so that RTP/SIP traffic will have maximum priority.

Basic breakdown of traffic shaping rules I want:
Priority 1 - Routing, ICMP, management connections to the device (dedicated 10KB/sec).
Priority 2 - SIP/RTP (maximum out of the available - 10KB/sec)
Priority 3 - Web browsing (small objects, under 50KB) - 50% of the remaining available bandwidth, burstable to 90% of the remaining available (where remaining available is max bandwidth - 10KB/sec - whatever SIP requires)
Priority 4 - Web browsing (bulk downloads (over 50KB) and e-mail (30% remaining available bandwidth, burtstable to 90% remaining available, as long as web browsing doesn't want it)
Priority 5 - everything else except BitTorrent (20% remaining available bandwidth, burstable to 90% of raining available bandwidth (as long as my access to device, and SIP/RTP, email and web browsing experience doesn't suffer)
Priority 8 - BitTorrent (whatever left, if bandwidth is available)

Generally, I'd need to know the maximum bandwidth available, and based on that come up with the rules. But is there a way to come up with generic rules, that will work no matter how much upload and download bandwidth one gets from the DSL or cable modem?

I currently use the l7 classifier for BitTorrent recipe from here ( http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/L7 ) and bandwidth controls from here ( http://wiki.mikrotik.com/wiki/Bandwith_ ... _ADSL_link )

Thank you.

How I've struggled with this paradox. You wan't to know the bandwidth, so you will either need to generate traffic yourself to measure it (slowing others down), or try to learn it passively from the current traffic.

Passive measurements need a minimum speed, for quiet periods, since you would measure your speed as slower than is actually available. Still, if only one type of network is busy (say a 20% limited part), the total bandwidth is too low for you to detect your connection is actually much faster at the moment, and you would not be able give this available extra speed to your traffic. This is a waste of bandwidth.

Active would be nicer (if you don't pay per MB), but only if we could give it such low priority, any other traffic is prioritized over it. I'm not sure if this is possible, especially in the download (see a bit below), but if anyone knows a method, please let me know!!!

With scripting you could then change your Simple Queue's rates and burst speeds in absolute values that you calculate from your percentages. Question is how quick you need it to respond and if scripts are up to the task

Maybe the approach of working so ridigdly is the problem. If normal Queue priorities worked very well, we would not really need so much regulating; the Voip would always have enough bandwidth for example. But the problem I always found with Simple Queues is that it works fine in uploads, but hardly in downloads if the WAN connection is slower than your internal network (which is nearly always the case).
If we could put a RouterOS in the DataCenter, at the other end of our internet connection... you could route/tunnel between these routers! We would have the same Queues on each router. Your local would work well on your uploads and the one at the DataCenter on uploading to your office, which is the same as your download: both directions priorized.

Perhaps someone has experience with this dual-router scenario?

Cheers,
Niels
niels.bos@live.com