What I’m really trying to determine is how Cambium handles the rate limited traffic, not the high priority traffic.
The CDN and Windows Update traffic issues just keep getting worse. We currently don’t use the radios for rate limiting, we do traffic policing (RED) in the tower router, either Cisco or Mikrotik. Trying to figure out if there’s anything we can do short of Procera/Sandvine/Saisei. Our network topology doesn’t have a nice NOC with a controlled environment with all bandwidth flowing through it. I was thinking if we also implemented QoS at the AP, if it smoothed out the bursts and put some back pressure on the CDNs in the form of increased roundtrip latency, it might help. Mainly interested since they added max burst rate. I think as we have deployed more 450 sectors, it has bitten us in the ass, because a 3M or 6M customer can burst at 50M for a few seconds. Plus the router traffic policing propagates bursts while discarding some packets, and the CDNs and video streams seem to look at that as an invitation to just push more traffic and retry whatever doesn’t get ACK’d. I have a suspicion that we are also seeing Netflix Ultra HD (~1080p) streams now, whereas the highest we used to get was their HD (720p). I saw something that Netflix Ultra HD only worked with a Koby Lake CPU and Edge browser, but so many people are using Smart TVs now, I think streaming on a PC has become irrelevant. So in addition to the Windows 10 Update problem, I’m seeing a lot of 6M customers max’d out with what appears to be a single video stream, while in the past we would see the stream at more like 5M. I think now it just switches on the fly between HD and Ultra HD, to use all available bandwidth. And then the Windows 10 Update traffic which sends 180% of the rate limit, plus people get frustrated and turn off the PC, so it never finishes the download. From: Af [mailto:[email protected]] On Behalf Of Mark Radabaugh Sent: Friday, November 25, 2016 12:30 PM To: [email protected] Subject: Re: [AFMUG] Cambium 450 QoS details? Ken, Not entirely an answer to your question, but hopefully useful. The backstory - I was getting pretty annoyed that our VoIP techs kept claiming that Canopy QOS didn’t work even though I have proven with packet captures a number of times that it does work, so we set up a test lab to see how High Priority and standard traffic rate limits interact. End result was that I was only partially correct and it took a little more tweaking to the configuration than I thought. The Canopy manual is correct - but you have to read the fine print and it’s not all in one place if I recall correctly. Anyway - this i what works for our VoIP customers using QOS with a standard and voice vlan: For All Dual-VLAN (Internet + VoIP) Juniper SRX Deployments: On the SM.... 0. Set "Sustained [Uplink|Downlink] Data Rate" (Kbit/s) based on the customer's service plan (i.e. 6 down / 1.5 up) 1. Set "[Uplink|Downlink] Burst Allocation" (Kbit) to a value equal to "Sustained [Uplink|Downlink] Data Rate" 2. Set "Max Burst [Uplink|Downlink] Data Rate" (Kbit/s) to a value twice that of the "Sustained [Uplink|Downlink] Data Rate" 3. Enable "Hi Priority Channel" 4. Set "Hi Priority [Uplink|Downlink] CIR" to a suitable value. i.e. [(100 * #phones) + 100] (aka 500 Kbit/s for 4 phones) 5. Set "Priority Precedence" "802.p then DiffServ" (either one actually works, but this is belt & suspenders in case the SRX config isn't fully implemented). 6. On the SRX, configure both WAN VLAN interfaces (i.e. internet and phone) with firewall rules to mark traffic as high priority (phone) or low priority (internet) [interfaces -> IFNAME -> UNITNUM -> family inet -> filter] 7. On the SRX, enable rewriting (dscp and 802.1p) on both of the WAN interfaces [class-of-service -> interfaces] This config is valid and tested with 80 Mb/s of simulated upload traffic, 500 Kb/s of simulated VoIP traffic, on an SM with only a 1.5 Mb/s upload cap. No lattency/jitter/packetloss on the simulated VoIP traffic. Only 15-30 ms latency on the internet upload (not bad, considering the SM is forced to discard 95% of the traffic it's getting over the wire). We didn’t analyze the traffic to see how the drops were handled on the SM->AP side. Mark On Nov 25, 2016, at 12:56 PM, Ken Hohhof <[email protected] <mailto:[email protected]> > wrote: I also posted this question on the Cambium Community forum, but maybe this is well known and someone here can answer for me, or point me to the info. How exactly does Cambium 450 QoS work? Does it buffer traffic and shape it to the configured rate, or does it do traffic policing? And if it buffers, what is the buffer size? Is it just a global buffer pool whatever memory is available, or a fixed buffer per SM/LUID? If it does policing (and even shapers have to discard traffic if the buffer overflows), does it discard whole packets (PFIFO instead of BFIFO)?
