Category: Networks

The infamous “Ernesto” announces new countermeasures to grab even more of Comcast’s residential network:

BitTorrent throttling is not a new phenomenon, ISPs have been doing it for years. When the first ISPs started to throttle BitTorrent traffic most BitTorrent clients introduced a countermeasure, namely, protocol header encryption. This was the beginning of an ongoing cat and mouse game between ISPs and BitTorrent client developers, which is about to enter new level.

Unfortunately, protocol header encryption doesn’t help against more aggressive forms of BitTorrent interference, like the Sandvine application used by Comcast. A new extension to the BitTorrent protocol is needed to stay ahead of the ISPs, and that is exactly what is happening right now.

As much fun as this sort of thing is, it’s not really going to work. Bram Cohen, the inventor of BitTorrent explains why:

…when it comes to dealing with ISPs, obfuscation is some combination of hostile, unprofessional, and harmful. Software projects which value quality over featuritis generally steer clear of such things, especially when their potential effectiveness level is the equivalent of spitting in one’s face than actual utility.

Oh, and by the way, the amount of CPU necessary to do a diffie-hellman key exchange is enough to be annoying, and if you’re making a connection via a trusted intermediary, like, say, a tracker, or already have a reasonably secret piece of shared information like, say, an infohash, there’s no need to use a diffie-hellman key exchange to establish a shared secret. Imagining that crypto will stop being done by dilettantes is clearly a pipe dream though.

This won’t stop the pirates, of course, but it should cause them to think about what they’re doing. Not that it will.

Note: A reader points out that Cohen’s remarks referred to a previous obfuscation scheme that clearly didn’t work, and suggests the current one will work for some magic reason. I doubt it, because all that Comcast has to do is look for a large number of inbound connections when none are going out. No form of obfuscation will hide that scenario because the traffic stats alone are enough to expose it. I never cease to be amazed by how naive these pirates can be.

Here are some of the jewels among the comments submitted to the FCC on Save the Internet’s hilariously silly petition opposing sensible network management practices.

Brett Glass, the operator of a wireless ISP in Wyoming, points out that Saving the Internet would put him out of business and his customers off the net.

Rob Atkinson of the Information Technology and Innovation Foundation explains a bit about networking in general and DOCSIS in particular.

Comcast slams its clueless critics in a forceful and detailed response.

Competitive Enterprise Institute advocates market solutions.

Jerry Brito of the Mercatus Center reminds the Commission of the framework around new rules.

AT&T comments in support of rationality:

Some net neutrality proponents urge the Commission to preserve what they view as “the fundamental idea on the Internet since its inception . . . that every Web site, every feature, and every service should be treated exactly the same.” But this “dumb pipes” vision of the Internet is irresponsible nonsense. Some real-time Internet applications—such as video, voice, and telemedicine—have a much greater need for high service quality than other applications, such as ordinary e-mail. The Internet’s constituent networks can satisfy consumer needs only by treating such applications differently.

Verizon lays out the dollars and options:

Investing nearly $23 billion, Verizon has led the charge in fiber deployment and now makes its fiber-to-the-premises network (FiOS) available to 6.8 million homes and businesses, with plans to pass 18 million homes and businesses with FiOS by the end of 2010. Verizon’s investments are prompting competitors – such as the cable companies and other broadband providers – to respond, which has benefited consumers with lower prices and increased speed and quality. Competitive alternatives include 3G mobile wireless, fixed wireless/WiMAX, WiFi, broadband over powerline, and satellite. Verizon Wireless’s 3G technology, for example, now reaches 242 major United States cities with a total population of more than 200 million people.

George Ou gets down with the technical issues, and illustrates the key point.

Hands off the Internet joins the fray.

Progress and Freedom manages the demand glut.

Save the Internet isn’t wearing any clothes.

Peter Svensson, the AP reporter last seen carrying water for the EFF, has a new piece out on the bandwidth shortage:

Internet service providers and consumer advocates agree that some form of network management, also called “traffic shaping,” can be good for everybody. Not all Internet traffic has the same level of urgency. It makes sense for the service providers to give priority to a voice call, which needs a steady stream of quickly delivered data, over a movie download.

This is unusual territory for telecommunications providers — in the old telephone network, some phone calls aren’t generally prioritized over others. Prioritization makes the Internet more like the postal system, where you pay for delivery speed and quality of service.

Indeed, one the major problems with Internet regulation is the tendency of the consumer lobby to insist it act like the old telephone network. If the only tool you have is a telecom regulation, every computer looks like a phone. But on the Internet and its access networks, every user competes with every other use for Quality of Service, and that’s why we need traffic shaping and other forms of QoS.

Check out the latest Tech Policy Weekly podcast, Network Management Redux:

Two networking / IT experts join us for the podcast this week to discuss the ramifications of potential government regulation of broadband network engineering issues. The experts are Matt Sherman, a San Francisco Bay Area web developer and a technology policy blogger who blogs at RichVsReach.com, and George Ou who is the Technical Director of ZDNet, and is a former IT consultant specializing in Internet engineering and IT infrastructure and architecture issues. Also on the show are Adam Thierer of the Progress and Freedom Foundation, Jerry Brito of the Mercatus Center at George Mason University, and Tim Lee of the Cato Institute.

It’s a frank and lively discussion of broadband policy from several points of view.

Brilliance on Google’s crocodile tears about Microsoft’s takeover of Yahoo! from The Secret Diary of Steve Jobs:

This is Google’s favorite song. They sing it whenever they want to get their way. Whether the issue is net neutrality, or the bid for wireless spectrum, or now this — these guys do their best Eddie Haskell impersonation and look everyone straight in the eye and say it’s not that they’re concerned about their stock price or their revenue growth, it’s that they’re concerned about users, because gee whiz these evil guys who are opposing our efforts could really mess things up for everyone. The Google guys are the good guys, see? They’re the ones who put the needs of Internet users first. The amazing thing to me is that so many people believe this bullshit.

Ahem and indeed.

Some 28,000 public comments have already been posted to the FCC on the Comcast petition, and Save The Internet! is urging members to file more.

This is taking on the character of a DOS attack, as most of the comments are junk. Telling the FCC that you love the Internet is nice, but’s not exactly relevant to this enquiry. How will the non-junk comments get to the attention of the examiners?

But that’s the whole point.

One piece of required reading on Internet Architecture is the literature on End-to-End arguments. The canonical paper was End-to-End Arguments in System Design by Salzer, Reed, and Clark, which was substantially clarified by Clark’s follow-up, Rethinking the design of the Internet: The end to end arguments vs. the brave new world. Tim Moors offered a thoughtful critique, A Critical Review of “End-to-end arguments in system design” which makes this argument about Congestion Control:

In today’s Internet, congestion control is primarily implemented in end-systems: Most traffic is carried by TCP, which employs a Slow Start algorithm [21] to try to avoid congestion, uses the rate of acknowledgement return to estimate the permissible transmission rate, and interprets packet loss as indicating congestion that requires that the source throttle its transmissions. The only network support is some Random Early Discard devices that reinforce TCP’s behavior by signaling the onset of congestion by discarding packets. However, congestion control is not amenable to end-to-end implementation for the following reasons: First, like routing, congestion is a phenomenon of the network, and since multiple endpoints share the network, it is the network that is responsible for isolating endpoints that offer excessive traffic so that they do not interfere with the ability of the network to provide its service to other endpoints. Second, it is naive in today’s commercial Internet to expect endpoints to act altruistically, sacrificing the performance that they receive from the network in order to help the network limit congestion. The end-to-end arguments that enable the success of peer-to-peer applications also allow the rapid proliferation of applications that do not behave in a “TCP friendly” manner. It is cavalier to allow the commercially valuable Internet to be susceptible to such risks. The requirement that the transport layer implement congestion control also prevents the use of active networking to make transport layers configurable [22]. Summarizing these first two reasons: even though the network is responsible for controlling congestion, it has no reason to trust that endpoints will cooperate in controlling congestion.

A third argument against endpoint implementation of congestion control is that it is inappropriate for certain networks, leading to an unnecessary performance penalty. For example, Slow Start unnecessarily impedes sources that are transmitting on optical circuits (which don’t congest), Media Access Control protocols already provide congestion control for traffic that is local to a LAN, and the assumption that packet loss indicates congestion is invalid for wireless networks in which appreciable loss may also occur due to noise. Fourth, the transport layer lacks the innate ability to detect that congestion is imminent; it can only detect the possible presence of congestion, e.g. through observing packet loss. Schemes such as RED may signal imminent congestion, but they do so by unnecessarily discarding traffic for which the network has already spent resources partially delivering. Fifth, endpoints that implement congestion control separately must independently re-learn the network state, leading to excessively cautious behavior. Finally, while the endpoint may know how it would like to adapt to congestion, it is the network that knows when and where adaptation is needed [23], and should be responsible for ensuring that adaptation occurs. Thus, congestion control is one function that is not well suited to end-to-end implementation.

Like many things designed 40 years ago, the Internet carries design mistakes. These can be corrected, and we’ll all be better off if they are.