[WLANware] B.A.D M.A.N

[Sven-Ola Tuecke]

Fabian,

einen Routing-Daemon bis zur Produktionsreife zu entwickeln kostet Zeit + 
Nerven (mindestens). Ich find' die Idee prima, mit unserer vorhandenen 
Infrastruktur / Erfahrungen was neues zu probieren, waehrend die 
Professionellen noch pennen / Vortraege machen / NS2-Simulieren. Anstaendige 
Vorschlaege zur (Mit-)Gestaltung haste ja auf [berlin at olsrexperiment.de] 
schon geschrieben :)

Man sollte dabei die Projektziele nicht aus den Augen verlieren. Diese 
koennen lauten (ist mehr eine Wunschliste):

- Scalability: Die OLSR-Implementation wird uns irgendwo jenseits der 1000 
Nodes auseinanderfallen. Man kann mehr Rechenkraft drauf werfen, aber da 
gibts Grenzen.

- Genauigkeit: Unsere Messmethode "Broadcast Packet-Loss" hat Nachteile. 
Daten gehen Unicast (andere phys. Bedingungen), mit anderen Paketgroeszen 
und die Kapazitaet einer Strecke wird ueberhaupt nicht betrachtet.

- Tempo: Wir optimieren auf ein stationaeres Modell. Ich finde aber 
Reaktionszeiten und um 90-360 sekunden auf Node-Ausfaelle viel zu langsam.

Nicht zuletzt finde ich es wunderbar, der Patentmafia mit einer Nasenlaenge 
Vorsprung ein Schnippchen zu schlagen. Entwicklungsabteilungen mit 
Shareholder-Value-Optimierung verbraten bei der Beratung der 
Oberpatentstrategen offenbar nicht unerheblich Energie auf die Frage "Wer 
hat das Kontextmenue erfunden". Das koennen wir sicher besser - ohne diesen 
Abfluss von Denkenergie erfindet es sich leichter ;-)

Grusz, Sven-Ola

"Fabian Melzow" <wlan at tpwm.dyndns.org> schrieb im Newsbeitrag 
news:20060329011638.31c9419c at p0b.localnet...
Hallo Leute!

Ich hab mich ja echt über die B.A.T.M.A.N-Ankündigungsmail gefreut,
weil es endlich mehr Infos gibt als Aussagen in der Form "Mit
B.A.T.M.A.N wird alles besser...". Ich hab dann auch gleich mal das
SVN ausgecheckt und dann gesehen, daß die Idee, die ich im Zusammen-
hang mit der Bandbreitenbestimmung ähnlich auch mal kurz hatte, dort
realisiert wurde.

B.A.T.M.A.N. sieht für mich so aus, als hätte man das Routing des
Internets (ARPANETs) von 1979 mit einem schlechteren RIP gekreuzt.
(siehe http://www.tm.uka.de/itm/uploads/folien/12/tm06-ka-1up.pdf
und http://www.tm.uka.de/itm/uploads/folien/93/tm-routing-1up.pdf)

Vielleicht solltet ihr besser schon mal ein Versionsfeld mit ins
Protokoll aufnehemen. ;-)

Ja, man braucht wirklich nur den besten nächsten Hop auf dem Weg
zum Ziel (das Schwierige ist ja nur gerade, herauszubekommen in
welcher Richtung  das liegt...) zu kennen und die Idee ist imho auch
nicht schlecht, wenn man ihre ganzen Probleme wegbekommen könnte.

Die Idee, das der ganze Broadcast-Overhead durch den Paketverlust
kompensiert werden könnte, ist auch echt gut.

Hier mal die Probleme, die mir bisher mit B.A.D M.A.N (v 0.0.6)
aufgefallen sind:

* geringste Bandbreite ist limitierend. Soll heißen: Es gibt einen
  Netsplit, wenn der dünnste Link verstopft ist und es keine
  Alternativ routen gibt.

* Netsplits entlang langer Pfade, für die es keine Alternativroute
  gibt: z.B.:  1-2-3-4-5-6-7-8
  Wenn ein Paket von z.B. von Knoten 3 abhanden kommt, kann 1
  8 nicht mehr erreichen und man hat 2 Teilnetze. Bei RIP verschickt
  man imho deshalb gleich die ganze Routingtabelle.

* langsame Reaktion auf den Ausfall von Knoten, weil bis der kaputte
  Pfad vergessen wurde (gibt ja bei Ausfall keine Statusmeldung),
  wird wohl möglich erst einmal in die Tonne geroutet, weil der
  kaputte Pfad eine bessere Metrik hat.

* Pakete mit alten Sequenznummern, die lange Laufzeiten haben,
  überschreiben neuere "Pfad"infos, da isDuplicate() das Paket
  nur bei gleicher Sequenznummer weg wirft und nicht auch bei
  älteren.

* Die Broadcasts verstopfen möglicherweise die Links, zumindest im
  Nahbereich. Idee: Man mancht eine Broadcastreduktion, auf dem
  jeweiligen Interface, indem man einfach die Intervallzeit zwischen
  den Broadcasts hochsetzt, wenn keine neuen Knoten über dieses
  Interface zur Routingtabelle hinzugefügt oder aber Knoten entfernt
  werden. Das entschärft die Situation in statischen Netzteilen
  bei hoher Netzauslastung. Klar darf die Rate nicht gesenkt werden,
  wenn man gar keinen Knoten über das entsprechende Interface "sieht".

* Die Latenzzeit sagt nur bedingt etwas über die Weglänge und Qualität
  aus! Warum soll eine Satellitenverbindung oder Lanverbindung über
  mehrere Switche schlechter sein, als eine WLAN-Verbindung mit
  niedriger Latenz? Warum also nicht die Bandbreite messen?
  Das hat auch den Vorteil, daß man nicht nach der Vergangenheit
  routen muß, wenn einem die Zukunft interessiert!

* die TTL sollte imho besser hoch als runtergezählt werden, denn
  so weiß man, das immer bei 0 begonnen wurde.

* keine Erweiterungsmöglichkeiten im Protokoll vorgesehen. :-(
  Ja, das finde ich schlecht, weil ich hab schon jede Menge Ideen,
  u.a. auch für automatische Tunnel übers Internet.

Zum Thema Erweiterungen: Zuerst hatte ich über TLV nachgedacht,
aber das halte ich nicht für sinnvoll, besser finde ich, jede
Nachricht mit einem eindeutigen 16 bit-Wert zu beginnen, anhand
dessen man herausbekommen kann, ob die Nachricht für einen
überhaupt interessant ist. Am besten packt man auch noch die
Gesamtlänge des Pakets (16 bit) vor diesen Wert, dann hat man es bei
der Speicherreservierung für das Paket einfacher und weis, das man
auch alles bekommen hat, wenn das Paket fragmentiert wurde.

Den ID-Wert kann man dann für verschiede Pakettypen benutzen, wie
Routinginfos, Tunnelendpunktannouncements, etc. und man hat keine
Probleme bei Umstellungen und Erweitereungen, da man per default
alle Pakete mit IDs, die man nicht kennt, einfach forwardet.

So können z.B. die Gateways, die es anbieten, Infos über ihre
externe IP und den Typ des Tunnelprotokolls verteilen etc.

Gruß
Fabian
_______________________________________________
WLANware mailing list
WLANware at freifunk.net
https://freifunk.net/mailman/listinfo/wlanware