I’ve been reading blogs and articles about Application Aware Networking, and thinking. There seem to be many rather differing ideas about it. A lot of vendors / people seem to think the applications will (and should) tell the network what they want. Let’s think about that together …
The Application is King / Boss?
Most of the use cases or quasi-use cases I’ve encountered have been ones where the application tells the network what it needs. Like bandwidth. I’ve noticed the application always seems to be the boss here — the network just takes orders and does as it is told. Network janitor — bandwidth needed on aisle 4. Bzzzt, wrong! That use case doesn’t particularly make sense to me. I may be dissing this Spring’s somewhat simplistic Cisco Partner Summit demo in saying so.
This doesn’t make sense to me because I’m not convinced most applications would know what to tell the network to do for them. And, like some kings or queens, or politicians with power, might over-reach and demand more than they should.
QoS as a Use Case for This
As a long time practitioner of QoS, I am well aware that any QoS scheme can be trashed by an application sending its traffic with DSCP marking EF, thereby stomping on the voice traffic that my carefully and laboriously crafted QoS policy is trying to protect. There used to be rumors that if Microsoft NetMeeting thought it was experiencing congestion, it would crank up its DSCP markings. I have no idea if it actually did that.
That story did plant the idea in my head of a programmer doing something like that to make their program look good — at the expense of the network and other applications. Relevance: could a programmer with odd notions of how things work code up something well-intentioned that asks the network to do something irresponsible? Or for that matter, gets units wrong and asks for Gbps instead of Mbps of bandwidth?
Anti-social programming does happen! More and more programs open multiple TCP streams for faster performance. Great for their user, and for the web browser or file sharing program to look great. Somewhat anti-social in terms of what it does to other users, unless they use similar mechanisms. Doing this increases the loading on DNS servers and increases the number of flows in the network. I’m seeing devices (like Web Compression devices, Web anti-malware devices) that cannot handle the growing number of flows.
Back to QoS as a use case for Application Aware Networking. I used to try to take defensive measures when deploying QoS. I still do. Doing so creates extra work and gets painful, fast. So lately I’ve dialed it back to essentials, e.g. not worrying about policing inbound “voice” EF traffic to sane limits. I usually recommend not trusting server markings and resetting server DSCP to 0, where possible. But if trusted Call Servers and other key servers aren’t in separate VLANs, or are scattered (e.g. your typical Shoretel Call Server deployment), that gets a bit painful. Site by site or port trust, or laundry list of IP addresses … yuck.
Is it a good idea for the network to just take each app at face value “I need DSCP EF treatment”? I don’t think so. In doing some labwork I did a couple of years ago, an adaptive video app grabbed something like 20-25 Mbps on a lab DS3 for one HD video stream. It looked equally good to me at 2 Mbps. (I stuck some shaping in the middle and played with the allowed bandwidth.) If you were paying for that bandwidth, or total bytes received, I imagine you might want a say in what the application does! Yet creating policy to control such apps is a bit of extra work.
Most Microsoft physical handsets can run in a voice VLAN. That does help with physical phones, but not softphones. Microsoft’s current answer for QoS for Lync softphones is for the desktop admins to set a GPO (Group Policy Object) specifying port range and DSCP value. That requires Windows 7 or later. (My guess: softphones don’t tag since too many cheap NIC adapters don’t do 801.1q tagging — and who wants to run trunking to desktops?)
So for softphones, we either have to trust the desktop, or have a policy that QoS is not provided for softphones, since I really don’t want to trust DSCP markings coming from desktop computers. I generally want to trust desktops less than servers. And thanks to all the programmers who couldn’t be bothered to code so their VoIP app runs by default on only a few published UDP ports, which would allow me to “narrow the aperture of exposure” by sanity checking already-marked packets. That includes you, Cisco!
Tentative conclusion: it may be useful for apps to ask rather than just start pumping out traffic. But if application awareness is a negotiation rather than a demand, it requires specifying a network policy. Hmm, I don’t see a lot of Call Admission Control being done at sites… I like the potential here. Does it pass the real world plausibility check?
Do Programmers Understand Networking?
Many programmers and server admins do seem rather unaware of and oblivious to the network. I’ve seen (and had to troubleshoot) too many programs where a little thought about packet flows (times Round Trip Time) would have allowed the programmers to speed the program up vastly. Related example: not using stored procedures with databases. Yes, there are some sharp programmers and server admins out there who do get networking and how it can impact an application. All too many seem to assume that all networks are as fast and reliable as their high-speed LAN. (Microsoft has some of them: why Blue Screen of Death or hung behavior when a WAN network file share is slow or down? Why does Windows Explorer freeze for 10-20 seconds when I drag a file across a “folder” for a remote filesystem mount? Why are there menu hangs in some media playing apps, code just stuck waiting for the DVD drive to spin up? Rather poor programming!)
Getting back to apps and Application Aware Networking … The bottom line here is that often the programmer is trying to get the darn thing working by a deadline. They have to fix critical bugs, and follow the priorities set by his or her management. Documentation, thought — who has time? And management often ranks new features over bug fixes (get new customers while losing irritated old ones?).
Here’s where I’m going with this… Communicating with the network? That’s a frill, low priority. Is there an API for it? Since there isn’t right now, programmers have to adapt to whatever the network gives them. And come to think of it, if the Internet is in the middle of a traffic flow, they’re always going to have to do that. So do we get a split into “enterprise-only” apps and “cloud-based”, where the former communicate with the enterprise network, and the latter adapt? I don’t see that happening. Mobility is going to drive applications into the cloud, be it public or private.
As another case in point, take RSVP. It is a great mechanism for an application to request and reserve bandwidth. Somewhat of an early pre-cursor of Application Awareness. Not widely used. Too much bother for programmers, apparently. Or lack of awareness RSVP exists?
Tentative conclusion: for applications to inform the network of what they want, we’re going to need one API, a way for information to be communicated. Programmers will have to learn to use that API. This is reminding me of the ATM era assumption that applications would change to become ATM aware. A few years later, LANE (LAN Emulation) came along, since applications weren’t changing. Lesson learned: application changes of that magnitude take a 10-20 year cycle, even with a standard in place! I.e. don’t hold your breath!
Also consider: there will need to be a whole policy enforcement or negotiation mechanism on top of that. Does every program get its way? Hmm, does every pushy person get what they ask for? I hope not. And part of the policy might be like what RSVP is supposed to do, namely “you can have that request if the amount of bandwidth up for grabs is less than X”. Where is all this stuff going to come from? Condensed marketing vapor?
Is It the App or the Deployment Team that Wants Something?
Intrigued by this idea, I set out to look around blogs and the Internet to see what else vendors and people might mean by “Application Aware Networking”. My suspicion is that “Application Aware X” has become like SDN — ubiquitous mandatory marketing for 2013.
One of the many good blogs I try to read regularly is Lori MacVittie’s blog at https://devcentral.f5.com/users/38/my-contributions. Google turned up one of her blogs from May titled “What Applications Want”. You can find it at https://devcentral.f5.com/articles/what-applications-want#.Ui-t1z_qK2k. (No, there is no such upcoming movie sequel to the Mel Gibson movie.)
The blog got me thinking, as Lori often does. It talks about WCCP and service chaining. Or an app asking for web application firewall services. Server Load Balancing services is the other service that comes to mind here. And re service chaining: not only asking for service but in a specific order.
I like the idea of an application coming bundled with information about how it should be placed on the network. And this is great use case information.
BUT! Is that really information that is a property of the application itself, or is it information coming from the application deployment team? Does every deployment of an application require a Server Load Balancer, for instance? Or only bigger and more mature sites that require High Availability?
I’m ending up with the conclusion that this seems more like info one would want in Puppet, etc., or a controller, as information about the desired end state of the deployment of the application. Hence, I see this as more something coming from the owner of the application at a site, not the vendor itself. I supposed if a future vendor ships a vApp, i.e. multiple canned VMs for web front end, application middle services, and database back end, then the service chain (firewall, then SLB, to these IP addresses) might be specified as part of deployment packaging. But the necessary information is more of an attribute of a collection of VMs than any single one of them?
Returning to a starting theme: Can an application specify how much bandwidth it needs? Doesn’t that depend on size of organization, number of users, speed of server, speed of server network connections? Hmm, seems like the programmer might have to learn a lot about the network behavior of the app — still not common in the enterprise apps space. Or might this be something the installing admin might set, based on some sort of performance / capacity information? I’m coming back to the idea that some notion of context and intended use may be easier to get from the installing human or installation software than being built into the app itself. Arguing with myself (it’s ok, I’m a Libra), as more people use the application, yes, it might need more bandwidth … so is the answer some of each (app, app owner/installer)?
I also find myself amused by the thought that keeps popping up implicitly here, of security being managed by each server or app team (or dev team?). Security (and maybe server / SAN backup) are two tasks that I don’t believe can be distributed. They require accountability. Or there will be at least one server owner who hasn’t had time to deploy firewall rules, or thought their backup was working but never checked. I personally believe firewalling may well migrate into virtual appliances and then the NIC or hypervisor … but is that best when subject to distributed management or centralized management? Could an application really specify the appropriate security for itself? Would YOU trust your security to external app developers? Me: No Fine Way.
Yet Another Take on Application Aware Networking
What Cisco seems to be espousing along the lines of Application Aware Networking is more the network being aware of flows and helping troubleshoot — the tools aspects of Medianet, and Application Visibility and Control (AVC). Those concepts I buy into. Managing flows and especially QoS and Security has got to get easier. And Cisco’s competition has clearly seen some opportunity in this space.
Give Me Use Cases, Please
I love debating technology like this. To me, it comes down to use cases. They give me something I can sink my teeth (my brain?) into. The above is a kind of generic use case, tied to my QoS experiences. Are there some other good use cases?
I’m hoping the above gets you thinking. Comments with links to good use cases would be appreciated — Google isn’t coming up with much useful info for me.
What does an application want (from the network)? Does it dictate or does it negotiate?
I don’t have any firm conclusions for you at this point. I do have some further thoughts that may appear in a follow-on blog.
Life Log
Apologies for the blogging gap! I’ve been writing up a lot of network assessment and QoS reports lately. So I probably have QoS on the brain. All the writing and long hours temporarily exceeded my daily writing capacity. Going forward, I’m going to try to transmit more of the (short!) blogs that are queued in my brain. The several QoS design/deployment assistance consulting engagements I’m currently involved with may adversely impact that.
Disclosure
The vendors for Network Field Day 5 (#NFD5) paid for my travel expenses and perhaps small items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds. I’d like to think that my blogs aren’t influenced by that. Yes, the time spent in presentations and discussion gets me and the other attendees looking at and thinking about the various vendors’ products, marketing spin, and their points of view. I intend to try to remain as objective as possible in my blogs. I’ll concede that cool technology gets my attention!
Stay tuned!
Twitter: @pjwelcher