Managing the Robot Overlords of SDN

There’s a new Battlebots show on ABC. (And doesn’t it speak volumes that it’s in primetime on a major network instead of on basic cable? Geeks: Co-opting your culture since 1984.)

What’s interesting is that it’s very clear these robots have been greatly improved over the old ones on TV from 2000-2002. It’s not just that technology gets better, but that engineers try and learn what works and what doesn’t with each iteration and test. When older designs go up against newer ones, the result is like silverware in a microwave: sparks and a whole lot of pain. 

Which brings me to machine learning, one of the key benefits of moving to software defined networks. One of the things that happens when you start abstracting former hardware into software is that it can be iterated and evaluated via computing’s ability to do “very fast, very dumb math.” 

We’ve come a long way since Robert Metcalfe started to propose the Ethernet standard, but each network improvement has relied on a combination of hardware improvements and iteration more or less by hand. With SDN, being able to constantly measure, analyze and model and then automatically use the configuration that bears the best result is, in many ways, a game changer.   

That is, ironically, if humans can adapt to machines learning to adapt. As John Villasenor mentions in an article for Network Computing, “People love to say, ‘Yes, I want to leverage the power of machines,’ yet many are afraid to let go of their old workflow habits.” 

Villasenor uses the example of YouTube’s auto-caption system as an example of the practicality of machine learning. I’m not sure that it’s the best idea, considering just how inaccurate those captions are. But each YouTube caption has helped Google’s overall infrastructure to better understand the human voice and apply those learnings to more accurate searches via voice on Android phones and better Google Translations, for instance. 

His main point is that many of the caption translations are good enough. They help people find what they are looking for, and most can understand what the translation is trying to convey even if it is not 100% accurate. It’s the people who get hung up on accuracy who aren’t adapting, as he states: 

“Those stuck in old workflows will measure all of the mistyped and incorrectly translated speech-to-text in the transcript, and snidely claim that there’s too much noise to rely on this approach. I call this silliness.” 

In the case of SDN, network engineers must adapt their workflows, but they have good reason at this point not to completely trust the actions controllers are automatically taking. The methods operators have traditionally used to manage networks do not work well with SDN, making them lose visibility and control. As Packet Design CTO Cengiz Alaettinoglu has asked: “If applications and services are being rolled out without operator intervention and adequate visibility, how do you plan for them? Who or what governs whether or not these programmatic changes should be made? How do you know the network can support a new request without negatively impacting existing applications? 

The ability to answer these questions – a must if SDN is to become a widespread technology – of course lies in machine learning; fighting fire with fire if you will. We must automate many of today’s management practices, making use of the “big data” that machines can parse but no human would have the time to understand. 

This is what we are developing with our upcoming SDN Service Assurance platform, which will take our real-time and historical network routing models, traffic matrices and performance analytics to facilitate intelligent, real-time orchestration by SDN controllers. In addition, it will enable network engineers to effectively monitor overlay networks and dynamic SDN applications. The platform determines in real time whether or not application requests for network resources can and should be satisfied, and how. 

For example, the platform’s traffic matrices predict network load based on historical patterns and are used to calculate how best to provision new bandwidth requests. Additionally, it determines the impact that requested changes will have on existing services by calculating the resulting network topology, traffic behavior and performance.  

Once the management issues are addressed, the role of the network engineer will be less about making adjustments to the network and more about finding where adjustments can improve performance – and letting computers do the brute-force math to find the best ones. That may be an uncomfortable transition for some, because not only do we have to trust the computers, but we also have to accept that SDN will radically change the nature of the job. But if the computer can learn to adapt – so can we. As we begin to obtain and use the right analytics for management purposes, I for one welcome our SDN robot overlords.