[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New draft on embedding the RP address in IPv6 multicast address



[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

On Thu, 10 Oct 2002 19:08:07 -0700 (PDT)
 Greg Shepherd <shep@juniper.net> wrote:
> 
> On Thu, 10 Oct 2002, Marshall Eubanks wrote:
> 
> > 2000 member multi-player games come to mind. I believe that these have
> > been done (as military simulations).
> >
> > SSM will have state and flows that goes as N^2 in this case - the
> 
> Many-to-many will always have flow of order of 1 outbound and N-1 inbound
> - ASM or SSM. State is also the same between SSM and ASM - though

Greg;

I am not sure I agree...

Assume some many to many game application implemented using multicast

Suppose that you at home and someone at the U of O want to participate in the
same group, and that I join here too. Assume (as I believe to be the case) that
you and the UO guy are topologically close in the network, and let the router A
be at the point where the tree from me to you two diverges, and assume symmetric
routing.

Now, in an ASM model, I join one group. At the router A, once the SPT is set up,
there is only state for the one path to me. In the SSM model, I have  to join 2
channels - one for you, and one for UO. At router A, even though the groups have
the same path, state has to be maintained for both channels. So, no, I do not
see that the state is the same between SSM and ASM in this case, at least
between router A and me, although the data flow is the same. Whether this is
important is another question.

> technically SSM has less state in that it does not require *,G for each
> unique G. Only a shared-tree-only mechanism like BiDir can reduce state
> for ASM.
> 
> The ONLY thing ASM has over SSM is in-band source discovery. So do we
> build some ~universal mechanism in protocols to provide this, or do we
> push off to the application writers to provide source-discovery as best
> fits their audience scale and needs. Hmmm. ;-)
> 

You may be right. Maybe there is no real _need_ for inter-domain ASM protocols
in IPv6.

Maybe a toolkit approach would make sense here - if you need automatic
source-discovery, here are some ways to do it - along the lines of the reliable
multicast working group approach.

> Greg
> 

Marshall

> > real question is, can there be multi-domain solutions that only require
> > state and flows of order N.
> >
> > Regards
> > Marshall
> >
> > Leonard Giuliano wrote:
> > > -) >
> > > -) > However, you might be able to make ASM "SSM like" in that, if you
> > > -) > find the group address by some means out of band, you can join to
> the RP
> > > -) > and either send or receive.
> > > -)
> > > -) This is actually what is expected to happen.  The steps look like:
> > > -)
> > >
> > > Going back a bit, if this ASM mechanism will rely on SSM-like group
> > > discovery, why not just use SSM in the first place?
> > >
> > > The main problem with SSM in IPv4 is that ASM was already in use, and
> > > there aren't enough implementations/deployments of SSM yet.  But v6 need
> > > not carry the same albatross of legacy mechanisms around it's neck.  It's
> > > a chance to do things right from the start.
> > >
> > > Does anyone actually see any real cases where SSM won't be at least "good
> > > enough?"  Is all the complexity of ASM, and the duct tape solutions being
> > > discussed worth it just so that SDR will work?
> > >
> > >
> > > -Lenny
> > >
> >
> >
> > --
> >                                   Regards
> >                                   Marshall Eubanks
> >
> >
> > T.M. Eubanks
> > Multicast Technologies, Inc
> > 10301 Democracy Lane, Suite 410
> > Fairfax, Virginia 22030
> > Phone : 703-293-9624       Fax     : 703-293-9609
> > e-mail : tme@multicasttech.com
> > http://www.multicasttech.com
> >
> > Test your network for multicast :
> > http://www.multicasttech.com/mt/
> >   Status of Multicast on the Web  :
> >   http://www.multicasttech.com/status/index.html
> >
> >
>