Skip to Content.
Sympa Menu

wg-multicast - Re: QoS requirements of multicast applications

Subject: All things related to multicast

List archive

Re: QoS requirements of multicast applications


Chronological Thread 
  • From: Jon Zeeff <>
  • To: Toerless Eckert <>, Goorah Shravan <>
  • Cc:
  • Subject: Re: QoS requirements of multicast applications
  • Date: Fri, 01 Mar 2002 08:46:49 -0500

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




Archive powered by MHonArc 2.6.16.

Top of Page