All things related to multicast

[Hugh LaMaster <>]

On Mon, 4 Mar 2002, Jon Zeeff wrote:

> Date: Mon, 04 Mar 2002 11:54:08 -0500
> From: Jon Zeeff 
> <>
> To: Richard Mavrogeanes 
> <>
> Cc: 
> 
> Subject: RE: QoS requirements of multicast applications
> 
> Yes, there is a fundamental incompatibility between tcp's "use all 
> bandwidth, packet loss is a normal signaling mechanism" and "packet loss 
> has very bad
> effects on video conferencing".  QOS helps.
> 
> 
> 
> >I would add that the extent the network is otherwise well designed, when a
> >user pulls down a 1G file and the network attempts to use all the bandwidth
> >to allow it, real time services must suffer.  I would argue this is where
> >QoS comes in.  There is nothing more unequal than the equal treatment of
> >unequal things.

QoS is clearly a good thing to have in order to balance the 
requirements of fixed-bandwidth realtime applications and
bulk data transfer applications.

However, there are so many ways to get packet loss ~1%
that I don't think it is reasonable to assume 0% packet 
loss as an end-end requirement.  I would like to see 
applications tolerate up to ~10% loss before becoming
unusable or uninteresting, with the usual range .5%-5%.

I wish that application developers would take advantage
of the existing FEC mechanisms, and, would also adjust
codec parameters, to make data streams much more robust
in the face of a small percentage of packet loss.  For
example, talking about MPEG, more I-frames, I-frames w/FEC,
no B-frames, etc., would certainly result in more bandwidth
consumed per frame (e.g., depending on settings, you might
get 8-10 Mbps consumed instead of 6 Mbps, or, alternatively,
fewer fps if limited to 6 Mbps).  Some would say that such
parameters are not "optimal".  But, that assumes 0% packet
loss.  "Optimal" at .5%-5% packet loss results in a different
set of parameters.

I realize that software designers are probably at the mercy
of what industry provides for broadcast satellite and DVD
applications, but, having seen direct satellite broadcast 
TV as well, I would say that it would also benefit from 
more robustness than would be required for, say, DVD applications.
I would hope that codec manufacturers could see the benefit in 
building-in flexibility wrt parameter choices supported 
and their ease of use.


--
 Hugh LaMaster, M/S 233-21,    Email: 

 NASA Ames Research Center     Or:    

 Moffett Field, CA 94035-1000  Or:    

 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.