- SDN applications are not exciting to enterprises and aren’t generating much interest.
- SDN applications that drastically improve operations and application performance are a vendors’ ticket to success.
We know that network congestion impacts application performance. The physical network matters because bottlenecks in the physical network will impact overlay networks regardless of what some folks at VMware want you to believe. We also know that some applications have more stringent demands than others. Real-time media such as IM, voice, and video are affected more by long delay and delay variability (jitter) than lack of capacity. Audio and video CODECs can adjust for some degradation based on network conditions, but let’s face it, those adjustments are a precursor to unrecoverable poor quality. We also know that other applications are more tolerant towards delay and jitter like email or HTTP.
IT can define service level agreements (SLAs) to establish the parameters for acceptable application performance based on knowledge of how applications behave; based on business logic…or anything, really. The difficulty is ensuring that SLAs are met in the face of network competition and congestion. The network can mark packets with priority bits, but that really only delays if, and when, the application’s flow of packets degrades. High priority applications degrade later while lower priority applications degrade sooner but all application packet flows degrade when congestion gets bad enough.
There has to be a better way.
How about this? A network application that monitors network health and takes into account metrics like link utilization, switch queue depths, application flow delay, variation in delay, packet loss and so on, and then maps that data onto a physical topology. Then, when an application is at risk of falling out of its SLA, the network is empowered to move flows around the topology so that the demands of all applications can be satisfied. Applications that are time sensitive like live media go the most consistent and shortest path between peers while bulk traffic is routed out of the way onto longer paths. When that traffic moves, anything that depends on the traffic flows like application performance or security monitoring has to move with it. If network conditions mean that SLAs can’t be met, then alert someone to that fact. Given this kind of application, server workloads can either be allocated additional resources (if available) or moved to hypervisors that have adequate CPU, RAM, storage, and network capacity.
Now that is an interesting SDN application that could vastly improve data center operations and application performance. Sure, it would be a complicated system to design, but certainly within current capabilities and the industries extensive knowledge of traffic engineering. Enterprise IT would love it, and isn’t that why they are paying you great gobs of money in the first place?
One thought on “The SDN Application I Want to See”
Very good post, Mike. You are right on. The same thinking needs to be applied outside the data center, in the WAN. This is what we are working on at Packet Design.