[avahi] More mDNS efficiency by using multiple multicast addresses? (like ICMPv6 Neighbor Discovery)
Petr Menšík
pemensik at redhat.com
Tue Jan 17 18:53:53 UTC 2023
I think such mechanism is not required on MDNS. It instead put more
logic into having common cache and reduces number of multicast queries
sent. Only few types are used commonly and I doubt it would save
significant CPU processing. MDNS allows multiple queries in single
packet, so computing destination on queried type would be hard.
I think MDNS instead relies on cache and ability to not send some
queries often, because that state is maintained in cache. Sure, battery
operated wireless devices may save more power if they do not have to
open packets not interesting for them.
I have seen somewhere, it might have been ADD IETF group, attempt to use
local network unicast cache instead. MDNS is used just to locate local
network responder, which can be then asked over unicast. It reduces
packets processed by multiple devices, which might be way to go. Not
sure what was the name exactly.
But I doubt anyone is working on extending MDNS to hash-like link
addresses. I doubt the protocol is ready for such extension. I would say
such approach were refused during the protocol design.
Regards,
Petr
On 1/13/23 21:46, Linus Lüssing wrote:
> Hi,
>
> As far as I know mDNS only uses the following two multicast addresses
> so far: 224.0.0.251 for IPv4 and ff02::fb for IPv6.
> In larger broadcast domains this can create quite a bit of "noise"
> though.
>
> I was wondering, is anyone aware of any attempts to extend mDNS
> with mechanisms similar to ICMPv6 Neighbor Discovery to reduce the
> amount of mDNS multicast transmissions in a network? Could someone
> thing of any pitfalls if trying to adopt such an approach for mDNS?
>
> ICMPv6 Neighbor Discovery has this beautiful concept of
> solicited-node multicast addresses. Instead of broadcasting like
> it was done with ARP Requests in IPv4, a host's unicast address is
> mapped to a multicast address. When one IPv6 host wants to resolve
> another host's IPv6 unicast address it uses this mapped IPv6
> solicited-node multicast address. Which typically only this one
> host listens to. That way a network with MLD snooping capabilities
> can efficently direct the ICMPv6 Neighbor Solicitation message
> with the mapped solicited-node multicast address to this one
> specific listener, with no burden for unrelated hosts. And
> for an ICMPv6 Neighbor Solicitation for
> Duplicate-Address-Detection (DAD) instead of address resolution
> there is typically even no listener at all. An MLD snooping switch
> can drop it immediately.
>
> So my naive thought/question would be if mDNS could use a
> multicast address more like ff02::fb:<hash32(service-id|dns-id)>
> instead (maybe even larger than just the last 32bit of the
> multicast address, IPv6 uses 24bits though for the solicited-node
> multicast address: FF02:0:0:0:0:1:FFXX:XXXX).
>
> Any thoughts?
>
> Cheers, Linus
>
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
More information about the avahi
mailing list