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

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

On Fri, Mar 02, 2018 at 08:38:13AM +0000, Tim Chown wrote:
> On 2 Mar 2018, at 07:57, Mikael Abrahamsson <[email protected]<mailto:[email protected]>> wrote:
> 
> 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.
> 
> 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
> [cid:05F0B5D3-AD5E-4A02-9A51-217CF8D02FD6]



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


-- 
---
[email protected]

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