Re: [B.A.T.M.A.N.] Node keeps switching back and forth

[elektra <onelektra@gmx.net>]

Hi -

>
> With your tests with massive traffic streams, can you confirm that 
> (for example) a user who's downloading something big (or an 
> interactive ssh session) should not see a difference and the flow 
> should stay constant, even though the traffic switches to another path 
> several times during the session? 

If two routes have similar quality it is no wonder that the protocol may 
switch because self-inflicted interference from payload degrades the 
route metric. If the alternative route is 10 % worse, the protocol may 
occasionally use the latter for a short time if the best route is fully 
saturated. As soon as the superior route has no payload anymore the 
metric improves again, while the metric of the inferior route drops. So 
the protocol will switch back quickly.

In such a scenario the superior route may be used most of the time, 
while the inferior route may be chosen less often. This may have a minor 
affect on the throughput - if one route has 10% less throughput than the 
other, but is only used 20% of the time, the negative effect is very 
limited. I'd prefer this behavior over adding hysteresis, which may 
introduce new and more severe headaches.

What is important to me is that the protocol is responsive to changes, 
and while it changes often, doesn't produce any routing errors.

When I was working on OLSR in 2004 and 2005 for Freifunk, we had the 
problem that OLSR started producing routing loops under such conditions 
in our mesh. We saturated a route (transferring high speed data traffic 
at 200 kByte/sec for 10 seconds) and then the route would break down 
completely for 40 seconds and come back at a speed of something like 8 
kByte/sec and 'stabilize' itself there... We solved the problem for OLSR 
(not entirely, but to about 95%) by making its responsiveness slower and 
slower and introducing Fisheye into OLSR (send topology information more 
redundant and more often without drowning the network with protocol 
overhead).

I have made some rough tests to see how much a fully saturated link 
degrades the metric value measured by Originator messages. I have found 
that a fully saturated link does reduce the metric values of Batman a 
bit, but in my tests it was less than 10%.

If the protocol would switch between a miserable route and a good route, 
and utilize each one half of the time this would have a significant 
effect on the throughput, and it was one of my worries in the early days 
of the protocol design. As far as I have seen in practice this is not 
the case.

> That'd be great (and I'll test that tonight!)
Yes, please test it.

cu elektra