What’s Holding Up Multicast Streaming?
What Happened?
The foundations of today’s streaming industry were largely laid by multicast engineers in the early and mid-1990s. For example, the Real Time Transport Protocol (RTP) and the Session Description Protocol (SDP), both widely used in streaming today, were created for multicast. But multicast became a victim of both bad timing and technological over-optimism.
By 1995, streaming on "the MBone" (the Multicast Backbone) using RTP and SDP was becoming widespread—but multicast was not ready to share in the exponential growth of the rest of the Internet. The MBone was a set of point-to-point links, using an early multicast routing protocol called DVMRP. This routing used so-called "dense-mode" multicast, where all of the network is assumed to want a stream unless they indicate otherwise by leaving the group. A dense-mode protocol floods every stream throughout the network, and is clearly not fit for general deployment. In addition, most of the point to point links in the old MBone used Internet tunnels (i.e., they were virtual links carried on other Internet channels) and tunnels require manual configuration. Perhaps worst, DVMRP creates its own routing tables and the old MBone could generate megabits per second of routing traffic while those tables were converging. The largest audience for the old DVMRP MBone was almost certainly the "NetAid" concerts of 1999 (partially sponsored by Cisco Systems, a consistent supporter of multicast).
NetAid proved to many streaming experts of the day that the MBone was close to collapse and needed replacement. Substantial resources were being expended in creating multicast protocols that were ready for prime time. Since dense mode multicasts waste bandwidth by flooding a network with streams, "sparse-mode" was created. In sparse-mode multicasting no traffic is sent without an indication of interest—a substantial improvement in efficiency. Good unicast routing tables are widely available so they became the basis of a new multicast routing protocol, Protocol Independent Multicast - Sparse Mode, or PIM-SM, which not only used sparse-mode (the SM), but also the underlying unicast routing tables (the PI). PIM-SM can be run "natively" (as part of the general Internet routing), therefore removing the need for tunnels and their manual configuration.
While the fundamental problems with the first generation of the Internet were being overcome with PIM-SM, time did not stand still and the Internet entered its period of Web-driven hyper-growth without a reliable multicast routing protocol.
Since native PIM-SM multicast wasn’t ready in time for the NetAid concerts, these events also gave impetus to "middleware" caching solutions, pioneered by Akamai and others, which can also be applied to limit the bandwidth usage of Web sites and which captured some of the large-scale streaming market. At about the same time multicast pioneer Broadcast.com (which was paying Internet Service Providers, or ISP’s, to install MBone tunnels) was bought by Yahoo.com, which showed little or no interest in furthering multicast.
In short, multicast missed the hyper-growth window of opportunity by literally a matter of months. By 2000, native multicast routing was deployed in a number of large ISP’s and also in the academic and research networks, but it was too late. The "Dot-Com" money investors put into their Internet ventures had to produce immediate results and these could, for many companies, be achieved via the unicast-ready Internet. The senior author vividly remembers being told in 2000 that "saving money doesn’t matter" by an executive in a large streaming startup.
While that company is unfortunately no longer with us, the attitude of "buzz over profits" did damage to the streaming industry which is only now being corrected.
Related Articles
Multicast isn't new, but CDNs, operators, and content publishers have finally caught up to the possibilities it offers for increased scale and decreased costs.
20 Jan 2016