Re: A concern about draft-acg-mboned-multicast-models recommendations

Hi,

I'll be working on the "deprecate inter-domain ASM" text today.  

Personally, I would rather focus the other document on SSM use intra-domain, and as stated below to explore what missing pieces there might be (e.g. around service discovery), and to understand for which applications ASM is still beneficial/preferred (which may include local applications with highly dynamic bidirectional participants).

A side effect of such a document would be to imply where ASM is at least currently more suited intra-domain.  It would be interesting to determine what those cases actually are.

Tim 


> On 28 Feb 2018, at 20:22, James A. (Jim) Stevens <[email protected]> wrote:
> 
> Tim, Dale, Bert - thanks for your feedback and description of plans for the next release(s) of the draft-acg-mboned-multicast-models-02 document.
> 
> I do not disagree with high-level recommendation about having RFC deprecating use of ASM for interdomain.
> 
> I support the group's plan to separate the document into two documents - one for deprecation of interdomain ASM and the other to provide current best practice for multicast use makes sense.  For this second document, I recommend that it include the intradomain use cases where ASM is better solution than SSM as well as all the use cases where SSM is better.  The ASM use case I described in my email is basically the same use case that Toerless described in his Wed, 20 Dec 2017 19:10:03 +0100 email, namely distributed apps with a lot of short-term multi-party group-transactions.
> 
> Regards,
> Jim
> 
> On Tue, Feb 27, 2018 at 5:33 PM, Tim Chown <[email protected]> wrote:
> Hi,
> 
> Thanks Dale.
> 
> Yes, the general principle we agreed was on inter-domain deprecation. I suspect Jim has read the draft, but not caught up on the mail list, which if he's new here is only to be expected :)
> 
> For intra-domain, what consenting adults do in their own networks is up to them, if it's constrained, but I do sense a wish to document recommendations for adoption of SSM intra-domain too, to explore what missing pieces there might be (e.g. around service discovery), and to understand for which applications ASM is still beneficial/preferred (which may include local applications with highly dynamic bidirectional participants).
> 
> But I think it's important not to get lost in detail when making the high-level recommendation on inter-domain ASM, hence the split of the document, and my question in the previous email.
> 
> Tim
> 
> > On 27 Feb 2018, at 23:18, Dale W. Carder <[email protected]> wrote:
> >
> > Hi Jim!
> >
> > I think we're converging towards deprecating ASM for *inter-domain*
> > use, and what we say about intra-domain models is a bit in flux.
> >
> > I think the latest is at the bottom of Tim's most recent message:
> > https://www.ietf.org/mail-archive/web/mboned/current/msg02543.html
> >
> > glad to have you here!
> >
> > Dale
> >
> >
> > Thus spake James A. (Jim) Stevens ([email protected]) on Tue, Feb 27, 2018 at 04:29:00PM -0600:
> >> Hi, I’ve only recently joined MBONED, so this email may be rehashing old
> >> discussions. (If so, please just point me to the prior discussions.)
> >>
> >> With respect to multicast service models, I support customers who field
> >> hundreds to thousands of nodes where each node is a member of multiple
> >> (typically five to ten) multicast groups where most of the groups have
> >> dozens to hundreds of members that partially overlap in membership between
> >> the groups.  All of the members of the multicast groups are both multicast
> >> sources and receivers.  The nodes are spread out over multiple IP links
> >> (typically wireless).  The multicast groups are within a single IP routing
> >> domain that can contain dozens to hundred of IP links and subnets.  The IP
> >> links are typically other than standard WiFi or cellular IP links and have
> >> limited throughput capacity – ranging from tens of kilobits/sec to a few
> >> megabits/sec – so a key concern is to keep overhead down.
> >>
> >> For this multicast scenario with many dynamic bidirectional sources and
> >> receivers, we use ASM rather than SSM model to reduce management overhead
> >> and simplify source discovery by not having to track which nodes have
> >> joined which groups in order to do an SSM join to all the members of the
> >> group.
> >>
> >> The draft-acg-mboned-multicast-models-02 recommends “the use of SSM for all
> >> multicast scenarios.” For this multicast scenario, I don’t see how SSM
> >> efficiently satisfies this many multiple sources and receivers – especially
> >> since the multicast members are dynamically joining and leaving.
> >>
> >> Thus, I argue that SSM is not always the best multicast model and there
> >> shouldn’t be a blanket recommendation to use SSM for all possible multicast
> >> applications. In addition, I recommend section 7.6 address the fact that
> >> SSM is not as efficient as ASM for the case of many dynamic bidirectional
> >> sources and receivers.
> >>
> >> Or, am I overlooking something on how to use SSM to address scenarios with
> >> many dynamic bidirectional sources and receivers?
> >>
> >> Thanks,
> >>
> >> Jim Stevens
> >
> >> _______________________________________________
> >> MBONED mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/mboned
> >
> > _______________________________________________
> > MBONED mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/mboned
> 
> 
> 
> 
> -- 
> James A. (Jim) Stevens, PhD
> Network Architect / Technical Fellow
> Rockwell Collins Government Systems
> [email protected]
> 972-705-3475 (office)
> 214-392-2273 (cell)

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned