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!

Wrong Number: Why Phone Companies Overcharge For Data

timothy posted more than 2 years ago | from the now-tell-me-something-I-don't-know dept.

AT&T 105

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

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

DNS not counted? (2)

ccguy (1116865) | more than 2 years ago | (#41345035)

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

Re:DNS not counted? (5, Funny)

joostje (126457) | more than 2 years ago | (#41345081)

Re:DNS not counted? (1)

KiloByte (825081) | more than 2 years ago | (#41345161)

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.

Re:DNS not counted? (2)

Zocalo (252965) | more than 2 years ago | (#41345333)

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... ;)

Re:DNS not counted? (2)

GameboyRMH (1153867) | more than 2 years ago | (#41345377)

That's assuming port 53 traffic is free rather than DNS traffic being free - not the same thing.

Re:DNS not counted? (1)

Zocalo (252965) | more than 2 years ago | (#41345413)

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).

Re:DNS not counted? (2)

profplump (309017) | more than 2 years ago | (#41345965)

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, even if they are set to port 53. No DPI required. Sure, you'll prevent TCP DNS queries but that's rarely an issue of the kind of devices connecting to semi-open hotspots, particularly in the pre-payment phase of the connection.

Re:DNS not counted? (1)

KiloByte (825081) | more than 2 years ago | (#41345435)

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.

Countermeasure implimentation in (1)

davidwr (791652) | more than 2 years ago | (#41346769)

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 charging unless the DNS request is to their server. On the flip side, expect many to offer free access to other "in the free garden" pages including customer-service pages, their own ad-filled web-search engine, and the like.

Re:DNS not counted? (3, Insightful)

BumboChinelo (2527572) | more than 2 years ago | (#41345123)

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:DNS not counted? (0)

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

Operators use SGSN or SGW CDR:s for traffic volumes, not GGSN/PGW. You're comparing with the wrong data...

Re:DNS not counted? (2, Interesting)

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

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 Wireshark setup is miss configured, or you work for.. Nokia? :)

Re:DNS not counted? (4, Informative)

isj (453011) | more than 2 years ago | (#41345687)

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.

Re:DNS not counted? (0)

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

TFA is sensationalism.

Re:DNS not counted? (1)

isj (453011) | more than 2 years ago | (#41346245)

I'm not sure about sensationalism, but the article certainly has a strong bias.

Re:DNS not counted? (2, Insightful)

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

A strong bias and a poor conclusion. Rather, a poor methodology. Since you also appear to work in the industry - I'm wondering if you notice what I notice? The two methodologies they used for detecting traffic at the mobile... They used an android application that does not require root access (e.g. isn't taking pure IP level statistics) and the Traffic Status API.

Two pretty big problems. 1) They don't measure TCP Retransmissions... This is uhh a big "duhh" - but more disturbing they don't measure IP packet overhead. E.g. the application they used uses the same API their homebrew application uses - both of which look at actual TCP and UDP payloads (reassembled in the case of TCP). IP Packet Overhead, SYN's, SYNACK, FIN, RESET. Are those measured? Nope.

Basically, the methodology is flawed and the title is sensationalist. If this is the quality of research coming out of American Universities then we're fucked. Anyone who has a minor clue can read the paper and come to some astonishing conclusions:

1) They don't measure IP Packet Overhead
2) They don't measure TCP Overhead
3) They don't measure TCP Retransmissions

I'd wager most of the "over charged data" they're claiming is coming from #1 and #2, just setting aside #3. And with regards to #3 - it's clear that it's to the consumer's benefit to measure traffic at based on the number of IP Packets, as opposed to measuring traffic on the RAN. If the consumer had to pay for RAN - it would create a billing nightmare. Those who require a lot of RAN retrans would be screwed.

Finally, the idea of measuring actual payload received on the device, and then reporting that back to the network is simply laughable. It's stupid at best, retarded at worst. The overhead in this reporting would drive the cost of data usage up and would only hurt to consumers. Considering the possible signalling load, let alone the security implications...

Overly educated morons talking about shit they don't understand. It's no wonder CS grads in this country can't find jobs. They should demand their education $$$ back - because they clearly didn't learn enough to actually be effective in the workplace....

Re:DNS not counted? (1)

isj (453011) | more than 2 years ago | (#41349047)

No, I didn't notice that they didn't measure the L3/L4 overhead. I'm not familiar with the two APIs/tools they used. But if that is the case then it invalidates the majority of the study.

Re:DNS not counted? (2)

Scarred Intellect (1648867) | more than 2 years ago | (#41345943)

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.

Re:DNS not counted? (1)

flyingfsck (986395) | more than 2 years ago | (#41346741)

Hmm, so I should run my SSH socks proxy over port 53...

If only it worked both ways (5, Funny)

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

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

Re:If only it worked both ways (5, Funny)

Anonymous Coward | more than 2 years ago | (#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."

Re:If only it worked both ways (0)

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

Funny, but a better analogy would have been sending cash. Cashing a check doesn't have the same deniability that receiving data does.

That's probably the reason for not charging by amount of data received: it's easily hackable.

Wow, your mobile networks SUCK. (0)

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

Build better ones.

Re:Wow, your mobile networks SUCK. (4, Funny)

game kid (805301) | more than 2 years ago | (#41345145)

Thank you for your suggestion. at&t(R) is committed(tm) to rebuilding the nation's largest 4G network this year with your input. To pay for the buildout* you will notice a 10% 2012 Nation's Largest 4G Network Improvements Fee along with a 200% SMS price increase. Thank you again for choosing at&t(R), with the nation's largest 4G network.

*Buildout subject to cancellation without notice. Just kidding about that last part, we cancelled it while you were reading that sentence. The fee stands to pay for the costs of typing the prior two and commissioning a forthcoming Gartner study to validate their market impact.

they could charge more... (4, Funny)

joostje (126457) | more than 2 years ago | (#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 (3, Funny)

Spy Handler (822350) | more than 2 years ago | (#41345077)

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

Re:Step 1 (2)

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

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

It turns out you can already disguise all of your traffic as a DNS request.

Re:Step 1 (0)

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

Yes, but we'll need a version that runs on Android.

Re:Step 1 (-1, Troll)

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

Your dad's assplug runs Android.

Very unlikely (0)

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

However, it might run java [wikipedia.org] .

Re:Step 1 (1)

Zocalo (252965) | more than 2 years ago | (#41345353)

SSH clients that support tunneling are available for Android and, as far as SSH servers are concerned, port #53 is just another port you might want to bind it to. :)

Re:Step 1 (1)

GPLHost-Thomas (1330431) | more than 2 years ago | (#41345973)

I don't think TCP port 53 wouldn't be counted. That's used in the DNS protocol for zone transfers, not for DNS requests. And anyway, having a dns0 interface is so much more fun! :)

But what if I need to disguise a DNS request (1)

davidwr (791652) | more than 2 years ago | (#41346797)

or disguise a disguesed DNS request

or, oh, curses, refoiled again!

ET Phone home? (0)

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

So considering the nature of wireless and TCP/IP, how would one determine if the data didn't get through from the viewpoint of the wireless Carrier?

Re:ET Phone home? (2)

Hatta (162192) | more than 2 years ago | (#41345465)

The nature of TCP includes positive acknowldgement and retransmission. If you don't get that acknowledgement, don't charge the user for that packet.

Why do phone companies overcharge for data? (0)

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

Why do dogs lick their balls?

Re:Why do phone companies overcharge for data? (0)

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

Because they can.

Re:Why do phone companies overcharge for data? (2)

Merls the Sneaky (1031058) | more than 2 years ago | (#41345171)

To get rid of the taste of the food.

Re:Why do phone companies overcharge for data? (1)

fustakrakich (1673220) | more than 2 years ago | (#41345303)

Because they don't have thumbs...

Re:Why do phone companies overcharge for data? (1)

dr_dank (472072) | more than 2 years ago | (#41346315)

Probably because of the peanut butter they smeared on there.

The trouble is. . . (4, Insightful)

dtmos (447842) | more than 2 years ago | (#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.

Re:The trouble is. . . (3, Informative)

samjam (256347) | more than 2 years ago | (#41345223)

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]

Re:The trouble is. . . (4, Informative)

broknstrngz (1616893) | more than 2 years ago | (#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.

Re:The trouble is. . . (5, Interesting)

broknstrngz (1616893) | more than 2 years ago | (#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:The trouble is. . . (3, Interesting)

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

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.

Re:The trouble is. . . (2)

Archangel Michael (180766) | more than 2 years ago | (#41349715)

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.

Re:The trouble is. . . (1)

broknstrngz (1616893) | more than 2 years ago | (#41350729)

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.

Re:The trouble is. . . (1)

martin-boundary (547041) | more than 2 years ago | (#41349881)

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 web overall, because content owners would be a lot more careful about adding that extra bloat.

Re:The trouble is. . . (1)

broknstrngz (1616893) | more than 2 years ago | (#41345349)

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 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:The trouble is. . . (1, Insightful)

Lumpy (12016) | more than 2 years ago | (#41345635)

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.

Re:The trouble is. . . (1)

broknstrngz (1616893) | more than 2 years ago | (#41345373)

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 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:The trouble is. . . (1)

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

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 tower and aren't counting data that needs to be retransmitted because it got lost somewhere else in their network, charging for the data is "fair" in that it reflects their true cost of delivering the data. But it's "unfair" in that the cost is shifted to the consumer that is trying to use his phone in a fringe coverage area when that consumer can't do anything about that -- only the cell carrier can add more capacity and if they actually earn more money for poor coverage, there's less incentive to do so.

Re:The trouble is. . . (1)

trancemission (823050) | more than 2 years ago | (#41346337)

Change your database....

Re:The trouble is. . . (1)

sjames (1099) | more than 2 years ago | (#41347323)

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 doesn't charge you for the power lost in transmission. Long distance rates don't kick in until the phone is answered.

It should be charged anyway (0)

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

Data takes up network capacity whether the device receives it or not.

Re:It should be charged anyway (2)

gl4ss (559668) | more than 2 years ago | (#41345255)

Data takes up network capacity whether the device receives it or not.

if you're an operator..
step 1. hire some flooders.
step 2. profit.

essentially this is why they should sell by speed, not by usage.

Re:It should be charged anyway (0)

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

essentially this is why they should sell by speed, not by usage.

If you sell a 1Mbps plan, that's 300GB/month. If current operators sell shitty 1GB plans and still run into capacity problems, selling by speed will just make things worse.

Unless they offer 50k/100k/200k as the speed tiers though. That might work.

Re:It should be charged anyway (0)

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

Currently there appears to be such a problem on the KPN network in the Netherlands.
When using the "advancedinternet" APN, which has no firewall, customers suddenly receive invoices of thousands of euro for data traffic that is unsolicited.
It is not clear if the traffic is due to portscanning/breakin attempts or if it simply is malicious flooding to cause havoc.
The default APN appears to have a stateful firewall that drops traffic not belonging to user-initiated connections.

Re:It should be charged anyway (2)

Guppy (12314) | more than 2 years ago | (#41345899)

step 1. hire some flooders.

While I don't expect legit carriers to crap-flood for profit, it seems this presents a perverse economic incentive not to invest in improving the quality of their networks.

Vodafone Netherlands (5, Interesting)

hankwang (413283) | more than 2 years ago | (#41345207)

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.

Re:Vodafone Netherlands (1)

Rob Kaper (5960) | more than 2 years ago | (#41345541)

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.

Re:Vodafone Netherlands (2)

mkraft (200694) | more than 2 years ago | (#41346201)

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 be correct since data isn't applied the way you would think it should be.

Word Play (2, Insightful)

Dunbal (464142) | more than 2 years ago | (#41345229)

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

Re:Word Play (-1)

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

What if your Android phone or iPhone drops packet because it's busy rendering a 3D scene in your favorite app? The packet was still delivered to you.. but not measured by your packet-drop-app. Who stole your packets?

Re:Word Play (1)

Dunbal (464142) | more than 2 years ago | (#41345543)

So imagine if UPS was not accountable at all if they kept losing your parcels, but kept billing you for them?

Re:Word Play (1)

tomhath (637240) | more than 2 years ago | (#41345625)

The wireless provider is resending the packets, same as UPS tries to deliver a package a couple of times before telling you to come to the distribution center and pick it up yourself. Those retries by UPS are built into the shipping price whether they happen or not.

Word Play with UPS (1)

dtmos (447842) | more than 2 years ago | (#41345743)

Don't get so hung up on the UPS Service Guarantee [ups.com] (section 47, pdf page 32, paper page 29):

In the event UPS fails to attempt delivery within the time published on the UPS website, or as provided when 1-800-PICK-UPS® is called, UPS, at its option, will either credit or refund the transportation charges for each such package to the payer only, upon request, provided the conditions set forth in the UPS Service Guarantee are met. Transportation charges do not include other fees or charges that may be assessed by UPS including, but not limited to, fuel surcharges. This is the sole remedy available under the UPS Service Guarantee.

UPS shall not be liable for any damages whatsoever for delayed delivery, except as specifically provided for shipments made under the UPS Service Guarantee. Under no circumstances shall UPS be liable for any special, incidental, or consequential damages including, but not limited to, damages arising from delayed delivery or failure to attempt on-schedule delivery.

UPS may cancel or suspend the UPS Service Guarantee for any service(s), and for any period of time, as determined by UPS in its sole discretion, and without prior notice.[Emphasis added.]

What follows (in Section 47.1) is seven bullets of conditions, followed (in Section 47.2) by eleven bullets of exclusions.

I don't have a problem with UPS -- they've always treated me, and my packages, well -- but I'm not under any illusions that I could actually get a court judgement from them based on their terms of service, should they decide not to refund their shipping charges on a lost parcel, and I decided to sue. Any service guarantee that may be canceled by the service provider, at its sole discretion and without prior notice, isn't very reassuring.

Re:Word Play (1)

tomhath (637240) | more than 2 years ago | (#41345633)

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.

At&t does (0)

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

I've had it happen in the past, where I've blocked all data usage on the phone, requiring a password, which i had forgotten what it was. But month after month i would get charged about 50 cents worth of data. That was years ago.

I've been keep tracking of our cell phone usage, since my mother got an iphone, she has only used 50 Mb of data per month, maxing out at 80 Mb once.. Last month we got a notification that she was nearing hitting her 200 Mb cap. When the bill came, she was at 189 Mb. We were extremely surprised at this, We looked at the iphone data usage screen, since we have never cleared it since we got the phone, we added up what we have been charged in the past, and lo and behold, the difference was only ~57 Mb.. So this could explain why at&t was charging us the extra 140Mb that the phone says that we never used.

OH GOD why did you tell them?! (0)

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

Now my secret DNS-routing will be counted!

But really, I found something similar out with the 3 broadband service a while back when it first started.
Turned out if I embedded an iframe in one of their pages with a very simple javascript injection, I could access external resources without even having a connection and it wasn't charged to the account.
I never abused it if you are thinking that. I only used it in emergencies. I did and still do pay every so often whenever I need a connection.
It got fixed a while back anyway. I think someone else must have actually abused it.

Overages are a real concern though.
I like the way TalkTalk in the UK handle it at present with their broadband package. You get 40gigs for the basic package. If you go over that, automatically it is only an extra £5 for another 40gigs instead of some £x per YYYbs thing.
However with a metered system with low allotments such as mobiles, I think the best and fairest way would be to scale the overages up with time.
So the first small accidental overage will be really low, then the next a little higher, etc.
This way a person will likely be notified of the overage before it gets out of hand.

Of course, they don't care about your happiness to that level. They WANT your money. The more, the better.
Until one of those companies have the balls to take the plunge, nobody will because it is essentially free money.

Why do they overcharge for data? (0)

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

Because they overcharge for everything. Why would data be any different?

Carriers are businesses (3, Insightful)

Pete Venkman (1659965) | more than 2 years ago | (#41345555)

Do you really think what carriers charge is how much it actually costs to send a text message?

Re:Carriers are businesses (1)

isparkes (2726069) | more than 2 years ago | (#41347189)

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 better, write a letter.

What you are paying for is the convenience of having the mobile network always on and always with you. It's a luxury, and you pay for it as a luxury item.

Re:Carriers are businesses (2)

Pete Venkman (1659965) | more than 2 years ago | (#41348005)

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.

Re:Carriers are businesses (0)

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

"Yes, carriers charge pretty much what it costs to send a text message"

What the fuck are you smoking? Text messaging is a MASSIVE profit center for (many) carriers.

Re:Carriers are businesses (2)

Mr. Slippery (47854) | more than 2 years ago | (#41350199)

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 expense to be minimized. The profits go to shareholders, not employees.

Client side... (1)

Bert64 (520050) | more than 2 years ago | (#41345557)

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

Re:Client side... (1)

kenorland (2691677) | more than 2 years ago | (#41346243)

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.

Re:Client side... (1)

Fnord666 (889225) | more than 2 years ago | (#41346397)

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

Re:Client side... (1)

sjames (1099) | more than 2 years ago | (#41347371)

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.

Re:Client side... (1)

Bert64 (520050) | more than 2 years ago | (#41350985)

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.

Incorrect statement in summary (1)

markdavis (642305) | more than 2 years ago | (#41345599)

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

Re:Incorrect statement in summary (1)

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

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

Re:Incorrect statement in summary (1)

markdavis (642305) | more than 2 years ago | (#41349649)

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

Conflict of Interest (1)

jkflying (2190798) | more than 2 years ago | (#41345783)

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

Overcharge is about 5-7% hey? (0)

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

That sounds like a combination of MA protocol headers ("traffic meters" on phones/tablets only count payload sizes, not including header sizes because they're usually gone before they get to the Sockets layer) and the old "we charge 1 megabyte at 1,000,000 bytes" bullshit some ISPs inherited from the mass storage market.

IP over DNS using Iodine (1)

crow (16139) | more than 2 years ago | (#41345985)

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.

Re:IP over DNS using Iodine (0)

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

How much room is there in a DNS packet? Does it have more room than IP over text message?

Re:IP over DNS using Iodine (1)

crow (16139) | more than 2 years ago | (#41349197)

Yes, it's much better than IP over SMS. It depends on the DNS server, but you can sometimes get most of the 1500 bytes available, minus the encapsulation overhead. You have to set up your own domain and DNS server, and it's most efficient if you can send DNS directly to your own server, but that's not required.

Iodine doesn't have encryption or compression, so it's recommended to open an ssh connection and tunnel everything through that. Of course, it's pretty obvious what you're doing if anyone looks at the DNS traffic.

I still have an unlimited data plan (2)

sandytaru (1158959) | more than 2 years ago | (#41346099)

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.

So wait... (2)

Sprouticus (1503545) | more than 2 years ago | (#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.

why is this an "overcharge"? (1)

kenorland (2691677) | more than 2 years ago | (#41346237)

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 in an area in which you receive less than, say, 95% of the data packets, that should be counted as "no coverage".

Why?! (1)

Type44Q (1233630) | more than 2 years ago | (#41346283)

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...)

That why i have Sprint. (1)

trum4n (982031) | more than 2 years ago | (#41346449)

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.

Re:That why i have Sprint. (1)

nanospook (521118) | more than 2 years ago | (#41346601)

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

Not "Phone Companies" (0)

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

It would be nice if we had a competitive market like in the uk.

This article is BS - let's clarify (1)

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

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 equipment. The first approach is at the radio level using something known as "HARQ" for retransmission and error correction. If the device does not receive a transmission at this level, the content is automatically scheduled for retransmission. These air interface retransmissions are never charged to the subscriber - the carrier eats them. There's good reason for this: users who are at the edge of the cell need more retransmission than those who are closer to the center. The carriers thus don't charge users more just because they're at the edge.

So to summarize: there's a lot of retransmission in wireless networks - and most carriers eat the cost of most of the retransmission. It's only when a higher layer protocol, like TCP, needs a retransmission that a subscriber foots that bill. End of day, carriers are billing on IP Packets Sent/Received - not on the actual radio usage. This is hugely advantageous to the subscriber.

Another Exploit (1)

brit74 (831798) | more than 2 years ago | (#41347439)

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 different method to get free data.)

Re:Another Exploit (2)

mysidia (191772) | more than 2 years ago | (#41347739)

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 an end-to-end connectivity thing; it is no specific party's responsibility. Ultimately, the end user has to take responsibility for requesting packets that they are unable to receive.

It would probably be better if the phones warned the user about high packet loss or implemented a temporary self-shutoff or backoff. And wireless providers offered SLA credits, for data discarded before it's even attempted sent by the provider's radio towards the user's phone (e.g. Output discards).

Otherwise, packet loss by the phone itself, or loss of radio transmission, is a result of network congestion. There actually is very good sense in the user having to pay as if data was received when they are requesting packets that are being lost due to congestion --- the user is participating in the congestion that should be prompting the network provider to upgrade the network in that area, so they should pay more for causing that congestion.

The providers should just clarify that dropped packets do count, and choose appropriate pricing.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?