Re: [babel] BABEL / MANET / ROLL and multicast

FWIW, multicast service discovery on constrained mesh networks is a really
bad use of network resources. Every device gets the multicast, whether it
offers the service or not, so spends battery power and network bandwidth on
this. If the mesh does "best effort" multicast, this likely consumes a
great deal of available transmission time. It's a lot cheaper to have a
central registry. When defining new mesh networks, specifying SRP and an
advertising proxy (or infrastructure support for DNS-SD) is going to be way
more efficient. This is the choice we made for Thread—we do not do
multicast service discovery on Thread mesh networks, which are 802.15.4
constrained mesh networks.

On Tue, May 3, 2022 at 4:25 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

>
> On Tue, May 3, 2022 at 12:03 PM Juliusz Chroboczek <jch@irif.fr> wrote:
>
>> > Out of curiosity, what's the use-case for using multicast over a mesh
>> network?
>>
>> In public meshes, essentially mDNS.  People want to be able to find their
>> printer even if they're using a mesh network to cover their huge American
>> home.
>>
>> I'm not sure if the military have other needs, if so, they're not telling
>> (at least not to me).
>>
>> > When it comes to device/service discovery, we've found that a
>> unicast-based
>> > register/query model is much more reliable and wire-efficient.
>>
>> I agree that it would be more efficient for the printers to register with
>> the local DNS proxy when they acquire or renew a DNS lease, but that's not
>> what the market has chosen.  (Some people at Apple may or may not know
>> more
>> on the subject, and they may or may not be called Stuart.)
>
>
> That's not what the market has chosen over Ethernet, but it is what the
> market is
> apparently going to choose for mesh home networks. Leading companies in the
> smartphone and home automation spaces have joined together to create Matter
> <https://en.wikipedia.org/wiki/Matter_(standard)>, a new home automation
> standard based on IP and IEEE 802.15.4. Their plan for service discovery
> is to
> use DNSSD (RFC 6763) but not mDNS (RFC 6762). mDNS is one way to
> perform DNSSD using multicast, but you can also perform DNSSD using
> unicast, and that's what we're building over in the DNSSD working group:
> https://datatracker.ietf.org/doc/rfc8766/
> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp
> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-advertising-proxy
> (Someone named Stuart might be involved with these documents, and
> someone named David might be chairing a relevant working group)
>
> David
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>