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.'"
Hah. I remember when DSL first came out and I waited to get that instead of cable I got some comments from friends but Verizon seemed to make sense to me vs the more shared bandwidth of cable. I knew it wouldn't take long for customers to start complaining about not getting all the bandwidth promised and other measures enacted to restrict user's bandwidth. Based on comments here and from friends and relatives. Instead of blocking p2p they do stuff like this http://www.crn.com/software/206903773
Verizon wireless internet services are a different story it seems.
I'm on AT&T, and I use P2P about once a week, and I've never seen any resets in my router log.
AT&T may not be throttling P2P. As an AT&T DSL victim^H^H^H^H^H^Hcustomer, with their use of PPPOE (setting up a PPP connection -- the protocol used for dialup -- to tunnel over ethernet) and generally crappy service, my PPP connection drops and IP therefore changes very frequently (more than once a day). I would imagine that the TCP RSTs are caused by these connection drops more than anything else.
It's unfortunate that in the cheap end of the "broadband" segment ($30/mo for phone line + 768k/256k), AT&T DSL is really the only option, at least in my area.
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.
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.
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.
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.