[Discuss] B.A.T.M.A.N. Analyse/Diskussion

[Bernd Petrovitsch]

On Fri, 2007-07-13 at 01:28 +0200, David Draco wrote:
[....]
> Ich bin gerade bei einem "eix --sync" über B.A.T.M.A.N. gestolpert,
> ein sich von OLSR distanzierendes Routing Protokoll, das speziell für
> nicht 100% verlässliche, sich ändernde Verbindungen und für unsichere
> Medien, sprich für Wireless, entwickelt wurde.

So wie OLSR, AODV und viele andere auch - irgendwo gibt es lange Listen
mit Links .....

> Informationen dazu gibt es hier:
> http://open-mesh.net/batman/documentation
> http://open-mesh.net/batman/documentation/batman-status.pdf

Es gibt dort auch eine Mailingliste.

> Jetzt wollte ich kurz die Experten fragen, ob das, oder in welchen
> Fällen, das besser ist als OLSR (das ja bei Funkfeuer glaub ich

Nach welcher Metrik "besser"?
Technologisch kann/wird man sehen (d.h. man kann
denken/theoretisieren/beweisen und/oder simulieren und/oder ....), ob
und in welchen Fällen welches Protokoll "besser" ist (und rein praktisch
hilft mir das theoretisch beste Protokoll nicht, wenn es in der Praxis
versagt, weil es irgendwelche RL-Einflüsse nicht berücksichtigt bzw.
ignoriert).
Es gibt halt etliche Netze, die OLSR benützen (oder auch anderes). Wenn
man dort "mitspielen" will, muß man OLSR nehmen.
Und nachdem verschiedenen Protokolle nicht kompatibel sind (sonst wären
sie nicht verschieden;-), muß man entweder das komplette Netz umstellen
oder sich Koexistenz/Umstiegs/...-Strategien überlegen und
implementieren - sowohl am Routingprotokoll-Level als auch
organisatorisch.

> eingesetzt wird). Gab es zu dem Protokoll schon eine Diskussion?

siehe ML-Archiv der b.a.t.m.a.n ML?

> Ich nehme ja nicht an, dass ihr umstellen werdet, selbst wenn es
> besser ist, weil das ja irrsinnig aufwendig wäre, ich wollte nur
> fragen, wie ihr B.A.T.M.A.N. seht.

Der Vollständigkeit halber: b.a.t.m.a.n kommt von Leuten, die massiv
OLSR seit Jahren in Berlin einsetzen (>600 Knoten? Aaron weiß
normalerweise bessere Zahlen), deshalb gibt es dort vermutlich auch
etwas mehr Erfahrung wie in Wien damit. Und es  verfolgt einen etwas
anderen (und nicht "radikal" zu schreiben) Ansatz, der (wenn ich es
richtig kapiert hab) auf Kabelnetzen nicht skalieren/funktionieren
würde.
Naiverweise (zumindest ich vor ein paar Jahren) hab auch gedacht, "WLAN
ist wie LAN ohne Kabel". Ja, so ist es auch am 1-zeilgen Top-Mgmt-Level
heute noch.

<disclaimer>Ich übertreibe vielleicht ein wenig im folgenden, aber der
Punkt soll rüberkommen.</disclaimer>

Sobald man 2 Ebenen runtergeht, ist technisch einiges signifikant anders
wie in der Kabelwelt:
-) Die Kabelwelt kann Packet-Loss im Protokolldesign ignorieren, weil
praktisch keine Pakete verloren gehen[0].
-) Für die Wireless-Welt ist Unicast eine degenerierte Form des
Broadcasts, weil der Layer 1 schon Broadcast ist (und nichts anderes
kann). Noch extremer: Stell Dir vor, wenn alle IP-Router weltweit
*immer* auf alle angeschlossenen Interfaces (am MAC-Layer) broadcasten
würden. Genau das passiert aber bei WLAN am Layer 1 (und man kann es
nicht verhindern[1]).
Die 2 für sich sind noch relativ harmlos, aber gemeinsam:
In der Kabelwelt muß man sich massiv drum kümmern, daß der IP-Verkehr
nicht exponentiell steigt, nur weil wo wer (der Host mit der
Applikation, der Server am anderen Ende, alle Router dazwischen) zum
retransmitten anfängt, weil es "zu lang dauert" (jeder Switch macht
schon "store-and-forward" und generiert damit Latenz, detto drüber. Und
die Latenz des Layer n geht normalerweise im Rauschen der Latenz des
Layers n+1 unter).
In der Wireless-Welt ist das kaum ein Problem, weil der (inhärente)
Packet Loss das sowieso löst.
Und nachdem Broadcasts in der Wireless Welt keinen Malus haben, weil es
eh nix anderes gibt (in der Kabelwelt schon - da kann man sinnvoll
Unicasten), wäre es wohl kaum verkehrt, mal alles konzeptionell zu
broadcasten. Und nachdem jeder Knoten ein Router sein kann (nächster
großer Unterschied zur Kabelwelt  da sind es nur ganz wenige, meist
dedizierte, Knoten), kann ich auf jedem Routingentscheidungen treffen,
welche Pakete ich weiter broadcaste (weil irgendwann schlägt schon das
exponentielle Wachstum des Verkehrs zu, wenn alle immer alles
broadcasten - das Extrem wollte ich oben nicht vorschlagen).

Und wenn man ein neues Protokoll entwickelt, dann schaut man sich idR
an, was es schon gibt und "erfindet" was (hoffentlich) besseres. Das ist
dann (mbMn zwangsläufig) vom Geist des alten beseelt und schleppt einen
großen Rucksack expliziter und impliziter Annahmen und
Design-Entscheidungen mit (die aus der alten Welt kommen).

Und dann braucht es Leute, die sich (geistig) genug von den
existierenden "Lösungen" distanzieren können, um ganz neue Ideen from
Scratch zu generieren. "Neue" Ideen gibt es eh viel zuviele - gute und
nicht so gute - (siehe das Patenunwesen), d.h. da muß man mal was auch
implementieren (was auch nicht viele der "Ideengenerierer" machen) und
ausprobieren (was im Patenunwesen weder gefordert noch notwendig ist)
mit dem Risiko, daß die eigene "gute Idee" eigentlich Müll und damit
unbrauchbar ist (und wer will sich und Der Welt das schon beweisen?).

	Bernd

[0]: Ja, überlastete Router dürfen IP-Pakete einfach wegschmeißen. Aber
das ist vernachlässigbar wenig.
[1]: Und das mir jetzt keiner mit "wir bauen flexible Richtfunkstrecken
und der Router dreht die Antenne in die richtige Richtung" kommt.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services