The difference between fluency and awareness can mean the difference between meeting and missing an SLA

We - and that's the networking industry at large - have been using the term "Application Fluency" for a long, long time. It started back in the days of bandwidth management solutions. QoS enforcers from many now-relegated-to-history vendors like Packeteer and Sitara Networks and Lightspeed Technologies first introduced application awareness as a means to classify traffic. Being able, at that time, to distinguish HTTP from FTP or SMTP was a pretty big deal as it meant policies could be created and enforced based on classes of applications, enabling operators to stop bursty FTP traffic from consuming every kilobit of bandwidth and effectively executing a DoS on all other corporate traffic.

But over the years, particularly as HTTP has become the de facto transport protocol standard, distinguishing traffic based solely on protocol has become an ineffective means of managing application traffic. Over time additional distinguishing features were added: content type, secure or unsecured, user-agent, and location became important factors in understanding the unique delivery requirements of a given application. How an application interacts with the network became important, offering clues on what specific settings should be tweaked, tuned, or turned off (Google "Nagle's algorithm" for some interesting reading on the impact of the algorithm on applications).

And yet that wasn't enough, either. The behavior of an application - how it's used, by whom, from where and how frequently - is increasingly a critical factor in ensuring the appropriate delivery policies are applied and enforced, including those related to the security of both the application and its data.

It isn't enough to know the network (IP), transport (TCP), application transport (HTTP) and even application (HTML, CSS) protocols like the back of your hand, you've got to know how the myriad TCP RFCs and specifications and the user behavior are going to interact across its seemingly infinite combinations.

"Application fluency" must comprise the understanding of how protocol, behavior, and network variables combine to impact - positively or negatively - the performance, security, and availability of any given application. Two out of three is bad when you're talking about an aspect of an application that can dramatically increase - or decrease - operational risk. Failing to recognize the impact of an application being delivered over a cellular network can mean the difference between acceptable performance and a lost customer. Failing to recognize the behavior of the application may mean the difference between stopping a data leak and saving the day.

Application fluency means being able to factor in the protocols, the behavior, and the interaction with the network to determine how best to secure, accelerate and assure availability a given application.

Anything less is not fluency, it's merely awareness. And like the concept of languages from which fluency is lifted, being aware someone is speaking French doesn't mean you can actively participate in the conversation.

Being fluent, however, does.