All things related to multicast

[Richard Mavrogeanes <>]

To the extent the routers support priority queuing, one can simply set the
TOS field of the source to a high level and the router can ensure this
traffic receives top attention.  Obviously, QoS is only an issue in an
oversubscribed network (i.e. not an issue for local switches), and this
approach works well.

There is no magic: one could send duplicate frames to reduce the effects of
loss (increased overhead), perform FEC (increased latency), engineer the
decoder to mask loss, or engineer the network to minimize loss.  


Regards,

Rich Mavrogeanes


-----Original Message-----
From: Jon Zeeff 
[mailto:]
Sent: Friday, March 01, 2002 9:30 AM
To: Marshall Eubanks; Toerless Eckert; Goorah Shravan
Cc: 

Subject: Re: QoS requirements of multicast applications


To the extent that routers can't properly route packets (CPU overload) and
circuits randomly drop packets, I agree that QOS won't work.  But I suspect
that the vast majority of packet loss is caused by the simple case of 
trying to put too many packets down too small a pipe.  QOS definitely makes 
this
case less painful.

At 09:02 AM 3/1/2002 -0500, Marshall Eubanks wrote:
>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
> >