Showing posts with label IP multicasting. Show all posts
Showing posts with label IP multicasting. Show all posts

Sunday, January 27, 2008

Video Delivery: Some Ways Better Than Others


At some point, as much more video starts to be delivered using IP networks, network marketers and engineers are going to have to come up with ways to entice people to use alternate means of delivery, when it is feasible to do so. At some point, it simply will not make sense to chew up valuable voice and interactive data bandwidth for relatively low value YouTube clips, as entertaining as they might be.

Consider for example what Qwest is doing: it has esentially decided to keep all traditional linear video programming, including high definition TV and on-demand programming intended for TV screen viewing, off its IP pipe. It is doing so by delivering linear TV in the most bandwidth efficient means possible, namely by satellite, streaming point-to-multipoint.

As would be the case for IP multicasting, the idea is simple" launch one single copy of each program to a virtually unlimited number of users who can view the stream at the same time or on a store-and-watch-later basis (TiVo or another digital video recorder).

That will reserve the IP connection for unicast video and other interactive applications. The same sort of "offloading" principle is used by Netflix with its "DVD in the mail" approach. The point is that we do not have to force everybody to use IP bandwidth for watching unicast video when multicasting, sideloading, satellite, physical media or some other approach, including time-shifted delivery, might work just as well.

The baleful alternatives will find service providers unable to meet customer demand for bandwidth because there no longer is any money to be made; a dramatic increase in monthly prices; or both. Consumers are smart. Given a reasonable set of different ways to get video, at discrete prices for different delivery times and media, they'll make choices that relieve pressure on access bandwidth bottlenecks.

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...