alex_aldo - Fotolia


Application performance measurement gets boost with DPI

There are lots of technical approaches to sifting applications out of the sand pile of network traffic, but when you get down to the details, the best solutions all do it the same way: with deep packet inspection, writes Patrick Hubbard.

Once upon a time, I wanted to send a little Simple Mail Transfer Protocol traffic past the firewall, but without all the hassle of getting an exception for an outbound hole in the network. It seemed innocent enough -- simple application testing -- and I was young, in a hurry, a bit of a cowboy and didn't like paperwork. My solution was an HTTP proxy on port 80. At the time, nobody noticed because back in the day the Web represented a fraction of total traffic. Besides, who had time to look at every port 80 packet to see if it was actually transporting HTML or related content?

Today, however, when watching NetFlow data, especially on unwashed segments like your BYOD Guest VLAN, it's a rarity to see apps trying to use anything other than port 80. Developers know that's the one enterprise-friendly route they can count on. So, if you want to get a little promiscuous, or, failing that, ready to fire up Wireshark in promiscuous mode, you'll see some interesting traffic on port 80, even beyond whatever quasi-legitimate Web shenanigans you'd normally expect.

Packet inspection holds the key

If you've already read a packet, then it's a small extra step to identify what it truly is by its signature.

Wireshark's tagline is a great one: "Go deep." There are lots of technical approaches to sifting applications out of the sand pile of network traffic, but when you get down to the details, the best solutions all do it the same way: with deep packet inspection (DPI). Wireshark does it by sniffing packets off the wire, while Cisco and other hardware vendors do it inflight on the router or switch. But what they don't do is correlate the application traffic on your network with devices and topology, or give you dashboards to gauge the most valuable and elusive enterprise metric of all: quality of experience (QoE).

Take, for example, the low-hanging fruit of network and application performance measurement -- just by looking at handshakes. Gross network quality is easy to measure if you can correlate TCP handshake events. In just three packets (SYN-> SYN, ACK -> ACK {Data}), packet analysis is capable of measuring the relative real-world network quality by the applications actively using it. Watching these metrics change over time or comparing performance of one path against another communicates what's really going on 20 layers beneath a help desk ticket. Better yet, it makes QoE a real metric that's reportable over time.

Another trick up DPI's sleeve is service performance monitoring. After the TCP handshake, the client-server traffic can be used to measure application think time. Client requests are usually followed by a server ACK ("I heard you, stand by"), a pause, then data packet(s). By measuring the delay between the request ACK and the response data, you measure the actual think timefor the service.

But that's just the beginning

Your network performance monitoring platform is the natural hub where DPI and all of your other network metrics should be brought together. And to make your network monitoring a fully armed and operational QoE battle station, you should include application signature detection (ASD) in the mix.

If you've already read a packet, then it's a small extra step to identify what it truly is by its signature, regardless of port, endpoint location or other factors. A packet can try to say, "I'm a ghost. You don't know me," but ASD can quickly deduce that it's actually Skype, torrent traffic, Vimeo or whatever else it really might be. This lets you report, alert or take other action to enforce policy.

It also adds other powerful analytic features like traffic categorization and risk and productivity assessment. Have you ever wanted to report on the relative value of the traffic coming from an endpoint? How about what risks its traffic creates for the business? With ASD, admins can even speed change planning. How handy would a real traffic-based reporting be for all custom in-house applications connected ball-and-chain to a central Oracle back end? This type of information would certainly be a boon for virtualization architects.

Relax, it's just software

DPI processing and the related analysis for ASD, conversation metrics and everything else that provides a comprehensive view of QoE does have to happen somewhere. Fortunately, there are several options available, ranging from appliances to software. If you're considering DPI, there are a few considerations to keep in mind:

First, DPI products should be easy to maintain, because you'll be on the hook for support. It's not just good-old Simple Network Management Protocol -- there can be lots of new moving parts -- but you still shouldn't need a doctorate to run it.

Second, it should offer the option of analyzing either via port spanning in bulk or virtual probes -- ideally, both concurrently. And here's a pro-tip for you: If your platform offers probes, make sure that probe deployment and management are cast into the core of your console and are dead-simple to maintain. Fiddling insistently with scattered probes will shorten your lifespan. Of course, I'm not picking on anyone … reverse(replace(“I love it”, “[\se]”, “”)).

Finally, go have some fun and run traffic risk assessment reports on the executive wing endpoints. They love that. Just keep the results to yourself.

About the author:

Dig Deeper on Network application performance

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

How important is the use of DPI in your network?