NTT DoCoMo Asks Google To Limit Android Data Use 160
An anonymous reader writes "NTT DoCoMo has had enough of Android's effects on its mobile network in Japan. Following a service disruption due to Google's Android VoIP app, the company is now asking Google to look at reducing Android's data use. In particular, the amount of time allowed between control signals being sent either by official apps or 3rd party ones. Typically these occur as often as every 3 minutes, but scale that up to thousands of apps on millions of handsets and you can see the issue DoCoMo has. So, does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reining in?"
Well that depends... (Score:5, Insightful)
If its telling Google to try and control the amount of bandwidth the users decide to use, well, I think they are going to have a little trouble getting that done.
Both (Score:5, Insightful)
Both Apple and Google need to be aware of their bandwidth usage, but it is not just those two, but the app developers as well. Better to spend a few more CPU cycles and compact the data a little more than to bring down the network. XML is fine, but hardly the most efficient way to transmit data, especially not without compression.
On the other hand, the providers must realize that the trend are for increasing data usage, as we take our daily communications with us, rather than sitting at home with our fixed line broadband connections.
Re:Well that depends... (Score:4, Insightful)
If its telling Google to try and control the amount of bandwidth the users decide to use, well, I think they are going to have a little trouble getting that done.
TFA specifically states they are trying to control VOIP data usage. Not unlike the (failed) domestic attempts to limit voip on a smartphone in order to preserve traditional airtime revenues. Do you remember all the hubub when apple/at&t tried to ban Skype? It's a thinly veiled attempt to screw customers, and I'm sure Google has no particular interest in limiting their users traffic based on the content being transmitted.
Re:NTT DoCoMo is the standard gold of mobile netwo (Score:5, Insightful)
Considering that Google has a SERIOUS interest in making control signal intervals as long as possible for battery life purposes - if they are too often, the carriers only have themselves to blame. Too many carriers have aggressive NAT firewalls with short TCP connection timeouts, and it's much better for the handset AND the carrier to send a keepalive within that timeout period than to have to detect a dead connection and set up a new one.
Google "netpiculet" or look at my last post earlier on this article for an eye-opener of how network providers shoot themselves in the foot.
If Google is sending control signals too often - DoCoMo should take it up with the carriers that deployed broke-ass NAT boxes that forced Google to do this.
Re:Well that depends... (Score:4, Insightful)
Perhaps they shouldn't sell a product if they can't provide it, rather than stripping and restricting what people thought they were buying later?
Should we just pray they don't alter the deal further?
Re:Control signals- NOT Data (Score:5, Insightful)
What Android desperately needs is a nice, API-level convenience method that lets you create a http(s) request, complete with args, then hand it to the OS and say, "You don't have to do this *right this millisecond*, but at some point within the next ___ seconds/minutes, please wake up the phone (if necessary), establish network connectivity, make the request, then fire {this-intent} with the server's response (or failure info)" (and optionally, if the request fails, try making a test request to something like 8.8.8.8 and/or 8.8.4.4 to make sure the phone's internet access is REALLY working before assuming failure, so the program only has to deal with the failure of its own web service, instead of having to deal with the failure of the phone itself to sustain a robust network connection).
Believe it or not, right now, there's NO good, reliable, graceful way to do the equivalent of having a cron job fire off a http request when the phone is asleep. There are ways to kludge it, but they're all either unreliable (the phone will go back to sleep before it even has a chance to MAKE the http request, the network might be down because it hasn't finished reconnecting yet, etc) or dangerous (holding partial wakelocks in static variables, with no way to guarantee their release if something crashes).
Android gives developers lots of power, but it also imposes enormous amounts of responsibility that maybe 1% are really equipped to handle. In the real world, the network failure strategy of most Android applications can be summed up as "relentlessly keep beating away at the URL in the hope it might eventually work". Oh, most semi-new Android devs don't SET OUT to be irresponsible... the problem is, anybody who tries to make a single network call and fail politely and exit if it doesn't work quickly discovers that an average Sprint user will have the app die within 10 minutes (thanks to the stupid way Sprint phones thrash between 3G and 4G in quite a few real-world indoor usage scenarios). So they adopt "keep trying over and over again" as a strategy, because it makes their app work on Sprint phones, but kills the battery of anybody who's somewhere like a subway tunnel when the phone decides to make its next http request. If Google gave developers a nice, bulletproof way to politely make asynchronous http requests that can be gracefully scheduled and batched, instead of trying to hack together buggy solutions that almost work, we'd all be better off.
Re:There are limits though (Score:5, Insightful)
CDMA techniques do not get you a free pass around Shannon-Hartley's channel capacity theorem.