All things related to multicast

[David Richardson <>]

I have to agree with the sentiments that over R&E networks, loss is more
often due to configuration problems than congestion.

But either way, applications have to expect loss, and it's not clear to me
that from an overall perspective we would save engineering time by
deploying better than best effort QoS services, since the applications are
going to have to be coded to cope with loss anyhow.

I think all of the elements in the toolbox have to be used:

- FEC is a must, and I don't think it need be a source of latency. Most
  video compression techniques introduce a great deal of latency, swamping
  any latency FEC might add. There is also a lot of data in video, so you
  can get a comfortable FEC coding rate even if you only protect the data
  in a single video frame. And there are lots of efficient, guaranteed-
  latency algorithms to choose from.

- Error concealment is a must. Again, there are a lot of classic
  techniques that can be used to smooth out missing video or audio.

- Applications have to adapt to the state of the network. If there is
  steady loss, drop the resolution or frame rate or color depth or
  increase the compression.

- Less than best effort QoS might be helpful. Unfortunately, there are
  social challenges to deploying QoS mechanisms that attempt to provide
  better than best effort -- who gets to have their packets preferred?
  Less than best effort allows an application to choose how it should
  be degraded, and avoids some of the social problems. An MPEG app would
  mark P and B frames less than best effort, hoping that at least audio
  and I frames make it through whole.

 - David



On Mon, 4 Mar 2002, Hugh LaMaster wrote:

>
> On Sun, 3 Mar 2002, Bill Nickless wrote:
>
> > I can't begin to count the number of times we find duplex mismatches, 
> > dirty
> > circuits (clock skew is my favorite), routers mis-configured to handle
> > multicast forwarding in software, IGMP brokenness, 5% of circuit speed 
> > rate
> > limits on multicast traffic (!!) and so on.
> >
> > The challenge with many of these problems is that TCP hides them too
> > well.  Often the multimedia application is the first to find a problem
> > that's existed for a long time.
>
> Bill Nickless is right on.  Very, very often, I have seen
> underlying problems from duplex mismatch, or, autonegotiation
> failure/reset, other switch problems, dirty fiber connectors,
> bad fiber jumpers, other SONET-layer problems, marginal switch
> boards, and on and on, not show up with TCP other than the
> inevitable slowness, and be revealed by multimedia UDP applications,
> either multicast.  We've seen cases where error rates went way
> up as traffic went way up, guessed that the behavior implied layer-3,
> only to discover a bad fiber jumper was the problem.  Things like
> this have happened so many times, but, it is a hard lesson to learn.
>
> And, for some strange reason, the gut-level reaction that
> many of us have when we first see the problem is to blame
> the multimedia application, rather than try to debug the
> layer-1/2 problems.
>
> Multicast multimedia applications are actually great tools
> for verifying the integrity of the network paths end-end.
>
>
> --
>  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*.
>
>