Netcasting's catch

Netcasting is not broadcasting … yet.
Publish date:
Social count:

Internet-based efforts such as YouTube and Google Video are increasing the demand for video to the desktop. Newscasts with video have been available for some time, and many of you have attended webinars that included video.

Many forward-thinking broadcasters and content creators see the Internet as another outlet for their programming. Companies such as CNN have been repackaging their Internet content for more than 10 years. But is the Internet just another antenna for broadcasters? Is it just another way to distribute our content, or are there challenges and issues that make the Internet fundamentally different from broadcasting?

There is no doubt that many companies would like to send the same content to many hundreds, if not thousands, of people over the Internet at the same time. Aside from broadcasters, educators and even the government are interested in this technology. However, those interested in using the Internet for broadcasting should know that distributing Internet content is fundamentally different from traditional linear broadcasting in terms of bandwidth, cost and equipment load.


Figure 1. In broadcasting, the transmitter is completely unaffected by the number of receivers. In netcasting, the media server must establish a connection with each receiver

Broadcasting takes up the same amount of bandwidth no matter how many televisions are tuned in. The transmitter puts out a 6MHz-wide signal one time, and everyone in the viewing area can watch it. The load placed on the transmitter is exactly the same at 3 a.m., when two people are watching as it is during a popular event such as the Super Bowl, when hundreds of thousands of people are watching. (See Figure 1.)

Compare this with an Internet video feed. Because traditional Internet data protocols are connection-based, an Internet transmitter (typically a media server) will need to establish a connection with each device receiving the stream. Then the media server will need to originate a stream to feed that device. If two people are watching the stream, the server will need to generate two streams. If 100,000 people are watching the stream, the server will need to generate 100,000 streams. Ouch!


The cost structure of broadcasting is significantly different from the Internet. In the linear broadcasting model, the broadcaster pays the power bill. The consumers buy television sets, plug them in and are free to watch whatever is distributed. (This rather simple model has been changing over the years with cable, satellite, pay-per-view and video-on-demand.) Because the number of people watching does not affect the load on the transmitter, the broadcaster's power bill remains steady.

The Internet broadcasting model is quite different. Because the demand on the source of the stream is directly related to the number of people watching, the more people watching the stream, the more bandwidth the combined streams consume. And because bandwidth cost is a function of bandwidth consumed, the more successful an Internet broadcast is, the more it costs to distribute it.

Typically, network bandwidth is sold based on 95 percent of peak demand. Usage is metered, and the top 5 percent of peaks are thrown out. The user is then billed for the month at 95 percent of peak. This means that when a popular event is shown, the bandwidth consumed will go way up. If the event lasts several days, or interest remains high for several days, then the cost of the bandwidth for the broadcast will be high for the entire month. (Note: There are other billing options available, especially to customers who consume large amounts of bandwidth.)

There is also a cost to the consumer for watching more Internet content; the user has to pay for more bandwidth. Anyone who has a simultaneous computer user in the house (a teenager perhaps?) knows the benefit of opting to pay for higher-bandwidth service. This is fundamentally different from the linear broadcast model, where the number of TVs in a house does not affect the consumer's experience. (Cable and dish distribution have modified this cost structure somewhat.)

Equipment load

There is also the issue of equipment load. A broadcaster can use the same physical plant regardless of how many people are watching. Internet broadcasting requires the originator to increase its physical plant as the number of clients increases.

The costs are not linear, but are step-wise. For example, if you purchase a media server, it is capable of delivering up to 100 streams. After that, you will need to add another server. At some point, you will want to add fault tolerance and probably use shared storage. Of course, as your computer facility becomes more complex, you can gain economies of scale by making smart decisions about equipment configurations.

The solution

It seems obvious that the solution for IP networks is to create a network that behaves more like traditional linear broadcasting. A single computer would send out packets to the network, and the computers that want to receive the broadcast would listen to that stream.

This capability exists in Ethernet networks. You probably have heard of a network broadcast address. The network broadcast address is a reserved address; anything sent to this address is delivered to all computers on the network.

Broadcast IP addresses end in .255. (See Figure 2.) If you wanted to send broadcast packets on a 192.168.1 Ethernet network, you would send packets to All computers listening on the network would receive and interpret these packets.

The broadcast address was created for network management and diagnostic purposes, but it seems like a perfect solution to our broadcast Internet issue. Unfortunately, things are not that simple.

While it is true that a broadcast message will go to all computers on a network, the key word is “network.” Remember, Ethernet is designed so that traffic is segmented. Messages are only sent to computers that need to see them.

A large network could quickly run out of bandwidth if every message from every computer was presented to every other computer in the company, or on the Internet. To accomplish this segmentation, Ethernet routers check the source and destination of each packet. They either keep the packet local or pass it on to other networks, depending on the source, destination and routing table.

By definition, broadcast messages are not routable, meaning that all broadcast messages stay within the confines of the local network. So a broadcast message will never be allowed on the Internet. Furthermore, the router would also drop a broadcast message sent to a remote network.

By now, the hardcore computer readers are probably jumping up and down saying, “No one does Internet broadcasting that way, and what about IGMP?!” Well, we are almost out of space in this month's column.

But seriously, the computer industry has been well aware of the issues surrounding broadcasting on the Internet, and it has worked hard to resolve them. The most promising solution at the moment is Internet Group Management Protocol, Version 3 (IGMP V3) as specified in RFC 3376. (RFCs can be found at If you have looked at previous versions of IGMP before and have concluded that it will not work, I encourage you to look at the third version, which contains several significant additions. Next month, we will look at IGMP as part of a wider discussion of IPTV.

Brad Gilmer is president of Gilmer & Associates, executive director of the Video Services Forum and executive director of the AAF Association.

Send questions and comments