This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Would You Automate QoS Policy Based On Real-Time Flow Data?

FormerMember
FormerMember

Following up my query about how folks are making the most of their flow data, I’m also curious about what automated tasks people are performing as reactions to flow data, if any. This question is rooted in the reading & writing I’ve been doing about software defined networking.

For example, let’s say there’s a 10Mbps WAN link we use for voice as well as data that a monitoring station is getting flow data from. In a statically defined network (i.e. the way we do things today), we’ve probably built a QoS policy for that link based on expected peak call volume, but the key is that the interface definition is static. We make our best guess as to how to provision the interface based on traffic mix history and expected future trends.

But, what if the QoS policy was flexible based on current demand the flow data is telling us about? The idea is that the flow data gets exported to a controller that can reprovision the QoS policy of the WAN interface on the fly. More calls coming through? Beef up the low-latency queue. Fewer calls? Re-allocate queues to other flows. I recognize that there are products that can do this, although I think of them as service provider tools than enterprise tools for the most part.

The question then is this: does running a network this way - where real-time flow data could change the overall traffic policy of a network – sound like the best thing ever, or more like a miserable pain in the backside you’d get sick of troubleshooting? I know networking vendors want to take our networks to this software defined panacea in a thousand different ways, so it’s an interesting point to discuss.

  • Sounds like a pain to me.

    As I have said before, I would rather make changes manually, although a semi-auto macro standing by would not seem to be a bad idea.  I would not mind a system to advise as to the best option at the time, perhaps showing the affects of the change(s) once made.  But when it comes to actually making that move/change, I want a non-Skynet employee in control. emoticons_mischief.png

  • This could be good, but I would still want a base configuration in place to be able to switch the flip and go back to in case of issues.

    Having presets programmed in and adjusted specifically based on current traffic analysis would be better than giving the reins to your robotic arm.

    Let's hope the programmer programmed left as left.

  • I'm with , sounds like a nightmare to support. Advice is a great idea, but don't automate changing the stuff I have to support.

  • It could be useful - I think the ability to turn it 'up and down' in degrees would be essential, however. I like cahunt's idea of presets. If one could build the presets intelligently with knowledge of environment in mind, then you could automate that piece without fear of cybernetic overlord syndrome.

  • In my opinion, this is why we use monitoring and alerting tools. Alert based on what ever the thresholds are and make the changes manually.

    Dynamic management can be dangerous and unpredictable. Just ask the geniuses that implemented the auto-traders for the stock market.

  • Simply no. Your network confiugration should be very intentional. Having it change automatically is asking for trouble.

  • I can see both sides of this. With today's dynamically changing network traffic I can see doing some automation to adjust Policy based on flow data but I also agree this could be very dangerous, unpredictable and, more importantly, difficult to troubleshoot. Forecasting traffic patterns would be even better. Alerting on flow data thresholds then modeling and forecasting this data would be more help than the automation. Even use of ToD/wk/month in your Policy (if available in equipment used) based on these models would better server the support community. I think donpepe said it best,

    Simply no. Your network confiugration should be very intentional. Having it change automatically is asking for trouble.

  • Agreed 100%. I like the idea of having hints from an automated analysis of flow data telling me "Hey ! you could give some more here and a little less here based on the current demands." But full blown automation ? I don't like it at all.

  • I think dynamic routing protocols are akin to 'automatic' changes based on distance vectors, link states, etc...so maybe all automation isn't bad.

  • FormerMember
    0 FormerMember

    QoS policies can be flexible in that way.  A voice policy can be a priority queue for peak call volume but that doesn't mean other classes can't use bandwidth from the voice policy if available.   The QoS implementation on the router, for example, is already looking at the traffic and managing it dynamically based on your rules.  Making dynamic changes to network device configurations would never fly with our change management policies.  If your QoS config is changing and problems come up how would you ever know what the configuration was at the time of the problem?  Depending how frequently changes are made you could bring real-time change detection applications to their knees and possibly the network device too.  In environments like ours where QoS markings are set as close as possible to the source of the traffic, you're talking about potentially changing thousands of interface configurations on the fly.  No thanks.

    I'd rather let the QoS mechanisms on the device do their thing and have a traffic monitoring tool that presents me information on the traffic and my QoS policy performance.  Information like really good base lining for each metric/KPI, alerts when thresholds are reached and the duration, granular detail that is retained for as long as I want, baselines per polling/collection interval(not the entire 8 hours of my chart).