Slashdot Mirror
AT&T Denies Resetting P2P Connections
betaville points out comments AT&T filed with the FCC in which they denied throttling traffic by resetting P2P file-sharing connections. Earlier this week, a study published by the Vuze team found AT&T to have the 25th highest (13th highest if extra Comcast networks are excluded) median reset rate among the sampled networks. In the past, AT&T has defended Comcast's throttling practices, and said it wants to monitor its network traffic for IP violations.
"AT&T vice president of Internet and network systems research Charles Kalmanek, in a letter addressed to Vuze CEO Gilles BianRosa, said that peer-to-peer resets can arise from numerous local network events, including outages, attacks, reconfigurations or overall trends in Internet usage. 'AT&T does not use "false reset messages" to manage its network,' Kalmanek said in the letter. Kalmanek noted that Vuze's analysis said the test 'cannot conclude definitively that any particular network operator is engaging in artificial or false [reset] packet behavior.'"
It's ironic that in America, the country that much of the basis for the Internet hails from, seems to be regressing in Internet access. In Eastern Europe, more and more people enjoy fast and unthrottled connections, and ISPs don't care how many gigabytes of traffic you pull in each month. One ISP I know in Romania helped alleviate demands on its network by setting up a DC++ server where people could share films and music with people from the same city, not by penalizing customers.
I can say that they never reset conne
I'm on AT&T, and I use P2P about once a week, and I've never seen any resets in my router log.
No! No! We are not screwing our customers to maximize profits!
Basic principle of greed you try to do as much that is legally and ethically grey; and then deny it until you are finally dragged kicking and screaming into court.
The Long Now Foundation
"suggesting that industry forums like the Distributed Computing Industry Association would
provide a better means for addressing such questions."
That the computer worlds version of a closed door human rights meeting for despots and dictators?
Just tell your consumers the truth Charles, you missed a decade of upgrades.
Domestic spying is now "Benign Information Gathering"
use anything on Joost and record your network logs 6-12 hours after. you will still register numerous hits per minute from AT&T regional hubs.
Any chance that the reset packets could be sent from someone else? If AT&T can send a reset packet that looks like it's from the person on BT you are communicating with, what's to stop other users from sending a similar packet. If I was on AT&Ts network, could I forge a packet that looks at though it was from another IP Address? Sure I couldn't get a response back, but I would only be sending out reset packets, and wouldn't want any ACK back for my bogus reset.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
No and Vuze was quite up-front about the study, they basically measured the number of RST messages and divided by the number of network connections. The numbers weren't intended to be accurate but rather to give an indication of realevive trends.
For example,
37 users on Telecom Italia France using ASN 12876 experienced a median of 2.53% RST messages;
27 users on AT&T WorldNet Services using ASN 6478 experienced 13.97% RST messages;
24 users on AT&T WorldNet Services using ASN 7018 experienced 5.35% RST measages;
40 users on Comcast Cable using ASN 33668 experienced 23.72% RST messages.
One thing you have to remember is the forged RST packets is a man-in-the-middle-attack, the Vuze plugin connected on a AT&T connection doesn' know if the RST came from AT&T at ASN 6478 , AT&T at ASN 7018, Comcast or Telecom Italia France.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Then i guess their network just sux.
---- Booth was a patriot ----
I have an AT&T DSL connection. I've used it for years. I've also beaten the heck out of it for years with massive downloads, uploads and the like. It has worked fine, until the last few months. Now, whenever I have a P2P Torrent going a day or more, I know my connection is going to lock up completely anywhere from 20 to 28 hours into the process. The only solution is to hard boot my DSL modem. It then happens again, about once a day, until I stop the torrent.
Coincidence? I think not.
Steven
Well, they have ... once or twice a year you hear about raids by ORDA (Rumanian Intellectual Property Rights Office), networking equipment confiscated and hefty fines paid. Quite the same rate as in US, considering that Rumania is only 22 mil.
What is different: real competition in the market. About half of the home connections are managed by small companies with a few thousand to some ten thousand customers, and the rest is split between three big guys with cable connections and three with wireless connections, one of which is the former state telecom company. Competition is so big that you can have at least four or five offers at the same time in the same location: Romtelecom, one EVDO/CDMA network with reasonable bandwidth, two G3 networks I never used but heard good things about quality of service, one of the big cable tv companies (there are two, but they avoid competing with each other) and at least one of small companies.
The small companies usually have bittorent trackers and DC++ hubs. I think they can afford to pay the fines, but cannot afford to lose customers.
TCP resets can occur for many reasons. All that client software can know and report is that the TCP reset occurred. But, for example, it can't know whether it got a reset because the software on the other end of the connection crashed, or had a bug, or the computer was turned off, or there was some corrupted communications between the two causing the TCP connection to get confused and need to be reset. This is all explained at http://www.tcpipguide.com/free/t_TCPConnectionManagementandProblemHandlingtheConnec.htm (for example).
Vuze's test only counted reset rates, so it can't prove anything about what's going on. At most, it could suggest areas where it might be productive to do more investigation.
Enable 3D printed prosthetics!
... One more note... Not only does this study do nothing to show that AT&T might be modifying traffic, it shows that AT&T is probably NOT modifying traffic!
/. look like a group of geeks with nothing better to do than bash AT&T. I'm sure you can find some legitimate grievances against AT&T instead of wasting people's time and ruining the reputation of a good news source with trash like this.
Comcast has admitted to sending false resets, so, no surprise, they are on top of the list. In fact, they are not only on top of the list, they're nowhere else. This is to be expected with a systematic interference with traffic.
HOWEVER, if you look down the list, and I mean, WAYYY down the list, you'll find that ranked at #101 (out of 108)... is AT&T! If AT&T has been systematically producing false resets, they wouldn't just have one network high on the list, but all of them.. (see: Comcast).
No one ever got a good rep defending AT&T, but stories like this just make
I guess the time for the encrypted, anonymized overlay networks is now.
This approach to testing is stupid. One correct approach is to record all the packets sent and received at both ends of the connection, then compare them after the session. Any unexpected packets are bogus.
There are some routers that will generate bogus packets through out and out bugs. The Sveasoft Linux software for Linksys routers had that problem a few years back. If you had more than one or two packets queued for the air link, some of the packets would get garbled. Most users never saw this, because they were connecting to the Internet via a low bandwidth link. In that mode, you can't saturate the air link, and you never build up a transmit queue. We were doing big downloads from a local file server to a local client, with no traffic to the outside world at all. (We were using this for a robot vehicle, with long debug logs and code updates being transferred.) An FTP connection wouldn't work for more than about fifteen seconds. It would stall, retransmitting until the connection timed out. We finally put packet sniffers on the links and found out that TCP packets were being garbled by the "internal firewall", even when it was supposedly turned off. The garble wasn't random; it occurred in a repeatable way that made each TCP retransmit fail.
In 2007, I found a transparency problem with Coyote Point load balancers. This one would mysteriously block connections. If you made an HTTP connection through a Coyote Point load balancer, and sent an HTTP header with a "User-agent" string ending in "m" but not containing another "m", and the HTTP header contained no additional fields, the load balancer would not pass any TCP packets to the systems behind the load balancer. This turned up on a site where I know the people who run the site, and we did packet dumps on both sides of the load balancer to confirm this. Coyote Point parses HTTP headers with regular expressions, and I suspect that, somewhere in the built-in rules, someone wrote "\m" where they meant to write "\n". In a typical non-response, Coyote Point suggested we upgrade the load balancer. I pointed out that Coyote Point's own site had the same problem.
So a good network transparency test for end users would be a useful tool to have around. The existing tools tend to be part of protocol analyzers, and assume the user knows TCP/IP/Ethernet down to the bit level.
It could also the the OS or BT software that you are using. A few years ago (not sure if it's still the case), I used to get 3-4 time the speed when downloading torrents in Linux as I did in Windows. Currently I can max out my connection in Windows, but I'm only on a 1 mbit connection. Whereas I used to be on a 5 mbit. I could max that out in Linux, but not in Windows. I know my brother in law maxes out his 10 mbit connection using windows, but he has an uber gaming computer with dual core and 2 gigs of RAM. When I had my 5 Mbit connection I was running XP on a machine with 256 MB of RAM and only running at 266 MHz.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
While it could be TCP resets, as I see someone talking about in a comment above, Time Warner being pricks is so much more attractive...
-- haaz.
... is why ISPs want to be in the business of monitoring their networks for certain content. Aren't they supposed to have common-carrier status (which, AFAIK, is supposed to mean that they're agnostic about and not responsible for the traffic on their networks)? Why do they want to spend money on engineering and PR damage-control for all this if they could just ignore it? They don't. I've never heard of any ISP who's monitoring their network for specific content, because it raises all sorts of legal questions.The reason that ISP's are starting to manage traffic it is due to capacity issues - changes in user behavior (e.g. viewing high quality video online, p2p) dramatically increase the bandwidth consumption per user, causing demand to exceed available bandwidth.
Given that demand exceeds current supply, and expanding capacity is time consuming and expensive, some ISP's appear to be managing traffic in a protocol-specific way (i.e. deliver time-sensitive VOIP traffic before HTTP page views before P2P seeding), and others appear to be managing traffic in a protocol-agnostic way.
Of course, many ISP's are building out to have capacity that exceeds demand. This is expensive and time consuming (e.g. Comcast has started deploying DOCSIS 3.0, but it'll take years and billions of dollars to upgrade everyone, Verizon has been rolling out fiber to the home, but again it'll be years and billions of dollars before fiber can completely replace DSL). And, in lower population density areas, or parts of the world where people can't pay much for broadband, the cost of providing more capacity exceeds what people are willing to pay, so traffic shaping is the only viable answer.
I've seen some people say "They sold me X bandwidth, and now they're not delivering it". They're confusing two very different types of bandwidth, capped and committed.
Capped bandwidth is cheap, because there are no guarantees other than that you won't get more than a certain amount. This is what home users generally buy. So if you read your ISP's terms, they probably are very clear that you're getting "up to X" performance, but with no committed performance, or even availability. For this, you might pay $60/month for 20 Mbps, or $3/Mbps.
Committed bandwidth is expensive, because the ISP reserves resources so that you can always get all the bandwidth that you're paying for, with financial penalties to the ISP for slowdowns or outages. For this, you might pay $359/month for a T1 line giving you 1.5 Mbps, or $239/Mbps.
What this means is that if you pay for capped bandwidth, you're making the choice of saving a lot of money by buying unreliable bandwidth. If you really, really want committed bandwidth, you can do what web sites and businesses do, and pay for committed bandwidth.
Enable 3D printed prosthetics!
So don't hold your breath. If they can tell what hosts you are communicating with, they can determine everything else. They are either at an ISP or a backbone provider (or in your basement, if you're the paranoid type).
1. a freebie, we presume the forger knows the IP of the machine to interfere with
See http://kerneltrap.org/node/3072 for some math on it. It's still less than one in a billion without attracting attention to yourself on some level.2. the destination port is straightforward to guess
3. the sequence number is easy to fake out due to widespread use of TCP size windows.
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1