i would love it if moto would give us a way to limit PPS also in QOS!
damn filesharing ppl
I’m assuming you have a flat network with bandwidth controlled by the canopy, sadly moto hasn’t really cared about bandwidth shaping. my consumer part of me says thats a good thing. my bussiness side of me says that its only hurting the network. but in any case there may be more solutions out there but i would say the cheapest/easiest (i use the term easy lightly) would be to go with mikrotik as that routing system gives you much much more control over packets and QoS. this is a discussion that i’d like to see
i won’t use those things… WAY to small of control and to high of a failure rate, and entirely to slow… we are using juniper systems for our routing, and we have QoS setup all over the network, problem we run into is all BE traffic is getting killed by Torrents and Filesharing apps we have used some IDP to prevent the traffic, but we are sitting in a lawsuite over that which is retarded… we have also used wireshark and kicked some people off of the network for it but it would simply be nice to have a way to control PPS in the SMs.
we use the SMs to set bandwidth and basic stuff, our JOS does all of the QoS,routing, UTM and IDP yata yata yata
we have a script that runs each night on our sql database to turn off/on or change service for our VoIP and internet services… so for the lack of anything to do on our end other than give an IP address to an SM along with a customers street address in our QB we don’t have to do much network managing as far as settings speeds and such by hand.
Canopy is very good to us in this regard as the bursting controls play a huge factor. We had a situation come up recently where a bunch of people on a tower got into NetFlix really heavily. Of course they were complaining that video was choppy and other customers were complaining that they couldn’t even load web pages! Instead of telling them to go yell at their neighbors I cranked the burst size setting and dropped the sustained rate. Now the AP is less congested overall, normal surfing behaviour gets through no problem, and interestingly because the [u:9psx92x9]lower[/u:9psx92x9] sustained bitrate is more stable than the previous higher one, NetFlix is running more smoothly as it doesn’t have to rebuffer high-rate data or change codecs constantly. On top of this a speedtest shows above-advertised speeds. LOL 
This is on a 900 MHz AP with about 40 subs, mostly 2X links.
Another thing we found quite helpful is implementing transfer quotas. The second people started to become more mindful of how much data they move in a month we saw a lot of congestion disappear. There are a lot of arguments in wired-Internet land against this and I agree with a lot of them, but in wireless world where things like “The equipment is full, there is no higher speed gear, and there is no other frequency to operate on” are a reality, I think it’s inevitable.
As for QoS, I don’t think that traditional stuff like 802.1p CoS and DSCP will work in a Canopy environment very well. When I was evaluating a proper VoIP rollout over Canopy I learned that the radios have two queues. Normally there is just the one; the High-Priority Channel needs to be manually enabled and requires a committed minimum bit rate and a DSCP mapping to be configured properly on every device. This is oriented for supporting VoIP more than anything. So unless your network is set up like this, the QoS you perform at your edge and core is basically meaningless except for some possible minor re-ordering on congested backhauls and switchports. As well, since you are having troubles specifically with BitTorrent, there is no way to set QoS coming up from the customer side unless you attach a device that pokes around in the Layer 4 or Layer 5 region and sets CoS/DSCP on every packet. So no matter what crap a subscriber uploads it is all going to get lumped into a single queue in the radio and jam up the AP.
What I think ATItech is referring to is more of a device that does traffic shaping like a NetEqualizer or box from SandVine (anyone heard of a little cable co. named Comcast before?). These things really help with TCP-based flows as they end up controlling both directions of a connection by holding an ACK for a few extra milliseconds, and force buffering so that rules you set up are always preferred.
All that said a PPS limit would be cool. One way we had of ‘controlling’ bandwidth that actually sort of dealt with P2P file sharing was an unintended behaviour of our crappy old PPPoE aggregator. Because of how it was set up it was limited by its own hardware to only supporting 200 flows per connected subscriber. With stuff like BitTorrent of course this keeps the connected peer count down low, and hence bit- and packet-rates. It wasn’t at all ideal as there were unpleasant side-effects like certain games couldn’t populate server lists properly, and of course if you only connected to 4 peers in BT and one of them had a 100 Mbps connection you’d be downloading pretty fast, but hey for some purposes it was an interesting trade-off.
we actually have done very well with QoS controls in our network, VOiP works verywell even on the 900, video streams are limited to 1mb per stream, but the problem is a user that has opened many connections on filesharing. if you do a link test with 64 bit packets you will see what i mean, a 2.4 AP will do good to break 3 mb agrogate, and a 900 less that 1.5. our QoS configuration is based on the limited bandwidth on an AP, not the PPS. our routers know that this port can only handle x, so it shapes and pauses frames headed for each port to match the flow of the APs so we have extreamly tight control of QoS. we never have an issue with it messing with our customers phone calls, or chopping out video streams (both voice on video have diffrent ToS types that our routers reconize) but the browsing traffic is dscp (ToS) mark as the fileshare, so one or two people can devistate the browsing on the 900s without much effort. the video flow is only give a max commited service flow per port of 2.0 mb for 900 and 7mb for 2.4 (downstream) and 100k upstream for the entire AP. voice gets 512kb both ways on 900 and 1.5 mb for 2.4 the rest is BE, of course when the other services are not used, its all BE traffic. about half of our subs are using our VoIP service and we do have netflix users, but since we have issued limits for these videos streams it helps to keep netflix from flowing at the high bit rates, thus keeping bandwidth more in shape. i’m just looking for a way to stop 1 person from using frost wire from dropping the network without having to use UDP and “filter” there connection which has gotten us into a legal issue with an ex sub. or using wireshark to figureout who is using a protocal that is against our ToS and warn/kick them off of the network.
the old, you can’t have your cake and eat it too… situation i guess 
salad,
what burst and sustained rates do you have set in your 900SM’s because we mainly use 900 on our network and we are running into similar issues you say that you were able to address. Ours are currently set at the default of 20000 and 500000.
Thanks for your input!
Custcomp
For most of our towers we have this set:
2X links:
Down burst: 8000 kbits
Down sustained: 1500 kbps
Up burst: 4000 kbits
Up sustained: 512 kbps
1X links:
Down burst: 4000 kbits
Down sustained: 1024 kbps
Up burst: 2000 kbits
Up sustained: 256 kbps
Problem APs with everyone trying to watch NetFlix:
Down burst: 16000 kbits
Down sustained: 512 kbps
Up burst: 4000 kbits
Up sustained: 256 kbps
A couple of questions for you salad:
1. 8000kbits seems really low. How many kbits are transferred on an average speed test site for download testing? 8000kbits is not quite 1 MB.
2. Do you have to go in and manually edit every QOS screen on every SM attached to the AP, or can you just make the adjustment under the QOS in the AP only? If you DO have to touch each SM, then what is the point of making the QOS edit on the AP side?
Thanks,
custcomp
The 8000 kbit figure (which I pretend is 1 MB because I’m lazy) isn’t designed around specific results on a speedtest, but rather a guesstimate of what I think the size of an average web page is. Note that customers on that profile are sold “up to 1.5/512” service so anything over on a test is a bonus. In that case I’m just trying to get them off the AP faster because of its limited bandwidth.
I’m not sure what the AP QoS settings are for, I think it’s just there to maintain compatibility with the software featurea on SMs since they’re almost identical. These settings I apply through BAM with Prizm. The default bandwidth service paln is that 2X one, with the others being for special cases.