All things related to multicast

[Jon Zeeff <>]

I agree, many vendors don't seem to be doing a good job on handling
less than perfect connectivity.  Was talking to one vendor recently and
the comment was that there isn't much they can do since they are
just handing the data to a MPEG decoder chip.  So lots of  ugly green
blotches if a packet was lost.

Packet loss causing some small frozen spots on the screen for a few frames
should be achievable.  And packet redundancy makes sense for the ultra 
important audio.

I don't know that I agree that packet loss is predictable.  QOS is absolutely
needed.   FEC is efficient but causes latency.




At 11:25 PM 2/27/2002 -0800, Toerless Eckert wrote:
> Most of the video-conferencing / video broadcast software out on the
> market today is not doing stream redundancy or forward error correction (FEC)
> when using ip multicast. In result, every lost packet causes visible loss
> in quality. For this reason you want to have traffic of such application
> to be in a higher priority queuing based class than best effort
> TCP traffic: Best effort typically does not cut it. Different
> codecs have different sensitivity to packet loss. From my experience,
> MPEG2 is worst - a single packet loss in an I frame of a 4Mbps stream
> can stop your whole video signal for the better part of a second.
>
> Theoretically this "real-time-behavior" is of course independent of
> wether or not you use FEC or not - as long as you get quality deterioration
> by packet loss and as long as you don't do retransmits, you are in
> the real-time traffic class. Practically, FEC can actually avoid
> visible quality degradation upon predictable packet loss (most of the
> packet loss in real networks has predictable characteristics), so that's
> why you practically could well classivy video streaming application with
> FEC into the best effort class like TCP - unles you're really stressing
> your network so much that that best efforts class packet loss becomes
> not predictable enough.
>
> So that's just about live streaming video services. If you consider
> other classes of ip multicast applications, you may end up with
> different CoS requirements. Interestingly enough even a less-than-best-effort
> traffic class would be very useful for valuable type of applications
> with ip multicast, and this is something often overseen in most QoS
> architectures that just view the world wthin the boundaries of best-effort
> TCP web traffic and real-time Voice-Over-IP traffic  - all unicast of
> course ;-(
>
> Cheers
>         Toerless