All things related to multicast

["Marshall Eubanks" <>]

Some issues are missed here :

1.) Not all video conferences are round robin. There may be a
plethora of receive only or receive mostly - transmit rarely - sites,
so the normal multicast gains apply.

2.) Also of interest is the time delay involved. Most
vc units introduce a time delay of at least one packet but more commonly
a video frame per additional participant. The result
is that 5 party videoconferences typically have nasty latencies - up a second.

With multicast,  TeleSuite videoconferences have a negligable additional 
latency
per additional site.

This may seem trivial, but it isn't, and it is a major plus.

3.) I think of a large multi-party videoconference as limited by
the screen space available (but, of course, that is closely related to the
bandwidth required).

Example - the TeleSuite VC system uses up to 4 screens of 600 kbps each H.264 
video IF
they are full sized. If we divide them into halves, that's 8 remote sites,
each at 300 kbps. If into quads, thats 16 remote sites, each at 150 kbps.

True, outbound if we were unicast it would still be ~ 2400 kbps. BUT, this 
would represent
N copies of the local video stream, and something has to do this replication.
A polycom VS 4000, for example, can replicate the stream it creates up to 4 
times internally.
More than that, and you have to buy MCU conference bridges, and the
cost starts escalating.

So, there is more to life than saving bandwidth, and multicast does make sense
for videoconferencing.

Regards
Marshall

On Mon, 17 May 2004 11:17:43 -0400
 Bill Owens 
<>
 wrote:
> 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.
>