Hi Marek,
Sorry for the very late reply, but here it comes.
On Fri, Jul 20, 2018 at 12:06:14PM +0800, Marek Lindner wrote:
On Tuesday, 26 June 2018 01:29:19 HKT Linus Lüssing wrote:
- Host (A) joins the network and has the IP_X / MAC_a statically assigned.
- Some ARP Requests reaches this host, it issues an ARP Reply which populates the DHT.
- The host leaves the network.
- Another host (B) joins the network with IP_X / MAC_b statically assigned.
Let's distinguish the problems we're trying to solve:
- Cache consistency during updates: A local DAT cache which is not updated
during a cache update event, thus needs to time out faster and a global DAT cache receiving regular updates with less need to update.
- Timely cache update: The global cache shall be updated as soon as the
information is available.
My previous email focused on the former while your response is about the latter. Is that your assessment too ?
Both problems require solving to fully support this dynamic environment you are describing whilst reducing ARP traffic overhead.
Would you mind commenting on the cache consistency issue ? Antonio will respond to your 'snoop outgoing ARP Requests' question separately.
Sure. Actually, I think the example given has something to do with "cache consistency" (unless I'm misunderstanding "cache consistency"?), too:
and a global DAT cache receiving regular updates with less need to update.
If this "less" is too less then we would go into ARP Request broadcast fallback less often. Which could lead to a temporary inconsistency between the DAT cache and the actual host using an IP address, as explained with the example with statically assigned addresses.
And that would result in the cache not being timely updated, right. In that regard, that's your second point.
A local DAT cache which is not updated during a cache update event, thus needs to time out faster
What you are trying to point out here, is it that the local DAT cache needs to time out frequently as we would potentially miss updates otherwise, as updates are generally only ensured to the global DAT cache / the three DAT candidates?
Hm, if that's your point good point. Haven't thought about it that way. Would that mean that we would need to keep querying the global DAT every 5min. after the local DAT timeout even if we are likely a DAT candidate for the specific address ourselves? I'm currently trying to wrap my head around what that implies.
The "needs to time out faster" is interesting, too. Right, assuming no DHCP-DAT snooping (or a high DHCP lease timeout) if a local DAT Cache entry times out then it will currently likely have timed out in the global DAT Cache at about the same time. Because ARP Requests were previously answered locally by the local DAT Cache, resulting in no global DAT cache updates through ARP Replies from the genuine host.
And if every 5min. both the local and global DAT cache times out then this results in the ARP Request broadcast fallback. Rendering the unicast queries to the global DAT cache meaningless.
Does that make sense? Is that what you were alluding to?
Anyway, I'll update this patch to go for the initial idea. And will add a push to the global DAT cache upon ARP Request the source MAC/IP snooping as Antonio and no one else seemed to have any objections. Which will hopefully also help with the potential problem of statically assigned addresses not being updated timely.
Thanks for your feedback, Marek and Antonio!
Regards, Linus