Showing posts with label Robert X. Cringely. Show all posts
Showing posts with label Robert X. Cringely. Show all posts

Friday, December 21, 2007

IP Multicasting Coming?


Not being a "techie," I first became aware of "IP Multicasting" in 2000, when working with some folks developing a streaming media service. As somebody who spent some time in the cable TV business, it made a huge amount of sense. Basically, the idea is that for popular content, say a TV show that millions of people want to watch, one uses multicasting to launch a single stream that all those viewers can watch, rather than millions of discrete streams. Those of you who are network engineers will appreciate the elegance of the way this conserves bandwidth, in the same way that satellites deliver a single stream that millions of viewers can watch. That's the beauty of all multicasting: highly efficient sharing of downstream bandwidth.

Carriers proved resistance to enabling multicasting, however, for all sorts of other reasons, not the least of which was the fear that control over available bandwidth would be lost. But technology journalist Mark Stephens (Robert X. Cringely) argues multicasting is the future of television. Well, at least the future for some sorts of television: the highly-viewed, synchronous sort.

Multicast was built into the structure of the Internet from the very beginning but was generally not turned on because network administrators view it as a resource hog (local storage and resources, not bandwidth, per se).

Cisco long has been a huge supporter of multicast because it requires ever bigger and more powerful routers. That might be true, but multicasting still makes eminent sense as a way to distribute highly-popular video. Sure, there are other sorts of video that have to be unicast because demand is low. But multicasting is quite efficient of bandwidth for highly-popular streams.

Stephens uses a simple example. Say a user wants to see Seinfeld episode 60, and is entitled to do so. That event gets assigned a multicast address.
When the show is made available on a server anywhere on a part of the net that supports multicast, the user receives it. All the routers between here and there look for multicast subscriptions and enable them and the episode is is cached locally.

In order to lower their bandwidth bills, ISPs are trying to take greater control of the way we, their customers, use our "unlimited" bandwidth, says Stephens. But IP multicast offers another tool to do so, and is less bothersome.

Both Comcast and Verizon are rapidly rolling out IP multicast, Stephens notes. The reason is that IP multicast remains a highly-efficient to deliver popular programming, and means most of the linear cable channels. ESPN demands as part of its contracts that much of their programming on MPEG-2-equipped cable systems must delivered at 5 Mbps to 8 Mbps, compared to the 2 Mbps used for most other channels.

Contracts are similiar for premium cable services such as HBO or Showtime.

Internal audience studies at Comcast have shown that 90 percent of the customer base watches 10 percent of the available channels.The problem is that each of use might have a different seven favorites. Also, even if few people actually are watching, cable companies can't turn them off because programming contracts with the studios require carriage.

Multicast solves this problem because it allocates no bandwidth to channels that aren't being watched. It's an interesting business issue: the signals are "carried" but maybe not "broadcast" to consumers who aren't actually "tuned" to the channel.

IP Multicast is an alternative to P2P, in other words.

"Tokens" are the New "FLOPS," "MIPS" or "Gbps"

Modern computing has some virtually-universal reference metrics. For Gemini 1.5 and other large language models, tokens are a basic measure...