Ed Felten’s Alternate Internet

Professor Ed Felten tells Comcast to stay after class and clean erasers:

There are well-established mechanisms for dealing with traffic congestion on the Internet. Networks are supposed to respond to congestion by dropping packets; endpoint computers notice that their packets are being dropped and respond by slowing their transmissions, thus relieving the congestion. The idea sounds simple, but getting the details right, so that the endpoints slow down just enough but not too much, and the network responds quickly to changes in traffic level but doesn’t overreact, required some very clever, subtle engineering.

Indeed, if everybody was nice, polite, and well-behaved, the Internet’s traffic management features would be enough for Comcast and everybody else. And we wouldn’t need jails, or police, or traffic signs because everybody would just be good. That’s the end-to-end world, and it exists nowhere in this universe.

What does exist is a program called BitTorrent that allows the user to set targets for bandwidth consumption in both the upstream and the downstream direction, and strives to reach those limits by any means necessary. If the link is slow, it opens additional connections. If TCP is slow, it uses UDP. If its connection requests are filtered, it encrypts them. If its port is blocked, it uses a different one. It worms through firewalls and works around NATs. Nothing in the conventional arsenal of TCP effectively limits BitTorrent’s appetite for bandwidth, it’s all up to the user. And if he’s a hog, it’s out of control.
The long-term solution to congestion is to increase bandwidth, and there is no cheaper way to to that than to expel bandwidth hogs. Comcast doesn’t always go that far, and for that they get blasted in the blogs. Life is not fair.

Fundamentally, the problem that Comcast addresses with its TCP RSTs isn’t an Internet problem, it’s an Intranet problem, as in the DOCSIS network inside Comcast doesn’t handle high loads of upstream traffic without going unstable. This isn’t a problem that the Internet can address, although TCP does provide Comcast with a knob to turn.

H/T Tech Lib.

2 thoughts on “Ed Felten’s Alternate Internet”

  1. Bittorrent is designed to work around network obstacles through the methods you mentioned on techliberation.com. But unlike spambots or hijacked PCs, both parties to a Bittorrent connection want to exchange with each other. For the most part, an actual human being wants to share a file with another, so torrent clients have redundancies designed to compensate for a whole host of scenarios.

    You say Bittorrent has an insatiable appetite. That’s true. But any protocol can be overused. People who stream too many videos off Netflix, or download too many 5GB 720p movies off Xbox Live, or spend too much time in online gaming or even backup their hard drive regularly to an online storage website could easily consume more bandwidth than a typical Bittorrent user. There will always be hogs and there will always be a single protocol that is utilized the most. That protocol is currently Bittorrent, but it could change as high bitrate video becomes more prevalent. Seven years ago Napster was a major drain on bandwidth. And before that websites full of images used lots of network resources. Plus line speed is limited so a user can’t upload more than 1Mbps no matter how much bandwidth an application desires.

    There’s nothing wrong with being a hog except for its effect on ISPs that are running low on capacity. But how many reports have surfaced about a customer of Verizon or AT&T or Speakeasy being terminated for overuse? Zero. So clearly it is possible for an ISP to be profitable while still having some hogs. Of course cable has a distinct network architecture with inherent limitations, but in the end aren’t all residential internet services shared? Groups of DSL users share a single optical carrier that connects to a backbone, which has a finite amount of bandwidth. But I have not heard FiOS or DSL users getting terminated because, presumably, as usage increases over time the telcos simply add capacity to their network.

    Also there is no evidence Comcast is spoofing RST packets only when necessary to alleviate network congestion. At 3AM I can’t imagine many nodes are saturated so why not let people seed to their heart’s content? Also, why not reset TCP connections only after a single IP address has been seeding for a while? If those clever engineers at Sandvine can design technology to limit bittorrent through RST packets I see no reason they can’t develop these added controls for a price. And Comcast has undoubtedly paid dearly for this traffic shaping technology.

    Cable companies really need to come up with a business model that coincides with their cost structure. Cablevision in New York already has DOCSIS 2.0 with 38Mbps down, 5 up for the same price as Comcast. To my knowledge, Comcast skipped DOCSIS 2.0 entirely but now it looks as if that decision is coming back to bite them. If Verizon can earn profit from 20Mbps symmetrical uncapped at $64.95 a month I don’t understand why Comcast can’t make money off 8Mbps/768Mbps at $52.95. They come across as unwilling to invest in network upgrades, and it appears they are putting off needed infrastructure modernization unlike Verizon and AT&T which are leaping forward faster. Originally DOCSIS 3.0 was supposed to be rolled out in 2008 but now it is looking like mass deployment won’t be until 2009. And why doesn’t Comcast offer 16/1 everywhere, considering it charges the same for 16/1 as 8/768? If it is profitable to provide 16/1 service in areas where FiOS exists, then Comcast must be making a killing off 8/768 at $52.95.

    And your mention of Bittorrent violating RFCs is interesting. I don’t know much about them and I’ve read they are more or less irrelevant because interconnect agreements are what really matter nowadays. But if they are important, isn’t there a compelling case to be made that Sandvine actually violates them? Here’s a Slashdot post that makes the case against forging RST packets.

    Pardon me for my technical incompetence. I’m not a network engineer so please correct any technical mistakes I may have made.

Leave a Reply

Your email address will not be published. Required fields are marked *