RC&Q / Rate Limiting

  • 1
  • Question
  • Updated 4 years ago
  • Answered
I'm trying to understand more as how the RC&Q (Rate Control & Queuing) works and the settings of it as it seems a tad confusing to me.

Here are a couple threads that explain it fairly well.
https://community.aerohive.com/aerohive/topics/rate_control_policy_has_no_effect

https://community.aerohive.com/aerohive/topics/restricting_throughput_bandwidth_in_user_profile_poli...

But, based on these two posts, there is no way to set a hard limit to a specified user or a user profile (group of users like a Guest SSID User Profile).  Is that accurate?  As the help file states the following (http://www.aerohive.com/330000/docs/help/english/6.1r2/hm/full/help.htm#config/qos/rateCtrl.htm#Addi...):

  • Aerohive devices enforce rate limiting at all times but apply WRR (weighted round robin) scheduling only when there is contention for network resources. Otherwise, a device simply forwards the traffic it receives up to the amount of bandwidth allowed.
Is this statement incorrect?  Or am I misinterpreting it?


As well it states:

  • You set the maximum rate limits for individual users in a user profile, here on this page.
  • You set the maximum rate limits for entire user profiles in network policies. For Help, see "Network Policies".
These also make it sound like there is the possibility of hard limits on a per user basis as well as an entire user profile...  Again, correct or am I taking it out of context?


Those both lead me to believe that rate limiting is enforced ALL the time, but the WRR only comes into play with contention.  Can someone explain this more clearly for me and anyone else that may be confused by it?  What exactly does the WRR have to do with enforcing rate limiting?  I understood the WRR applied to the types of traffic (Voice, Video, Best Effort, Background, etc.). 


I also do not see anywhere in the Network Policies page where you could set a maximum rate limit for an entire user profile.  Maybe I'm overlooking it, but I cannot seem to find it.


The big "C" seems to be able to do bi-directional rate limiting as per this document. http://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/113682-bdr-limit...

I just skimmed over it and there may be caveats that come into play, but it s

Ruckus seems to do some bi-directional rate limiting as well.  Although they seem to frown on the fact that folks use it for some very good reasoning.  But

https://forums.ruckuswireless.com/ruckuswireless/topics/rate_limiting-b68ri
and
https://forums.ruckuswireless.com/ruckuswireless/topics/effect_of_rate_limiting_on_channel_efficienc...

I'm sure others do this and some may not.


So I guess my end all be all questions is...  Can Aerohive rate limit users and user groups as they seem to state? 


Here is a blog by David Coleman that even recommends doing it to the "Guest WLAN".
http://blogs.aerohive.com/blog/the-wireless-lan-training-blog/how-to-set-up-guest-wlans-101


A rate limit when contention is in the air doesn't really accomplish the goal of rate limiting users so as to not saturate a WAN link.  Which should be done at that point, via the customers firewall device.  But I'd reckon that if you put out a poll for most of the Aerohive VARs, very few would understand how rate limiting works and are pitching it as a selling point when they probably shouldn't be.




Photo of Brian Powers

Brian Powers, Champ

  • 396 Posts
  • 92 Reply Likes

Posted 4 years ago

  • 1
Photo of Sam

Sam

  • 120 Posts
  • 31 Reply Likes
Brian,

We support actual rate limiting as well as contention based limiting. You can set / adjust any number of these values including Entire User Profile limit and per user limit.  

Per user rate-limiting will always be enforced as will the entire user profile rate limit.

Hope that clears this up. 

Within the User Profile, create a new "Rate control & Queueing policy" 




Entire user profile rate limiting can be found within the QOS section of the User Profile:

Photo of Steven Bateman

Steven Bateman

  • 65 Posts
  • 12 Reply Likes
Also, a QoS classifier map must be enabled in order to perform rate-limiting at all. HiveManager on-prem and Online spins up with a classifer map created by default, but not enabled.

While now obvious to me based on the underlying mechanism, this tripped me up for about a week when I was testing this for the first time and wondering why no rate limiting was occurring.
(Edited)
Photo of Larry

Larry

  • 55 Posts
  • 1 Reply Like
Steve - Where is that enabled?
Photo of Sam

Sam

  • 120 Posts
  • 31 Reply Likes
Additional Settings> QoS Settings > Classifier Map [New/Existing]
Photo of Larry

Larry

  • 55 Posts
  • 1 Reply Like
See image below. Does this mean I'm all set?

Photo of Sam

Sam

  • 120 Posts
  • 31 Reply Likes
No - add it here:


(Edited)
Photo of Larry

Larry

  • 55 Posts
  • 1 Reply Like
Great, now I should be able to test it by connecting as guest and trying to download a big file and see if I'm capped there?
Photo of Sam

Sam

  • 120 Posts
  • 31 Reply Likes
Correct.
Photo of Brian Powers

Brian Powers, Champ

  • 396 Posts
  • 92 Reply Likes
So finally getting around to digging into this more, it seems I was incorrect.  I appreciate the knowledge on how the rate limiting works. 

It'd seem as if when doing this testing with something like iperf/jperf, the first second or two is bursted higher than the limit.  This, I believe is what confuses our end users when they are testing the rate limiting with a speedtest app on their iOS device as I assume the same thing is happening in this scenario as well.

On another note, so far it hasnt seemed to matter if I added the QoS classifier map to get the rate limiting to work.  I've been able to get 5.21 Mbits/sec on a 4 MB rate limit (not excluding the bursted data at the start) with the QoS classifier map applied or not.

Thanks again for everyone that chimed in here to give tips/pointers!