All things related to multicast

["Marshall Eubanks" <>]

On Fri, 01 Mar 2002 08:46:49 -0500
 Jon Zeeff 
<>
 wrote:
> 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.
> 
> 

Latency is OK for broadcasting, but not for
videoconferencing. We are doing broadcasting.

IMHO, QOS (i.e., intserv or diffserv) 
will _not_ help with predictable packet losses actually
seen. See my presentation to the last IETF MBONE meeting :

http://www.multicasttech.com/papers/ietf-52-mboned-tme-1.pdf

Regards
Marshall
> 
> 
> 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
>