I want my MTV! MBone (and Multicast)
By Jeff Pulver October 24, 2005
Over ten years ago, before the Internet went commercial, it was possible to get a T1 line using UUNet and have MBone access which supported Multicast for our applications.
Now that broadband has become widely available in the US and around the world, now would be a great time to bring back the MBone, that was in effect the experimental “multimedia backbone” of the Internet. As I watch the disruptive broadcasting space continue to evolve, the advent of having Multicast supported by the companies offering broadband internet access could only help to accelerate the disruption of the traditional wireless broadcasting space. This would actually be in the public interest IMHO, since the radio spectrum for TV would better used for mobile communications that will include TV anyway.
I have recently asked a few friends the question “When will Multicast on the Public Internet Happen?” and the reply I heard most often was “Probably Never.” It seems there are no commercial incentives for IP multicast and there is also a belief that it is not in the best interest of the cable companies and DSL providers to enable consumers to have access to a new MBone.
One friend has noted: “Multicasting in the market is, on the global scale, a rather sad story. Except for research networks, I am not aware of true multicast deployments. It appears that most ISPs are afraid of the multiplication effect that can be achieved by allowing their customers to send multicast — and the difficulties this creates for capacity planning and traffic engineering. True IP multicast-based multimedia conferencing or games are therefore pretty much constrained to the research community. Everyone who needs flexible multipoint communications these days seems to be using overlays (pretty sad from an efficiency perspective). On the protocol side, the Reliable Multicast Transport (rmt) WG and the MBONE Deployment (mboned) WG in the IETF have made real progress. However, many of the companies active in this area in the past have disappeared. RTP works fine for multicast as well but you will find people who want to convince you that multicast is not needed — at least in their narrow business model view of the world.
To counter the carrier and cable provider’s fear and to address foremost needs, namely 1:n content distribution, the concept of source-specific multicast (SSM) was introduced in the IETF several years ago. This allows only one source per multicast group and thus comes pretty close to common distribution needs: for television broadcasts (well: multicasts) and other forms of content distribution.
And here multicasting is actually alive: there is quite a market for satellite-based content distribution via multicast, similar for cable and digital terrestrial broadcast. Even the MBMS service of the 3GPP features cell-local multicasting. And multicast is increasingly used in the context of ISPs on the last mile: when they start enriching their services towards triple play, they need to support efficient distribution of television over IP (even though some still think in terms of ATM) and this gets IP multicast to the last mile. Set top boxes suddenly speak IGMP to tune into program channels and SAP/SDP-style announcements/EPGs (more general: Internet Media Guides, IMGs gain importance.
The final areas where IP multicasting is relevant are corporate networks (for content distribution, for service discovery, to simply DHCP, etc.) and probably mobile/ad-hoc networks (again for service discovery).
At some point, maybe WiMAX and WiFi hot-spots will also see multicasting as this may help with radio resources (particularly if TV is also delivered over WiMAX)..”
Right now one of the great ironic twists of Internet Broadcasting comes that the more successful one’s programming is, means that there is a need for higher capacity streaming media servers and more and more (and yet more) server bandwidth. Not that I have anything against paying for more and more bandwidth as more people tune-in but the advent of multicast would eliminate this problem.
While the future of broadcasting on the Internet isn’t dependent on whether or not public Multicasting is enabled, things would be a lot different if (or when) it were to happen. Gone, for example would be the need for high power “streaming media servers” for pulver.RADIO and pulver.TV. While having access to highly scaleable, high capacity servers would always serve as a backup when someone’s Multicast access was being blocked, the advent of Multicast would open up the gates and empower a generation of people to become personal content providers — both in the video and audio “broadcasting” space as well as other yet to evolve communication technologies.
Of course, these days P2P technologies are getting the job done and content providers can look to deliver personal broadcasts using Bit Torrent. Personally, I also like the idea of uploading content to Google Video, or trying to put together a content distribution deal with Apple.
Now that broadband is happening around the world, it would be great if we can find a way to bring back the MBone in 2006. I would like to believe that there are enough people with common interests to find a way to make this happen. Please feel free to drop me a line if you have ideas on how to make this Internet dream, IP multicast, come true.
Reliable delivery of multi-cast conferencing data
Method and apparatus for multi-cast based video conferencing