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

On Tue, May 3, 2022 at 2:23 PM Ted Lemon <mellon@fugue.com> wrote:
>
> 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.

Modern wifi routers are often multicasting at faster rates now
(11-22mbit) (plus). They are also usually fully bridged across
2.4,5.8, and 6ghz.

SSDP still exists.
DLNA still exists

I am not presently aware of wide adoption of dns-sd (?), although I am
aware of the codebase, the principal problem was that it didn't fit
and required two daemons where one would have sufficed. Are any home
routers shipping it?

My chromebook, perhaps others, does not do mdns by default. It's 2022,
and still a PITA to print.

Over here I'd collected a very, very long list of possible
requirements for future home routers.

https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554/52

If y'all have anything you'd like to add, or subtract?

>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.

Happy to hear that.
> 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
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC