All things related to multicast

[Bill Owens <>]

On Thu, May 13, 2004 at 03:01:24PM -0700, Greg Shepherd wrote:
> 
> The scalling advantages of mcast only benefit the sender, not the
> receiver. So in a confernce app, you only need to send one stream which
> gets replicated to each reciever by the routers in the path. BUT, you will
> be getting a stream from each sender.
> 
> So, a confernce with N members means you will still receive N-1 streams.
> 
> If this came N members had a unicast conference app, you would still
> receive N-1 streams. So the the bandwidth savings are asymetrical,
> trivializing the real benefit of mcast.
> 
> One-to-many is the mcast killer app - SSM is right mechanism to deliver
> it.

I must be missing something here. We have two options:
 - multicast conference, either ASM on a single big group or SSM with each 
participant in their own sender group and all the receivers joining all the 
groups, and with each participant sourcing and sinking traffic
 - unicast conference with a central server that receives all streams and 
re-sends

There are N members, each of which sends a stream with B bandwidth.

In the multicast case each site has the following bandwidth needs:
 outbound: B
 inbound:  N*B

In the unicast case, each site has the following needs:
 outbound: B
 inbound:  N*B

In addition, the central server needs:
 outbound: N*B
 inbound:  N*B

And all the traffic follows the triangle path from sender-server-receiver, 
rather than the direct sender-receiver path. The central server also becomes 
a point of failure (as in our conventional conf call last week) How isn't 
that a win for multicast?

Note, I'm assuming that we aren't using switch-on-voice or chair control. 
Either of those would help the unicast bandwidth argument. I am modelling the 
'conference call' activity, where participants are in a free-form 
conversation and everyone gets to talk (and interrupt ;) 

Bill.