Today seems to be the day for me to needle some of my main targets. This morning I had another shot at the hapless RCS service, and now it's the turn of my biggest network-side punchbag, application-based charging.
I've just been given a classic example of why this is going to be nigh-on impossible to ever get right.
In theory, the network should be able to pick out the fact that I'm using Google Maps. I'm sure it's got a pretty predictable "signature" that the average DPI can spot.
But what it probably can't spot is *why* there is Google Maps traffic being used. I've just downloaded the latest version of the Vodafone "MyVodafone" app for my iPhone. It's pretty useful, with a good dashboard feature showing how much data I've used against my cap and so on. This version also comes with a WiFi logon feature.
The sign-up for this has a warning message, telling you that in order to find the nearest WiFi access point, the app uses (guess what) Google Maps. And that I am liable for the data charges incurred in doing so. Now I'm guessing that this is done for a good reason - most probably speed and expediency of getting the thing released, plus I also expect it doesn't use *that* much data in the big scheme of things.
In theory, Vodafone ought to have set up some sort of rule in its network to obviate this, and zero-rate its own offload-location data consumption, especially as its reduced macro network load makes it the main beneficiary. But that would have needed to somehow check that the offload app was indeed the "user" of Google Maps, rather just than me trying to find my way around normally. And that's rather hard, without some sort of agent on the device watching what's going on and trying to decode what GMaps packets are "native" in the mapping client, and which are used via the local API for specific apps.
This is precisely sort of hard and complex situation that I have in mind when I say that app-specific charging is going to be a nightmare. Imagine for a moment that Vodafone had a "menu-driven" non-neutral pricing model, where I got charged £3 a month for using the Google Map app. I'd be rightly irritated if *I* didn't use it, but the operator did itself through its own software, charging me for the privilege anyway. I don't expect the regulator would be too happy either.
On another note, let's see how the Vodafone WiFi app manages to coexist with my other WiFi finder (BT Fon) on my handset. I don't think either is auto-logon, but I can imagine some interesting situations if they are, as both use BT Openzone. Will I be able to tell which "virtual" WISP I've logged into?
I've just been given a classic example of why this is going to be nigh-on impossible to ever get right.
In theory, the network should be able to pick out the fact that I'm using Google Maps. I'm sure it's got a pretty predictable "signature" that the average DPI can spot.
But what it probably can't spot is *why* there is Google Maps traffic being used. I've just downloaded the latest version of the Vodafone "MyVodafone" app for my iPhone. It's pretty useful, with a good dashboard feature showing how much data I've used against my cap and so on. This version also comes with a WiFi logon feature.
The sign-up for this has a warning message, telling you that in order to find the nearest WiFi access point, the app uses (guess what) Google Maps. And that I am liable for the data charges incurred in doing so. Now I'm guessing that this is done for a good reason - most probably speed and expediency of getting the thing released, plus I also expect it doesn't use *that* much data in the big scheme of things.
In theory, Vodafone ought to have set up some sort of rule in its network to obviate this, and zero-rate its own offload-location data consumption, especially as its reduced macro network load makes it the main beneficiary. But that would have needed to somehow check that the offload app was indeed the "user" of Google Maps, rather just than me trying to find my way around normally. And that's rather hard, without some sort of agent on the device watching what's going on and trying to decode what GMaps packets are "native" in the mapping client, and which are used via the local API for specific apps.
This is precisely sort of hard and complex situation that I have in mind when I say that app-specific charging is going to be a nightmare. Imagine for a moment that Vodafone had a "menu-driven" non-neutral pricing model, where I got charged £3 a month for using the Google Map app. I'd be rightly irritated if *I* didn't use it, but the operator did itself through its own software, charging me for the privilege anyway. I don't expect the regulator would be too happy either.
On another note, let's see how the Vodafone WiFi app manages to coexist with my other WiFi finder (BT Fon) on my handset. I don't think either is auto-logon, but I can imagine some interesting situations if they are, as both use BT Openzone. Will I be able to tell which "virtual" WISP I've logged into?
2 comments:
I think this is a design issue in the application rather than an issue for the DPI to sort out.
The architect should design the application to use GMaps through the server, so it should have communications only with its server which in turn connect to GMaps and perform the fetches needed from there.
I have also noticed this problem, and it is tricky. DPI complexity grow exponentially with reduction of statelessness - for example, it would need to keep track of Vodafone App sending start and stop signals to know when to give away Google Maps data for free and when to charge. Add HTTPS on top, and we are talking crazy pressure on DPIs.
However, if I read Ammar right, I agree with his proposed workaround. Vodafone could setup a proxy server that talks to Google Maps just for this purpose. Other solutions could be adding custom headers or HTTP src port.
Post a Comment