OLSR Experiences Notes

From What The Wiki?!

1 OLSR experiences

OLSR experiences

These are notes from the "Experiences with OLSR" brainstorm/workshop at the Wireless Village, What The Hack, July 29 2005, the Netherlands. They are by no means complete, but should serve as a reminder to the people taking part.

[edit]

setup Amsterdam

75 nodes, between 30-40 in a small area in the east. Most of the problems are in east. Nodes have up to 8-9 direct line of sight links. lots of different routes to same clients. Problem with a high node with several nodes around it. This node gets clogged by hello messages, causing the mesh to route around it. Especially large packages don't get through anymore. Another problem: olsr measures link quality with small packages, which tend to get through better. - maybe also measure other package sizes for management.

for the first problem, a test was to limit the number of udp packages manually. That helped, but should be automatic. Also nodes with only one connection should be taught to not continuously say hello. Hellofreq is now 5 seconds. Amsterdam has switched to using ETX, by the way, as most others have done.

[edit]

setup Berlin

uses fragmentation algorithm of the cards. Frag value 500 to split bigger packets. RTS 250 is to get around the hidden node problem.

[edit]

problems and brainstorm about solutions

There is some research that indicates 6 neighbours is about optimal. Maybe limit transmit power to get to that.

Thomas included hysteresis for the ETX. Basically this means that only if a node is 10% stronger than another, the new route will be announced. This value probably needs to be increased, the networks react very nervously now.

Keep in mind that we shouldn't let users wait for 10 minutes or more before the fact that a node is down get noticed. There probably is some optimum to be found here...

A lot of ad-hoc protocols suffer from the same problem. For some protocols, it's more efficient to periodically re-discover the links.

Idea: limit the amount of changes per minute. This should be configurable per network.
Idea: limit the amount of hello-messages, increase the ETX hysteresis, send control messages more.

More problems:

bssid confusion, happens a lot here at WTH. Degrades performance, degrades everything. The elcheapo Atheros cards on sale here at What The Hack blindly create their own bssid and cell. More sane cards then join this cell, leading to cell splitting. Maybe a workaround: leave them for 5 seconds in managed mode, then switch them to adhoc. Works on prism54. The Atheros issue is probably a driver issue on Linux.

Roofnet is using demo-adhoc, pseudo bssid. But they use identical hardware so that's easy for them. Using madwifi.stripped They also took out networking from the Linux kernel, replacing it with their own routing-optimised version. This might actually be interesting, because it would have to be kernel level to work on a Linksys or similar. Usermode would be too slow now. But our networks also live by the fact that we work on different hardware. That has disadvantages, but also advantages. We don't want to become dependant on specific brands of hardware.

Another approach would be to connect the backbone on managed mode, splitting the adhoc network into several smaller ones. Actually this is sort of what is happening in berlin and amsterdam in the moment.

OLSR turns into an ueberprotocol, being run on crappy wifi links but also on highly stable cat5 cable. OLSR is not really good at calculating link quality on high-traffic wired interfaces yet, but could be modified.

ETX measurements doesn't include link speeds. If the ueberprotocol becomes a reality, it should do this.

interfacing olsr to other routing protocols: there is some work done on interfacing with Zebra, but this is a hush-hush military thingie so no good open documentation.

there is some discussion about whether olsr/adhoc should or should not be used on backbone infrastructure, or should just be tunneled. There are different use-cases here. How stable are stable links anyway? There is a problem with tunneling. You spend valuable CPU-power to calculate links between nodes that are in Berlin while in the Netherlands. This is not a good idea, if we don't want to accelerate global warming dramatically. It should just know in what general direction Berlin lies, what IP numbers to reach there, but *not* calculate internal routes there.

Pro-active routing protocols will probably scale to about a few hundred, not more. We also sometimes get routing loops.

We're not really sure if there is an implementation for incremental Dijkstra algorithms. Fish-eye routing is supposed to be in mobilemesh, but nobody really knows. Should we include some kind of time-to-live info? And how?

There are lots of issues with evil Atheros cards and creative interpretation of bssid. But they multiply like rabbits, so we need some solutions here. Maybe in firmware, maybe it can be solved in driverspace. Maybe a workaround would be to claim your card has an amazingly old timestamp and will win the bssid contest. Ultimately, we will need a MART (Manufacturer Attitude Readjustment Tool)...

two wishlists: one for olsr and one for hardware issues.

[edit]

Wishlist OLSR:

olsr should signal to wireless card to turn down power if there are too many neighbours, or higher if no neighbours. Probably a bit hardware-dependant, but it could be done as a plugin.
ETX hysteresis threshold should be configurable
variable hello-message speed

[edit]