backtop

Print 30 comment(s) - last by overlandpark4m.. on Feb 5 at 9:52 PM

  (Source: Allvoices.com)
Lawsuit claims the carrier overstates data usage, charges for phantom data

AT&T Mobility has been hit with yet another class action lawsuit, the Courthouse News Service reports. The lawsuit alleges that AT&T overstates the amount of data used by iPhone and iPad customers each month, and also charges for phantom data.

The class says AT&T's billing system "is like a rigged gas tank that charges for a full gallon when it pumps only nine-tenths of a gallon into your car's tank." 

Named plaintiff Patrick Hendricks claims that an independent consulting firm that was hired by his counsel discovered these charge. During a two-month study, the firm "found that AT&T systematically overstate web server traffic by 7 percent to 14 percent, and in some instances by over 300 percent. So, for example, if an iPhone user downloads a 50 KB website, AT&T's bill would typically overstated the traffic as 53.5 KB (a 7 percent overcharge) to as high as 150 KB (a 300 percent overcharge)."

On top of this overstatement of data consumption, Hendricks also claims that AT&T charged for data that was never transferred. The same consulting firm purchased an iPhone from an AT&T store and immediately disabled all push notifications, location services, e-mail accounts, etc. Then, they let the device sit untouched for 10 days. "During this 10-day period, AT&T billed the test account for 35 data transactions totaling 2,292 KB of usage. This is like the rigged gas pump charging you when you never even pulled your car into the station," the lawsuit claims.

And while the class claims that these charges have only "a modest effect" on individual customers' bills, "they have a huge effect on AT&T's bottom line." With more than 92 million customers, AT&T could potentially be falsely inflating its revenues if these charges are legitimate.

AT&T is no stranger to class action lawsuits. According to Courthouse News, previous cases have been brought against the carrier claiming it charged for downloads customers never made, charged for services it didn't (or couldn't) deliver, and promised that iPhones could send SMS and MMS, among others.

Comments     Threshold


This article is over a month old, voting and posting comments is disabled
I hate to be the one that defends AT&T, but
By monitorjbl on 2/1/2011 9:11:41 AM , Rating: 4
This sounds pretty normal to me, and it should to anyone that understands the basic principles of networking. A webpage may only be 50KB, but the HTTP packets that encapsulate the data sent to the device (as well as the IP and TCP packets that encapsulate those) have some size. Allow for the occasional TCP retransmit from lost packets and you're looking at a sizeable increase in data transmission sizes.

It's a byproduct of the 3G network really; the signal quality isn't always perfect and you can lose a fair number of packets to noise, requiring many retransmits before your webpage actually loads on the phone. I despise being with AT&T, but I really don't think they're in the wrong here.




RE: I hate to be the one that defends AT&T, but
By SpinCircle on 2/1/2011 9:39:45 AM , Rating: 5
That may be true, but the company that tested this actually bought a new phone and then turned off all data on the phone and were still billed for data used for the time the phone was off.


RE: I hate to be the one that defends AT&T, but
By monitorjbl on 2/1/2011 10:14:04 AM , Rating: 3
They didn't turn off the modem though. The iOS will still do things like check for app updates and a few other things with Apple as well as periodically check in with the tower's data service unless its actually put in airplane mode. This isn't unusual, just watch your computer's "Packets Sent" counter when nothing is running but the operating system.

Now, 2MB is a lot for all that, so there may be something else going on here, but in most use cases having some overhead on your downloads should be expected.


By AlphaVirus on 2/1/2011 11:43:03 AM , Rating: 1
This.

As long as the device has modems running, the operating system will continue to activate certain features that run in the background. Unless the device was placed in airplane mode then there will be loose packets sent.

I see where they are trying to go with this, but unless they want to rewrite the technology books they have no grounds for a lawsuit.

As others have stated, I dislike some of the things ATT does but this CAL has little basis.


By phantom505 on 2/1/2011 9:39:29 AM , Rating: 2
So you may be paying for their lousy network performance in the form of overages too.

Sounds fair, for them. Just one more argument against ridiculous data overages and tiered data.


RE: I hate to be the one that defends AT&T, but
By jenli on 2/1/2011 9:54:24 AM , Rating: 3
This doesn't make sense...if ATT has lousy network
and had to retransmit 1 GB of packets to get 1 byte
packet through, is it justified to charge you for
the 1 GB ?

I wonder turning off data services on the phone
is sufficient ? Would underlying connection
protocol, for voice, sms, network presence (like arp)
still charged as data ?


By Azethoth on 2/3/2011 5:48:08 PM , Rating: 2
Their coverage area is what it is. If you hop in the elevator or your homemade faraday cage and barely get any reception or operate from some mountain top at the edge of reception you will get bad results.

Blame at&t if you will or just don't do silly things.

Now if you are in some super dense metro area and fighting others for bandwidth and losing, then that is a real issue. But it is a limitation of current wireless tech. Not a sign that [some wireless company] has a bad network.


RE: I hate to be the one that defends AT&T, but
By Uncle on 2/1/2011 1:45:08 PM , Rating: 3
My problem with this is, why is it always skewered in favour of companies in stead of consumers whenever it is about bits and bytes. I'm sure if the company found out it was in favour of the consumer they would correct the situation promptly.


RE: I hate to be the one that defends AT&T, but
By monitorjbl on 2/1/2011 2:57:30 PM , Rating: 2
That's a fair point, but its not exactly easy to track that sort of thing. You're asking for mobile data companies to keep track of every packet it sends to each customer. Essentially, a counter is updated anytime your device sends or is sent data, which is a low-cost, low-overhead solution used today. If they were to suddenly start keeping a record of the packets that actually made it to your device, they'd have to delve into the actual contents of the packets and determine how much needs to be subtracted from the counter.

No one, especially the poor AT&T network admins, wants to be this nitpicky about the amount of data moving through their systems. 2MB is quite literally insignificant when you're moving many orders of magnitude more data through your network every second. The real solution here is to just make unlimited or at the very least cheaper, bigger data plans. No one with one of those is going to care at all about the extra few megs of lost packets and iOS communiques to Apple.


RE: I hate to be the one that defends AT&T, but
By lballs421 on 2/1/2011 4:17:09 PM , Rating: 3
It actually is really easy to track how much data is transmitted or received while omitting re-transmits. The counter code must be in the Transport Layer of the stack... for example, when you see a TCP ack you then free the retransmit data from the buffer and up the bandwidth counter. This actually required less CPU usage then counting every single packet. Of course this only works for an error correcting protocol such as TCP. It is not possible to detect lost UDP packets from the server side since that data is not acknowledged by the receiver. This is common for things such as streaming audio/video.


By ChristopherO on 2/1/2011 8:30:21 PM , Rating: 2
This isn't quite right though. UDP is a blind transmit and doesn't get an ACK for a successful packet.

However, if you wanted to be "fair", you should reduce the data-charge by the TCP retransmit amount, and use that same percentage and assume that UDP has a roughly-equal percentage (which isn't quite perfect since someone might run Pandora 90% of the time, and only use TCP apps when siting at home on the couch).


By Yames on 2/2/2011 12:59:22 PM , Rating: 2
No it is not easy to track TCP retransmissions because they look exactly like normal transmissions. My guess is that AT&T tracks usage on the network, and TCP lives on the end devices, so either Apple would have to rewrite their iOS TCP stack for this or AT&T would have to have sophisticated monitoring equipment that keeps tracks every TCP session.

And anyway if the loss is not occurring on the AT&T network and is happening lets say at the web server, then how will they know? TCP will not reveal where the loss is.

As for UDP, it will not track loss itself, but can expose the loss to the application above. Look at tools that measure loss (iperf, nuttcp) they use UDP to measure loss as TCP will hide the loss from them.


By Uncle on 2/1/2011 5:09:54 PM , Rating: 2
I'm sure it is easy to do, because the cable companies have just implemented Usage Based Billing, keeping track of each byte I get, making sure I don't go over my cap. They also use it with voip.


By Solandri on 2/1/2011 3:06:50 PM , Rating: 3
It's not skewed in favor of the company. All that's happening is the tools you're using to measure your network usage are only reporting the size of the file you received. It's not reporting the actual amount of network bandwidth consumed to transmit the file, which is what the company is using.

The problem is not with the company, it's with the practice of measuring network bandwidth by transmitted file size. It made sense in wired networks where packet loss is probably less than 0.1% and ethernet overhead is only about 3%. But in wireless networks there's a substantial amount of overhead for handshaking and packet loss. It's why 802.11g is capable of a 54 Mbps data connection, but your actual data throughput will rarely go above 20 Mbps. If cellular networks are able to keep this overhead at 7-14%, that's pretty darned good.


By XSpeedracerX on 2/2/2011 6:45:14 AM , Rating: 2
"HTTP packets that encapsulate the data sent to the device (as well as the IP and TCP packets that encapsulate those) have some size."

You should do some more research on basic networking technology. There aren't any 'HTTP packets'; the packetization of data only occurs in the transport layer. Applications (like an HTTP browser) send large complete chunks of data to be then broken up into packets by transport layer protocols (like TCP) which then send them to labeled with to/from IP addresses. From there, they travel across the internet. Also, there is no 'repacketization'. It occurs once and only once in the transport layer.

"as well as the IP and TCP packets that encapsulate those"

And here is where we learn you don't know anything about networking; TCP is a packeting protocol, IP is an address protocol. There is not and never has been any recursive packeting going on.

"Allow for the occasional TCP retransmit from lost packets and you're looking at a sizeable increase in data transmission sizes."

1) If my packet never reached AT&Ts towers, how would they know I even tried to send one out? That's a blatant case of charging for data transmission that never occured. Also, every single bit of data, including that added by packeting and addressing protocols would be accounted for. You offer no explanation as to why AT&T could count this extra data but the consulting firm for some reason could not.

2)A typical TCP header is 256 bits of data. That's it. The max size for a packet total according to this protocol is 576 bytes. Even if we assume the consulting firm magically loped off their packet headers, that would amount to a maximum data loss of 5%. Not 10%, 15%, or an outrageous 300%.

"It's a byproduct of the 3G network really; the signal quality isn't always perfect and you can lose a fair number of packets to noise"

Irrelevant. Charging me for packets that don't reach my phone amounts to charging me for data transmission that never occured and is still wrong. We know they can check to see which packets got there or not and it wouldn't take someone with a Ph.D in computer science to design a program able charge me for the packets I actually got. From AT&T's POV, I guess it's just more profitable to charge me for data I didn't use anyway.

"I despise being with AT&T, but I really don't think they're in the wrong here."

Of course not. You don't know anything about networking technology. How would you be able to tell either way?


RE: I hate to be the one that defends AT&T, but
By monitorjbl on 2/2/2011 11:16:48 AM , Rating: 2
First of all, you're being a prick about proper terminology when it isn't strictly necessary here. HTTP "packets" do exist, they're encapsulated by the TCP packets that carry them. They're just very large and because of the magic of the TCP transport layer, they don't have to worry about breaking themselves up. The TCP packets are encapsulated by IP packets, so TCP doesn't have to also handle routing. This is called the Internet layer. The IP packets are finally encapsulated by whatever link layer the 3G implementation uses. This is all in the OSI model, which I'm sure you're familiar with

A TCP retransmit happens when either the receiver or the sender fails to receive a response within an allotted window. You're 100% right about this part, your TOWER obviously won't know YOU sent something if it never receives it, and that won't affect your bill. This seemed so obvious that I never bothered to spell it out, but I guess I should have. But if the TOWER sends something to YOU that YOU never get, YOU will (according to the TCP spec) ask for it again. The TOWER will send it again and it will affect your data usage. This is the biggest source of extra data usage, because you can lose quite a few TCP packets when the tower is sending you stuff from a couple of miles away.

HTTP headers can be really big, upwards of a couple of kilobytes depending on what is being sent back and forth, but they're only sent with every HTTP request (GET, POST, etc.). TCP headers are 256 bits, IP is around 160 bits, and the link layer header is probably less than that. TCP and IP headers are sent with every single packet, so even though they're small, the overhead adds up. Open up wireshark and look at how many TCP packets get sent on every page view. This is all on top of whatever your webpage's actual size is.

Go read your networking textbook again, freshman. Oh and since you aren't great at understanding implied things, I don't care if you're an actual freshman or a network admin with 20 years of experience, you're still wrong and a jerk to boot.


By XSpeedracerX on 2/2/2011 3:40:13 PM , Rating: 2
Pay attention folks. You're about to discover the difference between googling something and recieving a college level education on the subject.

"First of all, you're being a prick about proper terminology when it isn't strictly necessary here."

Umm, sorry but no. TCP is where packeting occurs. It's not done by HTTP or any application layer programs. It's not done by any of the transport layer programs. It is ONLY done at the transport layer by protocols like TCP. It is not mere terminology; it is the main function of a packet switched network and you conflating this process to happen elsewhere(or indeed anywhere) in the system, then to bitch about 'terminology' reveals your woeful ignorance on the subject. Sorry. Truth hurts.

"The TCP packets are encapsulated by IP packets"

Wrong, wrong and wrong again. there are no IP packets dude! TCP is where packeting occurs, in the transport layer and no where else. IP is not a packeting protocol. I repeat, IP is not a packeting protocol it is an address protocol and you need to already have a packet ready to go before you can make use of it.

"But if the TOWER sends something to YOU that YOU never get, YOU will (according to the TCP spec) ask for it again. The TOWER will send it again and it will affect your data usage."

And this is not overcharging you for data transmission that never occured because...?"

"you can lose quite a few TCP packets when the tower is sending you stuff from a couple of miles away."

Data loss is a function of signal strength, not distance from the tower. You are not guaranteed to lose packets 100% of the time for merely for being far away from a wireless tower.

"HTTP headers can be really big, upwards of a couple of kilobytes depending on what is being sent back and forth, but they're only sent with every HTTP request (GET, POST, etc.). TCP headers are 256 bits, IP is around 160 bits, and the link layer header is probably less than that."

From the perspective of a network, none of this is relevant. Every packet will be 576 bytes in size max and every single one will have the same header information. Whatevers contained within it will not be relevant until it returns to the application layer. But of course, if you knew something about how the OSI works instead of just being able to google it, you'd know that...

"TCP and IP headers are sent with every single packet, so even though they're small, the overhead adds up. Open up wireshark and look at how many TCP packets get sent on every page view. This is all on top of whatever your webpage's actual size is."

5% is 5% is 5%. it doesn't matter how many packets we sent; because we are using IPv4 header information, every single packet will have the same size header and the packet itself will be of a certain size. A trillion packets later it will not just magically inflate to 300% of the total just because we have a lot of packets now. Wow. Not only do you not know anything about networking technology, you don't even know your percentages and I learned those back in grade school! Can't say I'm shocked.

By the way, way to fail at explaining how AT&T can count the extra data that the consulting firm would somehow miss. It's not due to the packeting or the data being packetized. It's likely due to them liking money and wanting to get more of it.

"Oh and since you aren't great at understanding implied things, I don't care if you're an actual freshman or a network admin with 20 years of experience, you're still wrong and a jerk to boot. "

Oh, I hurt your wittle feewings? TOUGH. You have, and continue to, conflate the internal operation of a packet switched network, now you want to cry about terminology when this is pointed out to you. I'm sure you've never told any of this nonsense to anyone who actually works on networks for a living because, judging by the thinness of your e-skin, they'd leave you in tears.


By Gzus666 on 2/2/2011 3:53:08 PM , Rating: 3
If you two don't stop baking muffins, I'm gonna fly over on my toast wagon and butter your radial tire. It is a fluttery tricycle outside and you damn kids keep speeding your race coach outside of the trumpet.

So, do you want to talk about scrappy worms outside of the hobo frumps? I hear Santa was going to steal all your Suzie wigs if you ate coal on the chimney, but he said it was all squagles.

Anyway, hope all your potatoes didn't rot, have a moppy sailboat.


By monitorjbl on 2/2/2011 5:43:18 PM , Rating: 1
quote:
Pay attention folks. You're about to discover the difference between googling something and recieving a college level education on the subject.


Which one of just Googled this now? You spelled "receiving" wrong and you can't grasp the fundamentals of a conversation unless they're written exactly like they are on Wikipedia. Oh, and you're trolling online, the hallmark of the academic elite. But yeah, I'm sure it was me. Dunno where this computer engineering degree from NC State came from though. Must've blown in on the wind.

quote:
Wrong, wrong and wrong again. there are no IP packets dude! TCP is where packeting occurs, in the transport layer and no where else. IP is not a packeting protocol. I repeat, IP is not a packeting protocol it is an address protocol and you need to already have a packet ready to go before you can make use of it.


Every single TCP packet has to be encapsulated by IP. As you keep saying, this is because IP is an addressing protocol, which TCP is not. Therefore every IP packet is in an IP "envelope" (since you have to be such a baby about this) for the TCP packets to be put into. It's basically the same thing as a packet. In fact, many people DO call it a packet and I'm going to continue calling it that myself. And I never claimed IP did the actual packeting, just that each TCP packet is wrapped in an IP packet.

quote:
Umm, sorry but no. TCP is where packeting occurs. It's not done by HTTP or any application layer programs. It's not done by any of the transport layer programs. It is ONLY done at the transport layer by protocols like TCP. It is not mere terminology; it is the main function of a packet switched network and you conflating this process to happen elsewhere(or indeed anywhere) in the system, then to bitch about 'terminology' reveals your woeful ignorance on the subject. Sorry. Truth hurts.


I never claimed it did the packeting, just that an HTTP request/response is a single packet contained in the TCP packets that transport it.

quote:
And this is not overcharging you for data transmission that never occured because...?"


It DID occur, the data was sent out from the tower. Your phone may not have received it because one of a million things happened (signal was too weak, noise corrupted the data, etc.) and the data had to be sent again. Your data being sent DID occupy their tower's time even if you didn't get it.

quote:
Data loss is a function of signal strength, not distance from the tower. You are not guaranteed to lose packets 100% of the time for merely for being far away from a wireless tower.


I never said this. I said that you could lose quite a few packets when you're a couple of miles a way.

quote:
From the perspective of a network, none of this is relevant. Every packet will be 576 bytes in size max and every single one will have the same header information. Whatevers contained within it will not be relevant until it returns to the application layer. But of course, if you knew something about how the OSI works instead of just being able to google it, you'd know that...


Yes, there is a max value on every packet. That's not always the case in practice. Because of this inconsistency, the percentage of data occupied by headers will vary. This has nothing to do with the OSI model as a concept either, this has to do with the specifications of the protocols used at each layer. All the OSI states is that each layer accomplish a specific function, not how it has to work internally. It's an interface, if you know anything about Java. What you actually mean to say is that I would know this if I knew how TCP worked. Which I do.

quote:
5% is 5% is 5%. it doesn't matter how many packets we sent; because we are using IPv4 header information, every single packet will have the same size header and the packet itself will be of a certain size. A trillion packets later it will not just magically inflate to 300% of the total just because we have a lot of packets now. Wow. Not only do you not know anything about networking technology, you don't even know your percentages and I learned those back in grade school! Can't say I'm shocked.


I never said that the headers were the only source of overages. In fact, I made it pretty clear that most of the data would come from retransmits

quote:
Oh, I hurt your wittle feewings? TOUGH. You have, and continue to, conflate the internal operation of a packet switched network, now you want to cry about terminology when this is pointed out to you. I'm sure you've never told any of this nonsense to anyone who actually works on networks for a living because, judging by the thinness of your e-skin, they'd leave you in tears.


Your first response was to immediately call me an idiot. You could have politely disagreed with me, and we could have had a nice discussion. Me calling you a jerk back is somehow evidence of my e-skin being thin? By your logic, your e-skin is so frail that you can't bear to read words that don't strictly conform to what you expect them to be without immediately strangling a kitten and screaming at your monitor.


By IvanAndreevich on 2/3/2011 12:47:41 AM , Rating: 2
So what are you saying - the worse their network is, the more you have to pay for data? If most packets are corrupted, and the data needs to be retransmitted frequently that is. That hardly seems right to me. They should only charge for data successfully delivered.


Hmm
By InvertMe on 2/1/2011 8:56:23 AM , Rating: 2
As much as I like to see bad things happen to AT&T I don't this case has much grounding. AT&T can pretty much just say that data is overhead of smartphone useage. Which it probably is. I'd be curious to see what AT&T says is consuming the data.

and:

"his counsel discovered these charge." chargeS.




RE: Hmm
By dsx724 on 2/1/2011 10:07:10 AM , Rating: 1
I purchased 1 gallon of oil off Amazon for $30. Amazon's shipping company destroys 99 gallons of oil while delivering my oil. Amazon charges me $3000.


RE: Hmm
By InvertMe on 2/1/2011 11:21:56 AM , Rating: 2
I think a better analogy is:

You need gas for your car. You drive to the gas station and burn X gas getting there. You fill up and burn X gas back home. X+X is the extra needed to get your tank filled.

Make sense?


RE: Hmm
By WayneCoffee on 2/1/2011 3:54:54 PM , Rating: 2
You analogy is saying the extra is entirely caused by the "user". It's not really true in this case.

Software checking for updates, push notification, location services, etc. This can be an analogy of living close to/far away from the gas station.

The rest of the phantom data is a byproduct of the 3G network, poor signal quality, etc.

A better analogy will be: a lousy temperature control unit on the stored gasoline at a gas station(supposed to be 15 degree C, and now it's 18 degree C). Due to thermal expansion, the volume expanded and you are actually paying more for the same "mass" of gasoline.


Please make this public...
By quiksilvr on 2/1/2011 8:56:10 AM , Rating: 3
I just want to see a commercial (preferably a Super Bowl commercial) showing this to the country. To hell with AT&T!




Bad math
By jordanclock on 2/1/2011 11:29:51 AM , Rating: 3
I'm pretty sure an increase from 50 to 150 is a 200% increase, not 300%.




Are they the only ones?
By Jeff7181 on 2/1/2011 11:48:51 AM , Rating: 2
I wonder if the same test was done with Verizon or Sprint or Tmobile what the result would be and what about Android devices? What about Blackberries?




New Math
By The Insolent One on 2/1/2011 2:11:28 PM , Rating: 2
I'd love to find out if they consider 1000k to be 1MB like the storage guys.

If so, that would get class action status in a heartbeat.




It's not fair.....
By overlandpark4me on 2/5/2011 9:52:55 PM , Rating: 2
I'm not done laughing about their, "AT&T covers 97 percent of America misleading craptastic commercials.




By EricMartello on 2/1/2011 8:24:56 PM , Rating: 1
While it makes sense from a business standpoint, I can see the average consumer feeling a bit ripped off. I don't think this lawsuit is unwarranted because the average idiotPhone user doesn't know what network overhead is, and being billed for it is taking advantage of ignorance...it could be construed as misleading. If you pay for 2GB of data, you expect to be able to download 2GB of actual data in addition to whatever overhead may be involved with processing the requests for said data.




"It's okay. The scenarios aren't that clear. But it's good looking. [Steve Jobs] does good design, and [the iPad] is absolutely a good example of that." -- Bill Gates on the Apple iPad











botimage
Copyright 2012 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki