[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-avahi
Subject:    Re: [avahi] More mDNS efficiency by using multiple multicast addresses? (like ICMPv6 Neighbor Discov
From:       Petr Menšík <pemensik () redhat ! com>
Date:       2023-01-17 18:53:53
Message-ID: 9ad0cae1-bfd4-96ad-31bf-ebe49edb6393 () redhat ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]