On Knowing Your Subject

by on January 25, 2007 · 2 comments

“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.

SHARE: 2 comments

About Tim Lee

Timothy B. Lee (Contributor, 2004-2009) is an adjunct scholar at the Cato Institute. He is currently a PhD student and a member of the Center for Information Technology Policy at Princeton University. He contributes regularly to a variety of online publications, including Ars Technica, Techdirt, Cato @ Liberty, and The Angry Blog. He has been a Mac bigot since 1984, a Unix, vi, and Perl bigot since 1998, and a sworn enemy of HTML-formatted email for as long as certain companies have thought that was a good idea. You can reach him by email at leex1008@umn.edu.

Read more articles by Tim Lee.

  • http://bennett.com/blog Richard Bennett

    I think pseudonymous Cog’s analysis is pedantic. While it’s certainly true that Hahn and Litan studied the wrong RFCs, they’re essentially right that the Early Internet was not as neutral as those who’ve adopted Net Neutrality as a religion claim it was. It had “urgent data”, precedence, and RED, and the mature Internet has added IntServ, DiffServ, SIP, Deep Packet Inspection and VPNs to segregate traffic classes.

    But it is true that the Early Internet was substantially neutral for a given class of applications. As long as your application had service requirements similar to ftp, you were fine; if your application had interactive service requirements like telnet, you were not so fine and your best course of action was to change your application to suit the one and only service provided by the Internet.

    That’s because “end-to-end” is a structural bias in favor of applications that deal in bulk data on a loose time line and against those what deal in small units of data on a tight timeline. There’s no way around the fact that this is not “neutral” at the level of application needs. But this structural bias is what end-to-end advocates call “neutrality.” That’s one reason it’s hard to take them seriously, even when they’re brave enough to use their real names.

    Frankly, all this kow-towing to the Internet Architecture circa 1980 doesn’t thrill me. Whatever it was, where is it written that it can’t be improved, or that it doesn’t need to be improved in order to support a wider set of applications?

    And if it’s not a settled fact of engineering that there’s one and only one way to build an Internet, what is the motivation for regulation that stifles experimentation and progress? Bob Kahn certainly doesn’t think the Internet closes the door on network architecture, and he’s got a little history on the project.

  • http://bennett.com/blog Richard Bennett

    I think pseudonymous Cog’s analysis is pedantic. While it’s certainly true that Hahn and Litan studied the wrong RFCs, they’re essentially right that the Early Internet was not as neutral as those who’ve adopted Net Neutrality as a religion claim it was. It had “urgent data”, precedence, and RED, and the mature Internet has added IntServ, DiffServ, SIP, Deep Packet Inspection and VPNs to segregate traffic classes.

    But it is true that the Early Internet was substantially neutral for a given class of applications. As long as your application had service requirements similar to ftp, you were fine; if your application had interactive service requirements like telnet, you were not so fine and your best course of action was to change your application to suit the one and only service provided by the Internet.

    That’s because “end-to-end” is a structural bias in favor of applications that deal in bulk data on a loose time line and against those what deal in small units of data on a tight timeline. There’s no way around the fact that this is not “neutral” at the level of application needs. But this structural bias is what end-to-end advocates call “neutrality.” That’s one reason it’s hard to take them seriously, even when they’re brave enough to use their real names.

    Frankly, all this kow-towing to the Internet Architecture circa 1980 doesn’t thrill me. Whatever it was, where is it written that it can’t be improved, or that it doesn’t need to be improved in order to support a wider set of applications?

    And if it’s not a settled fact of engineering that there’s one and only one way to build an Internet, what is the motivation for regulation that stifles experimentation and progress? Bob Kahn certainly doesn’t think the Internet closes the door on network architecture, and he’s got a little history on the project.

Previous post:

Next post: