We wish to offer our views about what's holding up Public Multicast streaming. Here is a partial list of the problems my company had to overcome in order to bring a "business model" to Public Multicasting.

::Backbone Security:: Television networks and system integrators must have the extra assurance they need. They need assurance that goes beyond point-to-point encryption and decryption. Their critical multipoint backbone must be impervious to attack. Without enhanced backbone security (Multicast Repeating) there is no profit motive for broadcasters or system integrators. Currently, only one company provides a method for Public Multicast repeating. There needs to be more.

::Enanced Reliability:: Native Multicast lacks a mechanism to enable a solid picture on wireless networks without overly bloating the backbone signal with redundant data (FEC or Forward Error Correction) - Without an enhanced "no bloat" reliability feature, high definition TV (HDTV) signals would become to bandwidth intensive for transmission without expensive equipment upgrades. A reliability mechanism that doesn't bloat the signal is needed in order to enable legacy equipment.

::Multipoint Bi-Directionality:: Multicast needs a protocol that addresses high speed channel surfing (dynamic accelerated buffering). Such a bi-directional protocol could also offer Increased revenue opportunity (targeted commercial insertion), a database log of who's watching, AND of course quality of signal reporting.

::Automated Environment Testing:: A self implementing multicast level escalation mechanism is needed to establish the best method of multi-point connectivity and, where none exists, a 4th level (US model) protocol to create a tunnel to the NEAREST (think TCP latency limitations) multi-point enabled network.

::Source Discovery for IPV6:: SSM must have IGMPV3 in order to work, yet IGMPV3 has been absent from the MAC OS and most Universities use IGMPV2 at the IPV4 edge. The IPV6 community doesn't want another flooding discovery protocol (like MSDP), so IPV6 Multicast needs an elegant discovery protocol that doesn't add to Internet Message Processor (router) overhead. Vint Cerf, Paul Vixie, Kevin Almeroth, Joe Breen, Brian Billadeau and I have proposed to address this problem as a test bed for the "Directory of Persistant Objects".

In our most humble opinion, these tools at a minimum are needed for a Public Multicast business model.

Cheers and best wishes to fellow Multicast proponents who are working to bring forth world wide Tele-Vision (We call this TV 5.0)!

Ian A. Stewart - Chairman Worldcast.tv

Internet Group Management Protocol Fails In A Radio LAN Environment

To those that think IP Multicast works in a radio environment there is one little problem. IGMP is not a reliable protocol.  How IGMP attempts to gain reliability is by sending several copies of its messages. For example; the IGMP join group message will be sent several times, after all, isn’t it ok as long as the intended receiver of the IGMP message is aware of this “feature”. The problem is when it comes to the radio LAN environment packet loss is often so high that those little IGMP packets are often stepped on.

Why FEC alone won’t do!

Forward error correction is beginning to get some votes on the ipmulticast.com poll, but FEC alone can’t give us Reliable IP Multicast.  There are several reasons for this:

·         Latency – FEC or spread spectrum FEC is going to increase latency during channel changes.

·         Conspicuous consumption – In order to support a Radio LAN you have to send a LOT of FEC.  Like 10 times the data in a noisy situation. In a radio LAN environment packet out-of-order and packet loss drive consumption beyond acceptable levels.

·         Packet loss again – Yup', when your in a noisy environment, there aint' no' formula that accomplishes a perfect data transfer. There will always be a significant chance that the same redundant data will be lost multiple times.

·         If one dynamically scales FEC (as some have proposed) then a congested network will signal to send more FEC and hence a more congested network. Unless we do something as lame a stepping down to the lowest receiver in the network. 

So keep those thinking hats on because we aren’t quite there yet!

Sorry but FEC alone won’t do!