The IP over ATM Mailing List Archive by date

[asmith@Baynetworks.COM (Andrew Smith)]

> From owner-ip-atm@nexen.com Fri Mar 22 13:30:16 1996
> Date: Fri, 22 Mar 1996 16:24:30 +0500
> From: jhalpern@us.Newbridge.com (Joel Halpern)
> To: taddy@cc.gatech.edu
> Subject: Re: Multicast Servers for use with MARS
> Cc: ip-atm@nexen.com

> I am going to use this as a hook to try to start a discussion of one of
> the questions I felt was seriously under-discussed in LA.  (This is not
> a criticism of the presenter, but meerely an area I had questions about.)
> 
> What are the advantages and disadvantages of the two kinds of sharing
> among MCS?  And why would you use either one?
...
> Do other people have the same understanding of the two categories?

It is the hybrid "sender and receiver sharing" scheme that gives the
big saving in VCC signaling messages: here each sender sends to one MCS
and each receiver receives from only one MCS. For peer-peer applications,
this uses the fewest VCCs and their signaling messages. Of course it is
arguable that most applications of real multicast are client-server, not peer-
peer.

> If so, what are the factors in the tradeoff.
> 1) Is the signalling overhead for members coming and going within a group
>    such that it needs to be shared.

This was Rajesh's point: he says "yes". I say "yes, it might be, but there
are other ways around this e.g. use smaller LISs and mrouters".

> 2) Is the collected data load for all the senders of for a group such
>    that some degree of sharing, short of declaring that the senders will
>    do it themselfves, is useful?

I would say probably not: just merge an MCS with each sender and use a mesh.
This has interesting implications though: the client protocols for doing this 
are already in ipmc-12 but limit sender allocation to a single sender per
MCS (i.e. the MCS that is co-located with the client): the question
is then "is single-sender per MCS adequate for all of our sender-sharing
needs?". Of course there is no reason why multiple MCSs (same LIS, different
groups) could not be colocated so long as they don't have to share VCCs.
If they need to share then we may need some new protocol.

> Are there other factors to consider?

3) Redundancy: localisation of failures is very important and this is a
     particular problem with sender sharing.

4) Total VCC count at any one UNI (and the *rate* at which these need to be 
     recovered/rerouted on failures)


> Thank you,
> Joel M. Halpern				jhalpern@newbridge.com
> Newbridge Networks Inc.
> 

Andrew


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy 				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************