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