Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
The Pulpit

<< [ Revolution, Not Evolution ]   |  The Once and Future King  |   [ Leaner and Meaner Still ] >>

Weekly Column

The Once and Future King: Multicast looks to (finally) be the future of television.

Status: [CLOSED] comments (51)
By Robert X. Cringely

Twice each year the top 100 or so television critics in the U.S. lock themselves in a Los Angeles hotel for a couple weeks to meet all the producers and stars of TV shows being offered in the coming months. In January and July this ritual takes place, supplying content for thousands of newspaper columns and websites. But not this January, because the Writers Guild of America strike has crippled most of the (non-PBS) winter TV schedule and gloom reigns in Hollywood. Had the meeting been held (it was cancelled just last week) I was supposed to make a big presentation about New Media, explaining to America the future of TV. But now I get to explain some of it to you, instead. And the future of TV in America, my friends, is multicast.

IP Multicast is the not-so-simple carriage of the same digital signal to thousands or millions of people at the same time. This is as opposed to unicast, which can also serve millions of people but requires millions of parallel video streams to do so. Multicast was built into the structure of the Internet from the very beginning but was generally not turned on because net admins hate it as a resource hog. But one man's resource hog is another man's chance to sell a lot of new equipment, so Cisco has long been a huge supporter of multicast because it requires ever bigger and more powerful routers to implement. Years ago Cisco bought Judy Estrin's Precept Software and its IPTV product primarily to have an application that would drive the adoption of multicast in the enterprise and beyond. Only that didn't happen because net admins weren't giving in, there was no YouTube, and the x386 computers of the era really weren't capable of handling much video anyway.

IP Multicast, while it has been around forever, has mainly been a buzzword more than a reality even to companies that supposedly used it. Tibco, for example, used to proudly proclaim that it was using multicast for real-time data feeds from stock tickers or oil refinery safety valves, but I don't really think they were. Instead they were using IP tunneling to carry multicast traffic through places where multicast addressing wasn't supported. IP tunneling was a stopgap that has long justified multicast's resource hog reputation because it layered multicast atop another service, making everything between here and there do even more work just so we could pretend we were using multicast.

But the funny rule about IETF RFCs (Internet Engineering Task Force Request for Comments) is that if you wait long enough just about every one will eventually be required and that's finally becoming the case with IP multicast.

Here's a very simple explanation for the way that IP Multicast is supposed to work. Seinfeld episode #60, The Junior Mint (which happens to be the third most popular Seinfeld episode of all time according to some Internet poll) is assigned the Class D multicast address of If you want to watch that episode you click on it in some client application that "subscribes" to that address. When the show is made available on a server anywhere on a part of the net that supports multicast, you will start to receive it. All the routers between here and there look for multicast subscriptions and enable them. If no other customer at your ISP wants to see The Junior Mint, then the video isn't carried on your subnet nor is any of it cached locally. No bandwidth is used. But if one person does want to see The Junior Mint, then it is held to some extent in a local cache and available for all local subscribers.

See, multicast IS a resource hog.

But to more and more ISPs multicast is looking like the best answer to a huge bandwidth problem, while also being a sneaky way to take back control of the Internet.

The first problem ISPs are facing is that they are running out of IP addresses. Many, including Comcast (my ISP), are already reusing IP addresses on subnets and are rapidly moving toward IPv6. The second problem these ISPs are facing is they are running out of bandwidth at layers 1 and 2 of the OSI protocol stack. We're not talking so much about Internet bandwidth here but Intranet bandwidth -- bandwidth within the ISP's own cable plant -- and this loss they blame primarily on P2P file-sharing services.

In order to lower their bandwidth bills, ISPs are trying to take greater control of the way we, their customers, use our "unlimited" bandwidth. So Verizon and a lot of other DSL and wireless data providers are placing download caps on their monthly service while Comcast has been traffic shaping to limit the growth of P2P file-sharing services like BitTorrent. This is all intended less to slap us around and more to keep ISP costs in line so they can -- big secret coming -- CONTINUE TO MAKE NEARLY ALL THEIR PROFIT FROM PROVIDING INTERNET SERVICE. You think your phone company makes a lot of profit on voice and long distance or that your cable company makes a lot on carrying video channels? Think again. Comcast barely breaks even on video and makes a killing on Internet and VoIP. If cable company Internet subscriptions fall, those companies are in real trouble.

Why, then, would they risk alienating us, their customers? Because they think we are stupid, for one. And because they intend to offer us alternatives, like IP Multicast.

Both Comcast and Verizon are rapidly rolling out IP multicast, as I am sure most big cable and telephone ISPs are. Even Verizon's fiber-to-the-home service, FiOS, is moving to multicast because it was architected in a dumb way that sorely limits what should be a lot of throughput.

Let's look at the issue from the perspective of a cable company or MSO (Multiple System Operator, an operator of multiple cable television systems), which typically has 750 MHz of available bandwidth on their cable plants. They have to support analog video service since the bulk of their customers don't have digital cable service (they want that coax coming out of the wall to plug directly into their TV).

Typical analog video service is a 70-channel package. Each analog video channel consumes 6 MHz of the plant spectrum. That's 420 MHz of their 750 MHz of capacity consumed already. We'll be dead and buried before analog video service is retired, so that 420 MHz is unlikely to be recovered.

And if you're thinking the FCC decision about going all digital on February 17, 2009 is going to change this, think again. In fact, it will probably increase analog cable subscription numbers since the MSOs will have to take the digital-only signals coming from local broadcasters and convert them back to analog signals so customers can receive them. The FCC order doesn't affect cable or satellite companies.

As for digital video on cable systems, each 6 MHz analog channel devoted to digital use is good for anywhere from 28 to 40 megabits per second of bandwidth depending on the QAM implementation on that cable system. Newer or upgraded cable plants implement the newer QAM-256, and thus can pack in more data (and more digital video channels) per 6-MHz analog channel.

The cable guys are stuck with MPEG-2 video for a few more years due to the millions of set-top boxes currently deployed that are only MPEG-2 capable (no MPEG-4). This means higher bandwidth consumption for quality digital video on older systems. That will change over time but not quickly. The same goes for older satellite systems.

The folks at ESPN demand as part of their contracts that a lot of their programming on MPEG-2 systems be delivered at 5-8 MBps (SDTV resolution) compared to the 2 MBps used for most other channels. Same for pay cable services like HBO, Showtime, etc., though they are willing to accept slightly less bandwidth than ESPN because they don't have the motion issues associated with sports programming.

So replicate the current video offerings of a cable company on the digital side (70 channels for basic+), add in some analog premium channels (HBO, etc.), add some packages that entail multiple premium channels (HBO, HBO Family, HBO Signature and others), pay per view, adult, etc., on top of the analog video, and you're looking at 600+ MHz of the 750 MHz available spectrum JUST FOR VIDEO.

With everyone and their grandmother signing up for broadband plus wide use of P2P applications, these companies are honestly running short of intranet bandwidth.

For Comcast part of the answer to this problem is to move toward IP delivery of video using MPEG-4. This will allow them to reduce the amount of bandwidth required per channel PLUS implement IP Multicast. Internal audience studies at Comcast have shown that 90 percent of the customer base watches 10 percent of the available channels AND NOTHING ELSE. But Comcast can't easily dump the underutilized channels people don't watch because programming contracts with the studios require carriage and having a bunch of channels available that you never watch is part of the perceived value of the service we are paying for. Would you pay $50 per month for the seven channels you actually watch? Me neither.

Multicast solves this problem because it allocates no bandwidth to channels that aren't being watched. Multicast also solves (from the cable company's perspective) the "problem" of P2P because they'll give multicast addresses to paid content and content from movie studios and traditional TV networks that PAY for this privilege, saying that this is a preferred alternative to P2P, which will continue to be traffic shaped.

There are only two ways for today's ISPs to carry tomorrow's Internet video traffic. They can embrace wide-open P2P or they can implement IP Multicast. Which do you think they will do?

Merry Christmas.

Comments from the Tribe

Status: [CLOSED] read all comments (51)


Can you please elaborate on your comment about Verizon FIOS:

"Even Verizon's fiber-to-the-home service, FiOS, is moving to multicast because it was architected in a dumb way that sorely limits what should be a lot of throughput."

Perhaps this is addressed in a previous column that I missed?

David Strom | Jan 02, 2008 | 9:58AM

And another question -- if the cablecos move to IP Multicasting for TV delivery, what happens to CableCard support? FCC requires cablecos to support CableCard, I believe, and I doubt that there is support for IPTV by CableCards.

David Strom | Jan 02, 2008 | 10:36AM

Having noticed this late because of the holidays, this is a late correction/comment.

Having conferred with some of my colleagues here at TIBCO, I can confirm that multicast occurs all over the place - in local networks, and not just in our products. My colleague mentioned Apple's Bonjour, UPnP, in addition to our own products.

My colleague does concur that routing of multicast is difficult.

Eric Johnson | Jan 03, 2008 | 1:58PM