AEI-Brookings Paper on Network Neutrality

by on January 24, 2007 · 8 comments

The AEI-Brookings Joint Center has a new paper on network neutrality regulation.

The economic logic of the paper is impeccable; price discrimination often benefits consumer because it allows service providers to provide premium services to those willing to pay, while giving other consumers the option of bare-bones service at cut-rate prices. The example they use is airline seats: both first class and coach passengers benefit from the airlines’ price discrimination–those who care about comfort get a nicer ride, while those who care more about price get a cheaper ticket.

But like most people commenting on this issue–on both sides of the debate–Hahn and Litan are frustratingly vague about how exactly the price discrimination regime would work. For example:

Online gaming provides a good example of how and why all bits are not treated equally by access providers. If there is even a small delay in response time with some games or degradation in the quality of the video stream, product quality declines unacceptably. The suppliers of these games will frequently pay Web-hosting companies to offer faster and more reliable service than they could achieve with their own servers. They may pass the costs through to their customers. For example, users pay between $13 and $15 a month to subscribe to the popular multiplayer online role-playing game World of Warcraft, part of which presumably goes to maintain the quality of the gaming network.

It seems to me that there are several problems with this example. If they’re simply referring to the fact that companies often purchase rack space from facilities that have fat pipes, fast servers, and are topographically near most of their customers, that’s perfectly true but I don’t understand how it’s relevant. I haven’t seen any proposals to prohibit companies from purchasing fatter pipes or beefier servers.

On the other hand, if their claim is that companies like Blizzard are purchasing QoS contracts from backbone providers on the public Internet, that’s news to me. There are no citations in the paper, so it’s hard to tell what exactly they might be referring to.

Hahn and Litan state that “The Internet is literally a network of computers.” But that’s not actually true–it’s a network of networks. And this isn’t just nitpicking. Those networks are owned by thousands of different organizations. A prioritization scheme wouldn’t be especially useful unless everybody agreed on the same prioritization scheme. Yet the authors seem to suggest that I can visit any ISP and purchase “priority service” that will give my traffic higher priority across the entire Internet. This is not, as far as I know, true today, and I think it’s unlikely to be true any time soon.

So the authors are right that in principle, price discrimination can be economically beneficial. But I have yet to see anyone (on either side) offer a detailed explanation of how discrimination would work in practice.

One final nitpick: on the fourth page of the PDF (labeled page 31), the authors cite three RFCs over the course of the last 35 years purporting to show that network discrimination has a long pedigree. However, they don’t, as is common practice, give the numbers of the RFCs, to say nothing of a specific quote, so it’s hard to be sure what exactly is being referred to. It also doesn’t take into account the fact that not every RFC reflects common practice on the Internet. It’s called a “request for comments” for a reason. There are many RFCs describing protocols that were never widely adopted, or parts of which are never widely implemented. So the fact that three out of nearly 5000 RFCs mention prioritization doesn’t tell us a whole lot about common practice on the Internet, either today or in the past.

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

    Network neutrality is an attempt to resolve an engineering problem through regulation; it’s reminiscent of the Ohio Legislature’s Act defining pi as 3.0 to simplify things for the children.

    The old end-to-end arguments described a network optimized for one application: “careful file transfer”, where all the bytes arrive correctly with no particular time constraints. That was fine 35 years ago, but the Internet of today and tomorrow needs to support a diverse set of applications with a diverse set of transport and delivery requirements.

    The AEI-Brookings authors are on the right track, even though their exposition is less than clear in many places.

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

    Network neutrality is an attempt to resolve an engineering problem through regulation; it’s reminiscent of the Ohio Legislature’s Act defining pi as 3.0 to simplify things for the children.

    The old end-to-end arguments described a network optimized for one application: “careful file transfer”, where all the bytes arrive correctly with no particular time constraints. That was fine 35 years ago, but the Internet of today and tomorrow needs to support a diverse set of applications with a diverse set of transport and delivery requirements.

    The AEI-Brookings authors are on the right track, even though their exposition is less than clear in many places.

  • http://www.freedom-to-tinker.com Ed Felten

    Richard,

    I think you’re missing the point of the end-to-end argument. The point was not to engineer the network for a particular kind of application. The point was to engineer a maximally flexible network, because we didn’t know which applications people would want.

  • http://www.freedom-to-tinker.com Ed Felten

    Richard,

    I think you’re missing the point of the end-to-end argument. The point was not to engineer the network for a particular kind of application. The point was to engineer a maximally flexible network, because we didn’t know which applications people would want.

  • http://www.freedom-to-tinker.com Ed Felten

    Regarding the RFC citations: the longer version of the paper does cite specific RFCs. But Hahn and Litan seem to have misunderstood the RFCs they cite, which mostly recommend an end-to-end approach.

  • http://www.freedom-to-tinker.com Ed Felten

    Regarding the RFC citations: the longer version of the paper does cite specific RFCs. But Hahn and Litan seem to have misunderstood the RFCs they cite, which mostly recommend an end-to-end approach.

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

    Actually, Ed, I’m not missing the point at all. Read the infamous “End-to-End Arguments” paper and pay special attention to the part about having to type in some source code from listings because the bad memory in the IMP interface corrupted a file transfer; the goal at that moment in time was to build a better file transfer system.

    And the facts are that a passive network controlled by the end-points is great for some applications and not so great for others. I can prove that mathematically.

    So what we have in the passive Internet is a network that’s fine for file transfer applications and things built on the file-transfer model, such as web browsing, but a network that’s not so great for voice, video-conferencing, and on-line gaming. There is no way to stretch the passive architecture to support these applications optimally.

    If you were around at the time of the Great Switchover in 1983, you are no doubt aware of the fact that it was very hard to get telnet to work well on the TCP/IP Internet, because it’s fundamentally a latency-sensitive application. One of the tricks that had to be employed to make it look good was local echo, which is an example of application changing to support the needs of the network. Voice over IP is more of the same, but there are limits to what you do by way of compromising applications to fit defective network architectures.

    So whatever the “point” of end-to-end was, the result is a network that’s hostile to real-time communication.

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

    Actually, Ed, I’m not missing the point at all. Read the infamous “End-to-End Arguments” paper and pay special attention to the part about having to type in some source code from listings because the bad memory in the IMP interface corrupted a file transfer; the goal at that moment in time was to build a better file transfer system.

    And the facts are that a passive network controlled by the end-points is great for some applications and not so great for others. I can prove that mathematically.

    So what we have in the passive Internet is a network that’s fine for file transfer applications and things built on the file-transfer model, such as web browsing, but a network that’s not so great for voice, video-conferencing, and on-line gaming. There is no way to stretch the passive architecture to support these applications optimally.

    If you were around at the time of the Great Switchover in 1983, you are no doubt aware of the fact that it was very hard to get telnet to work well on the TCP/IP Internet, because it’s fundamentally a latency-sensitive application. One of the tricks that had to be employed to make it look good was local echo, which is an example of application changing to support the needs of the network. Voice over IP is more of the same, but there are limits to what you do by way of compromising applications to fit defective network architectures.

    So whatever the “point” of end-to-end was, the result is a network that’s hostile to real-time communication.

Previous post:

Next post: