“Cog” at The Abstract Factory has a pretty damning critique of the Hahn/Litan paper’s citation of RFCs. He considers each of the four RFCs in turn and makes a pretty compelling argument that none of them say what Hahn and Litan say they say.
Before I get to Cog’s post, I should note that I was wrong in saying they didn’t cite the RFCs in question. There is, apparently, a short version and a long version of the paper, and I was looking at the shorter version, from which the footnotes are omitted. But they did offer them in the full version.
Anyway, I’ll just quote Cog’s comments on one of the four RFCs Hahn and Litan quote:
First of all, TCP is an end-to-end protocol. Period. Every single normative sentence in RFC 675 describes an operation that occurs on an end-host, not on a router internal to the network. The above sentence describes how an end-host should prioritize processing of packets in buffers inside its networking stack. It is, in other words, a hint to operating system implementors who want to write TCP/IP stacks. It has nothing whatsoever to do with “the network” prioritizing packets.
If this sounds like an abstruse distinction, imagine “the network” as the US Postal Service, and an end host as your home. The operating system’s network buffer is your mailbox. What the above sentence is saying is that before you stuff outgoing mail into your mailbox, you should take your incoming mail out of your mailbox. It is saying nothing about whether the US Postal Service should pick up your mail in one order or another.
Does RFC 675 present a “sharp contrast to the romantic ideal of the end-to-end principle”?
It does not.
This is, again, why it’s important to distinguish neutrality as an end from neutrality as a means. The end-to-end principle is a principle about what routers implementing the TCP/IP principle ought to do. It says nothing about broader social questions such as whether it’s “fair” that Akamai gives some companies the ability to get their content to consumers faster than others. (Some activists may opine on this in their arguments for regulation, but that’s their error. The distinction is pretty clear to the ones who know what they’re talking about)
Cog closes his post with another important point: this is a technical subject, and when you write a paper on a technical subject outside of your area of expertise, you should consult one (preferably several) people with training in that field. In particular, if you’re going to argue that the Internet does or doesn’t work a certain way, you should ask someone with computer science training, and preferably someone with training in network design. That will help you make the sort of elementary mistakes that Cog highlights in his post.
Cog’s analysis of the other three RFCs cited in the paper is equally good, so I encourage you to check out his post.
The Technology Liberation Front is the tech policy blog dedicated to keeping politicians' hands off the 'net and everything else related to technology.
Comments on this entry are closed.