Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

AT&T Denies Resetting P2P Connections

Posted by Soulskill on Sat Apr 26, 2008 08:14 AM
from the it-was-the-one-armed-isp dept.
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.'"
+ -
story

Related Stories

[+] Technology: AT&T's Plan to Play Internet Cop 272 comments
Ponca City, We Love You writes "Tim Wu has an interesting (and funny) article on Slate that says that AT&T's recent proposal to examine all the traffic it carries for potential violations of US intellectual property laws is not just bad but corporate seppuku bad. At present AT&T is shielded by a federal law they wrote themselves that provides they have no liability for 'Transitory Digital Network Communications' — content AT&T carries over the Internet. To maintain that immunity, AT&T must transmit data 'without selection of the material by the service provider' and 'without modification of its content' but if AT&T gets into the business of choosing what content travels over its network, it runs the serious risk of losing its all-important immunity. 'As the world's largest gatekeeper,' Wu writes, 'AT&T would immediately become the world's largest target for copyright infringement lawsuits.' ATT's new strategy 'exposes it to so much potential liability that adopting it would arguably violate AT&T's fiduciary duty to its shareholders,' concludes Wu."
[+] Competitors Ally With Comcast In FCC P2P Filings 220 comments
crocoduck writes "Right before the deadline passed for filing comments in the FCC investigation of Comcast's traffic-management practices, telecoms and other cable companies submitted a slew of comments defending Comcast's actions to the FCC. 'Just about every big phone company has filed a statement challenging the FCC's authority to deal with this problem. AT&T, Verizon, and Qwest all submitted lengthy remarks on February 13th, the last day for comments on the proceeding (parties can still reply to comments through the 28th). "The Internet marketplace remains fundamentally healthy, and the purported 'cure' could only make it sick," AT&T's filing declared. "At best, the network-management restrictions proposed by Free Press and others would inflict wasteful costs on broadband providers in the form of expensive and needless capacity upgrades — costs that would ultimately be passed through to end users, raise broadband prices across the board, and force ordinary broadband consumers to subsidize the bandwidth-hogging activities of a few."' P2P fans have also weighed in."
[+] Technology: Vuze Study Exposes P2P Throttling By Canadian ISP Cogeco 117 comments
urbanriot writes "Despite a growing number of complaints on the popular North American consumer broadband site BroadbandReports, employees working for the Canadian cable internet provider Cogeco have publicly denied interfering with torrents on their network. However, a recent plugin put out by the Vuze team exposed Cogeco of being the second worst ISP globally, of those tested. So far, Cogeco has failed to respond to these findings, but recent coverage from the mainstream media and Michael Geist may prompt them to finally admit to their controversial practices." The report by the Vuze team has some interesting information about other ISPs from around the world as well. Prior to this, Bell Canada was taking most of the flak in Canada for traffic management.
[+] Technology: Beating Comcast's Sandvine On Linux With Iptables 361 comments
HiroDeckard writes "Multiple sites reported a while ago that Comcast was using Sandvine to do TCP packet resets to throttle BitTorrent connections of their users. This practice may be a thing of the past as it's been found a simple rule in the Linux firewall, iptables, can simply just block their reset packets, returning your BitTorrent back to normal speeds and allowing you to once again connect to all your seeds and peer. If blocking the TCP packet resets becomes a common practice, on and off of Linux, it'll be interesting to see the next move in the cat-and-mouse game between customers and service providers, and who controls that bandwidth."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • 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'm on AT&T, and I use P2P about once a week, and I've never seen any resets in my router log.
      • Re:no reset for me (Score:5, Informative)

        by arth1 (260657) on Saturday April 26 2008, @12:11PM (#23207526) Homepage Journal

        I'm on AT&T, and I use P2P about once a week, and I've never seen any resets in my router log.

        Unless you run a business class router and have configured it to log incoming RST packets, you haven't seen any resets in your router log because they are not logged.

        The typical Linksys/Netgear/D-Link/whatever NAT "router" found in most homes most certainly won't log incoming RST packets.

        Regards,
        --
        *Art
          • Re: (Score:3, Informative)

            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
    • 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.
    • Sounds like the Romanian ISPs don't have the RIAA, MPAA, and courts breathing down their back about the illegality of transferring movies and music.
      • by emilper (826945) on Saturday April 26 2008, @10:02AM (#23206984)

        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.

    • by CastrTroy (595695) on Saturday April 26 2008, @09:04AM (#23206776) Homepage
      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.
  • Did Vuze ever confirmed that P2P connections created resets? or its just the reset count from the plugin?
    • Re:Confirmed? (Score:5, Informative)

      by budgenator (254554) on Saturday April 26 2008, @09:19AM (#23206838) Journal
      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.
  • by Anonymous Coward on Saturday April 26 2008, @08:23AM (#23206612)
    I can say that they never reset conne
  • Denial (Score:5, Insightful)

    by Narpak (961733) on Saturday April 26 2008, @08:39AM (#23206676)
    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.
  • by AHuxley (892839) on Saturday April 26 2008, @08:42AM (#23206686)
    "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.
  • by nurb432 (527695) on Saturday April 26 2008, @09:34AM (#23206896) Homepage Journal
    Then i guess their network just sux.
  • by sjvn (11568) <[moc.1anv] [ta] [nvjs]> on Saturday April 26 2008, @09:54AM (#23206964) Homepage
    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
  • Chuck's right (Score:5, Informative)

    by laird (2705) <laird.pando@com> on Saturday April 26 2008, @10:07AM (#23207000) Homepage Journal
    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 [tcpipguide.com] (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.
  • by Animats (122034) on Saturday April 26 2008, @11:00AM (#23207236) Homepage

    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.

      • Re: (Score:3, Informative)

        Like Comcast they can forge packets on BOTH sides of the router if they were doing it and therefore you'd get RST packets on both sides. Therefore merely comparing the output on both sides is not enough to determine if forging RST packets is occurring.

        You need to log, at each end, what each end is both sending and receiving. Then compare the results. Unless you installed a stateful firewall or a proxy server, there shouldn't be anything in the middle changing the packets. If there is, it's useful to k

  • by haaz (3346) on Saturday April 26 2008, @12:41PM (#23207638) Homepage
    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...
    • Yep. I consistently get max or close to speed on my FIOS, provided there is no other bottleneck and the remote host can support 15-20 megabits per second.

      I've been VERY happy with FIOS. We've had it for over a year now and I have had one 3 minute outage in all that time. That was during a horrendous storm last Summer.
    • ... 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 app

          • Re: (Score:3, Insightful)

            ... the actual reason that ISP's are doing traffic shaping related to p2p is driven by bandwidth consumption exceeding their capacity ....
            I don't understand. If it's strictly a bandwidth issue, why don't they do traffic shaping for all bandwidth regardless of protocol?