[Olsr-dev] Committed Patches

[Sven-Ola Tuecke]

Ahoi Aaron,

right. That's a Freifunk special. If the NAT-Endpoint (the preferred 0/0 HNA 
emitting node) is to be changed, the ETX value of the current 0/0 is 
compared to the new one. If the ETX difference is too small, the default 
route isn't changed. Simply as that.

Background:

We measure link quality by evaluating LQ_HELLO message loss. Because OLSR 
messages are normally sent inside UDP Broadcasts, there is no Wifi ACK 
mechanism to resend a lost packet. Hence, the full physical wifi packet loss 
rate has some influence on the measured LQ_HELLO message loss. Which selects 
the most efficient link for routing. Operates as designed and expected.

Until you start transferring data on that link. A lot of unicast payload 
packets will be sent and received together with a flood of Wifi ACKs. Which 
in turn increases the Wifi UDP broadcast packet loss. The current Freifunk 
Firmware tries to circumvent this effect with a traffic shaping prio queue 
for UDP port  698 As well as by elongating the 
LQ_HELLO-Loss-Measurement-Window to 128 messages.

Nevertheless: If you start using a link, the ETX values will change a bit 
over time. Which triggers a route flap if there are two equal or nearly 
equal hop chains (in terms of ETX). This is fine and also expected 
behaviour. A route switch should not break anything. But in the case of a 
NAT gateway, all connection oriented services will terminate if you change 
the NAT gateway. Because the next NAT gateway does not have the state info.

The "cost" of risking pingpong or even circle routes is lower than the 
"cost" of users experiencing broken downloads, interruped phone calls etc. 
This is where the NatThreshold jumps in. BTW: if the 0/0 gw isn't changed, 
the default route change will be executed as normal, even if triggerd by 
minimal ETX diffs.

Ideas:

* We can switch from routing to tunneling. Makes live of a network 
operator/admin a bit harder. But prevents NAT-Gateway-Switches. We may be 
able to automate, e.g. only switch tunnel enpoint if no UDP/TCP connection 
state info exists in tunnel endpoint or so. Something to consider: the TOR 
network is similar. And there is Batman, which implements tunnels for this. 
Have experienced very unexpected exit points for IP packets with that 
auto-tunnel stuff.

* We can add in more info for selecting a gateway. Currently, there is no 
bandwith / utilization / freedom-to-transport-anything / owners-sharing-will 
/ uptime-in-the-last-year etc. info in the OLSR routing scheme. If we 
consider this additional info while calculating the preferred 0/0, I'am sure 
that NAT gateways will be more distinguisable. Current ETX-only evaluation 
for the decision what default route / tunnel enpoint to select is 
less-than-real-live. A completely blocked ISDN/Analog uplink up for today is 
handled the same way as an 36Mbit SDSL or DS3 line up since the 1990's.

* We can get rid of NAT even by using an external tunnel endpoint. A cheap 
root server - preferably on the isle-of-man or in antarctica to circumvent 
other problems, SCNR. Of course, a solution like this does not need support 
inside olsrd IMO.

* We can implement a State-Info-Sync between NAT nodes, e.g. as Linux kernel 
module.

* We can change the measurement fundamentals to have more real-live-data in 
the system. Possible candiate: ETT (pat. pend.?). Install an ancient 
bandwidth measurement thingy by "apt-get install bing" then "bing localhost 
google.de" to dig in.

* We can simply start using batman && / || batman-ng. At least for managing 
the inet gateway. Marek and Elektra will welcome any development power I 
presume <ggg>.

Yes I know. Route damping has drawbacks. But all these things need 
implementation time. And the little hack does it's little job - at least for 
me and at least _now_.

Just my two cents,
// Sven-Ola

----- Original Message ----- 
From: "Aaron Kaplan" <(spam-protected)>
To: <(spam-protected)>
Sent: Tuesday, September 18, 2007 6:28 PM
Subject: Re: [Olsr-dev] Committed Patches


>
> BTW:
>
> At the WCW we noticed the NatThreshold parameter in /etc/olsrd.conf
> in the freifunk fw
> AFAIK this parameter does not exist in CVS.
>
> What is it for? Is there another patch somewhere for it?
>
> best,
> a.