11:35 AM
Connect Directly
Repost This

Should Applications Listen To The Network?

One goal of SDN is to make the network more responsive to application needs. But applications also have to be responsive to the state of the network.

For the entirety of its existence, the network has functioned just like a utility company: a service available for all manner of useful functions. It has almost no visibility for developers and the applications they write to use the network.

Now, the call is going out to make the network responsive to application needs. We have to create harmony between two things that, until now, have been almost entirely ignorant of each other. But if the network becomes more responsive to applications, applications also have to give something back to the network.

QoS was one attempt to make the network more flexible based on different application requirements, such as voice. Not that the network engineers got it right the first time; it took priority queuing, weighted fair queuing, class-based weighted fair queuing and finally low-latency queuing to capture the characteristics of voice traffic.

It might have been much simpler in the beginning if the voice stream could have told the network, "I need to have some guaranteed bandwidth to make sure my packets get to their destination in the right order. But I don't need all the bandwidth on the link."

Now, the promise of SDN says that the network can respond to application demands. Apps can ask for things and the network can be reconfigured to provide resources as needed. That's a powerful tool for developers. It's like teaching children to ask for things instead of them shyly hoping that they'll be given something.

There's a lot of talk about the transformation of the data center via software, but what's real and what's hype? Get some perspective in "Software Defined Data Center: Marketing or Meaty?."]

The ability to affect your operating environment is huge for developers who want to ensure availability and performance. But that ability comes with some responsibility.

For example, applications need visibility into network conditions to be able to request resources. Those same applications also need to be able to listen to network conditions and respond accordingly when those resources aren't available.

Think of it like a GPS in your car that has a real-time feed for local traffic conditions. If a particular link is blocked, the network should be able to make that condition known to the application and suggest alternate links. One might be high speed but carry a higher cost. This would be critical for real-time traffic processing. The other option may be slower but less expensive. For bulk data this would be ideal. Traffic can be processed appropriately as needed based on network conditions.

You're probably saying, "That's silly. Why not just make the decision for the application? Why provide feedback at all?" That's a good point. Think about the first generation GPS units that did automatic traffic rerouting based on conditions. You might get offered a strange surface street route to your destination instead of getting a toll road that would cost you something but get you there much faster. Would you ask your GPS why it chose that particular route? What if you have a pocket full of quarters and couldn't be late that day? Normally, you'd love the surface street option. However, conditions change and default choices need to be reexamined.

Making the choice is easy. We've built enough intelligence into the network to rapidly decide which route is best based on a number of conditions. What's important in the new network is offering the application a choice based on data that the network can provide.

If we can reconfigure on the fly and tag packets to choose certain links, whether it be through a tunnel to an exit point or a hop-by-hop tag protocol, then we should offer that choice to the application developers.

Why spend our time making the network do all the heavy lifting? Let the application make the decision before the first packet is sent. The network should just respond to the chosen information provided at a higher level and send the packet to the selected destination.

Again, QoS is a good example. It can only make packet decisions based on a small amount of information, like source IP or destination port. Some vendors have implemented advanced matching, such as Cisco's NBAR, but those are not universal by any means and don't track from device to device. To be really useful, QoS needs a big-picture view.

It will take some work to ensure that the applications don't take advantage of their influence. A set of policies can be enacted to discard application criteria when they are outside of a baseline or a threshold. For instance, maybe the satellite link is only for priority traffic in the event of an outage. Even if an application requests that link, a lower-order rule can prevent that traffic from transiting a given link.

Triggers can also be built in along the way to send notifications to stakeholders when developers get greedy and send their traffic along expensive or priority links. This can prevent sticker shock later on when a developer unknowingly prioritizes an expensive link for non-critical traffic. Those are the kinds of safeguards that the bean counters love.

The network and the application can no longer exist in separate black boxes. At the same time, these two need to learn to get along with each other and work together to make life easier on everyone. We've spent most of our lives trying to make the network listen. Now it's time to make the applications do the same.

What do you think? Should applications be responsive to the network? Or should the network stay quiet and make all the decisions absent of application input?

Are you gearing up to bring QoS to your network, or do you want a deeper understanding of how best to configure it? Check out Ethan Banks' workshop, "How To Set Up Network QoS for Voice, Video & Data" at Interop New York this October.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
8/29/2013 | 9:24:55 PM
re: Should Applications Listen To The Network?
Hi Tom - great topic and article. My PoV is that applications should indeed be able to state what they need, and ideally this is stated in very simple semantics that all types of infrastructure can understand (what we @ Plexxi call Affinity). Ultimately the network has finite resources, so the physical infrastructure needs to have an entity that has a global view of all the resources and needs to be able to decide what it can allocate to what applications based on what's asked and what's available and some knowledge of how to resolve conflicts. This is the ideal role of an SDN controller. Taking the next steps to give feedback to the app and have it make more fine grained decisions might be overkill and would certainly require a lot of extra application logic for potentially little gain. Maybe at some point, we'll have application <-> infrastructure brokers where this logic can be implemented, but still the primitives of applications being able to state what they need and the infrastructure being able to understand that need to be in place first.
User Rank: Apprentice
8/29/2013 | 6:45:26 PM
re: Should Applications Listen To The Network?
Hey Tom, really great posts.

This is certainly going to be among the most interesting areas to watch over the next few years. I think we all will grow more comfortable with what approaches work best as more experimentation is done in this area, but there is tremendous promise.

Some key use cases for me include QoS as we try to increase the average utilization across the network. In a private cloud that is running tier1 to tier 4 apps across a common infrastructure while also increasing average utilization significantly, there is definitely a significant need for progress. Another key use case is security where I dont see todays approach of opening massive ranges of ports for an app as sustainable. Another interesting one is flow steering - on one hand much of this could/should be done by the network, but if all the network knows is that application X is in QoS bucket Y, that isnt going to be granular enough. To your point above, i think it would be interesting for each VM to get its own token bucket, which would make a lot of sense with network virtualization ... but I am sure there will be many different approaches emerge, QoS needs to be fundamentally rethought imho.

Dell did a demo of Elastic DCB with SDN at this years Ethernet summit which I think showcases some cool potential. I just put it up on slideshare for you if your interested:

I also discussed this specific topic with Martin Casado if your interested:
More Blogs from Commentary
Infrastructure Challenge: Build Your Community
Network Computing provides the platform; help us make it your community.
Edge Devices Are The Brains Of The Network
In any type of network, the edge is where all the action takes place. Think of the edge as the brains of the network, while the core is just the dumb muscle.
Fight Software Piracy With SaaS
SaaS makes application deployment easy and effective. It could eliminate software piracy once and for all.
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
Hot Topics
IT Certification Exam Success In 4 Steps
Amy Arnold, CCNP/DP/Voice,  4/22/2014
Edge Devices Are The Brains Of The Network
Orhan Ergun, Network Architect,  4/23/2014
Heartbleed Flaw Exploited In VPN Attack
Mathew J. Schwartz 4/21/2014
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Twitter Feed