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

From: Greg Shepherd <[email-masked]>
Date: Thu, 10 Oct 2002 19:08:07 -0700 (PDT)

[ 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, 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
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. ;-)

Greg

> 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 : [email-masked]
> 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
>
>

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 11 Oct 2002 00:00:06 -0400

On Thu, 10 Oct 2002 19:08:07 -0700 (PDT)
> - 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.

> 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.

Marshall

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 10 Oct 2002 21:21:26 -0700 (PDT)

> be at the point where the tree from me to you two diverges, and assume symmetric

Where or not the paths diverge has no impact on state. You join *,G - you
get packets from S1 and S2, so your DR joins S1,G and S2,G - you get data
from both sources and you have the state for both source trees and the
shared tree.

Greg