How much bandwidth end users actually need is an evolving question, with an evolving answer. What a typical user might have found sufficient 10 years ago is no longer sufficient, and notions of adequacy will continue to change as video becomes a bigger part of the typical experience.

 

One way of looking at bandwidth needs is to look at what additional load might be placed on broadband connections were today’s linear TV viewing to be shifted to an Internet delivery mechanism.

 

According to Nielsen, the typical U.S. consumer watches 141 hours of television each month. Standard-definition fare might consumer about 2 Gbytes to 3 Gbytes. High-definition video, delivered in a compressed format over a 25 Mbps connection would transfer 11 Gbytes of data, according to Microsoft (News - Alert) engineers.

 

Assuming a typical user is on a 7 Mbps connection, and is downloading or streaming compressed video, an hour of standard TV would consume about 3 Gbytes. PC video, with a smaller displayed image, will require transfer of less data.

 

High-definition video, compressed or not, would require lots more bandwidth. How much difference depends on the coding, display parameters and compression, but as a rough metric four to 10 times more bandwidth might be needed.

 

For the sake of argument, assume a mix of HDTV and standard definition, on a mix of TV display and PC display devices, for an average transfer of about 5 Gbytes an hour.

 

If a typical U.S. viewer stopped watching satellite, cable or telco TV, and shifted that consumption to a broadband Internet connection, 141 hours works out to about 705 Gbytes worth of transferred data.

 

The policy and engineering issue is whether it is rational to substitute highly-efficient point-to-multipoint distribution for less-efficient point-to-point distribution.

 

Keep in mind that the difference is even more dramatic than might be suggested by this example. In actual point of fact, a point-to-multipoint video distribution network actually delivers streams that are not actually viewed. In other words, video is delivered, even if it is not watched, 24 hours a day, seven days a week. Assume delivery of 150 channels.

 

That works out to delivery of 120 Gbytes each day, for each channel, or 18 terrabytes a day, if I have done the math properly.

  

As a practical matter, it makes little sense to rely on point-to-point mechanisms to deliver linear video of this quantity. In fact, it makes more sense, from a network resources point of view, to broadcast as much video as possible, and then use local caching and other techniques as much as possible to supply the on-demand viewing features.

 

Video experiences obviously benefit from faster connections, but the issue is whether 70 Mbps is 10 times better than 7 Mbps, twice as good or only a bit better. Observers and proponents will disagree about that.

 

Consumers, though, likely will not disagree much about what they are willing to pay to view video, in its appropriate format. Not many will willingly pay five times more than they do today to watch the same video as they can get from a satellite, cable or telco provider. In fact, not many will pay twice as much as they presently do.

 

And that’s going to be an issue as national broadband policy is set. It is one thing to set almost-arbitrary targets for what typical bandwidth 'ought to be.' It is quite another to set those targets at levels people actually will pay for.

 

One can argue, in principle, that the government, using taxpayer money, should subsidize the access connections at whatever level is required to hit the targets. As a practical matter, one can argue that no governmental body in the United States can do so, any longer.

 

The required investment funds simply cannot be raised, given all the other deficits people know about, as well as the coming deficits people do not yet speak about (such as state level unfunded pension obligations).

 

That means some very hard, practical thinking will have to be done. Targets divorced from economic reality are not real targets.