Re: [manet] SMF in Manet and MPR

Hi Brain,

I would like if possible an update/information in 2024 about SMF
implementation or RFC6621 implementation regarding its use in OLSRv2
RFC7181, while considering the first message concerns within this thread
related to MANET routing standard (which the message posted within year
2022 shown below). Please note that I considered that message as a report
of experimental error which may be not solved yet, if it is not please
clarify?

comments below,

On Mon, Mar 21, 2022 at 3:29 PM Adamson, Robert B CIV USN NRL (5522)
Washington DC (USA) <brian.adamson=40nrl.navy.mil@dmarc.ietf.org> wrote:

> Hi Henning,
>
> I didn't participate in the discussion you mention but agree that
> heterogenous MANET is particularly challenging for multicast.  SMF by
> itself with distributed CDS relay set formation can't optimize (or even
> approximate it well) without multi-hop signaling.  I have been continuing
> to experiment (part time as I have opportunity) with the Elastic Multicast
> concept we presented several years ago.  The current "nrlsmf"
> implementation includes a variety of Elastic Multicast operating modes.
> One of those use the an Elastic Multicast flow advertisement (EM_ADV)
> message that propagates from multicast sources and builds up an ETX path
> metric that can be used by "downstream" nodes (and/or receivers) to select
> (and acknowledge via EM_ACK messages) upstream relays according to that
> metric.  I also plan to extend the code to support advertising the maximum
> supportable path bandwidth (and possibly even RTT) for flows in that
> signaling including report back to the source of available path bandwidth.

Thanks for your implementation efforts and discussion. Please inform the WG
if there is development on the code to support advertising the maximum
supportable path bandwidth.

>    That would allow for other metrics to be used in the forwarding
> tree/mesh selection.  This quickly gets into the application-specific
> domain if imagine how that information could be used.  It does seem there
> could be benefit for multiple applications being able leverage a common,
> underlying signaling approach like this.  Even though my code does not yet
> use PACKET BB (I was lazy on that while I'm still figuring out what
> meaningful information signaling messages should include), that could be
> done and integrated as an add-on to existing MANET signaling.  I.e., as
> opposed to each application implementing its own independent signaling.
>

I suggest that the RFC6621 implementation must use PACKET BB (i.e. MANET
Packet) RFC5444 if it is to be used with WG standard routing , because
OLSRv2 RFC7181 is using RFC5444. Or is there other suggestions
we can discuss?

Best regards
AB

> On 3/21/22, 9:08 AM, "manet on behalf of Henning Rogge" <
> manet-bounces@ietf.org on behalf of hrogge@gmail.com> wrote:
>
>     Hi,
>
>     I am reacting to the talk during the IETF meeting (chat didn't worked
>     for me for some reason).
>
>     My trouble with the MPR optimization for SMF (and a bit with SMF in
>     general) is that we currently have no good MPR algorithm for
>     heterogeneous Manet (Manet with multiple different types of radios).
>
>     The only described MPR algorithm (OLSRv2 appendix) works separately
>     for each interface... which means it always selects MPRs on long-range
>     (and slow) interfaces, which is really not what we want.
>
>     Of course there is also the problem that SMF completely ignores
>     routing metrics... and the problem that we lack a good dataplane for
>     SMF, which often results in horrible "raw socket trickery"...
>
>     So in general I would not suggest to people using SMF because I have
>     yet to find an use-case where SMF is doing well. Often an
>     application-specific forwarding strategy is much better than a generic
>     IP one in terms of multicast in Manet.
>
>     Henning Rogge
>
>     _______________________________________________
>     manet mailing list
>     manet@ietf.org
>     https://www.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>