Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Thursday, October 20, 2005

Wireless "policy management" and "packet inspection"?

Recently, there has been a huge surge of interest in bits of equipment that fit within mobile networks, and treat different types of traffic in different ways. "Block Skype", "Prioritise XYZ application", "Filter dodgy content", "Offload ABC application to a separate network" and so forth.

While some of this falls into the "fair enough" category, for example stopping children accessing dodgy websites on their phones, or stopping peer-to-peer traffic from bringing down a network, the more heavy-handed tactics smack somewhat of bad grace and censorship.

Quite a lot of this discussion has been based around the concept of stopping users from accessing apps or data hostile to the operator's business model (Skype or other 3rd-party VoIP, off-portal content etc) - or at least charging them more.

“We know that you, our customers, want to use that nice free stuff on the real Internet via your mobiles. We know you’re already used to using it over broadband at home and at work. And we know we could just give you a mobile “pipe”. But we’ve spent lots of money on our brand and beautiful walled garden, so we’ll throw our toys out the pram if you dare go to MSN, Google, eBay or content owners direct, rather than use our restricted and overpriced range of stuff. And don’t even think about comparing VoIP or IM with our oh-such-good-value voice and SMS tariffs. So we’re blocking it or degrading it out of spite, because we can't compete head to head & we're scared of the big bad IP world coming round the corner”.

I reckon that we’ll see two levels of this type of filtering / routing:

- "Service aware" networks are very believable and arguably essential. Services like video streams, mobile synchronisation signals and (maybe) voice require specific transport-related QoS criteria to be fulfilled in order for them to work. They are latency sensitive, need guaranteed bandwidth and so on. Having routers or “packet inspection” gear in the network to spot, optimise and variably route these traffic streams will happen. It will drive cheaper aggregated backbones, and enable triple-play type services. But there are only a certain number of these types of “service profile”, they don’t evolve that quickly, and they are likely to relate to in-house or partners’ services, which will be developed by cooperative individuals or companies.

- “Application aware” mobile networks, however, will probably fail. Applications (and programming techniques) evolve much faster than the policies can be developed to manage them. They are often developed by people who are uncooperative, and who will look for arbitrage opportunities. They are being aided and abetted by ever-smarter devices. And trying to separate a "friendly" app from an unfriendly one isn't as easy as it seems... and it will get even harder with wider use of applications made up of multiple components. Oh, and it's also worth noting that in some cases this is likely to be illegal anyway, even if it's technically feasible.

Who is to know if a Bittorrent transmission is an illegal video, or an investment bank's clever new way of distributing realtime prices to its dealers? Is that video stream Tom & Jerry, or a doctor's new telepresence app, or a video add-in to an enterprise application? Who knows what's inside that IP-VPN tunnel, especially if it's encrypted?

And even if some operator tries to block certain apps and prioritise others, surely some innovative software developer will tweak the "profile" of the application. Maybe an enterprising open-source coder will work out a way to make VoIP look and behave like SAP? And what happens when applications are written in component form? Trying to work out what application(s) a chunk of XML or .NET code ultimately fits into will be nigh-on impossible. And what happens where you have "layered" applications, like an email form, within a web page, accessing a portal, which feeds into a back-end e-commerce application?

This all reminds me of the late-1990s marketing hype for enterprise network policy management... "restrict the marketing department to 10% of Internet bandwidth except after 6pm", "de-prioritise email in favour of voice". That mostly failed, as companies realised they'd have to employ people called "policy managers", with a combination of IT, HR and business skills, in order to actually work out the policies effectively. In the end, everyone more-or-less gave up, threw more bandwidth at the problem, and just separated out a couple of the most sensitive data streams like voice.

To borrow from and extend a famous comment about the Internet by the EFF's John Gilmore....

"Smart applications will treat packet inspection as damage and route around it"

No comments: