StifleR Active Bandwidth Management Philosophy | 2pint Knowledge Base

StifleR Active Bandwidth Management Philosophy

The 2Pint Team behind StifleR have, in the past, been involved with the development of other bandwidth management solutions. They could see that these old solutions are not able to make use of the latest network technologies and infrastructure. This inspired them to go out and create a product designed to maximize the value of existing native infrastructure and meet customers updated requirements.

After talking to our customers and beta testers it was clear that the old methodology, like measuring latency every x milliseconds or doing packet inspection analysis, did not actually help a lot of customers overcome the issues that they were trying to solve. Typical scenarios involved solutions that were designed to avoid using more bandwidth or pushing the latency over a certain level, regardless of whether the connection was actually in use or under stress.

At first, this sounded crazy, but after many discussions we started to see the logic behind these customers needs. If a link was being measured during an active period and a content transfer was being made but no other traffic was there, that bandwidth would not be available as it would still be interpreted as rogue traffic and the Network Operations Centers (NOC) would detect this and start making calls. The argument that it was just using “free” bandwidth and not interfering with business data did not fly well in these scenarios.

So in order to avoid the NOC calls, customers had to set their download software to use just 20% of available bandwidth during the daytime, just to avoid having too many calls to deal with. But even with the setting so low, there were still times where the network team were requireing them to completely halt all transfers.

The best way to describe this would be to try to argue with the police that there are no other cars on the streets so therefore you should be able to drive as fast as you would like! Some cops might agree with you, but most wouldn’t. We found this to be the same with most large organizations dealing with overly concerned Network Operations Centers (NOC’s). The terms “unused bandwidth” and “predictive bandwidth analysis” did not fly well with those trying to protect the network.

We therefore took the decision to use a more efficient handling method that dealt with this type of scenario in a better way. Our goals were as follows: -

  • Less to-the-second reactive bandwidth management i.e. don’t back off lower than the percentage with which you are given to work

  • More tactical bandwidth management, i.e. make it easy to tune on the fly.

  • Visualize and report on the download data – In real time.

  • Use machine learning to automate scheduling tasks and predict requirements.

This is this philosophy that we started with several years ago, that has guided our goals so far and are things that still hold true to this day.

Happy Caching!