Re: [B.A.T.M.A.N.] Suggestion for routing improvement on poor links

[Antonio Quartulli <antonio@meshcoding.com>]

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

On 19/02/14 21:56, whangarei & opua wrote:
> Hi all,
> 
> have running batman-adv 2013.4.0 on a hamburg.freifunk.net
> out-of-the-box router.
> Have 3 uplinks over Wlan, with trees in the way and some rain at this
> time... So not perfect conditions...
> 
> Have seen via 'batctl o' 3 uplinks to the other side of the park.
> (logging was unfortunately not compiled in)
> Of cause, one was the best link based on the metric (or what you called
> it) at this time.
> 
> But also seen that the metric was not changed during packet lost =>
> increased last-seen time on this best link :-(
> 
> So there was a entry with a last-seen of up to 180 sec while other links
> have had much better update times because of less packet lost, but not
> so good metric like the main link at his 'best time'.
> So the 'old' best link was also active, at least by the metric shown by
> 'batctl o'. Expect the traffic will be sent to this way...
> 
> Is it maybe a good idea to decrease the metric after a last seen time of
> a links has increased 15 or 20 sec, step by step on the best link (or
> all links with increased last seen time) , so a more reliable link ( at
> this time) has a chance to be activated? I only think about the local
> routing decision, not about to announce anything to a neighbor...

If I got your question properly I'd say that batman-adv already performs
(in a similar way) what you are suggesting.

First of all I try to summarize your scenario. You have:
- a source node S, where you are reading the output of "batctl o"
- a destination node D, which you use to check the output of the command
above
- two neighbours of S, say N1 and N2
- N1 is the best nexthop towards D
- at some point the link between S and N1 becomes unusable and we have
really high packet loss -> no OGMs are received via this neighbour anymore.

At this point S still receives the OGMs generated by D via N2. Each time
one of these packets is received the metric towards D "via N1" decreases
a little bit.
When this metric "via N1" reaches a value that is smaller then the
metric "via N2" we have a route change: N2 becomes the bext nexthop.
You can check this by monitoring the TQ (name of the batman-adv metric)
towards D via N1 in "batctl o" (this command prints the "originator table").

How many seconds you need to see this switch depends on the current
metric values via N1 and via N2.

I hope this clarifies.

Cheers,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]