About a year ago, I first posted on why many vendors' and operators' strategies for Deep Packet Inspection would fail abysmally. After meeting again with a couple of vendors recently (including London-listed SandVine last week), I'm doubly sure I'm right.
The idea of segmenting network traffic into different applications (web, email, IM, Skype and so on) is completely flawed. It totally fails to recognise that increasing proportions of traffic will be "meta-applications" comprising multiple different components. MySpace pages have streaming (perhaps from YouTube), image, IM, maybe VoIP included in the future. Mashups by definition will include a wide and unpredictable mix of component sub-applications. Ironically, if it succeeds, even IMS services are likely to be ad-hoc mixes of various enabling elements, put together in the carrier marketing department faster than the network policy drones can keep up.
So all these charts with "20% of traffic is X, 30% is Y, 10 % is Z" are nonsense. If the end-user wants "a good Myspace user experience", or even a good "Carrier-based Myspace Clone experience", it will have to deal with the fact that today, there will be YouTube streams in it, maybe tomorrow there will be a Skype VoIP element, and the day afterwards a Google Earth mashup. And the suggestion that a carrier-resident service will only include carrier-optimised component applications is ludicrous.
Put simply, differential application-level filtering / blocking / limiting won't work, as the notion of "application" is evolving too fast to generate & enforce policies.
The only realistic use case in my view for DPI is in very non-granular network integrity protection. "Limit BitTorrent to 50% of traffic on this link, as otherwise there's a risk of failure".
To be fair, SandVine does have another pitch about using its boxes to try and spot security risks like DoS attacks. That's fair enough - that's not "application traffic", it's more the box doing a clever sort of "pattern recognition", which is an entirely different concept. In fact, I suspect that many of the DPI vendors' key IPR is actually in pattern recognition, and they've initially picked "application spotting" as a usage case, perhaps without realising that it only has months to live.
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
9 comments:
Although I agree with most of your article, I have to express my disagreement with the following statement:
"So all these charts with "20% of traffic is X, 30% is Y, 10 % is Z" are nonsense"
I believe that it is necessary to know what´s going on in a network to dimension and operate it properly and without DPI, it is difficult to identify more than 70% of the traffic in both access and core networks. Thus, I think this is another realistic use-case...
The point is, that analysis still won't tell you "what´s going on in a network to dimension and operate it".
So, DPI tells you 20% of packets are VoIP. So, which ones are phone calls, which ones are voice embedded within a game, voice within IM, or which ones are voice within an enterprise application?
And what happens when someone starts encoding VoIP steganographically in JPEGs and does Voice-over-Image?
I don´t want to make this into a debate (although it will probably end that way ;-)), but my point is that if you want to offer a better experience, you´ll need to configure your routers properly and to do so, you need some information regarding the traffic in you network. So if you find out that there is a 30% real Time traffic, you will want the queues correctly configured so this traffic gets a better treatment, obviously this method is not 100% accurate, but it is good enough to make users notice the difference. Nevertheless, you can alternatively overprovision your network so the load is under 30% and the only think you´ll need to worry about is to check from time to time the network load to see if you need bigger pipes...
BTW. If someone begins encoding VoIP in JPEGs, probably it is to do something illegal ;), so I don´t really think they will complain if the QoS is not as good as expected...
So does this make net neutrality unenforcable?
I agree that DPI is impractical and not going to deal with the applications that are evolving on the net, but I'm reading about some stuff, such as 802.1ah, that could implement net un-neutrality fairly easily.
I'm still trying to get to the bottom of it (and how they plan to make it work in practice with applications) but it worries me more than DPI...
What about ALLOT and their deep packet inspection?
I don't see that Allot, Cisco or any of the other umpteen DPI vendors has been able to address the increasingly "blended" and layered nature of applications and user experience.
It will be increasingly difficult (maybe impossible) to determine in the network exactly what a given packet will be used for, or how important it is.
There will be some uses of DPI for which the lack of awareness & subtlety will be unimportant (eg protecting the network from flooding, DoS, overload etc). But the more fanciful idea of using DPI as some sort of "Big Brother" to check up on what you're really doing & charge / prioritise / deprioritise in very granular fashion is arrant nonsense.
That's before you start to use VPN. Which I do over 3G, for lots of reasons - some of which are because I use my wireless data to get to my work and home systems, and I like the extra security. Reckon I'm not the only one.
All the operator will know about my use is how many packets I'm sinking and sourcing a second.
So what about other claims for DPI's usefulness? Usage-based customer segmentation, billing, and perhaps most importantly, the ability to identify same-session packets over different bearers in an IMS environment? Sounds too good to be true if you ask me.
Post a Comment