NetEqualizer News Blog

My daughter, a high school teacher, texted me the other day and said she is having trouble with her home video breaking up. This is not a good situation for her and many other remote learning operations around the world.  There are ways to mitigate this issue, but it must be done upstream by her ISP, and so I could not help her directly. I tried calling Comcast to let them know we have a solution, but they did not return my call. Perhaps one of their engineers will read the blog article that follows.

There is a very simple way to make sure video works well all the time, and with the new generation of video controllers this technique is better than ever.  Okay, sorry for sounding like I am promoting a miracle cure, but in essence I am (and have been doing it with success for 17 years now).

The basic technique involves making sure your circuit does not reach 100% percent capacity.  Video is like the proverbial “canary in a coal mine”; it will be the first to suffer and will abruptly stop working when it runs out of bandwidth.

How you should keep your circuit from reaching 100% percent capacity and disrupting video?   There are two important scenarios that you need to consider:

Scenario #1 assumes you have a large non-video consumers of bandwidth that are filling your circuit.  This is a problem that we normally deal with, and the solution is to use a bandwidth controller to limit streams larger than 4 megabits during peak usage.  By doing this you can free up traffic for video, as almost all video, Netflix, etc. use 4 megabits or less.  Remote learning applications use even less, as they generally don’t need the video quality of a high def movie to be useful.

The issue with this method, and one that has come to fruition recently, is a huge influx of video, now that other recreational activities have been put on hold.  Even for ISPs that were ramping up their delivery mechanisms with the normal usage curve, the spike in recent video demand was unexpected, just like the covid-19 virus causing unplanned quarantines and lockdowns.

Scenario #2 is the situation where a majority of your traffic is video, and you may not be able to recover enough bandwidth by limiting larger streams. What do you do now?

Several years ago most video streams were an all or nothing proposition. Either they received the bandwidth they needed or they just stopped.  As the industry has matured so have the video delivery engines. They are much smarter now, and you can now force them to back off gracefully.  Today’s engines will sense the available bandwidth and back off to a lower resolution as needed.

From the perspective of an ISP, you can trick video into backing off  before you have a crisis on your hands. The trick is to progressively limit 4 megabit streams down to 1 or 2 meg.

We can do this quite easily with our bandwidth controller, but for those of you that have a simple rate limiting controller without dynamic intelligence built-in, you might be able to do this manually if you can limit individual connections.  For example, you might have a user with a 50 megabit circuit.  You would not want to limit their entire circuit down to 2 megabits, but you could limit any stream that is pulling over 4 megabits down to 2 megabits, and video will still function and the customer will continue to have access to the 50 meg circuit for other services.  By limiting just “streams” and not the entire circuit you will trick the smart video services to back off on their resolution.

A proactive approach will prevent gridlock on your entire circuit before it happens;  whereas doing nothing will cause what we call a rolling brownout.  This is when everything is fine and  all of a sudden bandwidth across the enterprise maxes out, and you basically blow a circuit breaker.  There is no bandwidth left for the video services or any other application, and thus all users experience failing application for 30 seconds or longer.  In our opinion, this is a totally preventable situation, if you have implemented manual (or intelligent) bandwidth shaping.

If you are experiencing Scenario #2, and would like to discuss how you can implement bandwidth shaping, contact one of our engineers at 303.997.1300 x103 or email us to discuss further.