Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

NTT DoCoMo Asks Google To Limit Android Data Use

Soulskill posted more than 2 years ago | from the buy-more-ether-instead dept.

Android 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?"

Sorry! There are no comments related to the filter you selected.

Both (-1, Troll)

Anonymous Coward | more than 2 years ago | (#38869603)

Slopes never have enough room for American habits.

Americans are never efficient enough for those angry slants.

I say we kill 'em all and let God (or Morman God if you are Glenn Beck or Mitt Romney) figure it out.

You could be a sister wife for a pedophile in your next life!

Well that depends... (5, Insightful)

Ragun (1885816) | more than 2 years ago | (#38869617)

If all they are asking is for Google to optimize its network usage, as the article seems to imply, go all out.

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.

Re:Well that depends... (3, Insightful)

kelemvor4 (1980226) | more than 2 years ago | (#38869753)

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:Well that depends... (4, Informative)

kbielefe (606566) | more than 2 years ago | (#38870183)

It's not VoIP calls that are the cited problem, it's the periodic signals when it's not in use that tell the server, "Hey, I'm still here!"

Re:Well that depends... (1)

ColdWetDog (752185) | more than 2 years ago | (#38870221)

It's not VoIP calls that are the cited problem, it's the periodic signals when it's not in use that tell the server, "Hey, I'm still here!"

Does sound like a typical Geek problem, doesn't it?

Re:Well that depends... (1)

ewanm89 (1052822) | more than 2 years ago | (#38870847)

You mean the ones that are no different in load to the one the phone makes regularly to the base station for the same purpose. Those are a single packet or 2 usually.

Re:Well that depends... (-1)

Anonymous Coward | more than 2 years ago | (#38870229)

If any of you had half a brain you would realize how many billions of dollars the wireless carriers have spent building out these networks, they are for-profit companies, not non-profits. They have a right to make money in return. If not, then they should just shut down the entire wireless system and listen to everyone cry. They're not going to give away their services for free for God's sake!! Wake up!!!

Re:Well that depends... (3, Insightful)

tripleevenfall (1990004) | more than 2 years ago | (#38870353)

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:Well that depends... (0)

Anonymous Coward | more than 2 years ago | (#38871483)

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?

That's fine they will no longer support of sell Android phones.

Re:Well that depends... (5, Informative)

similar_name (1164087) | more than 2 years ago | (#38871151)

They have a right to make money in return

No, they have the right to try to make money in return. If they can't make money without constantly changing the rules instead of their strategy they should go out of business. I'm sure others could use the spectrum.

Re:Well that depends... (1)

Suki I (1546431) | more than 2 years ago | (#38869805)

If all they are asking is for Google to optimize its network usage, as the article seems to imply, go all out.

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.

I do not necessarily advocate this, but can't they detect individual users and throttle(?) or filter those control signals? If that takes more resources than just letting Androids bog down the system, I withdraw my question.

Re:Well that depends... (5, Informative)

kbielefe (606566) | more than 2 years ago | (#38869965)

It's not that simple on a wireless connection where everyone shares the medium. For communications originating at the phone, the network provider can't do any throttling until the packet has already been received at their equipment, because they don't control the phone's transmitter. By that time, the bandwidth on the wireless link has already been consumed and wasn't available to other users. If the control signals originate at the server, the network provider could throttle it, but setting it up isn't trivial, and then you have problems like the servers sending retries because they aren't getting responses from the phone. The best solution requires cooperation from the OS and/or application writers.

Re:Well that depends... (0)

Anonymous Coward | more than 2 years ago | (#38870155)

Sorry, but that is so wrong. Bandwidth on the air interface is hardly the limiting factor in basically every wireless network. What is much more severely limited is the backbone capacity, and there it is actually very easy to throttle individual users (in most western countries at least, throttling speed after a certain consumption limit is standard practice). With all contemporary cellular networks, the handset needs to tell the base station who it is in order to be able to use the network, for example in GSM networks, it needs to transmit the IMSI and MSISDN, so the network knowns whether this handset is even allowed to use the network, and which calls to route to that handset. Based on that information, it is ridiculously easy to limit the backbone bandwith that this handset is allowed to consume. You can even disconnect a particular service altogether, or how else do you think network barrings work?

Re:Well that depends... (1)

tragedy (27079) | more than 2 years ago | (#38870743)

That doesn't quite add up. The number of smartphones out there is on the same order as the number of high-speed connections in homes. The connection of cell phone towers to the backbone is extremely direct compared to high-speed connections in homes. And, finally, the total monthly bandwidth used by the typical phone is a lot less than the total monthly bandwidth of a home connection. So how is the backbone usage the issue when it's the same backbone as the home connections?

Re:Well that depends... (2)

AngryDeuce (2205124) | more than 2 years ago | (#38869869)

First it was bit torrent traffic, then video streaming traffic, then VOIP traffic...

They're just setting the stage for discriminating traffic so they can charge more to certain users to get back the money they lose from those customers not supporting their other services. The U.S. telecoms have been falling all over themselves trying to find a way to nullify Netflix to keep us from dropping their archaic tiered cable tv service.

Why would a Japanese company be any different? The Skype folks are going to end up getting squeezed for more money, just wait...and some goon will be saying to himself "that'll teach 'em to stop using up their anytime minutes!!" the whole time.

Re:Well that depends... (1)

bryan1945 (301828) | more than 2 years ago | (#38871053)

Makes me wonder if the telcos spent just a fraction of the money they do on advertising and fighting all types of competitors, and used that to improve their product, what would happen? (Yeah, I know pipe dreams and all that)

Re:Well that depends... (2)

Oliver Wendell Jones (158103) | more than 2 years ago | (#38871207)

How old is your Sig? I'm trying to figure out if it is new and and you're suggesting we replace the current crop of politicians with monkeys, or if in fact this is an old sig and explains our current predicament?

Re:Well that depends... (0)

Anonymous Coward | more than 2 years ago | (#38871229)

This is why content providers should not be the same companies as distributors.

Re:Well that depends... (1)

Anonymous Coward | more than 2 years ago | (#38871741)

First they came for the bit torrenters,
and I didn't speak out because I wasn't a bit torrenter.
Then they came for the video streamers,
and I didn't speak out because I wasn't a video streamer.
Then they came for the VOIPers,
and I didn't speak out because I wasn't a VOIPer.
Then they came for me
and there was no one left to speak out for me.

Re:Well that depends... (5, Informative)

Andy Dodd (701) | more than 2 years ago | (#38870031)

Docomo seems to claim that it's background sync/checking traffic - but Google makes a point of reducing this as much as possible. There's good reason to do this - the less often data is transferred to keep "checked in", the less often a device needs to wake up, and the better battery life is.

This is, for example, why IM apps that use Google C2DM (Such as Google Talk - but any IM app author can use C2DM) have a minimal impact on battery life, while poorly written apps that are not even remotely suited to mobile devices (like Skype) are massive battery hogs.

If Google's services are "checking in" that often on DoCoMo, it's probably because DoCoMo's NAT boxes are broken - http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf [sigcomm.org]

Re:Well that depends... (2)

wrook (134116) | more than 2 years ago | (#38871697)

I think there may be something to what you are saying. To be honest, I was very surprised by this article (I would really like to see the original Nikkei report in Japanese... too bad they don't link it).

I'm on DoCoMo at the moment and I have had nothing but terrific service. I live out in the sticks, but no mater where I am I get good signal, good data availability, *very* good bandwidth and decent ping times. I've even tunnelled X through ssh on it and it was (barely) useable. That's considerably better than anything I would expect. Even on my occasional journeys to Tokyo or Osaka, I've never, ever had even the slightest problem. So if they are struggling, it's definitely not obvious.

However, up until November, the gmail app was seriously draining my battery. I ended up going to manual updates and suddenly all of my battery problems were fixed. Then I upgraded to 2.3 and ended up re-enabling auto-update on gmail. No problem. I attributed it to the OS upgrade, but it definitely could have been an infrastructure problem that they have fixed in my area.

I wonder if this is simply some technical issue that they are having and that the cheapest way for them to fix it would be to make changes to Android. In other words a non-story that some reporter got the wrong end of the stick for...

English usage (0)

Anonymous Coward | more than 2 years ago | (#38869657)

"reign" a kingdom. "rein" a horse. Please.

Re:English usage (1)

Mike Hock (249988) | more than 2 years ago | (#38869981)

FTFY
"reign" a kingdom. "rein" a horse. NIGGA Please!!!

Re:English usage (1)

K. S. Kyosuke (729550) | more than 2 years ago | (#38870059)

"reign" a kingdom. "rein" a horse. Please.

The anonymous writer was actually the shy King Richard III of England.

Re:English usage (0)

The Mister Purple (2525152) | more than 2 years ago | (#38870179)

Your signature makes me smile!

NTT DoCoMo is the standard gold of mobile networks (5, Interesting)

Anonymous Coward | more than 2 years ago | (#38869665)

Having been to Japan, and several locations around the world, I can say with fair certainty that NTT DoCoMo has the best network service I have *ever* seen. It allowed me to measure what is due to the iPhone's failings, and what is due to the network operator's failings. By contrast, in New York, AT&T makes getting signal a game of hide and seek. France stands somewhere in between the depths of AT&T and glory of NTT DoCoMo.

All this to say that if NTT DoCoMo feels Android is unoptimized... than I pretty much take their word for it.

Re:NTT DoCoMo is the standard gold of mobile netwo (1)

Chuckstar (799005) | more than 2 years ago | (#38869751)

I live in NYC and rarely have any problems getting a signal on AT&T. Actually getting any data or calls to my phone over that signal, however, is a distinct challenge. ;-)

I often experience dropped calls and slow data rates while my phone happily shows "5 bars" of signal.

Re:NTT DoCoMo is the standard gold of mobile netwo (4, Interesting)

tlhIngan (30335) | more than 2 years ago | (#38870503)

I live in NYC and rarely have any problems getting a signal on AT&T. Actually getting any data or calls to my phone over that signal, however, is a distinct challenge. ;-)

I often experience dropped calls and slow data rates while my phone happily shows "5 bars" of signal.

That's because AT&T is suffering from the same problem NTT DoCoMo is suffering from - control channel congestion. You're getting 5 bars alright, but the big problem is stuff like dialing and establishing data connections consume control channel bandwidth. Dropped calls happen because your phone's trying to switch towers and can't because it can't get a word in edgewise on the control channel.

Slow data ditto - the phone on 3G needs to establish multiple PDP data sessions to get 3G speeds, and if it can't talk to the tower because the control channel is busy, well, it suffers.

Control channel congestion (caused by all this plus texting) is why AT&T service can be horrible, despite having plenty of free channels available for data and voice. It's what took T-mobile down once (a bad IM app overloaded the control channel).

Think of it as the old-timey POTS phone days where you lifted the handset and told the operator who you wanted to talk to. And now have lots of people do the same and the operator's now overloaded trying to establish and tear down connections, leading to phone calls not going through, the operator not responding to you, etc.

Re:NTT DoCoMo is the standard gold of mobile netwo (3, Interesting)

interval1066 (668936) | more than 2 years ago | (#38870063)

So what? The world is heading to MORE digital data usage, not less, that's a fact. And the prices for use are going to drop, that's also a fact. Maybe NTT DoCoMo needs to up their capacity, not worry about throttling it so much. Words all providers need to take to heart.

Re:NTT DoCoMo is the standard gold of mobile netwo (1)

Pieroxy (222434) | more than 2 years ago | (#38870159)

I pretty much agree. Plus, upping their capacity will make them reduce power emissions from their antennas which will calm down the GSM-is-microwave freaks.

Re:NTT DoCoMo is the standard gold of mobile netwo (1)

treeves (963993) | more than 2 years ago | (#38871301)

I'd guess they've already upped their capacity, and they probably think you should up yours.

Re:NTT DoCoMo is the standard gold of mobile netwo (5, Insightful)

Andy Dodd (701) | more than 2 years ago | (#38870069)

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:NTT DoCoMo is the standard gold of mobile netwo (1)

bloobamator (939353) | more than 2 years ago | (#38871821)

IANANetworkEngineer, but it sounds to me like you are saying we need a separate network for the handheld devices, to deal with the different TCP settings. Is that even possible with a cell carrier? Can we do something like a VLAN?

Both (4, Insightful)

JavaBear (9872) | more than 2 years ago | (#38869691)

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:Both (3, Interesting)

Omnifarious (11933) | more than 2 years ago | (#38869783)

I agree. But I would add one more thing...

Perhaps Google could come up with a standard for pushing all these control signals and keep alives through a single gateway. That way apps could piggyback on each other to reduce traffic.

I must have at least 5 different ways to asynchronously receive messages on my phone. I would love a way to combine the traffic for all of these down to something small. Especially if (and I realize I'm an extremely rare case for wanting this) I could redirect it through a web app or something running on my server at home.

It's like how almost every social website grows some form of instant messaging that's relayed through the website's servers. Why can't they all just use Jabber and be done with it?

Re:Both (1)

JavaBear (9872) | more than 2 years ago | (#38869931)

"Perhaps Google could come up with a standard for pushing all these control signals and keep alives through a single gateway. That way apps could piggyback on each other to reduce traffic."

That is actually a very good idea, but it will add latency. Then again, a little latency on a line updated perhaps once every 2 minutes would hardly be the end of the world.

Re:Both (2)

poptix (78287) | more than 2 years ago | (#38869947)

Google already has a standard for pushing those control signals over a dedicated persistent TCP/IP connection (when your signal indicator goes from white to green it's connected). Many apps choose not to use it for one reason or another, Facebook Chat for example posts a huge XML request every minute or so to poll for new messages.

Also, Jabber sucks mostly due to its use of XML.

Re:Both (1)

sgt scrub (869860) | more than 2 years ago | (#38869957)

Isn't there SSH for Android? You could tunnel specific traffic through it like a VPN. If it works for you then set up VPN and forward everything through it. Also, last time I looked ejabberd had extensions for most all of the IM services. They might have modules that can work, or be modified to work, for your social media site(s).

Re:Both (1)

shutdown -p now (807394) | more than 2 years ago | (#38870061)

Perhaps Google could come up with a standard for pushing all these control signals and keep alives through a single gateway. That way apps could piggyback on each other to reduce traffic.

The catch is that you then need to migrate the existing protocols to use that service. End result, we end up with a bunch platform-specific protocols (push for iOS, push for Android, push for WP etc).

A big attraction of Android for myself is that it's the only mainstream mobile platform that lets you use existing protocols, because apps can just open a socket and do what they need to it, even in background. Meaning you can write a Jabber or ICQ client that connects directly to existing servers, without going through Google's servers, or those of the app author.

Re:Both (1)

Dog-Cow (21281) | more than 2 years ago | (#38870301)

iOS lets you do this.

Re:Both (1)

shutdown -p now (807394) | more than 2 years ago | (#38870419)

Does iOS lets an app in the background keep a socket open to a random port for an indefinite time period?

Re:Both (1)

Samantha Wright (1324923) | more than 2 years ago | (#38870461)

The primary reason mobile IM programs like eBuddy for iOS use bouncing servers isn't a technical necessity. There are plenty of IM programs that go straight to the source, in fact; even IRC, FTP, and SMB clients exist. One reason that eBuddy in particular connects through its own server is to provide an answering service, like an IRC reverse proxy. Simply put, it caches messages when you're out of signal range; if you have something like an iPod touch with no ubiquitous cell tower coverage, this is quite useful. (Of course, it also lets them read your stuff, but fortunately there are plenty of alternatives.)

Re:Both (1)

shutdown -p now (807394) | more than 2 years ago | (#38870775)

I understand that iOS apps can open sockets pretty much willy nilly. The question is, can they keep them open while they're in the background, and accept and respond to packets that come during that time? It would be a pretty useless IM client if it could only receive messages when it's opened.

From what I've seen in the App Store with respect to XMPP clients, my understanding that the only way to receive any kinds of network notifications in background is to use Apple's push service, so existing protocols don't just work. At least I don't know how else to explain why all apps that connect directly to my XMPP server don't support notifications (e.g. Crosstalk, Monal, Talkonaut, Jabba and many others). OneTeam supports push, but only with a proprietary server extension (which I believe routes it through the regular Apple push stuff).

Re:Both (1)

Samantha Wright (1324923) | more than 2 years ago | (#38871829)

OS News discussed this in an Android review [osnews.com] :

In iOS, application programmers can only perform the following seven tasks in the background:

Background audio - application continues to run in the background as long as it is playing audio or video content
Voice over IP - application is suspended when a phone call is not in progress
Background location - application is notified of location changes
Push notifications
Local notifications - application schedules local notifications to be delivered at a predetermined time
Task completion - application asks the system for extra time to complete a given task
Fast app switching - application does not execute any code and may be removed from memory at any time

So basically, no; the program is suspended if it isn't using one of these facilities. The OS obviously supports true multitasking, and there is a Cydia program called Activator which lets you control how individual programs behave, but it no longer works on iOS 5, and Apple tries to sandbox app developers as much as possible to control this component of the UI experience. Their reasoning, whether you agree with it or not (and I don't think many geeks do) is that such constraints prevent "Where is my battery going?" moments for the especially non-technical. Apparently ensuring the approval of this portion of the market was more important than permitting the flexibility that true multitasking obviously allows. Since Apple makes money anyway, they can always offer to remove these artificial limitations in a later update.

But don't get too upset over that last part about money—the fact that Apple gets a cut of every single sale is still way more unnerving.

Re:Both (4, Informative)

Andy Dodd (701) | more than 2 years ago | (#38870105)

They already do - it's called Cloud to Device Messaging (C2DM).

If C2DM is sending syncs/keepalives every 3-5 minutes, it's because broken carrier NAT boxes are forcing them to.

http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf [sigcomm.org]

Re:Both (1)

Anonymous Coward | more than 2 years ago | (#38870535)

Perhaps Google could come up with a standard for pushing all these control signals and keep alives through a single gateway.

That's called blackberry push technology. Some company called RIM came up with it more than a decade ago.

Maybe people should actually use it...

Re:Both (1)

danbob999 (2490674) | more than 2 years ago | (#38871443)

Just what we need. A proprietary protocol that only works with devices from one vendor.

Re:Both (1)

dargaud (518470) | more than 2 years ago | (#38870917)

Yeah, that and a way to tell some apps to only use wifi when available and never 3G.

Re:Both (2)

Chuckstar (799005) | more than 2 years ago | (#38869807)

Yes. But everyone (users and network providers alike) would rather that users' data usage focus on data the user actually wants, and less on "checking in" with various servers. I would think users would be just as annoyed to find out that Android handsets are really using 10x the bandwidth on idle tasks as other handsets (assuming it is true, that is).

Re:Both (2)

getto man d (619850) | more than 2 years ago | (#38869835)

Oh yes, the providers (at least in the US) are well aware of this trend. It's reflected in the current data usage pricing scheme and the "unlimited" plan max caps.

Re:Both (0)

Anonymous Coward | more than 2 years ago | (#38869959)

I was with you until "XML is fine."

There are limits though (4, Informative)

Sycraft-fu (314770) | more than 2 years ago | (#38869991)

The problem is that pesky Shannonâ"Hartley theorem. Basically it says that your data throughput is equal to your channel bandwidth and SNR. With a wired connection, there's a lot you can do there. With wireless, there's serious limits. SNR is fixed by environmental conditions, unless you are willing to up the S part a lot which requires lots of power and thus isn't suitable for mobile.

Bandwidth is limited since you have to share the airwaves with lots of stuff and certain frequencies are good for certain things. So going with 60GHz might sound great because a 1GHz channel would be no problem, but you find that it has trouble with attenuation due to water in the air, never mind walls. 700MHz cuts through walls pretty nice, but your channel will be much smaller.

Then of course there's the real sticking point: You share with everyone else in the same area. If your throughput is, say, 100mbps total you are sharing that 100mbps between anyone on the same segment as you. So have 100 users, all trying to go full blast and you'll each get 1mbps or so.

The only solution is to build out the segments smaller. However there's limits to how much of that you can do. You can't realistically segment the network down to an arbitrarily small level.

The "JUST UPGRADE THE NETWORK!" thing that geeks like to scream is very unrealistic in the case of wireless. Yes, with fibre we can have shit tons of bandwidth, when you are talking carriers in the hundreds of Terahertz, you can have some bigass channels, you can have lots of channels, SNR is quite good in fibre and you can always just lay more of it. However wireless has some real physical limits you butt up against.

We have to accept that when you are using wireless, especially longer range wireless, that there are limits to deal with.

Re:There are limits though (4, Funny)

ColdWetDog (752185) | more than 2 years ago | (#38870351)

The problem is that pesky Shannonâ"Hartley theorem

Well, since it's just a theory, it probably isn't true. Like evolution and such.

So, just ignore it.

Re:There are limits though (1)

viperidaenz (2515578) | more than 2 years ago | (#38870573)

Except it is not that simplistic. The cellular networks use code division, which lets users transmit over the air simultaneously, dramatically increasing the bandwidth available.

Re:There are limits though (4, Insightful)

doshell (757915) | more than 2 years ago | (#38871091)

CDMA techniques do not get you a free pass around Shannon-Hartley's channel capacity theorem.

Re:Both (1)

Kagato (116051) | more than 2 years ago | (#38870019)

I tend to agree. I would say that Phones in Japan have been much smarter and data heavy than the US equivalents for some time. So it's not like the Android phones are replacing a bunch of Nokia Feature phones. For that reason I also think NTT DoCoMo knows what it's talking about as far as optimization.

Re:Both (1)

Blue Stone (582566) | more than 2 years ago | (#38870037)

Maybe there should be a rating system for apps (and the phones themselves) similar to the Energy Star Rating, but for data instead.

Re:Both (1)

treeves (963993) | more than 2 years ago | (#38871337)

Similar to Energy Star rating, but actually useful, would be a better criterion I should think.

Re:Both (1)

Anonymous Coward | more than 2 years ago | (#38870041)

XML is fine, but hardly the most efficient way to transmit data, especially not without compression.

When can always tell when you have a VERY inexperienced developer - they think XML is a silver bullet to everything. In the vast number of cases I've come across XML in use, it should have NEVER been used nor even considered.

If you're a developer and you've used XML for local application configuration, please put a barrel in your mouth and pull the trigger. Interestingly enough, a disproportionate number of these developers seem to develop on Java as their primary language.

Re:Both (1)

Dog-Cow (21281) | more than 2 years ago | (#38870361)

I hate XML more or less as much as the next guy, but it has one advantage not really shared by any other format: every relevant development environment has libraries out the wazoo to manipulate it. That means less custom parsers and crap that is likely to introduce bugs.

Cocoa Touch, for example, uses plists, which are XML when stored in text form, extensively. The framework classes have lots of support for them, including loading and saving class hierarchies with a single method call.

Re:Both (2)

viperidaenz (2515578) | more than 2 years ago | (#38870709)

If you're a developer and you've discounted a valid option purely because other people misuse that option then please, put a barrel in your mouth and pull the trigger.

Yes, it's an esoteric Android issue. (4, Informative)

jeffb (2.718) (1189693) | more than 2 years ago | (#38869695)

It's some "control-traffic" issue that you, the customer, really shouldn't have to think about. It's nothing to do with an application that routes voice traffic over a data connection, thereby disrupting the carrier's finely-crafted billing practices.

Re:Yes, it's an esoteric Android issue. (0)

Anonymous Coward | more than 2 years ago | (#38869849)

"The leading Japanese mobile phone service provider identified an Android application, which enables free-of-charge voice communication, as a major cause behind a service disruption that occurred on Wednesday, the business daily said."

Yep, that was my first impression as well. I'm assuming the unnamed app is Skype.

Re:Yes, it's an esoteric Android issue. (1)

b0bby (201198) | more than 2 years ago | (#38869855)

Yeah, the control traffic every three minutes is *just* as important to them as stopping the VOIP apps...

Re:Yes, it's an esoteric Android issue. (1)

kwark (512736) | more than 2 years ago | (#38870023)

My guess is that the control traffic related to voip might be SIP over UDP. That kind of traffic is soley controlled by the application and the server, if the client is NAT-ed an abundance of SIP control packets might be necessary for keeping the portmapping alive. But these persons who though that a control protocol should be done over UDP, should be the first againt the wall in my book.

Re:Yes, it's an esoteric Android issue. (2)

viperidaenz (2515578) | more than 2 years ago | (#38870779)

But these persons who though that a control protocol should be done over UDP, should be the first againt the wall in my book.

Its actually a protocol that can run over UDP, TCP or SCTP. Someone who thought a control protocol should be able to run over many different underlying protocols should be the last against the wall.

What happened to the Japanese? (0)

bogaboga (793279) | more than 2 years ago | (#38869739)

The Japanese used to be very pragmatic people. What happened to them? Some have said the South Koreans have taken over. I am inclined to agree when I look around my home.

Android is 'open'. The Japanese build and maintain their networks. The problem they describe is can be stemmed by a [simple] software 'update'. Why don't they do just that?

Again, what happened to the Japanese?

Re:What happened to the Japanese? (1)

medv4380 (1604309) | more than 2 years ago | (#38869885)

Yes it is open source. But how many handsets from how many manufactures are out their that need the update. It would be easier to just update the core OS and then convince the manufactures to get their version of the OS updated. Then they can do an over the air push of the updates. Otherwise you have to write the fix yourself for each version. Convince the manufactures to give you the keys needed to push the update. Then do it all over again for each brand when the OS has other updates because your update isn't in the Core OS.

Re:What happened to the Japanese? (1)

Grishnakh (216268) | more than 2 years ago | (#38870109)

I dunno, but if you look at the automotive world, the south Koreans have certainly stolen the Japanese's thunder there.

subtext translation: (1, Offtopic)

Thud457 (234763) | more than 2 years ago | (#38869759)

"Andloid's not done until VOIP won't run."

Control signals- NOT Data (5, Interesting)

sonicmerlin (1505111) | more than 2 years ago | (#38869779)

Uh... Control signals have nothing to do with overall data consumption quantities. When you send a text message, you send the 160 or so bytes of data through control signals. The issue here is that Android doesn't control the way its apps try to contact the towers, basically hammering them if they don't respond properly. This issue is one of the reasons Android has massive standby battery drain problems, as detailed in this 300 page xda thread: http://forum.xda-developers.com/showthread.php?t=1179809 [xda-developers.com]

The galaxy nexus has its own 100+ page thread dedicated to battery drain on standby.

Re:Control signals- NOT Data (1)

StikyPad (445176) | more than 2 years ago | (#38870095)

Yup, and if there are this many misguided comments conflating control signals with data usage on Slashdot, imagine how easily the issue can be spun by carriers to intentionally misrepresent the issue to an ignorant consumer base.

Re:Control signals- NOT Data (1)

Anomalyst (742352) | more than 2 years ago | (#38870241)

If DoCoMo (sounds like a Beach Boys song) thinks this is an issue, let them dedicate some of THEIR resources to provide an open source solution, whether it be kernel changes or an ECMA API spec that would that would allow tuning the communications flow that they find so disruptive. Make a positive contribution instead of having your suits whinging about how bad it is. I have no doubt that mutiple apps are sending keep alives and other such stuff which could be consolidated. I am sure DoCOMo will have no objection to volunteer server resources to centralize the notifications.

Re:Control signals- NOT Data (1)

robmv (855035) | more than 2 years ago | (#38870303)

Android problem or applications problems? What is the difference of Android vs a Laptop with 3G? If some Windows applications is using a lot of network, could the telco ask Microsoft to change Windows so that doesn't happen? The same way, If a Window application is on an infinite loop, consuming all the batery, is Windows the culprit here?

Stop blaming a multitasking OS for the failures of the applications. Android 4.0 is adding data usage limits per application so user can identify those buggy applications

Re:Control signals- NOT Data (4, Insightful)

Miamicanes (730264) | more than 2 years ago | (#38870385)

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:Control signals- NOT Data (1)

scamper_22 (1073470) | more than 2 years ago | (#38870619)

Which begs the question of this is an Android problem or a wireless issue. I really don't know where one begins and the other ends.

To what extent can network operators control the wireless devices?

Like is there a 3G/LTE command that DocoMo can send a device to tell it to limit its traffic to X kpbs, or pause sending for y seconds...

The anthem (0)

Caerdwyn (829058) | more than 2 years ago | (#38869785)

So, does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reigning in?"

Isn't the Slashdot mantra always "It's open source! Therefore, it's someone else's problem when it comes time to pay the bills!"?

Re:The anthem (1)

noh8rz2 (2538714) | more than 2 years ago | (#38869923)

a.k.a, "Information wants to be free (to me)!"

format and rhymes (0, Offtopic)

bhcompy (1877290) | more than 2 years ago | (#38869787)

DoCoMo
MoDaCo
Comodo

Where is the originality?

Re:format and rhymes (1)

meerling (1487879) | more than 2 years ago | (#38869857)

It's Japanese, if you knew the alphabet you'd understand a bit more.

Re:format and rhymes (0)

Anonymous Coward | more than 2 years ago | (#38869945)

Then please enlighten those of us who don't know the alphabet.

Snide comments are not helpful.

Re:format and rhymes (0)

Anonymous Coward | more than 2 years ago | (#38870231)

I don't understand what you are trying to say, there are about 100 other sounds in the "alphabet", what is so special about do, ko and mo.

Re:format and rhymes (3, Informative)

newcastlejon (1483695) | more than 2 years ago | (#38870483)

A quick look on wikipedia [wikipedia.org] tells me that DoCoMo is short for "do communications over the mobile network", while the Japanese word "dokomo" translates to "everywhere".

Re:format and rhymes (1)

DinDaddy (1168147) | more than 2 years ago | (#38870581)

I saw a Docomo poster in Tokyo that read "DOing COmmunications the MObile way". If that's the basis of their name, not sure how the Japanese "alphabet" enters into it.

A little less vague? (3, Interesting)

vlm (69642) | more than 2 years ago | (#38869823)

So I've got one of them gen-u-ine android phones. Which apps are supposedly hammering the network?

My guess is the GOOG latitude GPS plotting thingy must be updating fairly often. So in the big list of blacklisted apps, I've got one "i donno maybe guess".

This is important to me because my batteries life is very short... Enabling latitude position tracking thingy meant my battery died in about 10 hours (which is an issue for a guy who works 10 hour shift bracketed by a modest commute), so I shut it off, gaining me at least 6 more hours, making it very easy not go thru a working day without charging. I wonder if I disable "something else" if I'll magically gain yet another 6 hours... or more...

CDs? really? (-1, Offtopic)

defected (908047) | more than 2 years ago | (#38869829)

really... does anyone use CDs anymore? Especiallly CDs filled up with a bunch of crap?

I don't see it (1)

hawguy (1600213) | more than 2 years ago | (#38869971)

TFA:

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

I still don't see the issue they have... what is the issue? What are these "control signals"... is it TCP traffic or cellular network control signals? What resources are they consuming? Have other carriers had the same kind of problem or is it specific to DoCoMo? What update frequency do they recommend if 3 minutes is too often? 4 minutes? 6 minutes? 60 minutes?

Re:I don't see it (1)

viperidaenz (2515578) | more than 2 years ago | (#38870943)

Perhaps DoCoMo are the first to have these issues as they have over 57 million customers, half the entire Japan market which is made up of high (the highest revenue per customer in the world) value customers (read: lots of data usage).

One more option (1)

Ichijo (607641) | more than 2 years ago | (#38870135)

So, does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reigning in?

Given that this is a shortage, and that a shortage is when demand exceeds supply, DoCoMo can either add supply by investing in its network, or they can reduce demand by raising the cost of bandwidth, at least during peak periods. This gives DoCoMo two options to eliminate congestion on its network.

Raising the cost of bandwidth could be done pretty easily by setting caps on peak hour data usage.

Which app? (1)

Andy Dodd (701) | more than 2 years ago | (#38870167)

Was this a third-party app or an official Google app? If it's third-party, Google has no control. One packet every 3 minutes is, honestly, pretty damn good for some apps. Skype can cause a device to wake up once every few seconds (which is the main reason it's an epic battery hog).

Google's own apps are about as efficient as they can be in order to minimize periodic data, because keepalives and checkins wake the device, draining battery. The problem is that some major carriers have broken NAT boxes ( http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf [sigcomm.org] ), forcing Google to reduce keepalive intervals so that these carriers don't kill TCP connections - which forces an expensive (in terms of time, battery, and network resources) connection setup sequence.

Re:Which app? (1)

TuringCheck (1989202) | more than 2 years ago | (#38871289)

Even worse, having some type of Instant Messenger connected will cause a lot of traffic with friends coming on and off-line. I see pople having hundreds of friends online at any time.
GTalk for mobiles (not only Android) already tries to address these issues by pooling together updates. This sucks. The overall result is making mobiles 3rd world parties in the Internet game.
When I go online from a desktop I appear online in seconds on other desktops. On a mobile it may take several minutes to be noticed. Go on and off-line a few times and the situation can become very confusing - a stale state may persist for hours.

Precedents (1)

carrier lost (222597) | more than 2 years ago | (#38870181)

...does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reigning in?

640k ought to be enough for anybody.

Well FU. (0)

Anonymous Coward | more than 2 years ago | (#38870289)

*YOU* started it by superlow tcp timeouts. Give the users a public IP without double- and tripple-nat that's mainly intends to screw with our sessions for profit-maximisation (by breaking IM and voip-apps), *then* you can demand that users don't use the data their ****** PAYING for!

sigh, false dichotomy (1)

John Meacham (1112) | more than 2 years ago | (#38870339)

I know it makes articles sound more dramatic and controversial, but sometimes the answer is obvious:

"So, does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reigning in?"

The answer is clearly "both". Apps and android should optimize their data usage, doing so increases battery life and gives a better user experience all around. If DoCoMo is identifying particularly troublesome apps, then that is helpful to decide where to start hacking. _Also_, DoCoMo should be upgrading its infrastructure. It is clear that data use will only rise, and they certainly would like to have more customers, apps reducing their usage is a good thing, and will create a better experience, but not a solution to the problem that people actually have uses for all that data, and said usage will grow.

lol (1)

Charliemopps (1157495) | more than 2 years ago | (#38870391)

So after Google tells them to go screw themselves, what are they going to do? Ban the operating system?

The solutions to these problems are simple. If you have 100 customers, and you have 100MB/s of bandwidth on your network, don't sell them all 5MB/s plans. ITS SIMPLE MATH. To blame this on Google is like an all-you-can-eat buffet complaining to a local taxi service that they're dropping off too many fat people. Who do you expect to pay for all-you-can-eat? Twiggy?

Network usage (0)

Anonymous Coward | more than 2 years ago | (#38870439)

Seems like they really shouldn't oversell their network.

You can't offer high end services and phones and expect people not to use them. This sounds awfully familiar to North American telecos offering Unlimited* service and complaining when users actually use their bandwidth.

Re:Network usage (0)

Anonymous Coward | more than 2 years ago | (#38870759)

Seems like you should see the absurdity in your statement.

It's the war cry of the geeky idealists that a telecom system should be designed to handle 100% utilization from 100% of the users 100% of the time. Were the network designed that way, cellular service would cost $10,000 per month.

Go take a class in economics and then come back and contribute something useful to the discussion.

Let me see here... (1)

fish_in_the_c (577259) | more than 2 years ago | (#38870615)

Should Android be more efficient, and every app it runs. OF COARSE. There is not such thing as efficient enough, but Google has to decide if it is worth
their money right now.

Should the network provide stop wining because their network is running up against the physics of
allowing too users on it and just fix the problem. Probably.

Sorry, but don't take on more subscribers then you can service. And if their are devices that you don't like their affect feel free to ban them.
If that doesn't make you money , that's called business. It's balance. Either provide what people want , or go out of business.

Sprint on iPhone network effeciency (0)

sunfly (1248694) | more than 2 years ago | (#38870747)

Sprint's Dan Hesse said the iPhone is so data-efficient, it will help Sprint keep its mobile data plans unlimited. He claims they do not ping the network near as much, and are better at handing off data to wireless networks. http://www.forbes.com/sites/elizabethwoyke/2011/10/26/sprint-ceo-iphone-will-help-us-keep-unlimited-data-plans/ [forbes.com] Assuming that was a comparison to Android?

Just wait until Sili is released! (0)

Anonymous Coward | more than 2 years ago | (#38871327)

*Then* they'll have bandwidth problems.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?