Subject: [MBONED] A concern about draft-acg-mboned-multicast-models recommendations

From: "James A. (Jim) Stevens" <[email-masked]>
Date: Tue, 27 Feb 2018 16:29:00 -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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 27 Feb 2018 22:34:44 +0000

Hi Jim,

Indeed. I argued the same point, but not necessarily for the same reason as you.

I think the resolution might be to insist on SSM more for the inter-domain model than for intra-domain. Intra-domain, like in your case and mine, there are times when ASM is way simpler to implement. (I used the multicast-emulation-over-ATM, which resembles SSM conceptually, to shame the mboned wg into not demonizing ASM entirely!)

Bert

From: MBONED [mailto:[email-masked]] On Behalf Of James A. (Jim) Stevens
Sent: Tuesday, February 27, 2018 17:29
To: [email-masked]
Subject: [MBONED] A concern about draft-acg-mboned-multicast-models recommendations

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

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 27 Feb 2018 17:18:38 -0600

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

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 Feb 2018 23:33:16 +0000

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-masked]> wrote:
> 
> Hi Jim!
>

---

From: "James A. (Jim) Stevens" <[email-masked]>
Date: Wed, 28 Feb 2018 14:22:14 -0600

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-masked]> 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
>
> > Thus spake James A. (Jim) Stevens ([email-masked])
> on Tue, Feb 27, 2018 at 04:29:00PM -0600:

-- 
James A. (Jim) Stevens, PhD
Network Architect / Technical Fellow
Rockwell Collins Government Systems
[email-masked]
972-705-3475 (office)
214-392-2273 (cell)