[Olsr-dev] mDns plugin improvement

[Ferry Huberts]

(thinking out of the box)

If there were a free bit in the message to fiddle with, you could set it 
in the mdns plugin to indicate that it should not be (re)transmitted by 
olsrd. That way you'd keep the rfc compliant ttl=255 and still have a 
solution to your problem.

On 31-05-12 00:47, ZioPRoTo (Saverio Proto) wrote:
>> Let's try to comply to standards. We should not break nodes that
>> discards mDNS packets not having TTL=225. And support protocols
>> that have TTL=1.
>
> I still do not see this problem.
> I agree application should generate packets with TTL=255. But routers
> should not be able to alter the TTL value of the IP packets as usual ?
> If packet is not originated on the local link then TTL !=255, and this
> is okay with the standard.
>
>> Packet rate of mDNS would be low, so hash calculation looks
>> acceptable to me. This is the way SMF works.
>> http://tools.ietf.org/html/rfc6621#section-6.2.2
>> I prefer having the standards based method implemented. In
>> IETF, we had a long discussion. With this outcome.
>
> The rate of mDNS packet is not low if you have a big network.
> We have hundreds of end devices connected that generate a huge amount
> of mDNS traffic !
>
> Look at the size of our network:
> http://tuscolomesh.ninux.org/images/topology.png
> and IPv6
> http://cleopatra.ninux.org/topology.png
>
> we run both networks on top of devices that have small CPU and memory
> resources. Mostly Ubiquiti NanoStation M5. We already have issues with
> CPU spikes to 100%. We have two olsrd running one for IPv4 and one for
> IPv6
>
>
>> It would be nice having only one copy of the mDNS (or whatever
>> multicast) packet flooded. This needs some coordination between
>> the leaf routers. Could be active / backup election. Could be an
>> extended dup detection in the flooding mechanism, with a plugin.
>
> agreed this is a problem that the patch do not solve.
>
> Saverio
>

-- 
Ferry Huberts