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!

We need a solution! 

We need a software-based solution for large-scale delivery of video (or data) on the Public Internet.

IP delivered linear channels are sprouting up, but how will they conquer the point to-point delivery problems associated with IP video?  Even Akamai’s huge and expensive “edge” delivery system, which uses the Internet Engineering Task Force’s Real Time Streaming Protocol (RTSP), is limited to about 300,000 simultaneous viewers.

The CBS March Madness sporting event is a detailed exploration of the point to-point video delivery problems and corresponding limitations.  Despite this event’s success at serving approximately 300,000 viewers, many more potential viewers were frustrated and had to wait in line. 

Stanford University professor, Steven Deering invented the system we need (thanks Steve),  but Deering’s specification – which he called “IP Multicast” – was not a reliable protocol (set of rules).  IP Multicast is prone to a percentage of data (or packet) loss.  Deering’s “IP Multicast” protocol was never intended to be a complete solution, just a “building block.”