Re: [B.A.T.M.A.N.] [RFC PATCH] batman-adv: Increase DHCP snooped DAT entry purge timeout in DHT

[Marek Lindner <mareklindner@neomailbox.ch>]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

On Wednesday, May 16, 2018 7:48:59 AM HKT Linus Lüssing wrote:
> This patch increases the DAT entry purge timeout in the DHT for DHT_PUT
> messages which were triggered by DHCP snooping from 5 to 60 minutes.
> 
> DHCP snooping will ensure a timely update in case of a reassignment
> of an IP address to a new host in the DHT. This allows us to
> increase the DAT entry timeout for entries inserted via an incoming
> DHT_PUT message triggered by DHCP snooping without risking
> inconsistencies.
> 
> To signalize to a remote node that a DHT_PUT message was triggered
> by DHCP snooping and that it is suitable for such an extended purge
> timeout an according flag in the unicast 4addr header was introduced.

This patch deviates from our battlemesh discussions in a major point: It 
appears to cater towards your specific use-case more than towards a general 
solution. Can you outline as to why you feel the approach below is 
problematic:

When a batman-adv node retrieves a MAC-IP address combination from the DHT, it 
issues a DHT request to the 3 DHT candidates (owners) of this particular MAC-
IP address combination. Moving forward, those 3 candidates will be referred to 
as 'global DAT cache'. Upon reception of the requested information the 
requesting batman-adv node equally caches the MAC-IP address combination to 
speed up further lookups (the 'local cache').

Today, the global and local DAT cache are implemented and treated identically. 
In order to improve the ARP suppression success rate global and local DAT 
cache could be separated with the global cache having a much longer timeout.
The network updates the global DAT cache whenever new information becomes 
available. Therefore bearing little risk of returning misleading information.
As the network does not take care of updating the local DAT cache, its timeout 
should be kept short enough to ensure regular updates.

Cheers,
Marek


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]