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

From: Tim Chown <[email-masked]>
Date: Thu, 1 Mar 2018 13:15:43 +0000

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-masked]> 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-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
> 
> > On 27 Feb 2018, at 23:18, Dale W. Carder <[email-masked]> 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-masked]) 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-masked]
> >> https://www.ietf.org/mailman/listinfo/mboned
> >
> > _______________________________________________
> > MBONED mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mboned
> 
> 
> 
> 
> -- 
> James A. (Jim) Stevens, PhD
> Network Architect / Technical Fellow
> Rockwell Collins Government Systems
> [email-masked]
> 972-705-3475 (office)
> 214-392-2273 (cell)

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 1 Mar 2018 19:26:10 +0000

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Tim Chown

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

From my POV, as briefly as possible, those are cases where multiple group members may become the source, and we want to avoid the hassle of having to specifically list each one, or exclude ones. We may not even know what possible sources might crop up. Examples where ASM is exactly what we want, and anything more than that is just added burden for no benefit.

I get that inter-domain, with PIM-SM, that simplicity cannot exist. So inter-domain, SSM is actually simpler. It removes that rendezvous point complication, and then having to find a better route around it, for the multicasts.

Bert

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 2 Mar 2018 08:57:28 +0100 (CET)

On Thu, 1 Mar 2018, Manfredi, Albert E wrote:

>
> I get that inter-domain, with PIM-SM, that simplicity cannot exist. So 
> inter-domain, SSM is actually simpler. It removes that rendezvous point 
> complication, and then having to find a better route around it, for the 
> multicasts.

It makes it easier for the network, but it might make it harder for the 
applications.

Personally I do not know enough about what multicast applications are out 
there and why it might make their lives much easier if ASM exists, but I 
imagine these exist. The classic case was a many-user video conference 
where you had no application layer protocol to understand who might be 
sending video to you. I remember the 90ties where there was a multicast 
group with lots of webcams in it, so you could get real time glimpses 
of the world. There you just pointed your client to the multicast group 
and it split up each camera into a separate window, without any need for a 
source discovery protocol in the client.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Fri, 2 Mar 2018 08:38:13 +0000

On 2 Mar 2018, at 07:57, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:

It makes it easier for the network, but it might make it harder for the applications.

Personally I do not know enough about what multicast applications are out there and why it might make their lives much easier if ASM exists, but I imagine these exist. The classic case was a many-user video conference where you had no application layer protocol to understand who might be sending video to you. I remember the 90ties where there was a multicast group with lots of webcams in it, so you could get real time glimpses of the world. There you just pointed your client to the multicast group and it split up each camera into a separate window, without any need for a source discovery protocol in the client.

I remember that too. In around 2001/02 many of us in the European NRENs and universities were in a project called 6NET, where we had multicast conferencing tools running over IPv6 multicast, using UCL's vic and rat clients, and tools like ssmping and dbeacon for debugging, and also Stig's v4/v6 gateway (which I recall was written up as an IETF draft but didn't get adopted).  But that was over an ASM group on the 'm6bone' with a single RP; it was that project that then came up with the idea of Embedded-RP, in part from trying to run applications such as these were clients could join/leave at any time. It was a lot of fun, and hard to think it was now 16+ years ago!

A piece of history attached; this was a screenshot of a session where I was demoing the tools at the IST2002 conference. Stig was joined via IPv4, to demonstrate his gateway, the rest over IPv6.  Hopefully a 100K image isn't breaking list etiquette :)

Tim

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 9 Mar 2018 14:14:52 +0100

SSM is always simpler for the network than ASM. The question is rather when it
is inacceptable more difficult for the application.

Let me summarize 3 categories of ASM use:

a)

One example of "needs" ASM application is the classical situation awareness (SA),
where a distributed ssytem (for example a battlefield) consists of various
units/subunits (soldiers, tanks, weapons) and you need some subset of those
units receive telemtry of other units for decision making. What was mention
here on this thread in before reminded me of the typical parameters of such an
application.

Distributed simulations are similar.

b)

I would not necessarily count the multi-party video conference as a "needs"
ASM application unless it is meant to be "peer-to-peer" multi-party video conference
with no centralized server. Thats how the original mboned apps where built
(vic, vat, wb) - peer-to-peer. Before 1995 == before you would start to build
out every networked app through a web-server/cloud-server as the obvious
application layer rendesvous point. Just look at all those RTCweb apps that
have emrged from tht IETF groups work. To me the most obvious best scalable/
most easy solution (and typical RTCweb is of course interdomain) is unicast
from participant to rendesvous point, and then SSM back from that rendesvous
point. Of course helped by AMT to transit any non-SSM enabled paths in between.

Even if you want to get a central point out of the picture (delay,...),
it would for these apps IMHO still be better to use SSM and only use the
app-server as the rendesvous point to learn the source addresses. 

The main issue with this second class of apps is tht we can document all day
long, but to make any impact on actuall app deveopment, you better have an
open source library that apps could use. Just having seen the URL for SSM
support in node.js i think we're ccloding in being able to do this in the
typical web-application environment - javascript/web-udp-sockets. But
someone would have to write it. Could even be proposed as an extension to
e.g.: RTCweb as a typical use case.

c) 

The difficult part is service discovery. I think thats a real bad example
of ASM. Some app developer wants to develop a client-server app, asks
Stig, oops: IANA multicast address expert for an IP multicast address,
and then codes his own private discovery; server or client sends multicast
packets using this address to find the other side.

In sheer volume of assigned addresses for this crap, thats probably the
most successful use of IP multicast. 

I don't want to get through all the arguments how/why/where/what DNS-SD
with various degrees of multicast (mDNS), but rather:

Service discovery with multicast is a slippery slope unfortunately,
which makes the classification more difficult:

Consider a typical "shop" web-page you see where you see many different frames,
lets say one with product description, another one with pictures of the
product, another for your cart, what others bought, reviews, etc. pp.
Consider each of these frames to be an app provided by a large cluser
of nodes in a DC. The app that renders your web-page requests for
each of these frames a worker to render that frame - so each frame
type has a multicast group with all workers listening - but responding
based on load. This effectively is a somewhat more intelligent service
discovery - let least loaded worker reply first, select it. This was
done with IP multicast even before hadoop was a thing. And lead to the
development of Bidir-PIM because PIM-SM couldn't scale to the tenths
of thousands of parallel web-page renderers that would send those
requests to the hundreds of workers for fifty rr so apps. This reduced
stte from eg: 100,000 (S,G) to maybe 200 (*,G).

So, i would say that its easy to see how you don't want to discount
all variants of service discovery, but at least you shouldn't allocate
static multicast addresses for this anymore. These apps must use
locally managed multicast-apps. Which magically (IMHO) disables the use
of ASM where DNS-SD would be better, but does not hurt the other example
(distributed app, e.g.: DC/web). Alas, i think IANA has never managed to
come up with a policy to push back against these address allocations,
so i think thats been going on for 25 years now with just little pushback.
Stig would know more about this.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Fri, 9 Mar 2018 09:17:14 -0800

When it comes to policy, that is something we can decide in the IETF,
we aren't exactly running out of IPv4 multicast addresses though.
Maybe we would eventually, but with the transition to IPv6, maybe
there will mostly be requests for IPv6 in a few years, where we won't
run out.

We had some discussions in mboned about trying to come up with some
alternative way for applications to do discovery, other than each
using a unique address, about 10 years ago. I think the issue is
mainly that application developers are lazy, or avoid what they see as
unnecessary complexity. Which means that standardized libraries, new
socket APIs etc. could make a difference.

Of course it also helps if big companies that want to deploy an
application tells application vendors that they do not want to deploy
ASM and that they will choose another application if they cannot make
it work with SSM.

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 9 Mar 2018 18:48:30 +0100

Thanks, Stig

The obvious new approach over 10 years ago we could do in MBoned
to promote moving even enterprise networks to SSM only is to define
a mapping between mDNS and PFM.

And these type of discovery multicast packets are also exactly what
current PFM would not work with today, so when you want enterprises
to move away from ASM slowly, PFM today does primarily the source 
discovery for long-lived sources.

There are already hybrid mDNS/ucast-DNS proposal in IETF that are
based on ingres replication of mDNS packets to all possible egres-LANs.
So you also need to do egres-LAN discovery. IMHO convoluted enough
to have a better approach such as flooding via PFM.

Toerless

-- 
---
[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Fri, 9 Mar 2018 09:57:45 -0800

Hi

You've brought up several points related to PFM lately that I'm
interested in discussing and exploring further. One is the old idea of
creating a pim spec containing only SSM parts. We could do that, I'm
not sure how many would consider implementing that, and how hard it
would be for them to just ignore the unnecessary parts in the existing
spec though.

PFM is kind of ASM with only SPTs. Would it be useful to do a document
in mboned exploring this from a deployment and operational point of
view? Perhaps it's worth waiting until there are some deployments.

For the mDNS - PFM mapping, are you suggesting that an mDNS query gets
flooded by a link-local mDNS pim router using PFM?

Stig