MikroTik

Can i ask where in the network does Qos for VOIP, Skype video, etc be applied,
Is is just (1)CPE (2) AP or applied to each router used in the network (1) CPE (2) AP (3) PTP backhaul (4) Internet access router?

Ideally, you should apply QoS policies at all points of your network...

Each node should be configured in such a way that it knows what the maximum bandwidth is, so it can choke other traffic. Also keeping in mind whether or not your link is full-duplex (a lot of wireless links aren't...)

It's been my rule of thumb to only prioritize up to 75% of a link's maximum connection before it stops becoming effective.

There are many situations where this may not be possible due to processor limitations of the routerboard you're using. (Connection tracking and queuing is very intense).

For example:
I have a 54Mbps backhaul, which provides 28Mbps of usable throughput. I configured both sides to have a maximum total limit of 28M, and to prioritize up to 21M of voice traffic.

I have an 11Mbps AP, with an 11Mbps CPE, which provides approximately 4Mbps of usable throughput. I have both sides configured to have a maximum of 4Mbps, and up to 3Mbps of voice traffic.

On the upstream router, there is a 100Mbps connection, which is limited by the upstream provider at 40Mbps.
Here, we set 40Mbps (a separate queue for each direction, because it's a full duplex ethernet connection). And we prioritize up to 30Mbps of voice traffic. The upstream provider doesn't have QoS, but this is "good enough" for internet traffic.

It's necessary on all segments of your network, because it's possible your Point-to-point link will get saturated, and the CPE will have no knowledge of this-- so prioritizing only at the CPE won't do you any good, unless you never over-subscribe.

You cannot control packets coming INTO your network. Think carefully - how can you stop a packet arriving? You cannot! There is no mechanism to tell the sender not to send them. All you can do is delay it, or drop it. But if you delay it, it has still arrived. Therefore you only really have control over what is leaving and the order of those packets, what is delayed, what is not.

So.... if you have a CPE that can control QoS on an outgoing interface which is connected to your network, that is where you are able to control the packets leaving your client site. Once the packets are inside your network, it is too late.

For good QoS inside your network, the only real way is not to have congestion in the first place! In other words, your network should have enough bandwidth that all packets arrive without delay or loss. It is good practice to plan that you never go above 50% of the bandwidth of your internal links. Once you see traffic going over 50% it is time to plan what to do next. Either to stop your clients using so much, or to add more bandwidth. QoS only works by delaying unimportant traffic, thus allowing more important traffic to get through earlier. If you are only using up to 50% of the bandwidth, all the packets are getting through without delay anyway, so QoS is not required in your backbone.

Remember to make use of QoS on all your wireless links and to mangle the traffic correctly so that the two Mikrotik's at each use QoS on the RF link. http://wiki.mikrotik.com/wiki/Manual:WMM

Better still, use nv2 which supports even better QoS options?

Thanks for the replies:

@Nest
Ok If i stay below 50% there is no need of QoS,

@mbeckwell

Ideally, you should apply QoS policies at all points of your network...

Like many other WISP's I now have to provide extra bandwidth for same price, but in offering higher speeds to compete with opposition i want to avoid (or minimize) network congestion.

Should i setup QoS along with a script to dynamically assign download/upload limits?
My thoughts are if possible, it to set limits on those who download during peak hours and encourage them to download off peak?
(1) Effective during peak usage hours (5-11pm), or when the AP is under heavy load?
(2) I would hope to set Clients speed to 7Mbit but during peak hours after downloading for say 15mins reduction is to 3Mbit and after 30mins to 1Mbit, by these step downs i am trying to allow for pc updates as opposed to just downloading large files, OK they could pause and resume and in that scenario further tweaking is required.

I would welcome any advice on this.

For fixed clients with a wireless CPE we apply mangle rules and pcq queues on CPE for the traffic but also use WMM with QoS mangle rules. It works very well.

For fixed clients with a wireless CPE we apply mangle rules and pcq queues on CPE for the traffic but also use WMM with QoS mangle rules. It works very well.

Will the script run on 4.16

what script? It is mangle firewall rules and pcq queue trees.

For fixed clients with a wireless CPE we apply mangle rules and pcq queues on CPE for the traffic but also use WMM with QoS mangle rules. It works very well.

Interesting...

How do you use WMM? The Wiki manual is not very clear to me. I am trying to use WMM on my wirless links but am not sure how to do this. I already use QoS on my border router and my network node to prioritize traffic.

My initial setup would be:
1. Identify the service in mangle by its specific classifier (protocol, port, IP) and give it a conn. mark
2. This conn. mark is used to generate package marks for use in Qos in router.
3. Same conn. mark is used to set priority of package.
4a. Mangle rule with classifier "ingress priority" sets priority again to package? OR,
4b. Mangle rule with classifier "ingress priority" gives that connection a conn. mark for processing by local QoS?
5. Enable WMM on both ends of the wireless link.

Is this a proper setup?
The normal QoS IN the router works fine, but the priority setting of package that are transported over an WMM enabled link is not clear to me. Should I use ´ingress priority´ to set same priority again if the priority stays with that package anyway? Or is the ´ingress priority´ used via mangle and conn. marking only for router's internal queuing process?
What is exactly the relationg between DSCP/TOS setting and priority?

Some MT users only set TOS for certain traffic and use it then in their QoS on each router. Do TOS and priority exist side by side? What happens if both would be used but actually counter effective? (i.e. TOS would give high priority to package while priority of package is set to low?

You cannot control packets coming INTO your network. Think carefully - how can you stop a packet arriving? You cannot! There is no mechanism to tell the sender not to send them. All you can do is delay it, or drop it. But if you delay it, it has still arrived. Therefore you only really have control over what is leaving and the order of those packets, what is delayed, what is not.

I don't believe this is completely true. tcp traffic needs SYN-ACK from remote server. If packages now are dropped by router the requesting host has to send a SYN again untill remote server anwers with a SYN-ACK. Only if this is recieved (not dropped on the incoming chain) client sent ACK to remote server that now upon reciept send the data. Thus, the more tcp traffic is dropped on the incoming interface of the router, the less data remote server will send.
But since it won't work for other protocols like udp etc. you can go from the presumption the incoming interface cannot drop data....

For good QoS inside your network, the only real way is not to have congestion in the first place! In other words, your network should have enough bandwidth that all packets arrive without delay or loss. It is good practice to plan that you never go above 50% of the bandwidth of your internal links. Once you see traffic going over 50% it is time to plan what to do next. Either to stop your clients using so much, or to add more bandwidth. QoS only works by delaying unimportant traffic, thus allowing more important traffic to get through earlier. If you are only using up to 50% of the bandwidth, all the packets are getting through without delay anyway, so QoS is not required in your backbone.

IMHO this is not a realistic working modus. This would mean a backhaul running 54Mbps connection rate while clients are allowed to use 3Mb download (for instance) you can only have (54/2=27, /3=) 9 clients using it? No, oversubscribing is the norm in the industry. Without it networks would be too expensive to run and with proper QoS you can easy have many more users on such a link.
Only very expensive 1:1 lines provide such a contention ratio, which is then actually a waste of capacity since probably 99% of the time the link is not fully utilized. I run serveral links that have 54Mbps connection rate or even less and they serve many tenths of users. In general (90% of the time) traffic doesn't even hit the limits. Only when some heavy downloaders are downloading at the same time the limiting of the Queus jump in and drop packages of these flows so that more important traffic still gets through. Only in times of (near) saturation it is that low important traffic gets dropped. Since this is typically long running donwloads (P2P for instance) most users don't even notice. Only sometimes I get a remark like "my download program reported a bit low download speed last night" and I just reply with "well, it was busy on the network, or the internet as a whole..."

See your network as the regional drinkwater supplier. We all get sufficiant waterpressure and flow from our taps. But if we would all flush our toilet at the same time pressure/flow drops.
If watercompany would have to give all users full flow at all times the main pipes would be of enormous sizes!
The only difference with network traffic is that we can prioritize some data traffic above other. That's the only thing a water company cannot. So basically we can do better (make better use off our network) then a watercompany, electricity company, telephone company, etc.
Any infrastructure is never big enough to handle all theoratical maximum traffic. It is even not desirable because tf would put too much strain on availale resources.

Remember to make use of QoS on all your wireless links and to mangle the traffic correctly so that the two Mikrotik's at each use QoS on the RF link. http://wiki.mikrotik.com/wiki/Manual:WMM

Bear in mind that CPE's are the least powerfull units in the network. Putting too many mangle and Qos on these could actually degrease the performance to such extend you loose more then you gain...

Better still, use nv2 which supports even better QoS options?

I am not familiar with WMM but why could/should nv2 do better? Can you give me an example? I am trying to set both systems up in my network (on different links) but on both systems don't have to much experiance.

Also, on ´N´ links WMM is actually part of the standard (http://www.smallnetbuilder.com/wireless ... s-with-wmm) so if I want to use NV2 on ´N´ links, do you have any idea if WMM is then disabled? Or does WMM and NV2-QoS work side by side?

OK - there is a lot to reply to... so here goes.

I said "You cannot control packets coming INTO your network".
You said "I don't believe this is completely true"

You cannot stop a packet arriving. Therefore if you block it, it must have still arrived. If you keep rejecting these packets, more will come. You cannot control packets coming into your public interface as you have no control over what some other router will send to you. You are right that you can drop or reject and IF the sender chooses to re-send, then yes, of course, the packets will come again. But that is the problem, if you reject, they still come back again!

Therefore if a large amount of packets come into your interface, your interface could become flooded with more packets than your interface speed can handle (or the operating system / CPU can handle). How can you now apply some QoS rule to such an interface that you have no incoming control over?

As you elude, SYN-ACK is for TCP packets. Therefore your suggestion is to respond to it and to reply to possibly ask the other end to re-send. But as you also suggest, this is no good for those protocols not based upon TCP, such as UDP.

So, my original statement still stands. You cannot stop a packet coming into your interface.

You said "Thus, the more tcp traffic is dropped on the incoming interface of the router, the less data remote server will send"
I disagree. if the remote end is attempting to send you data and you drop packets, it will simply keep sending more until they get through to the destination, or until eventually the higher layer system (perhaps some FTP Client) tears down the connection with a timeout. But simply dropping packets or rejecting them, does not in itself stop more packets coming into your edge interface.

Tarpitting is probably better at slowing down the connection as the remote sending end will have to wait for each ACK for a long time, thus slowing down the traffic flow. But it still does not actually "stop" the remote end from sending them to your interface.

Regarding backhaul capacity, you said "IMHO this is not a realistic working modus. This would mean a backhaul running 54Mbps connection rate....." and "Any infrastructure is never big enough to handle all theoratical maximum traffic."

I am not saying that you take all your clients, add up all their theoretical maximum bandwidth speeds, then double that figure for your backhaul capacity figure. You have to look at your actual realtime mean bandwidth levels and if they go over 50% it's time to plan for what to do next as if your mean is running at 50%, your peak will be greater and will potentially affect your QoS. Have look at "Erlang".

You say "Putting too many mangle and Qos on these could actually degrease the performance"
Our CPEs are all 433's or better. They are more than powerful enough to handle the rules we have on them. With plenty of CPU to spare. You do not need many rules anyway. Some simple rules to limit sustained high contention upload speed based on contention-rate, some rules based on protocol to favour one protocol over another. Nothing clever nor too much for the CPU.

Regarding NV2. It has QoS built into the protocol which is why I suggested it may be worth investigating as an option. We have one link running NV2, one AP on the tower and two test clients about 5km away. We are using one HT channel. It is early days, the link has only been running for a week. So far, so good for a link using SIP VOIP and internet data. But, like I said, it is early days and only after a lot of testing will we consider placing the system across all our clients. I have yet to make a lot of phone calls while trying to saturate the link with high levels of data. As they say, one thing at a time. First I am testing the RF environment and interference protection. Next we move to what happens when we move real data over the link.

You say "Putting too many mangle and Qos on these could actually degrease the performance"
Our CPEs are all 433's or better. They are more than powerful enough to handle the rules we have on them. With plenty of CPU to spare. You do not need many rules anyway. Some simple rules to limit sustained high contention upload speed based on contention-rate, some rules based on protocol to favour one protocol over another. Nothing clever nor too much for the CPU.

To date we have only installed for CPE's 411+Ub5 or RB711 with built-in radio card and even at that we do not recover our install costs for a few months, using 433 would further add to the install cost which we cannot pass onto the customer in a competitive market?

Regarding NV2. It has QoS built into the protocol which is why I suggested it may be worth investigating as an option. We have one link running NV2, one AP on the tower and two test clients about 5km away. We are using one HT channel. It is early days, the link has only been running for a week. So far, so good for a link using SIP VOIP and internet data. But, like I said, it is early days and only after a lot of testing will we consider placing the system across all our clients. I have yet to make a lot of phone calls while trying to saturate the link with high levels of data. As they say, one thing at a time. First I am testing the RF environment and interference protection. Next we move to what happens when we move real data over the link.

I have only used NV2 on some of the AP's with mixed results one AP with 23dB antenna works great another AP 16dB antenna used to have daily wireless dropouts and reconnects another AP with 16dB antenna has hourly wireless dropouts and reconnects, On the Ap with daily dropouts i tried different data rates on all of the clients cpe and reduced the NV2 radius down from 30Km and also put in the distance from each client to AP along with other setting adjustments in wireless advanced, this has resulted in a stable NV2 connections, tried the same on the AP with hourly droputs and made no difference had to use 802.11 protocol, and all of my clients use 23dB antenna's, my opinion is NV2 will be great as soon as Mikrotik can time sync the AP's and include the PTP links as well?

Ok, the tcp ack and syn package are not completely understood by me, I am only been thought so by my tutor but it does work for me like I am going to explain:

I have 200+ clients. All their CPE's don't have any speed limit set. Not on the CPE itself nor on the AP. Connection rates are anywhere between 12MB and 56Mb (5Ghz network) but mostly the higher rates.
I do the speed limit for each client in the border router. Each client has a simple queue assigned (for his IP) and here I set his upload and download limit (together with some client level priority and general QoS is also done here).

Let see what happens:
Download: Traffic from the internet the client requested for (a file download for instance). The client basically asks the remote server, "send me file X" and then the server says "ok, here it comes..." The server sends it basically unlimited in speed, unless it has a limiter itself, and then the network infrastructure depicts how fast the data flows toward my network. I am on a high speed 20Mb symmetric line and most servers can produce something like up to 10Mb.
Lets us say that the traffic flow comes in with 5Mb.
In my network now it hits the queue for that client in my border router. Here the queue permits only 1Mb to the client. How? By dropping so many packets that the resulting flow after the queue is no more then 1MB.
Does this now mean that the router is dropping (which happens if a packet is not allowed to proceed, it gets dropped) 4Mb of the traffic flow? No, off course not. Basically if I have a traffic monitor before my border router, on the internet side (which I actually have) it would see 5Mb of data flowing? No.
The tcp protocol works in such that the sending remote server knows this and it drops its speed of sending data to something approximate 1MB.

Same happens on the inside of my network.
My clients are limited in my border router to 256k upload only. But I have many P2P users.
I even filter these P2P connections and give them an even lower speed limit, 128k. in the Qos. A special queue for P2P traffic that is recognized by the router as such kind of connection.

Now, if the client connects to his P2P network and he has ´seeding´ enabled many other users on the internet are going to start to drag traffic from his PC (This is one of the main headaches many WISP have to face).
If the CPE basically is connected with a link that can have up to 10Mb traffic for example (do a MT bandwidth test with tcp packets) then basically the client's PC starts to fulfill the remote demands and starts sending data with the highest possible speed he can produce and he is allowed to. If I would have no queues set, this flow will be 10Mb big! (That's what I see when I run a bw test from his PC towards my border router to test the link. It actually travels over several hubs before it reaches my border router and everywhere we see the 10Mb of traffic flying.. In this scenario the P2P will flood the link between my client and my border router.)
But, luckily we have a queue in the border router that drops his speed to what he has subscribed for to upload, 256kb. AND, P2P I even limit further to 128kb. What do I see now? I see in all routers down the line he is not sending no more then the 128k of P2P traffic and his total upload never reaches more then 256k anyway! So, where is this now arranged?
In the border router!
In the CPE nor on any of the routers down the line anything is done with the flow. So the only place where speed is limited is in the border router. And the CPE knows this thus is sending no more traffic then what he is allowed by the border router. How does he know? By the tcp protocol.

Off course is his PC continuously trying to make new and more connections, both tcp and udp. But his tcp traffic sending will never exceed the limit set by a router far away. Hence the tcp protocol takes care. (Unlimited amounts of udp and tcp connections can be the result, you can separately limit these too.)

If your explanation would be true all traffic shapers in the world would be busy mainly dropping enormous amounts of data. Since you think most connected PC send data limited by their hardware capacity and their infrastructure only. If this would be true the WWW network would collapse soon...

Off course it would still be better to do the shaping for upload on the CPE side. Because udp streams are not controlled in the same way. And since many P2P programs can use udp to transport data as well, this might start to consume all the traffic which then has to be dropped in the shaper at the border router which would make not so much sense anymore.
(But, by allowing tcp P2P traffic most P2P programs don't have the desire to transport over udp, tcp is just much more efficient. Only if tcp would be blocked some programs swap to udp traffic.)

If you have many rb112's and 133C's still running on your network then mangle and queue together with some other task would already mean too much for these boards. Maybe a simple "P2P or No-P2P" setup would work but the more complicated stuff has to be done in the border router anyway.
That's why I basically set nothing in my CPE's.
If you start a new network with all rb411's or 7 series board we talk different, then you can do a lot more in your CPE. But since my network still for 60% runs on these old boards I made the choice to leave the CPE's as much as possible in peace... Some clients have 10Mb assigned as download and 2Mb as upload so these boards already are working hard enough just to get this done over their wireless links..


NV2:
It make several of my rb133C's crash and it slows all 122's and 133C's down a lot. Even without any mangle or Queues. So NV2 is nice, in an environment where only more powerful boards are present. Only then I can also start work with the build in QoS (and/or WMM) and then I need more mangle on the CPE anyway so might as well do some basic (P2P) limiting on the CPE already.

using 433 would further add to the install cost which we cannot pass onto the customer in a competitive market?

Understood - but we are clearly selling to a different type of customer. But I agree with you that if the chosen CPE is not powerful enough, it's not possible for you to do this.

You are clearly using CPEs with insufficient CPU power to control upload speeds. You agree with me that it would be ideal to limit at the CPE and at the incoming router. But your choice of CPE is not the same as ours. We choose a CPE that has the power to do some simple filter rules and limiting. Looking at the CPU graphs for one typical client CPE, I see it averages between 20-25% CPU with 4MB/s sustained for the majority of the time and about 10% CPU when they are quieter at about 2MB/s.

If your explanation would be true all traffic shapers in the world would be busy mainly dropping enormous amounts of data

I have re-read my reply to try to understand why you think I am suggesting this. (I'm not) Where I said the sender will send more packets, I do not mean that the sender will keep on increasing the traffic speed in ever increasing amounts until the whole link is saturated to full capacity and the border router therefore has to drop or reject more and more!
I mean that, if you reject a packet, the TCP protocol will send another packet soon after. In other words, if you reject one, another one comes again. I do not mean that the sender will send more and more and more.

So, the point I have been consistently been stating is that you can't stop a packet arriving at your border router. You are correct that you can control what comes INTO your network. You are also correct that speed limiting your client at the border router works better for TCP and not at all well for UDP, that is why we limit upload speed on the CPE, not the border. We limit the download speed for our clients at the border, not the CPE.

You are clearly using CPEs with insufficient CPU power to control upload speeds.

Our speed contol is done at the AP PPPoE

So, the point I have been consistently been stating is that you can't stop a packet arriving at your border router.

I suggest to read this article. http://wiki.mikrotik.com/wiki/NetworkPr ... of_Service
Maybe you then agree you can limit a stream of tcp packets at the incoming interface of a router.

The conclusion is that a smart setup of a network does not need to have limits on the CPE's.
Which makes sense if you think about it, how would hotspot managment work. It is impossible to set limits for clients laptops if you don't know them! You can only limit their download AND upload in your hotspot router or other routeryou have control off. You don't have control over clients machine sending.......

He's simply stating in different words what that article you linked to says. Here the quote:

Control is Outbound
Inbound traffic for router - traffic that hits routers' interfaces, no matter from what side - Internet or local - it will be received by interface no matter what, even malformed packets, and you cannot do anything with these. Outbound traffic for router - traffic that goes out of routers' interfaces, no matter of direction, to your network or out of it. This is where you can set up queues and prioritize, and limit!

If something sends a packet to you there's nothing you can do about. You can discard it, but only after it has been received by the router and has taken up bandwidth already.

the only reason I see to run thottling at the CPE is because what happens if one CPE is using more than 1 ip? Now your throttling at the border router is much harder.

The benefit to doing qos on the cpe is now you can also setup priorities, etc so as it traverses your part of the wireless network you can provide a 'quality service'.

you just need to use one or the other or both depending on your setup. ive seen isp's bridge over 500 radios, well it works, but it's not the best arrangement. if you want an edge over your competitor you have a very tight setup : )

the only reason I see to run thottling at the CPE is because what happens if one CPE is using more than 1 ip? Now your throttling at the border router is much harder.

The benefit to doing qos on the cpe is now you can also setup priorities, etc so as it traverses your part of the wireless network you can provide a 'quality service'.

That's now exactly what I am doing..
Some of my CPE's have actualy two IP's on the network facing interface. One for all traffic with a general source nat from all connected local IP's to this first dynamically set IP.
The second I set for people that have VOIP of Skype phones. These devices get an IP from the local CPE dhcp server and this IP I now src nat to the second IP.
Now I mangle all connections for this second IP and give it a TOS mark (and I am working on priority setting of package so priority also travels over WMM enable link).
That's all, all other ´throttling´ as you call it is done in my border router.

I only do some extra ´throttling´ on some routers where traffic is actually hitting a bottle neck.
If the theoretical traffic demand from combined clients of an AP is bigger than a link actually is able to transport while my ISP's capacity is also capable of serving more than the link I have to ´throttle´ and prioritize traffic on the interface where packages are leaving onwards to the bottle neck. This is usually only on the side closest to the border router for the download traffic stream (since that is usually more then the upload) but in some occasions on a very poor link I even have to ´throttle´ on the ´closest to client´ side of the bottle neck for the upload stream.

All my 200+ clients are at least connected to 3Mb download and 800k upload and none of the CPE's does do any ´throttling´ apart from the 2nd IP usage. I have never seen any issues because of that in my main router. Clients are limited in the border router and services get QoS here as well.
Even the amount of connections I sometimes see from clients (up to 100's or more) is not really bothering my rb1000. Max. through-puts I have seen so far is about 35Mb to the internet and even then, with 250 simple queues, the cpu hardly ever jumps above 20%.... 4-10% is sort of the standard.

If something sends a packet to you there's nothing you can do about. You can discard it, but only after it has been received by the router and has taken up bandwidth already.

I'm pleased someone finally got it!

But this has been an interesting discussion. Thanks to everyone for their input.

Well I get what's been said but I don't totally agree

For example, I can understand that you cannot choose what packets hit your network, but what you do with them will still have an enormous effect on what bandwidth that is forwarded than if you don't have any QOS. In fact if you don't have any QOS in my experience no network is fast enough because it will consume whatever it can get. If the packet coming in is dropped by the router the other end will time out after a while. Yes it would use a small amount of CPU power and a little bandwidth but not as much as if the packets were allowed to fulfil the request?

Also your forgetting that the shaping router isn't necessarily the destination of the packet. It can be a transparent shaper which is not the packets destination, by dropping the packet the destination address never knows any better?

I get what your saying is technically true, but in the case of QOS and in the case of the posters actual question it's not helpfull and it's not relevant. With a powerful shaping router the CPU is more than capable enough to handle that for the clients behalf. And yes you might have a vey little more network traffic than by limiting at source but the nature of TCP and UDP in most well used applications will back down.

Only malicious traffic in my experience will cause problems. But as you must know there is many other ways to deal with that like tarpit and rate limiting. And if you have a good network you need to have those facilities in any case.

And maybe you are serving customers with 1:1 bandwidth and thats great, but there is more to the market place than just that. And I think Wireless rudy is correct in his ideas about selling to the consumer market shaping and contention is a must.

[quote="nest"]You cannot control packets coming INTO your network. Think carefully - how can you stop a packet arriving? You cannot! There is no mechanism to tell the sender not to send them. All you can do is delay it, or drop it. But if you delay it, it has still arrived. Therefore you only really have control over what is leaving and the order of those packets, what is delayed, what is not.

So.... if you have a CPE that can control QoS on an outgoing interface which is connected to your network, that is where you are able to control the packets leaving your client site. Once the packets are inside your network, it is too late.
....../quote]
Just to clarify are you referring to packets that are arriving from the internet to a network which is obivious you cannot contol,

My questions were to ask if some (?) QoS control can be achieved at the CPE using the RB boards (411+711), i am also aware that caution needs to be used with applying too much QoS at the CPE, as just one poor performance by a CPE cpu overloaded with tasks, can effect the overall performance of the AP and associated clients connected.

It would be great if the wireless connection of the CPE was disconnected if the CPE was maxed out by QoS and then it would not effect the AP only the customer?