QoS/Rate Limit at port issue?

[bchur83]

We have used in the past for example a WS-6-Mini switch as a splitter for an MDU connection with rate limiting on each port. In this example we have a main dish (Bridged or Routed, doesn't matter) connected to our WISP connection coming into the WS6 and then we have lets say 4 customers connected to ports 3-6 and set to QoS/Rate limit them to 10M down/10M up. This works great to limit the speed in general, I run a speedtest to speedtest.net and it shows pretty close to 10/10. The issue comes up when doing other traffic besides just a speedtest, mostly video. The biggest complaint is Netflix will either load a video then buffer out and stop playing, rebuffer and stop, over and over. All of which during this time a speedtest and other traffic works fine, its just the video that stutters.

I have tested WRR/STRICT setting with no change in how it reacts. Normally we rate limit at the dish on a single customer using the Rate Limit Egress from the interfaces of the UBNT radios. We are in the process of moving to a full PPPoE setup with Queues on our core network routers but that is a little ways off for full implementation. It mostly affects video based services that it for some reason limits them to a very low speed that causes constant buffering or it just fails to load the videos. We have even had to go to the point of puting in like a UBNT AirRouter and rate limit on that at each unit but those aren't in production anymore and our options are quickly being limited. Most customers are utilizing standard residential grade routers and most of those don't have any rate limiting options on the WAN port. Is there a different way I should setup the QoS/Rate Limiting on the switch? I want to say in the past when the limits were set on the port page that we didn't have this issue, it wasn't until it was moved to the QoS tab that it seems like it started but that could be coincidence. If somehow it was implemented differently back then?

Any suggestions would be much appreciated.

[Stephen]

Have you tried creating a new qos rule to isolate the video traffic that place's it in the highest priority queue? ( i.e. queue 7)

[bchur83]

I have not yet done any actual QoS rules. I am not sure what the data type exactly is. All we are doing is throttling the port speed. Any ideas what generic video traffic would be set to? We aren't tagging it with and DSCP info so we wouldn't be able to go off that. Not sure if EtherType would be the way to do it and try to figure out the type of traffic? Is there a way to just allow all traffic equally? I don't need to prioritize the Video, just allow it through at normal rate limited speed without dropping packets?

[Stephen]

Well, by default all traffic is going to have the same priority. So if you're experiencing drops like this then it might be best to experiment with some qos rules.
I've had some success with netflix specifically by creating a qos rule based on the Source IP option.
After doing a packet capture, my streams from netflix tend to come from 198.38.122.0/24 ip block.
And if you check here:
https://ipinfo.io/AS2906

You can see that is a valid Netflix Streaming source.

If you are going to try to do it this way you might want to do a capture and see if you can figure out which source you are getting the packets from. It will vary from region to region.

Otherwise, from what I've read online it seems like generic video classification can be difficult when streaming through the browser.
I have some of my own experiments I want to try for this as well so if I find anything else that works better I'll post it here.