Slashdot Mirror
Can Apps Really Damage a Cellular Network?
schnell writes "In FCC filings earlier this year, T-Mobile described how the behavior of one Android IM app nearly brought their cellular data network to a breakdown in one city. Even more interesting, the US carrier describes how just the 300,000 unlocked iPhones on their network caused massive spikes in data usage. T-Mobile is using these anecdotes as evidence that mobile carriers should be able to retain control over the applications and devices on their network to ensure quality of service for all users. Do they have a point?"
Old Ma'Bell used the same argument decades ago when they were trying to force people to continue buying telephones directly from them because the phones were made specifically for THEIR network. It's all a load of crap. They just want control because control = profit.
data plans is biting you in the a** when it comes time to deliver, perhaps you should stop selling people unlimited or huge data plans... Arguing that not being able to control exactly how people use their data plan when you've advertised and sold them on the idea that they can do just about whatever they want seems sort of silly.
I'm not arguing that these phones/devices don't have the potential to cause huge problems, obviously they do, but you can't have your cake and eat it too.
Loading...
Is that the only thing the first post should say is 'No'
I was thinking exactly what you said, as a Network Admin in yesteryear I can't imagine anyone who says 'the users broke my network by using it!'
Our network simple handle 'bad users' on its own. To much traffic was simply handled by throttling the user to a safe level when needed.
Seriously, how can you not have complete control over a network when its this size? I'd have to resign if I was in charge of their network and had to say 'some random user broke it, sorry boss'
You NEVER trust any part of your network to 'play' nice, even if its under your complete control ... you can make mistakes too. You just assume the end users aren't going to play nice, and go from there, most do bad things without even knowing they are bad so you just plan for it like you would in any other business process.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
So the carriers in the US must have total control or their network is going to explode, eh? How is it that you can buy whatever device you want and connect it to whatever network you want here in Europe, eh? Why haven't the mobile networks in the EU exploded yet, then, eh?
9/11: Never forget it was a false-flag operation
do not constitute a reason for me to submit to having which applications I can and can't run decided by a third party.
Bandwidth should be managed on a user-by-user basis, not an application-by-application basis. If you have an application that sucks up all your bandwidth, then you shouldn't have anymore bandwidth to use. Carriers should advertise burst and long-term bandwidth rates and if you go above the long-term rate you should be subject to having your bandwidth capped at that rate.
No telling you which application you are allowed to run and which you aren't. No throttling based on port. If you're a customer, you are promised X bandwidth and no more. The carrier is allowed to deliver in excess of that if they so choose, but they aren't allowed to decide you use it for.
And the carrier should not be allowed to decide on a per-application basis whether or not you get to exceed the bandwidth cap. It must be based on a global, application agnostic bandwidth usage policy that chooses which customers get the extra bandwidth (if any) based on some algorithm that has nothing to do with what their traffic contains.
Need a Python, C++, Unix, Linux develop
Clearly the most they can do is continually use up as much bandwidth as possible.
You sir, are wrong.
And it's obvious you didn't RTFA.
TFA isn't just talking about bandwidth, it's talking about connections.
Poorly coded apps that refresh too often will kill a cell tower.
[Fuck Beta]
o0t!
That's not true.
UMTS signalling traffic is actually a big worry too.
Setting up and tearing down radio resource connections all the time has a burden on the network. Mobile applications, with their diverse update patterns (e.g. polling every 30 minutes (email apps), or minute or even few seconds (e.g. IM apps)), can make it difficult for carriers to set up their RRC inactivity timers and various other settings in a way that minimises signalling load on the network.
While EDGE is counted under the 3G banner, it's really not 3G at all.
EDGE is upgraded 2.5G (GSM/GPRS), speeds are not even close to basic HSPA.
There's a theoretical max of 473.6kbps for EDGE, 14mbps with HSPA. So the "traffic spikes" claimed by T-Mobile are laughable. If you're network can't handle 1/28th of it's capacity then there's something seriously wrong with it.
Actually, yes, it is possible.
You simply flood the network with control messages. That will effectively DoS the tower. What kind of control messages? Well, sending an SMS is a control message. Setting up and tearing down data and voice connections are other control messages, and all are done on behalf of apps.
Supposedly, one of the major reasons AT&T is having issues with the iPhone is because the iPhone actually does this, a lot. Control channel bandwidth is limited and normally, you don't have much going across it (because it's just call setup/teardown and the like). But with the meteoric rise of SMS and data usage, the control channel actually is in somewhat of a bandwidth crunch.
Europe and Asia have no problems with iPhones as they've gone to a dynamic bandwidth control channels because of the popularity of SMS. North America until recently didn't need to. So now control channels are somewhat packed with text messages, and you introduce the iPhone with its aggressive power management that tears down data connections ASAP. So a data channel might be established and torn down to view one web page or whenever an app requests data. Most phones prior to this created a data channel and hung onto it until it idled for a long period of time (after all, you're billed by the packet, so keeping the data channel open costs nothing, and it means it's always ready when you need it so you don't have to wait to establish the data channel again and again).
I can see a few apps that constantly abuse this which can easily take down a network. Setting up/taking down a voice call, setting up/taking down the data connection, do it fast enough and you can really clog up the tower. Enough people do this and the tower can be put out of service because it's stuck establishing and taking down connections so fast that no one else can get in.
Raw bandwidth wise though, you're not likely to do anything other than slow down due to congestion if the tower's uplink gets saturated.
In fact, that's what the IM client did - it established and tore down connections very quickly. A phone with aggressive power management (required on Android) would basically be spewing out control messages all day. This can be made more painful if the carrier makes notes in a database for billing purposes.
Actually, it wasn't necessarily bandwidth that was the problem. FTFA:
T-Mobile network service was temporarily degraded recently when an independent application developer released an Android-based instant messaging application that was designed to refresh its network connection with substantial frequency.
In other words, this app was continually connecting and disconnecting. It didn't really have anything to do with bandwidth.
What's funny to me, though, is the solution:
These signaling problems [...] ended up forcing T-Mobile's UMTS radio vendors to re-evaluate the architecture of their Radio Network Controllers to address this never-before-seen signaling issue. Ultimately, this was solved in the short term by reaching out to the developer directly to work out a means of better coding the application.
So T-Mobile's UMTS radio vendors learned something. The developer learned something. And T-Mobile's network, ideally, won't suffer from this problem again.
Sounds like a win-win to me. I don't see the problem.
Basic 3G is UMTS, 384kbps. EDGE can attain those speeds but typically, 200kbps is extremely good bandwidth and 100kbps is very good. 50kbps is not atypical. I've never gotten faster than 150kbps on EDGE.
On the other hand, I find that it is not at all difficult to get a full 384kps out of a UMTS device.
EDGE and GPRS seem much more affected by voice and messaging traffic than UMTS and HSPA are.
So T-Mobile is saying that they need to be able to have complete control over which apps can be run on devices on their network.They are asking us to accept their absolute control over what we do with our wireless devices.
Let me ask you all this: Has T-Mobile (or any of the other carriers for that matter) earned the benefit of the doubt to the point that we, as consumers, should trust them with this absolute control? They are claiming that unlocked phones or Droid apps are going to "damage their network". Given their history, is there any reason we should believe them?
I've noticed that it's possible to hook all sorts of devices to the Internet, which somehow keeps working. We haven't had to resort to "AT&T-approved operating systems, or browsers, or computers" in order to "protect" the Internet (which I'm sure the broadband providers look at as "their network").
It seems that we need a level of regulation and reform regarding the Internet and wireless networks that goes beyond simple "Net Neutrality". Maybe we should put the burden of proof on the providers to show why connection to the Internet should not be a regulated public utility.
I think stories like this make it pretty clear what the Internet is going to look like if Net Neutrality laws are not enacted.
You are welcome on my lawn.
I actually did just read the article and contrary to what many people are posting about, this isn't about data usage and utilization, it's about connectivity utilization and overhead. It seems that similar to opening and closing a database connection there is some overhead in establishing a data connection on a cell phone which is seems is again similar to what happens when you send and SMS. It seems that smart phone development is similar to desktop development in that the application is rarely responsible for creating it's own network connection and instead relies on the OS to handle the network connection. If the phone OS is designed to create and destroy a new data connection for each request then how is that the applications problem. Also, how does a jailbroken iPhone handle data connections differently than a non jailbroken iPhone, the claims made in TFA are just absurd.
I recall reading somewhere that some European carriers use a different methodology that doesn't create such a bottleneck when these connections are opened and closed. So it seems that once again, the US cell carriers are trying to blame the users of their network for causing problems that would (could, and should) be fixed by upgrading the infrastructure. Cell providers make way too much money to complain about not being able to upgrade their networks.
Do what thou wilt shall be the whole of the Law - Aleister Crowley
Yep, you hit it right on the head: FTFA
"T-Mobile network services was temporarily degraded recently when an independent application developer released an Android-based instant messaging application that was designed to refresh its network connection with substantial frequency,..."
Lots of comments chiming in on overselling bandwidth, but as you've noted, this has nothing to do with bandwidth. Its an infrastructure problem, and one that is slightly out of their control. They noted with this one app alone, network utilization increased 1200% per device. Its a signaling issue they didn't anticipate.
And if the ocean was made of taffy we could just walk our way to China.
Hi, I'm a representative from your ISP and I noticed that you're not posting from an approved web browser. Also you have some applications on your computer that are not approved.
Due to these violations, we're going to be disconnecting your service.
There's no -1 for "I don't get it."
If switching to another network were a matter of going into Android Settings and picking "Sprint", "Verizon", "AT&T", "US Cellular", "Metro PCS", or some other company from the dropdown, agreeing to their rate structure, validating your credit card, and ending your relationship with T-Mobile on the spot... you might have a point. Except, it's not. Regardless of whom you use for wireless service in America, you're chained to them by a relatively expensive phone that's a de-facto doorstop on the other carriers (with very, very few exceptions), plus beaten into passive acceptance by punishingly expensive early termination fees and lube up your ass all over again for the new company.
I don't think there's a single wireless carrier in *AMERICA* where you can use a gigahertz-class Android phone -- unlocked, unsubsidized, or otherwise -- without either being an existing customer or agreeing to a minimum 2-year contract. T-Mobile is at least nice enough to give you a $20/month discount if you bring your own phone, but NONE of them will let you casually establish service that includes 3G data speeds without at least an initial contract. The carriers do everything they can to make the market for wireless voice and data service as inelastic as they possibly can, and deserve no pity or compassion from the American public whatsoever.
> Setting up and tearing down radio resource connections all the time has a burden on the network.
Most of the aggressive instant teardowns are due to the criminally-inadequate batteries shipped with the iPhone and every gigahertz+ Android phone that will leave you "powerless" in 4-6 hours without aggressive battery management. If carriers like T-Mobile want to reduce the teardown rate, they could start by telling companies like HTC and Samsung to ship the damn phones with adequately-sized batteries in the first place. It really says something when you go to web forums for high-end HTC, Samsung, and Motorola Android phones, and more or less HALF the postings are directly or indirectly related to battery life. Aftermarket extended batteries are a piss poor option, because the form factor of the phone usually ends of constraining them into an obnoxious tumor-like lump instead of an extra millimeter of overall girth.
Five years ago, the Samsung SPH-I500 was almost regarded as "fatally flawed" because its battery *barely* could make it through 16-20 hours without a charge. Then Steve Jobs told the world it was normal and OK for phones to die after being away from a charger for 4 hours because it made the phone look thin and sexy, and the entire industry abandoned its common sense and blindly followed with undersized batteries. Fuck, it pisses me off. Imagine how much fun someone like Motorola could have if they'd released the DroidX with a beefy -- yet sculpted and well-distributed -- 3000+mAH battery that enabled it to run full-bore for 24 hours on a single charge with no real power management to speak of. They could have *shredded* the Evo/DesireHD and Galaxy S for dying by mid-afternoon, comparing them to anorexic models competing in the Ironman and dropping dead halfway through, and HTC & Samsung wouldn't have any real recourse besides sending everyone a free battery as an apology, and making sure their NEXT generation of phones had nice, beefy batteries too.
Hell, they could even resurrect Sir Mix-a-Lot's career for the commercials.
"When it comes to battlife, SteveJobs got nothin' to do with my selection. Four hours -- maybe six -- not all day? Not MY phone!" (sound of cracking whip amidst dancing troupe of big-backed 'Droids)
It's not TCP/IP that tears down the connection. That is a physical layer function, regardless of if the call came from the application layer. TCP/IP does not have influence over the physical layer.
When I was a kid not only were there no cellular phones - you weren't even allowed to own your own wired phone in the US. You had to lease it from AT&T for a monthly fee because Alexander Graham Bell founded that company (sort of - read the prior link for the historic details), and he invented the telephone (this much is not in doubt). It's only recently that we're allowed in the US to bring our own phones to the wireless network, and they've pretty much handled that by making sure that each phone generally works with only one wireless network. We're pretty accustomed to being molested by our communications providers. Only a few years ago it was common to charge more than a dollar a minute to talk to your neighbor across the street if the street was one of the imaginary lines that separated Regional Bell Operating Companies. It was cheaper to call across the country, or even a foreign country, than to organize a meeting of the Parent-Teachers Association (PTA). Back then I bought Karma by subscribing to a cheap long-distance company and performing the contemporary version of bittorrent by serving as a "filebone hub" on an antique mail and data network called "FidoNet". It was like the Internet except in batch mode and we had parties called Get Togethers (GTs). Back then I was fiending for Internet because I had had it in the military, but couldn't get it because it wasn't available to the general public - only businesses, schools, folks who could afford CompuServ and so on. Get Togethers were a lot of fun because we got drunk, and sometimes naked, in person rather than over video chat. CUCME (see you, see me - an early video chat program) wasn't invented yet - it was the late '80's, or very early '90s. We still stayed anonymous in person mostly - everybody had a "handle" - which nym is taken from a completely irrelevant radio network (Citizen's Band) which will occur later. But I digress.
Anyway, there was this Georgia peanut farmer, whose name was Thomas Carter (not the former US President Jimmy Carter, as some (formerly including me) believe), who wanted to make phone calls from his tractor in the field. He was electronics savvy, so he rigged up a Citizen's Band radio that would allow him to dial the phone and talk on it, and this was the Carterfone and he sold copies of it, as any right-minded entrepeneur would. And of course AT&T shut him down because they didn't own this thing and so could prevent him from using it on their network. He sued, and it was many years later that his lawsuit resulted in the breakup of the US phone monopoly. That led to AT&T becoming at first just the vestigal long-distance portion of the former phone company, and later just a brand.
Non-Sequitur: The breakup also led to Unix - which was invented by Bell Labs (a division of AT&T at one point which invented not only Unix and C, but a great many other useful things), being divided into parts. The Unix name was sold to The Open Group, which certifies Unix to this day. The Unix source code and OS was sold first to Novell, which sold it to a quite respectable Linux .com called the Santa Cruz Operation, which burned through their .com millions and sold it off to a spinoff of Novell called the Canopy Group. Actually, they sold it to a spinoff of the spinoff. This story goes on for a long time, and is slowly grinding to an end documented here. Unix was the coolest thing that AT&T ever did, and I wanted to work that in even though the code is now owned by a gang of bastards who are determined to ruin every last bit of its utility. But I digress again. Forgive me, it's late.
AT&T's motto was: "We don't have to care. We're the PHONE COMPANY." The company that owns the AT&T brand now has nothing to
Help stamp out iliturcy.