Forgot your password?
typodupeerror
AT&T Businesses Network Verizon Wireless Networking

Wrong Number: Why Phone Companies Overcharge For Data 105

Posted by timothy
from the now-tell-me-something-I-don't-know dept.
MrSeb writes "A recent study (PDF) conducted by UCLA professor Chunyi Peng shows that carriers generally count data usage correctly, but those customers who commonly use their device in areas with weak signal strength or to stream audio or video are often overcharged. Peng and three other researchers used data gleaned from an app installed on Android smartphones on two different carriers. The issue appears to be in how the system is set up to count data usage. Under the current scenario, data is charged as it is sent from the carrier's network to the end user. What does not exist is a system to confirm whether the packets are received, and thus preventing charges for unreceived data. Peng demonstrated this in two extreme circumstances. In one case, 450 megabytes of data was charged to an account where not a single bit of it had been received. On the flipside, Peng's group was able to construct an app which disguised data transfers as DNS requests, which are not counted by the carriers as data usage. Here they were able to transfer 200 megabytes of data without being charged. Overall, the average overcharge is about 5-7% for most users. While that does not seem like much, with unlimited plans gone and data caps in style that could pose potential problems for some heavy data users. Could you be going over your data allotment based on data you never received? It's quite possible."
This discussion has been archived. No new comments can be posted.

Wrong Number: Why Phone Companies Overcharge For Data

Comments Filter:
  • by ccguy (1116865) on Saturday September 15, 2012 @06:35AM (#41345035) Homepage

    DNS requests, which are not counted by the carriers as data usage.

    I'd love to see a source for this.
    Well, a source to anything actually, but it seems to much to ask around here these days...

    • by joostje (126457) on Saturday September 15, 2012 @06:46AM (#41345081)
      • by KiloByte (825081)

        Hey man, quiet, please! Like every single airport/etc which tries to charge (exorbitantly) for connectivity passes DNS through, so they can intercept connections and display their paywall page. If more people know about iodine, these holes will soon be plugged. A good part of countries has nazi laws forbidding open hotspots, so you can't get those, too.

        • by Zocalo (252965)
          Who needs Iodine? Anyone with access to an an SSH server could bind it to port 53, then just establish SSH tunnels to it to do all sorts of stuff, not least of which are avoiding all sorts of data charges and local content filtering. Hypothetically speaking, of course... ;)
          • That's assuming port 53 traffic is free rather than DNS traffic being free - not the same thing.

            • by Zocalo (252965)
              Sure, but that would require either DPI of port #53 traffic or forced redirection of DNS traffic to the ISP's servers to matter. In my experience there are not too many airport/hotel portals, wireless hotspots or repressive governments that are doing that (yet).
              • by profplump (309017)

                Actually many hotspots *do* require you to use the local DNS server. It's pretty trivial, since that's part of the DHCP config, so it's not like end-users have to do anything to make that work. In those cases your data needs to be close enough to the DNS protocol to get propagated upstream, which is basically what iodine does.

                Also note the SSH more or less requires TCP, so even if you allowed port 53 outbound you could limit access to the UDP protocol and effectively block SSH and many other tunneling tools

            • by KiloByte (825081)

              If port 53 is unhampered, iodine will just put the traffic there -- but its primary purpose is encapsulating packets in real DNS packets.

              Imagine queries like "TXT packet.123.dns-encoded.contents.are.abcdefgh123456.iodine.slashdot.org". The encoding is similar to uuencode, except for a different set of legal characters, and not all characters being legal at the beginning or end of a word.

          • 3...2...1...

            Seriously though, if airports, etc., wanted to enforce their paywall, they can just drop all packets that aren't destined for "inside the free walled garden" and be done with it.

            DNS or other UDP or TCP access to a machine inside the walled garden e.g. a "pay me" web site? Traffic allowed.

            DNS or other port UDP or TCP access to outside the garden? Drop or re-route to a fake server at that address.

            As for ISPs and cell-phone-data providers that offer free DNS lookups, expect most of them to start

    • Re: (Score:3, Insightful)

      by BumboChinelo (2527572)
      It is true, I work for a supplier of GSN nodes and most operators configure GGSN/PGW to classify DNS and TCP SYNs as free. However, this freebie is overset but charging retransmission in the telco IP network. Personal experience in comparing sent bytes vs received bytes on remote and charged bytes in CDRs. Wiresharking on Gn interfaces pointed out the origin of extra bytes in CDR. So there never is a free lunch
      • Re: (Score:2, Interesting)

        by Anonymous Coward
        I also work for a supplier of GSN nodes (with charging in particular, hence posting as anonymous coward). I know we can't work at the same company, because where I work, a major bug like that would halt any delivery until it's fixed. There's no way you'll have more bytes in a PGW/GGSN CDR than what you see on Gn. A bug report would be written immediately. Any internal packet drop in our system will not be counted in CDR:s. Packet drops on Gn? Not going to happen. So you're either making that up, or your W
      • Re:DNS not counted? (Score:5, Informative)

        by isj (453011) on Saturday September 15, 2012 @09:45AM (#41345687) Homepage

        The operators that my employer delivers charging solutions to rarely use the byte counters from the GGSN because they charge he traffic types differently, e.g. "free facebook" while other traffic is charged based on byte counters from the DPI box. It is true that some of the newer GGSNs/ASN-GWs have adequate DPI capabilities so they can classify the traffic with enough granularity and the byte from them can be used.

        There is one slightly fishy thing in the study (yes, I read the fine paper). Their test with logging on, go idle, move to radio-inaccessible room, then have server start steaming UDP to the phone (which will be dropped due to inaccessibility). In my experience the SGSN/GGSN quickly signals that the user has gone offline (PDP session termination), and the stream of UDP from the server is blocked at the DPI or the GGSN. Sounds like the operator that the study used has a major bug in its charging setup where PDP session termination doesn't also stop the IPuser association.

    • I'd love to see a source for this. Well, a source to anything actually, but it seems to much to ask around here these days...

      Seems to me the study is the source. Called a "primary source" where I come from.

    • Hmm, so I should run my SSH socks proxy over port 53...
  • by Anonymous Coward on Saturday September 15, 2012 @06:35AM (#41345037)

    Well I sent a check for my monthly bill... not my fault you didn't receive it.

    • by Anonymous Coward on Saturday September 15, 2012 @09:58AM (#41345735)

      Reminds me of a joke. Telephone lineman is recruited into the army. Gets to the rifle range for practice. Everyone is shooting, targets are being hit by all but the lineman. Sarge comes up and asks why his target got no hits on it. Lineman ties a rag over the end of his rifle and fires off a round, shows the sarge the rag with a hole in it and says, "No problem at this end."

  • Link to study (Score:5, Informative)

    by ccguy (1116865) on Saturday September 15, 2012 @06:38AM (#41345051) Homepage
  • by joostje (126457) on Saturday September 15, 2012 @06:41AM (#41345063)
    I guess that means the operators will shortly release an update for the phone OS's to also charge for the data the phone sent but wasn't received by the operator.
  • Step 1 (Score:4, Funny)

    by Spy Handler (822350) on Saturday September 15, 2012 @06:46AM (#41345077) Homepage Journal

    1. write an app that disguises streaming porn as a DNS request
    2. ???
    3. Profit!

  • by dtmos (447842) * on Saturday September 15, 2012 @07:21AM (#41345173)

    Resending a packet due to a missed ACK takes up air time, just like it did sending it the first time, and the carriers have no control on where the user will be. If they make their systems robust enough to move their present average packet reception rate from an already-good 93-95% to, say, 99%, this will only enable their users to move down another floor in their sub-basements, or another few city blocks, or another cubicle row deeper into the building, before the average goes back down again -- after all, wireless systems have limited range. The cost of the new infrastructure would be roughly twice that of the previous one ("increasing coverage is increasingly expensive"), and you're going to pay for the cost of the infrastructure either way in your air-time charges.

    Look at it this way: Even if the company only charged for packets successfully received, it would just increase their rates by (1/0.95) - 1 = 5.3% to (1/0.93) - 1 = 7.5% to maintain the same cash flow. Plus it would have to start keeping track of the success or failure of each packet transmitted, and put that into its billing scheme. That's a database PITA I don't want, thank you very much.

    • by samjam (256347) on Saturday September 15, 2012 @07:36AM (#41345223) Homepage Journal

      Keep track isn't hard. Telco's already have optimisation for tcp re-delivery from the mobile gateway so that the distant sender doesn't have to re-send the missing packet, the telco can do that.

      This service improves tcp performance over a mobile network and is important for customer retention.

      Maybe not all telco's do it but I doubt it.

      http://www.iith.ac.in/~tbr/teaching/docs/transport_protocols.pdf [iith.ac.in]
      http://www.cs.sunysb.edu/~jgao/CSE370-spring06/lecture17.pdf [sunysb.edu]

      • by broknstrngz (1616893) on Saturday September 15, 2012 @07:57AM (#41345291)

        Indeed, all sorts of TCP splitting techniques exist. However, there is only so much data such a device can temporarily queue to keep retransmission on the terrestrial side. If you run a network with 10 million subscribers, it becomes very interesting.

        The mismatch comes from the fact that operators collect CDRs on the terrestrial side of their GGSNs. So even if the mobile subscriber does not need to resend a segment, the terrestrial retransmission is still accounted, as are the duplicate ACKs sent by the Internet host.

        You simply can't expect both having the cake and eating it. High latency links come with trade-offs.

        I work for a provider with much higher RTTs (~1200ms). The 5% reported by the study is exactly what we are seeing.

        • by broknstrngz (1616893) on Saturday September 15, 2012 @08:04AM (#41345311)

          Also, most people have no idea of the optimization techniques operators use.

          Navigate to any content heavy website. If your mobile browser allows you to, try to see the source of the page.
          Chances are you will see all whitespace trimmed, all CSS and JS inlined. All pictures are compressed in a lossy
          fashion to reduce their size.

          There is also HTTP request coalescing. If you request "/", the whole page will be retrieved, then processed as
          above and delivered to the mobile browser in a single reply. How many GET requests do you save? A lot.

          If there were no such techniques, one's mobile bill would be almost twice as high and the browsing experience
          would be 4 times as slow.

          • Re: (Score:3, Interesting)

            by Anonymous Coward

            HTTP request coalescing is a mixed bag, since the all the stuff you inline will be resent when you request the next page. If you have carefully reduced the size of your html pages and set your CSS and JS to be basically cacheable forever, you may want to add Cache-Control: No-Transform to your headers to request that no such thing is done. The same header should theoretically prevent your images from being re-compressed with an absurdly bad JPEG quality setting.

          • Why is it then, that bad wifi on my phone is immensely faster than good Cell (3G)? One or two bars on wifi loads so much faster than full bars on my 3G? Is their network that over saturated that even with a good signal that they just can't transmit? It is even more obvious on mobile optimized sites. Just sayin.

            • Even with bad WiFi, your RTT should still be an order of magnitude smaller than on the 3G network.
              I suppose it also depends on your 3G network. I am in the UK and my service works well enough that
              I don't have to bother finding WiFi spots at all, I just use 3G.

          • If there were no such techniques, one's mobile bill would be almost twice as high and the browsing experience would be 4 times as slow.

            That's doubtful. There is a feedback loop where transmission gains encourage webisite operators to be profligate with their content, because the hardware side can "take it".

            Look at Google's homepage for a dramatic example of this over the last 10 years. If there hadn't been all the efficiency gains at the network level, chances are we'd have a faster we

      • Whoops, replied to myself a 2nd time instead.

        Also, most people have no idea of the optimization techniques operators use.

        Navigate to any content heavy website. If your mobile browser allows you to, try to see the source of the page.
        Chances are you will see all whitespace trimmed, all CSS and JS inlined. All pictures are compressed in a lossy
        fashion to reduce their size.

        There is also HTTP request coalescing. If you request "/", the whole page will be retrieved, then processed as
        above and delivered to the mob

        • Re: (Score:2, Insightful)

          by Lumpy (12016)

          and if the phones allowed ad-blocking, your data use will drop significantly.

          I'm fine with ad's in a unlimited ecosystem. but in a bandwidth limited, receiver pays, system? Screw all ad's. It's why I jailbroke my iphone and installed an ad blocker, and my android phone also had ad blocking added to it.

        • by tlhIngan (30335)

          Navigate to any content heavy website. If your mobile browser allows you to, try to see the source of the page.
          Chances are you will see all whitespace trimmed, all CSS and JS inlined. All pictures are compressed in a lossy
          fashion to reduce their size.

          There is also HTTP request coalescing. If you request "/", the whole page will be retrieved, then processed as
          above and delivered to the mobile browser in a single reply. How many GET requests do you save? A lot.

          If there were no such techniques, one's mobile bi

      • Mobile operators collect CDRs on the terrestrial side of the GGSN. Even if over the air there are no retransmissions,
        there will still be some on the IP network. I work for a provider with higher RTTs (~1200ms) and the extra 5% is pretty
        much what we are seeing. We all use the same TCP splitting techniques (Vegas on the slow link and Reno on the
        fast link), because the primary purpose is to improve the user experience.

        Navigate to any content heavy website. If your mobile browser allows you to, try to see the s

      • by hawguy (1600213)

        Keep track isn't hard. Telco's already have optimisation for tcp re-delivery from the mobile gateway so that the distant sender doesn't have to re-send the missing packet, the telco can do that.

        Keeping track of data that's delivered may not be hard, but if you accept that the Telcos charge so much money for data because it costs a lot of money to deliver data to your phone, it's that last mile of wireless delivery that's the most expensive. It costs them nearly nothing to get the data from the internet to their cell tower, the expensive part is in maintaining the infrastructure to get the data from the tower to your phone.

        As long as they are only counting costs for data when it leaves the cell tow

    • Change your database....

    • by sjames (1099)

      If they get to charge for packets never received, you can never know what your bill will be. If they raise their rates to account for 'breakage' (like a typical store will), then at least you know what the bill is going to be and you have a fair comparison of costs between carriers.

      Also, we want to give the telcos an incentive to improve their network, not to just let it degrade and use the packet loss as a stealth price increase.

      The water works doesn't charge you for their leaky main, the power company doe

  • Vodafone Netherlands (Score:5, Interesting)

    by hankwang (413283) on Saturday September 15, 2012 @07:33AM (#41345207) Homepage
    It happened that I wrote down the status of my data usage over the month July, so here is my anecdotal experience for Vodafone Netherlands:

    * Android Droidstats usage logger: 369 MB (2012-07-31 22:16h)
    * Android "My Data Manager": 337 MB (2012-07-31 22:16h)
    * Vodafone online usage monitor: 307 MB (up to 2012-07-30 17:46h)
    * Phone bill for July: 343 MB (since a couple of months they actually mention the total; before I needed to use a perl script to parse the PDF invoice and add the data usage of some 200 separate data sessions)

    When I asked about the differences a few months ago, the Vodafone customer service told me: "The information on your Vodafone account online is the real usage. Numbers from data usage apps are not reliable." But I highly doubt that I used 36 MB over the last day of the month, so it seems that within Vodafone they have different systems.

    My train commute (where I use most of my data) passes through an area with bad coverage, so I would have expected a bigger difference based on the theory that packet loss accounts for most of the difference.

    • by Rob Kaper (5960)

      When I asked about the differences a few months ago, the Vodafone customer service told me: "The information on your Vodafone account online is the real usage. Numbers from data usage apps are not reliable." But I highly doubt that I used 36 MB over the last day of the month, so it seems that within Vodafone they have different systems.

      Most likely the numbers in their on-line usage monitor are not truly up-to-date. The Vodafone website here in the Netherlands is not always the best example of engineering.

    • by mkraft (200694)

      With AT&T, I discovered that data usage takes about a day to be entered into the system, so the extra data could have come from the prior billing cycle.

      In my case, I had about 800 MB of data left on the last day of my billing cycle so I decided to download a 300 MB file. The data usage didn't show up in AT&T's system until the next day, so despite showing the correct usage date on my bill, the data was applied to next months data cap.

      Basically, don't trust usage monitors, apps or even your bill to

  • Word Play (Score:2, Insightful)

    by Dunbal (464142) *
    "Overcharged". What a sweet word to use instead of other words like fraudulently charged or stolen. No, you were simply "overcharged". Don't worry about it. And your bill is due by the 1st.
    • by tomhath (637240)
      It depends on what's in the contract you signed. I've never looked that closely at mine, but if your phone requests a packet and the provider sends it that doesn't seem like fraud to me.
  • by Pete Venkman (1659965) on Saturday September 15, 2012 @09:14AM (#41345555) Journal
    Do you really think what carriers charge is how much it actually costs to send a text message?
    • by isparkes (2726069)
      Yes, carriers charge pretty much what it costs to send a text message, and keep the infrastructure that the message traveled over running. People who work at carriers aren't all driving around in Ferraris, you know.

      What people forget is that it costs a *lot* of money to run a network, especially if that network is going to be any good. No one is forcing you to use the service - if you don't want to spend the money, then just step away from the mobile phone, and go home and use your ADSL or Cable, or even
      • If a business only charges actual cost for a product, they cannot make a profit. I want some companies to earn a profit, especially if I'm a stakeholder. If we're lucky, we have jobs (and paychecks) that are a result of some company making a profit. No, I'm not talking about hookers-and-blow-for-everybody kind of profit, either.
      • Yes, carriers charge pretty much what it costs to send a text message, and keep the infrastructure that the message traveled over running.

        The problem is that carriers also charge for a voice call what it takes to connect that voice call, and keep the call that the message traveled over running -- even though it's the same infrastructure used for text messages. Nothing like double billing.

        People who work at carriers aren't all driving around in Ferraris, you know.

        Of course not. Employee salaries are an expen

  • The telco can only rely on the data from their own equipment, that is they know the data was transmitted to the user but have no way to reliably tell if it was received.
    If they were to ask the user's device, then the device could lie in an attempt to get free use...

    • For TCP, they could look at retransmissions. For UDP, it's protocol dependent, of course.

      However, the deeper flaw with the article is the assumption that you should only pay for what you receive. In fact, your request of the data is what uses up bandwidth, regardless of whether you receive it or not, so you should actually be charged by what's transmitted, not what's received.

    • by Fnord666 (889225)

      The telco can only rely on the data from their own equipment, that is they know the data was transmitted to the user but have no way to reliably tell if it was received.

      If only TCP had some way to acknowledge that a packet was received by the endpoint so that connection participants knew if a packet was lost....

    • by sjames (1099)

      Actually, they can. If the client doesn't ACK the data sent, the connection stalls while the same data is sent again. Because of that, a phone that never acked data would have no useful data connection at all.

      • by Bert64 (520050)

        For TCP yes, but for UDP based protocols its much harder... So you'd be able to get round the bandwidth caps by using a custom udp based tunneling protocol where it was impossible to tell if a packet had been acknowledged.

        • by sjames (1099)

          Or they could also just count UDP based on transmission (since TCP is the bulk of the traffic).

  • >"While that does not seem like much, with unlimited plans gone and data caps in style that could pose potential problems for some heavy data users."

    I guess the author never heard of Sprint, which has unlimited plans and without data caps or throttling.

    Perhaps the statement was out of context, I don't know. But it is misleading.

    • > I guess the author never heard of Sprint, which has unlimited plans and without data caps or throttling.

      When your average EVDO speeds are 80-100kbps on a GOOD day, there's no need to cap or throttle. Someone did a study a few months ago comparing data speeds in South Florida, and even MetroPCS was faster than Sprint.

      • by markdavis (642305)

        In many areas, Sprint's 3G speeds are quite slow. Unfortunately, they are here too. The main problem is that Sprint is over-subscribed. But not all areas are slow. Plus, the areas that had WiMax had plenty of speed. Unfortunately, I am also in an area that never got WiMax. PLUS the LTE areas are very fast. Unfortunately, we don't have that yet either... but it is due pretty soon (thank God).

        I will point out that there was and is no cap or throttling on Sprint's WiMax or LTE...

        • Sprint's wimax was a disappointment, but it's what made them tolerable while their EVDO service deteriorated to levels that would have been laughed at by someone paying 250 Rupees/month for unlimited 1xRTT 100kbps service in India. The fatal mistake made by Sprint's management, which I believe is going to cost them *dearly* over the next 12 months in terms of lost customers, was to throw away everything they gained with wimax by not giving us a year or two of phones with dual-mode LTE+wimax 4G radios. Had S

  • Surely this means that network operators have no incentive to increase their coverage?

  • http://code.kryo.se/iodine/ [code.kryo.se]

    I've played with IP over DNS, and it works surprisingly well. It can break through most firewalls. I think there was something like a 50% performance hit, but considering how convoluted it is, that's pretty good.

    It shouldn't be difficult to port it to Android if you install a kernel with tun/tap support.

  • by sandytaru (1158959) on Saturday September 15, 2012 @11:13AM (#41346099) Journal
    It's only gone from the big carriers. I use Metro PCS, and have 4G in the city where I live, along the major route I commute to Atlanta, and of course have it in Atlanta itself. (The trade off is having text-only outside of the network.) If you live in a rural area and need one of the big guys to provide coverage, you're screwed, but if you live in a metro area, you'll probably get a better deal with a smaller regional carrier.
  • by Sprouticus (1503545) on Saturday September 15, 2012 @11:33AM (#41346187)

    All I need to do is run a website or service on UDP/53 and mobile users wont ever get charged? It can't be that easy.

  • The article makes the assumption that people should only be charged for packets actually received. But the company's wireless infrastructure is busy while it is transmitting packets, whether received or not. Bandwidth could be entirely saturated even if no client ever receives anything.

    It seems to me that people should pay the way they are, and if they don't like paying for dropped packets, they should turn off data when in marginal areas. Of course, coverage should also be measured that way: if you are

  • Why Phone Companies Overcharge For Data

    Shouldn't that read "How Phone Companies Overcharge For Data??"

    (I would think the why would be obvious to anyone who's not a mouth-breather...)

  • True Unlimited. How the hell are people stupid enough to have other carriers? They gave me an Air-Rave signal repeater because the signal at my house was weak. Free for life.
    • by nanospook (521118)
      You mean the free 3g signal or the non-existent LTE signal? Eventually I hope that Sprint's declaration that they rolled LTE out in Dallas will actually become a reality. Look at their map! It's everywhere.. but if you drive around, it's nowhere :) Vaporware! But that doesn't stop them from selling you a phone and telling you that you will have LTE service. So bully for you that you have unlimited but I suspect when they really handle a LTE work load for their customers, that will go away..
  • by Anonymous Coward

    First, carriers "optimize" traffic which actually saves the subscriber money. I won't get into the details - but most carriers around the world deploy optimization techniques that save their subscribers money at the carrier's expense.

    Second, subscribers are charged for IP packets, this is true. That includes TCP retransmissions. Subscribers are not charged for air-interface retransmissions. What I mean to say here is that there are multiple layers that involved in ensuring packets make it to user equipm

  • Reading the summary, I had to wonder: if the phone company only charged you for packets received, then couldn't the phone-owner game the system by instructing his phone to claim that the packet was never received? In other words, send a request for some data, receive the data and use it, and have the phone tell the company that the packets never arrived. Result: you can turn your limited data plan into an unlimited data plan. (This would obviously be an exploit similar to the DNS one, but it would use a
    • by mysidia (191772)

      Another thing is, you could attempt to download far more data than your connection is capable of. For example, making a portable device participant in a BitTorrent network, where the client intentionally attempts to download as much data as possible -- at a high loss rate, the data your phone isn't capable of receiving still gets sent by the tower, and therefore still congests the wireless portion of their network, but your device never receives the data, because it's not capable of it.

      Packet loss is

If a thing's worth having, it's worth cheating for. -- W.C. Fields

Working...