Modifying Ruckus QoS
Posted by on January 24, 2014
Ruckus does an amazing job finding traffic to be QoS’d, and using a suite of tools to make sure that traffic is delivered as quickly and reliably as possible. They do this with what they call Smartcast. Smart cast is a group of features:
•Traffic queuing on a per client basis (voice, video, best-effort, background)
•Automatic (heuristics-based) traffic classification
•802.11e/WMM support
•TOS and 802.1p classification
•Airtime fairness
•Band steering
•Rate limiting
•WLAN prioritization
•Client load balancing
•Power save (UAPSD and Legacy)
•IP multicast-to-unicast conversion
•IGMP snooping
All of these features work together, but in this post I will just modify the settings for ToS markings and manually classify my traffic.
Background:
In wireless QoS there are 4 global hardware queues to place traffic into – voice, video, data and background packets. What happens if one of the wireless clients is sending very slow or having problems it can cause a problem called “Head of line blocking” and will slow everything down from being processed accordingly. Ruckus has helped this by adding 4 software queues for each client! This helps relieve a problem with a misbehaving client and helps get delay sensitive traffic where it needs go. Ruckus also implements Heuristic based classification. This means the look at how the packets are being sent, the gaps and spaces between and classify if its voice/video by preset parameters. But what if you want to know for sure that your data is being put in the right queues — that’s where the below info comes in.
I was working with a client the other day and over some of their private wan links they were having Video issues through Lync. Voice was perfect and the Voice DSCP value was being honored throughout the path. Video was a different story, they were having slight video issues. I know there are many reasons it could be having problems, interference, network issues..etc. I am focusing on wireless QoS though.
We were marking our VOIP/Video packets with DSCP values ef and af41 respectively. Ruckus looks at the ToS value instead of DSCP. I logged into the ZD through CLI and could see what was manually being added to the software queues. See below:
From here you can see the ToS classifications in Hex, and the Heuristics used to detect voice/video/data. I wanted to make 100% sure that my video was in the video queue. So I changed from DSCP af41 Decimal 34 to hex 0x88. To add this I just checked to see what the video was already marked for, and added 0x88 (My DSCP value).
As you can see after adding the 0x88 value to the queue all classifications show up. You could also modify your Heuristic interval from here as well.
Ruckus has lots of documentation on all their greatness and features including some great youtube videos.
More info on Smartcast:
Hi Jeremy, above when you typed “binary 34”, I think you had meant to say, “decimal 34” for AF41.
Thank you! already changed.
You’re welcome! Thanks so much for publishing such useful info on PacketLife. I happened to be needing to tune & confirm QoS in a Ruckus ZD, downstream from a router which I’m using to mark packets and your article helped a great deal.