Subject: [MBONED] SSM migration mechanisms (was: Re: deprecating MSDP)

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Sep 2017 15:50:45 +0200

[Let me change subject here]

Hitoshi, *:

There is a wide range of mappings to enable SSM forwarding in networks,
implemented by various vendors. IGMP/MLD EXCLUDE G mappings to IGMPv3/MLDv2
INCLUDE (S,G) via manual config or via DNS learned mappings. Likewise
the same thing for PIM (*,G) joins translated to (S,G) joins. Starting
as early as 2004? if i remember correctly.

The reason why i never opted to document any of these mechanisms in the
IETF (beside "there is something more important to do") was always
two fold:

a) These transition solutions do not give you SSM. Calling them SSM
   is a lie in disguise. Oops: great marketing. !!!!!

   You still need to do ASM style multicast group addess management:
   You can not have two uncordinated application receivers randomnly
   choose group addresses and get away with it!!! With SSM, there
   is no need for any multicast group address management/allocation
   to application instances!!!

b) With a) taken into accoun, I thought and still think that these
   are transition mechanisms.  Documentating them would give them
   more credit than i think they should have. Aka: Especially today,
   there is IMHO no reason why any applications should not be able to 
   generate (S,G) memberships.
   
   If someone thinks there is a good reason, let me know!

Now, there are transition mechanisms that do not suffer from a),
namely IGMPv3 lite and URD. These are a class better, but never
catched on as much as the IGMP/PIM SSM mapping mechanisms - because
they did require application developers to do something - as opposed
to hos IGMP/PIM SSM mapping mechanisms, IGMPv3lite and URD where
only meant to get around the limitation of the OS not supporting
IGMPv3/MLDv2. But guess what: the whole reason why SSM has not catched
on as much as it should is LAZY APPLICATION DEVELOPERS and 
LAZY API STANDARDISERS (eg: IGMPv3 support in Java, websockets etc. pp).
And all OSs today support IGMPv3/MLDv2.

So, i would opt against documenting these mechanisms in a way that
would promote them. Besides, there are patents with my name
or other Cisco inventors on these, and given how i do not work for
Cisco anymore, i can not help in getting IPR disclosures from
Cisco.

I would be happy to write up an extended version of above text
for informational purposes describing the mechanisms, and doing
my best to stay factual and not let my opinions trickle in too much
(which i took the freedom to do above). If this is something the WG
would like to see. And maybe get some co-author...

Cheers
    Toerless

On Thu, Jul 27, 2017 at 02:55:35PM +0900, Hitoshi Asaeda wrote:
> Basic question.
> Why we should not have a function/mechanism to translate (*,G) join/leave to (S,G) join/leave?
> All (*,G) join/leave requests with global scope multicast address should be translated to appropriate (S,G) join/leave requests based on ???something???.
> This ???something??? may be a multicast database, a directory system, or some network protocol. If no ???S??? information on this ???something???, routers receiving join/leave just discards the request.
> 
> In fact, one big issue would be the deployment of SSM-aware applications. Recently, IGMPv3/MLDv2 are implemented on major OSes. (It took long years!) How about iOS and Android OS? (Maybe not?)
> Now???s the time to consider SSM-aware applications? (Wait for long years again?)
> 
> Long years ago, I tackled the issue and published a paper, whose title is ???Multicast routers cooperating with channel announcement system???.
> (http://ieeexplore.ieee.org/document/1266120/)
> It is an old paper. And the work was in progress at that moment but I stopped the work as my task was done; however this idea may be still interesting. It introduces various benefits, not only (*,G) to (S,G) translation.
> 
> I???m interested in hearing thoughts about (*,G) to (S,G) translation.
> (Sorry for changing the discussion about ???deprecating MDSP???.)
> 
> Regards,
> 
> Hitoshi

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 5 Sep 2017 13:18:53 +0900

Hi Toerless,

> INCLUDE (S,G) via manual config or via DNS learned mappings.

Manual config is troublesome and does not change the conditions better, unfortunately. Config via DNS doesn’t require fully functional deployment for all DNS servers? I also doubt to modify DNS to support the function to maintain volatile (S,G) information.

> Likewise

I previously worked on session announcement vs. source discovery vs. directory system, and my paper focusing on multicast routers cooperating with a session directory system was published on Jan. 2004.
The requirements for session announcement/discovery were also previously given in the following draft;
https://tools.ietf.org/html/draft-ietf-mboned-session-announcement-req-03

>   is a lie in disguise. Oops: great marketing. !!!!!

Native solutions are obviously better, but if some mechanism (which must be of course technically sound) breaks the deployment barrier, I support to use it.
If calling them SSM is the problem, then let’s say here SSM-compatible multicast.:)

>   to application instances!!!

A system, which could be a mapping system, directory system, or announcement system, translating (*,G) to (S,G) will in any case maintain group addresses and hence can assign a unique group address for each application. Applications only need to connect the system to obtain "G" information and register "S" information, and routers only need to translate (*,G) to (S,G). There is no need for any multicast group address management/allocation to application instances themselves.

>   If someone thinks there is a good reason, let me know!

From a view of the host side implementation, IGMPv3/MLDv2 must be supported in kernel, and applications must use MSF APIs such as IP_ADD_SOURCE_MEMBERSHIP with setsockopt() in C. MSF APIs are not used for the traditional multicast applications, requesting (*,G) join.
IMO, android does not support IGMPv3/MLDv2 and has no application using IP_ADD_SOURCE_MEMBERSHIP or equivalent APIs.
I don’t know Apple iOS, but at least, I’ve never seen SSM-capable applications (i.e. using IP_ADD_SOURCE_MEMBERSHIP etc.) for iOS.

I believe you don’t want to ignore android (and iPhone as well).

> LAZY API STANDARDISERS (eg: IGMPv3 support in Java, websockets etc. pp).

Many application developpers do not know or do not take care MSF APIs as they do not recognize the benefit given by SSM. They may think SSM or multicast itself only gives the networking benefit.
However, if the service qualities or performances for the current applications (having no MSF APIs) becomes better due to SSM-compatible networking, the application developers may change their minds as they recognize the application-level benefit. I don’t know the level of this benefit, though.

> And all OSs today support IGMPv3/MLDv2.

How about android and iOS?

> Cisco anymore, i can not help in getting IPR disclosures from

I’m afraid that I cannot say anything about this issue.. But maybe I support your thought.

> would like to see. And maybe get some co-author…

If some positive situation can be documented, I’m happy to work on it as well.:)

Regards,

Hitoshi

>> All (*,G) join/leave requests with global scope multicast address should be translated to appropriate (S,G) join/leave requests based on "something".
>> This "something" may be a multicast database, a directory system, or some network protocol. If no "S" information on this "something", routers receiving join/leave just discards the request.
>> 
>> Now’s the time to consider SSM-aware applications? (Wait for long years again?)
>> 
>> Long years ago, I tackled the issue and published a paper, whose title is "Multicast routers cooperating with channel announcement system".
>> I’m interested in hearing thoughts about (*,G) to (S,G) translation.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 5 Sep 2017 10:26:34 +0200

Thanks, Hitoski

1. Calling SSM mapping

I do not 't think we can call IGMP/MLD/PIM G->S mapping config options
"SSM compatible", because it really is not: SSM means no group allocation.

"(S,G)-only multicast" would work, but PIM-DM and DVMRP also do that.
"sparse (S,G)-only multicast" ? Correct but not catchy.

I am going to call it "Imitation SSM".
Like imitation crab meat it sells more than the original.
And it wll expresses what i think about it.

2. Address allocation systems

It does not make sense to consider work on a system that enables applications
to allocate multicast group addresses. That work was done in the 1990th
and ended up in RFC2730 (MADCAP), RFC2776 (MZAP), RFC2909 (MASC)  and
RFC2908 (architecture). That stuff was never adopted. I you ask me because
of my pet theory: application developers did never care about doing multicast
well.

3. Automating imitation SSM

Automating the configuration of imitation SSM was of course always
interesting. The DNS lookup for SSM mapping from yours truly 
does not require any new RR types but simply encodes the group address
into domain names (similar to .arpa) and uses A RRs, so runs on any DNS server
and can be set up to use a sub-zone explicitly set up for DNS mapping
so that it doesn't impact any existing DNS Zone.

Today one could think about automating SSM mapping configs via YANG, but
i am not quite sure how. Or if that would ever be better than DNS. And,
as mentioned, i am not a fan of imitation SSM, i just worked a lot on
it because it was the best we could get deployed in this industry.

4. SSM support for apps

These days, SSM is really supported on every relevant OS for at least
5 years i think. It got into linux in some 2.x kernel, so all 3.x and
4.x have it. It went last into MacOS X in something like 10.7 or
10.8 and at the same time into iOS. Android just inherits linux, so
it should havee s been there foreever, see eg:

https://github.com/android/platform_prebuilt/blob/master/ndk/android-ndk-r5/platforms/android-3/arch-arm/usr/include/linux/in.h

The main issue once it was in all OSs was language binding into
all languages, like Java, etc. I think it's now in all languages
that run native on OSs. Aka: with something like javascript the
main issue is the slow proliferation of UDP websockets, and yes, on
UDP websockets multicast is stsill missing AFAIK. But AFAIK thats ASM
and SSM.

Aka: SSM is ubiquitous for non-web-browser based apps. Ad for web-browser
based apps we could rely on AMT (unicast) web sockets for the time
being.

Cheers
    Toerless

On Tue, Sep 05, 2017 at 01:18:53PM +0900, Hitoshi Asaeda wrote:
> Manual config is troublesome and does not change the conditions better, unfortunately. Config via DNS doesn???t require fully functional deployment for all DNS servers? I also doubt to modify DNS to support the function to maintain volatile (S,G) information.
> 
> > Likewise
> If calling them SSM is the problem, then let???s say here SSM-compatible multicast.:)
> 
> I don???t know Apple iOS, but at least, I???ve never seen SSM-capable applications (i.e. using IP_ADD_SOURCE_MEMBERSHIP etc.) for iOS.
> 
> I believe you don???t want to ignore android (and iPhone as well).
> 
> However, if the service qualities or performances for the current applications (having no MSF APIs) becomes better due to SSM-compatible networking, the application developers may change their minds as they recognize the application-level benefit. I don???t know the level of this benefit, though.
> 
> I???m afraid that I cannot say anything about this issue.. But maybe I support your thought.
> 
> > would like to see. And maybe get some co-author???
> 
> If some positive situation can be documented, I???m happy to work on it as well.:)
> 
> Regards,
> 
> Hitoshi
> 
> 
> > Cheers
> >    Toerless
> > 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
[email-masked]