[Olsr-dev] mDns plugin improvement

[ZioPRoTo (Saverio Proto)]

There is a RFC that already defines packet format and protocol for
router election or we can start coding like monkeys ? :)

Saverio


2012/5/31 ZioPRoTo (Saverio Proto) <(spam-protected)>:
> Teco thanks for the input.
> We started working on a new branch from your inputs:
>
> https://github.com/zioproto/olsrd-gsoc2012/commits/mdns-elect-master-router
>
> Saverio
>
> 2012/5/31 Teco Boot <(spam-protected)>:
>>
>> Op 31 mei 2012, om 09:04 heeft Ferry Huberts het volgende geschreven:
>>
>>> (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.
>>
>> It is about having the attached network link in the loop, where bits in olsr messages are lost.
>> Updating packets is dirty, doesn't matter what bit we set/clear.
>>
>> Leaf router election is the standard approach. Dup detection such as smf/bmf is additional. Current approach doesn't filter duplicates because of multiple leaf routers, different originator and different sequence numbers.
>>
>> I would like on/off config options for leaf router election, ttl adjustments and hash based dup detection. On leaf router election, there is a need to know the mdns plugin state of peer routers. This requires additional signaling or planned configurations.
>>
>> Teco
>>
>>>
>>> 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
>>