Elektra Wagenrads Vortrag zum OLSRd hat sehr schön verdeutlicht, wie weit akademische Lösungen von der Praxis entfernt sind.
Die ersten OLSRd Implementierungen nach RFC3626 funktionierten in der Praxis überhaupt nicht. Ein Grund war Dijsktras Algorithmus: der OLSRd versucht damit den kürzesten Weg zwischen zwei Knoten zu finden.
Zwei weit entfernte Knoten, die gerade noch in Reichweite sind, haben zwar die Distanz von einem Hop, der Link ist aber so schlecht, dass kaum Daten übertragen werden können. Die mathematisch ungünstigere Route über einen dazwischen liegenden Knoten wird nicht herangezogen. Der OLSRd bewertet nun die Linkqualität zwischen den Knoten anhand des Packet-loss und versucht die Route mit der besten Linkqualität zu finden (LQ-EXT).
Neu in der kommenden Version 0.4.10 des OLSRd ist der LinkQualityFishEye Mechanismus. Damit sollen Routing-Loops minimiert werden. Routing Loops entstehen, wenn die Topologie-Information im Netz nicht synchron ist, also nicht alle Knoten die gleiche Vorstellung von der Netzwerktopologie haben. Anstatt nun mit viel Aufwand zu versuchen, die Topologie-Informationen zu synchronisieren, wird nur in der unmittelbaren Nachbarschaft diese Informationen so oft wie möglich aktualisiert.
Praktisch wird das mit kleinen Paket-TTLs erreicht. Die unmittelbaren Nachbarn werden sehr häufig mit Topologie-Updates (TTL=1) versorgt. Updates mit TTL=2 und TTL=3 werden häufig, aber nicht zu häufig versendet. Updates mit TTL=255 werden nur hin- und wieder versendet.
Selbst wenn ein Paket eine nicht optimale Route nimmt, ist es so ein paar Hops näher an seinem Ziel und damit vielleicht bei einem Knoten, der eine bessere Vorstellung von der Topologie des Netzes hat (ähnlich dem „Six Degrees of Separation“-Experiment).