Net neutrality has been a big player in the business and technology news for the past few weeks. It’s clearly a controversial subject. From the sidelines, the biggest question seems to be, “How will service providers’ peering changes impact my business?”
On one side of the argument is the idea that the U.S. government’s net neutrality rules could open the door for internet providers to charge some companies for faster delivery of their web content or services. The other side says this is complete nonsense, and with the repeal service, providers will be able to invest in their equipment. Investments like these will provide faster speeds, allow for more service options, and improve competition.
For what it’s worth, the FCC posted an interesting truth vs. fact document that outlines the validity of some of these arguments. No matter what side you’re on, one thing is clear: the ability to clearly identify network traffic is going to be a requirement.
We all know that a company’s network connection is vital to its daily workflow. We also know that understanding what makes up that traffic—specifically who is using it and what they are using it for—has been important to network admins for the past few years. Prioritizing mission-critical traffic is why things like cbQOS were created. By using policies like these, admins could ensure that mission-critical applications such as VoIP and video conferencing receive the highest priority. Seems like a good idea, right? Now imagine if your business was paying a premium for those applications’ traffic.
The idea doesn’t seem all that far-fetched. I know quite a few businesses that will and do pay more to ensure their VoIP or cloud-based CRM has the traffic it needs. In the simplest form, we might see more subscription options—maybe something similar to how cell traffic was charged in the earlier days, with the addition of fast and slow traffic lanes or per application usage. In this scenario, once you go over your SLA limit, you could be charged per application. At that point, auditing traffic can help save a considerable amount of money in yearly connection costs. No matter what happens, the cost of higher-demand traffic will go up. So how is business going to determine the validity of that larger-than-normal bill from their provider?
“The elimination of net neutrality means that internet providers can carve up service into fast and slow lanes, charging more for higher speeds. Comcast could demand fees from Netflix, for example, in exchange for preferential treatment.” – Fortune Magazine
NetFlow/IPFIX data is the clear choice
in this monitoring scenario. In most cases, your routing devices already support this technology. With this flow metadata, you can obtain a granular view of those conversations. Specifically, you would be able to leverage Deep Packet Inspection (DPI) to clearly see what applications are being used.
The traditional way of determining an application was via its well-known port. The idea is simple: port 80 traffic is tagged HTTP. In today’s world, however, things get trickier. Most data is passed via HTTPS. It’s difficult to tell Skype from Facebook traffic.
This is where DPI comes in. Deep Packet Inspection samples the conversation header as it goes through your router. This gives you a far better idea of what app the conversation was using. Now that you have this data, what do you do with it? How does it help?
As I mentioned before, it is possible that traffic analysis will be important to the bottom line and knowing what applications are being used and by whom will be par for the course. We have already learned that the NetFlow/IPFIX metadata that supplies DPI will give you the required visibility. Next, you’ll need a collecting/reporting tool to monitor it. Here are my suggestions when looking at tools.
Audit Teams and Historical Data
When selecting a tool, make sure it can support all of the data being sent to it. This might be a no-brainer, but you really need to make sure it can recognize the DPI templates that are being sent from your flow device. With this information, every conversation will be tagged with an application ID. This will be an important tool to the network admin because it will allow them to see which application is clogging up the bandwidth. Furthermore, they will also be able to easily change the report view and see who is associated with that traffic along with its cbQOS/QoS policy. This level of visibility will allow the admin to stop a costly issue before it happens.
My next suggestion is to make sure your reporting tool can retain your flow data for as long as is needed. Each company and industry has different needs for retention compliance. I have worked with companies that needed to generate application usage reports for the past six months so they could compare them to their ISP’s billing. In the end, being able to confidently go back in this data can save you from future arguments.
Monitor with Alerts and Alarms.
Next up is the ability to monitor and alert on a specific application. In the future, SLAs might be tied to application usage or delivery. When evaluating a flow tool, make sure that you can assign an alert to that application’s specific traffic. This will save you from future headaches, since it will alert you well before an application is getting near its threshold limit. Also, check to see how it can send these alerts to other applications. In my world, customers’ requirements seem to differ on where to send this information. I have had some that needed to send the alert to their in-house ticketing system; others needed to send it to their Splunk install. No matter what, make sure the alerts and notifications can be delivered correctly in your system.
Conclusion
Sadly, we really don’t know what will happen with this FCC ruling. We will have to wait and see. What I do know is that the importance of application visibility and monitoring will be vital to every network, no matter what happens. Is one of your requirements dealing with providers and getting a getting better visibility into your application traffic, but you don’t know where to start? Why not evaluate Scrutinizer?