[RFC] batman-adv: Increase DHCP snooped DAT entry purge timeout in DHT

  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.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

---

Unverified/untested so far! Expecting:

Reduction of (unanswered) ARP Requests from gateways:

60min: 98.95%

Other potential timeout periods for comparison:

45min: 97.95%
30min: 91.71%

https://www.open-mesh.org/projects/batman-adv/wiki/DAT_DHCP_Snooping

This patch requires:

"batman-adv: DHCP snooping for DAT"
---
 include/uapi/linux/batadv_packet.h     | 13 ++++-
 net/batman-adv/distributed-arp-table.c | 86 +++++++++++++++++++++++++++-------
 net/batman-adv/main.h                  |  1 +
 net/batman-adv/send.c                  |  9 ++--
 net/batman-adv/send.h                  |  3 +-
 net/batman-adv/types.h                 |  6 +++
 6 files changed, 94 insertions(+), 24 deletions(-)
  

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
  

Hi Marek,

Thanks for looking at this patch!

On Sun, Jun 03, 2018 at 07:53:01PM +0800, Marek Lindner wrote:
> 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.

I'm a little worried about the following scenario:

1) Host (A) joins the network and has the IP_X / MAC_a
   statically assigned.
2) Some ARP Requests reaches this host, it issues an ARP Reply
   which populates the DHT.
3) The host leaves the network.
3) Another host (B) joins the network with IP_X / MAC_b
   statically assigned.

Currently, we only update the DHT on outgoing (= into the mesh)
ARP Replies. I'm worried that an ARP Request would never reach
this node (B) during the whole extended timeout, therefore not
triggering the necessary ARP Reply, therefore leaving this
node unreachable over this whole time frame. Which would probably
result in a lot of confusion, I guess.

That is why I was wondering whether it might be better to stay
on the safe side and only apply an extended timeout to entries
created or updated via DHCP.

Cheers, Linus
  

On Mon, Jun 25, 2018 at 07:29:19PM +0200, Linus Lüssing wrote:
> Currently, we only update the DHT on outgoing (= into the mesh)
> ARP Replies. I'm worried that an ARP Request would never reach
> this node (B) during the whole extended timeout, therefore not
> triggering the necessary ARP Reply, therefore leaving this
> node unreachable over this whole time frame. Which would probably
> result in a lot of confusion, I guess.

Another option I was wondering about is whether we could go for
the original, simpler idea and add snooping of outgoing hw-src/IP-src
pairs from ARP Requests. And whether that could be frequent and
reliable enough to avoid confusion for the previously mentioned
scenario.

I'm also wondering why we do not snoop outgoing ARP Requests yet,
why we only snoop ARP Replies. Currently, in
batadv_dat_snoop_outgoing_arp_request() there is only a:

  batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);

to fill the local DAT cache. But something like a
"batadv_dat_send_data(bat_priv, skb, ip_src, vid, BATADV_P_DAT_DHT_PUT);"
to update the DHT seems absent.

Am I missing something?
  

On Tuesday, 26 June 2018 01:29:19 HKT Linus Lüssing wrote:
> 1) Host (A) joins the network and has the IP_X / MAC_a
>    statically assigned.
> 2) Some ARP Requests reaches this host, it issues an ARP Reply
>    which populates the DHT.
> 3) The host leaves the network.
> 3) 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.

Cheers,
Marek
  

Hi Linus,

On 11/07/18 04:23, Linus Lüssing wrote:
> On Mon, Jun 25, 2018 at 07:29:19PM +0200, Linus Lüssing wrote:
>> Currently, we only update the DHT on outgoing (= into the mesh)
>> ARP Replies. I'm worried that an ARP Request would never reach
>> this node (B) during the whole extended timeout, therefore not
>> triggering the necessary ARP Reply, therefore leaving this
>> node unreachable over this whole time frame. Which would probably
>> result in a lot of confusion, I guess.
> 
> Another option I was wondering about is whether we could go for
> the original, simpler idea and add snooping of outgoing hw-src/IP-src
> pairs from ARP Requests. And whether that could be frequent and
> reliable enough to avoid confusion for the previously mentioned
> scenario.
> 
> I'm also wondering why we do not snoop outgoing ARP Requests yet,
> why we only snoop ARP Replies. Currently, in
> batadv_dat_snoop_outgoing_arp_request() there is only a:
> 
>   batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
> 
> to fill the local DAT cache. But something like a
> "batadv_dat_send_data(bat_priv, skb, ip_src, vid, BATADV_P_DAT_DHT_PUT);"
> to update the DHT seems absent.
> 
> Am I missing something?
> 

We actually snoop ARP requests, but we use the extracted information to
update the local cache only.
You are right when saying that we don't update the DHT in this case.

We snoop ARP replies because we consider them "authoritative answers"
that we can effectively trust.

Unless somebody has any objection, I think we could consider as such
also the "source IP/MAC" in an ARP request and apply the same logic.


Cheers,
  

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:
> > 1) Host (A) joins the network and has the IP_X / MAC_a
> >    statically assigned.
> > 2) Some ARP Requests reaches this host, it issues an ARP Reply
> >    which populates the DHT.
> > 3) The host leaves the network.
> > 3) 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
  

On Fri, Jul 20, 2018 at 12:47:35PM +0800, Antonio Quartulli wrote:
> Unless somebody has any objection, I think we could consider as such
> also the "source IP/MAC" in an ARP request and apply the same logic.

Hrm, one potential downside just came to my mind...

A gateway for instance will frequently generate ARP Requests for
various addresses. Sending a message to the three, poor nodes that
happen to be the DAT candidates for the gateway IP might create a
significant amount of messages to these nodes if we were
triggering that for each ARP Request... And all those unicast
messages would basically be redundant as the gateway IP/MAC pair
will already be well populated in the DAT.

One solution would be to introduce rate limiting for global DAT
cache updates... So basically introducing a third timeout for a
DAT entry, next to the global and local DAT cache timeout split.