May 19, 2024

Nuts and Bolts of Network Discrimination

One of the reasons the network neutrality debate is so murky is that relatively few people understand the mechanics of traffic discrimination. I think that in reasoning about net neutrality it helps to understand how discrimination would actually be put into practice. That’s what I want to explain today. Don’t worry, the details aren’t very complicated.

Think of the Internet as a set of routers (think: metal boxes with electronics inside) connected by links (think: long wires). Packets of data get passed from one router to another, via links. A packet is forwarded from router to router, until it arrives at its destination.

Focus now on a single router. It has several incoming links on which packets arrive, and several outgoing links on which it can send packets. When a packet shows up on an incoming link, the router will figure out (by methods I won’t describe here) on which outgoing link the packet should be forwarded. If that outgoing link is free, the packet can be sent out on it immediately. But if the outgoing link is busy transmitting another packet, the newly arrived packet will have to wait – it will be “buffered” in the router’s memory, waiting its turn until the outgoing link is free.

Buffering lets the router deal with temporary surges in traffic. But if packets keep showing up faster than they can be sent out on some outgoing link, the number of buffered packets will grow and grow, and eventually the router will run out of buffer memory.

At that point, if one more packet shows up, the router has no choice but to discard a packet. It can discard the newly arriving packet, or it can make room for the new packet by discarding something else. But something has to be discarded.

(This is one illustration of the “best effort” principle, which is one of the clever engineering decisions that made the Internet feasible. The Internet will do its best to deliver each packet promptly, but it doesn’t make any guarantees. It’s up to software that uses the Internet Protocol to detect dropped packets and recover. The software you’re using to retrieve these words can, and probably often does, recover from dropped packets.)

When a router is forced to discard a packet, it can discard any packet it likes. One possibility is that it assigns priorities to the packets, and always discards the packet with lowest priority. The technology doesn’t constrain how packets are prioritized, as long as there is some quick way to find the lowest-priority packet when it becomes necessary to discard something.

This mechanism defines one type of network discrimination, which prioritizes packets and discards low-priority packets first, but only discards packets when that is absolutely necessary. I’ll call it minimal discrimination, because it only discriminates when it can’t serve everybody.

With minimal discrimination, if the network is not crowded, lots of low-priority packets can get through. Only when there is an unavoidable conflict with high-priority packets is a low-priority packet inconvenienced.

Contrast this with another, more drastic form of discrimination, which discards some low-priority packets even when it is possible to forward or deliver every packet. A network might, for example, limit low-priority packets to 20% of the network’s capacity, even if part of the other 80% is idle. I’ll call this non-minimal discrimination.

One of the basic questions to ask about any network discrimination regime is whether it is minimal in this sense. And one of the basic questions to ask about any rule limiting discrimination is how it applies to minimal versus non-minimal discrimination. We can imagine a rule, for example, that allows minimal discrimination but limits or bans non-minimal discrimination.

This distinction matters, I think, because minimal and non-minimal discrimination are supported by different arguments. Minimal discrimination may be an engineering necessity. But non-minimal discrimination is not technologically necessary – it makes service worse for low-priority packets, but doesn’t help high-priority packets – so it could only be justified by a more complicated economic argument, for example that non-minimal discrimination allows forms of price discrimination that increase social welfare. Vague arguments that you have to reserve some fraction of capacity for some purpose won’t cut it.

[Postscript for networking geeks: You might complain that it matters not only which packets are dropped but also which packets are forwarded first, and so on. True enough. I simplified things a bit to fit within a blog post; but it should be fairly obvious how to expand the principle I’m describing here to deal with the issues you’re raising.]

Quality of Service: A Quality Argument?

One of the standard arguments one hears against network neutrality rules is that network providers need to provide Quality of Service (QoS) guarantees to certain kinds of traffic, such as video. If QoS is necessary, the argument goes, and if net neutrality rules would hamper QoS by requiring all traffic to be treated the same, then net neutrality rules must be harmful. Today, I want to unpack this argument and see how it holds up in light of computer science research and engineering experience.

First, I need to make clear that guaranteeing QoS for an application means more than just giving it lots of bandwidth or prioritizing its traffic above other applications. Those things might be helpful, but they’re not QoS (or at least not the kind I’m talking about today). What QoS mechanisms (try to) do is to make specific performance guarantees to an app over a short window of time.

An example may clarify this point. If you’re loading a web page, and your network connection hiccups so that you get no traffic for (say) half a second, you may notice a short pause but it won’t be a big deal. But if you’re having a voice conversation with somebody, a half-second gap will be very annoying. Web browsing needs decent bandwidth on average, but voice conversations needs better protection against short delays. That protection is QoS.

Careful readers will protest at this point that a good browsing experience depends on more than just average bandwidth. A half-second hiccup might not be a big problem, but a ten-minute pause would be too much, even if performance is really snappy afterward. The difference between voice conversations and browsing is one of degree – voice conversations want guarantees over fractions of seconds, and browsing wants them over fractions of minutes.

The reason we don’t need special QoS mechanisms for browsing is that the broadband Internet already provides performance that is almost always steady enough over the time intervals that matter for browsing.

Sometimes, too, there are simple tricks that can turn an app that cares about short delays into one that cares only about longer delays. For example, watching prerecorded audio or video streams doesn’t need QoS, because you can use buffering. If you’re watching a video, you can download every frame ten seconds before you’re going to watch it; then a hiccup of a few seconds won’t be a problem. This is why streaming audio and video work perfectly well today (when there is enough average bandwidth).

There are two other important cases where QoS isn’t needed. First, if an app needs higher average speed than the Net can provide, than QoS won’t help it – QoS makes the Net’s speed steadier but not faster. Second – and less obvious – if an app needs much less average speed than the Net can provide, then QoS might also be unnecessary. If speed doesn’t drop entirely to zero but fluctuates, with peaks and valleys, then even the valleys may be high enough to give the app what it needs. This is starting to happen for voice conversations – Skype and other VoIP systems seem to work pretty well without any special QoS support in the network.

We can’t say that QoS is never needed, but experience does teach that it’s easy, especially for non-experts, to overestimate the importance of QoS. That’s why I’m not convinced – though I could be, with more evidence – that QoS is a strong argument against net neutrality rules.

How Would Two-Tier Internet Work?

The word is out now that residential ISPs like BellSouth want to provide a kind of two-tier Internet service, where ordinary Internet services get one level of performance, and preferred sites or services, presumably including the ISPs’ own services, get better performance. It’s clear why ISPs want to do this: they want to charge big web sites for the privilege of getting preferred service.

I should say up front that although the two-tier network is sometimes explained as if there were two tiers of network infrastructure, the obvious and efficient implementation in practice would be to have a single fast network, and to impose deliberate delay or bandwidth throttling on non-preferred traffic.

Whether ISPs should be allowed to do this is an important policy question, often called the network neutrality issue. It’s a harder issue than advocates on either side admit. Regular readers know that I’ve been circling around this issue for a while, without diving into its core. My reason for shying away from the main issue is simply that I haven’t figured it out yet. Today I’ll continue circling.

Let’s think about the practical aspects of how an ISP would present the two-tier Internet to customers. There are basically two options, I think. Either the ISP can create a special area for preferred sites, or it can let sites keep their ordinary URLs. As we’ll see, either option leads to problems.

The first option is to give the preferred sites special URLs. For example, if this site had preferred status on AcmeISP, its URL for AcmeISP customers would be something like freedom-to-tinker.preferred.acmeisp.com. This has the advantage of telling customers clearly which sites are expected to have preferred-level performance. But it has the big disadvantage that URLs are no longer portable from one ISP to another. Portability of URLs – the fact that a URL means the same thing no matter where you use it – is one of the critical features that makes the web work, and makes sites valuable. It’s hard to believe that sites and users will be willing to give it up.

The second option is for users to name sites using ordinary names and URLs. For example, this site would be called freedom-to-tinker.com, regardless of whether it had preferred status on your ISP. In this scenario, the only difference between preferred and ordinary sites is that users would see much better performance for perferred sites.

To an ordinary user, this would look like a network that advertises high peak performance but often has lousy performance in practice. If you’ve ever used a network whose performance varies widely over time, you know how aggravating it can be. And it’s not much consolation to learn that the poor performance only happens when you’re trying to use that great video site your friend (on another ISP) told you about. You assume something is wrong, and you blame the ISP.

In this situation, it’s hard to believe that a complaining user will be impressed by an explanation that the ISP could have provided higher performance, but chose not to because the site didn’t pay some fee. Users generally expect that producers will provide the best product they can at a given cost. Business plans that rely on making products deliberately worse, without reducing the cost of providing them, are widely seen as unfair. Given that explanation, users will still blame the ISP for the performance problems they see.

The basic dilemma for ISPs is pretty simple. They want to segregate preferred sites in users’ minds, so that users will blame the site rather than the ISP for the poor performance of non-preferred sites; but segregating the preferred sites makes the sites much less valuable because they can no longer be named in the same way on different ISPs.

How can ISPs escape this dilemma? I’m not sure. It seems to me that ISPs will be driven to a strategy of providing Internet service alongside exclusive, only-on-this-ISP content. That’s a strategy with a poor track record.

Clarification (3:00 PM EST): In writing this post, I didn’t mean to imply that web sites were the only services among which providers wanted to discriminate. I chose to use Web sites because they’re useful in illustrating the issues. I think many of the same issues would arise with other types of services, such as VoIP. In particular, there will be real tension between the ISPs desire to label preferred VoIP services as strongly associated with, and supported by, that particular ISP; but VoIP services will have strong reasons to portray themselves as being the same service everywhere.

Net Neutrality and Competition

No sooner do I start writing about net neutrality than Ed Whitacre, the CEO of baby bell company SBC, energizes the debate with a juicy interview:

Q: How concerned are you about Internet upstarts like Google, MSN, Vonage, and others?

A: How do you think they’re going to get to customers? Through a broadband pipe. Cable companies have them. We have them. Now what they would like to do is use my pipes free, but I ain’t going to let them do that because we have spent this capital and we have to have a return on it. So there’s going to have to be some mechanism for these people who use these pipes to pay for the portion they’re using. Why should they be allowed to use my pipes?

The Internet can’t be free in that sense, because we and the cable companies have made an investment and for a Google or Yahoo or Vonage or anybody to expect to use these pipes [for] free is nuts!

This is a pretty dumb thing for him to say, for several reasons. First, it shows amazing disrespect for his home broadband customers, who are paying $40 or so every month to use SBC’s pipes. If I were an SBC broadband customer, I’d be dying to ask Mr. Whitacre exactly what my monthly payment is buying, if it isn’t buying access to Google, Yahoo, Vonage, and any other $%&^* Internet service I want to use. Didn’t SBC’s advertising say I was buying access to the Internet?

Second, if somebody is going to pay somebody in this situation, it’s not clear who should be doing the paying. There is some set of customers who want to use SBC broadband service to access Google. Why should Google pay SBC for this? Why shouldn’t SBC pay Google instead?

Sure, SBC would like its customers to have free access to Google, Yahoo, and Vonage. But as Mr. Whitacre would put it, the Internet can’t be free in that sense, because Google, Yahoo, and Vonage have made an investment and for SBC or anybody to expect to use those services for free is nuts!

My point is not that SBC should necessarily pay, but that there is no rule of nature saying that one layer of the protocol stack should pay another layer. If SBC gets paid by Google, it’s because SBC faces less competition and hence has more market power. As Susan Crawford observes, Mr. Whitacre speaks with “the voice of someone who doesn’t think he has any competitors.”

At this point, economists will object that it’s sometimes efficient to let ISPs levy these kinds of charges, and so requiring net neutrality from SBC may lead to an inefficient outcome. I appreciate this point, and will be writing more about it in the future.

For now, though, notice that Mr. Whitacre isn’t speaking the language of efficiency. He wants to extract payments because he can. There’s a whiff here of the CEO-tournament syndrome that infected the media world in the 1990s, as documented in Ken Auletta’s “mogul” stories. Can Mr. Whitacre make the CEOs of Google, Yahoo, and Vonage genuflect to him? Is he really the man with the biggest … market power? If there are to be side payments, will they reflect business calculation, or just ego?

It’s one thing to argue that a policy can lead to efficient results. It’s another thing entirely to show that itwill lead to efficient results, in the hands of real human beings.

Discrimination Against Network Hogs

Adam Thierer has an interesting post about network neutrality over at Tech Liberation Front. He is reacting to a recent Wall Street Journal story about how some home broadband service providers (BSPs) are starting to modify their networks to block or frustrate network applications they don’t like.

Why would a BSP discriminate against an application’s traffic? The standard scenario that people worry about is that a BSP hinders traffic from Vonage or some other VoIP application, because the BSP wants to sell phone service to the customer and VoIP competes with that phone service. One can cook up a hypothetical like this whenever a BSP wants to sell an application-level service. The standard response to this worry is to suggest “net neutrality” regulation, which would require BSPs to carry all traffic on an equal footing, regardless of which application or protocol is used. There is a complicated literature about the economics of net neutrality; for now, suffice it to say that net neutrality regulation can help or hurt, depending on the precise circumstances.

Thierer opposes net neutrality regulation. He seems especially worried that neutrality might require BSPs to treat all customers the same, regardless of how much network traffic they generate. If a few customers use lots of bandwidth this will leave less for everybody else, or alternatively will require the BSP to upgrade the network and pass on the cost neutrally to all users. It’s better, he argues, to let BSPs price differentially based on bandwidth usage.

It’s hard to argue with that proposition. I don’t think any reasonable net neutrality advocate would object to a BSP discriminating or pricing based solely on bandwidth usage. They would of course object if a BSP blocked a particular app and rationalized that act with vague excuses about saving bandwidth; but a real bandwidth limit ought to be uncontroversial.

(Technically, customers already have bandwidth limits, in the sense that a given class of service limits the maximum instantaneous bandwidth that a customer can use. What we’re talking about here are limits that are defined over a longer period, such as a day or a week.)

It’s already the case that some customers use much more bandwidth than others. Thierer quotes a claim that fewer than 10% of Time-Warner customers use more than 75% of bandwidth; and another BSP makes an even stronger claim. This isn’t a surprise – this kind of business is often subject to an 80/20 rule (80% of the resources used by 20% of the customers) or even a 90/10 rule.

But will ISPs actually apply bandwidth limits? Here’s Thierer:

This raises the most interesting issue in this entire debate: Why is it that BSPs are not currently attempting to meter broadband usage and price it to account for demand and “excessive” usage by some users? In my opinion, this would be the most efficient and least meddlesome way of dealing with this problem. Per-minute or per-bit pricing schemes could help conserve pipe space, avoid congestion, recover costs and enable BSPs to plow the savings into new capacity / innovation. Despite this, no BSP seems willing to engage in any sort of metering of the pipe. Why is that?

I think there are two reasons that BSPs have so far been unwilling to price discriminate. Frist broadband operators are probably concerned that such a move would bring about unwanted regulatory attention. Second, and more importantly, cable and telco firms are keenly aware of the fact that the web-surfing public has come to view “all you can eat” buffet-style, flat-rate pricing as a virtual inalienable right. Internet guru Andrew Odlyzko, has correctly argued that “People react extremely negatively to price distrimination. They also dislike the bother of fine-grained pricing, and are willing to pay extra for simple prices, especially flat-rate ones.”

So if BSPs aren’t willing to bandwidth-discriminate now, and doing so would anger customers, why would we expect them to start discriminating in the future? It’s not enough to point to a 90/10 rule of bandwidth usage. If, as seems likely, a 90/10 rule has been operating for a while now, and BSPs have not responded with differential pricing, then it’s not clear why anything would change in the future. Perhaps there is data showing that the customer-to-customer imbalance is getting worse; but I haven’t seen it.

Ultimately, BSPs’ general refusal to bandwidth-discriminate would seem to contradict claims that bandwidth discrimination is necessary. Still, even net neutrality advocates ought to support BSPs’ freedom to bandwidth-discriminate.

Alert readers have surely noticed by this point that I haven’t said whether I support net neutrality regulation. The reason is pretty simple: I haven’t made up my mind yet. Both sides make plausible arguments, and the right answer seems to depend on what assumptions we make about the markets and technology of the near future. I’ll probably be talking myself through the issue in occasional blog posts here over the next few weeks. Maybe, with your help, I’ll figure it out.