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

[Stig Venaas <[e-mail]>]

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


On Fri, Mar 9, 2018 at 9:48 AM, Toerless Eckert <[e-mail]> wrote:
>
> 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
>
> On Fri, Mar 09, 2018 at 09:17:14AM -0800, Stig Venaas wrote:
>> 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
>>
>>
>> On Fri, Mar 9, 2018 at 5:14 AM, Toerless Eckert <[e-mail]> wrote:
>> > 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 <[e-mail]<mailto:[e-mail]>> 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/mboned
>> >
>> >
>> > --
>> > ---
>> > [e-mail]
>> >
>> > _______________________________________________
>> > MBONED mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mboned
>>
>> _______________________________________________
>> MBONED mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mboned
>
> --
> ---
> [e-mail]