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

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.


"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 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki