[Berlin-wireless] [WLANware] B.A.D M.A.N

Mi Mär 29 18:21:39 CEST 2006

Hi Fabian.

Mit Interesse habe ich deinen Text gelesen und finde ihn auch gut.
Aber Batman ist noch jung, und was ja nicht ist, kann ja noch werden ;)

Fabian Melzow schrieb:
> 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.
>   

Also rauszubekommen wo was in etwa liegt, ist ja durch die Ortsbezogene
IP-Adressvergabe schon möglich.

Zur Positionsbestimmung im wlan Netz eignet sich folgendes
Man könnte z.B. das im Amateurfunk übliche Locatersystem benutzen, wo
ganz Deutschland/die ganze Welt in Felder zur Positionsbestimmung
aufgeteilt ist.
Berlin ist z.b in diesem System auch in ca 5x5 km große Felder
aufgeteilt. Die Felder kann man mithilfe der Bildungsregeln und einer
Formel aus den GPS Koordinaten errechnen. Da in unserem Bereich die
Funkreichweiten geringer sind, könnte man es auch etwas hochdrehen und
die Felder 10-20 mal feiner aufteilen, im Bereich Berlin, so dass man
dann ne Auflösung von 500 bzw 250 m hat. Sein Feld kann man sich dann
noch ganz einfach ohne GPS Empfänger ermitteln, bei der Auflösung gehts
noch gut über "auf ner karte rauspicken".
Man müsste nur noch einen Switch in der Firmware installieren, wo man
angibt, ob man eine feststation ist oder nicht, und nur die
Feststationen dann zur Positionsbestimmung heranzieht.

> 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".
>   
Ich würde auch noch hingehen, und würde über schlechte anbindungen auch
weniger Routing-Infos senden, damit man mehr Nutzdaten drüberbekommt.
> * 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!
>   
Also ich würde nicht nur die Latzenz oder die Bandbreite beräücksichtigen.
Ich würde die Anzahl der Widerholungen, die für ein Paket gebraucht
wurden, für jeden Linkeintrag mitspeichern, und dann aus der Kombination
von Anzahl der erforderlichen Widerholungen, Bandbreite und Latenz eine
Linkbewertung durchführen, wobei ich das Hauptaugenmerk auf Anzahl der
Sendewiderholungen und Bandbreite legen würde. Allerdings weiß ich auch
nicht, in wie weit man bei Wlan die Sendewiderholungen für die einzelnen
Pakete abfragen kann.

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

Jap und wenn sie eine bestimmte anzahl überschreitet->tonne.
> * 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.
>
>   
Jap, genau so ein System wird im Packet Radio Protokoll verwedet.
Da wird die Länge der Nutzdaten im Info-Block gesendet.
Auch verschiedene Paket Typen werden über eine mitgesendete Kennung
kenntlich gemacht und die Pakete können dann auch jeweils anders
behandelt werden.

> So können z.B. die Gateways, die es anbieten, Infos über ihre
> externe IP und den Typ des Tunnelprotokolls verteilen etc.
>   
Jap, automatische Internettunnels fände ich auch gut.

QOS wäre auch noch ne Maßnahme um das Netz zu verbessern
Man könnte z.b als allererstes mal die Pakete durchlassen, die fürs Netz
wichtig sind.
Und danach dann die Userkommunikation.
Und da auch nochmal QOS machen, VOIP ganz oben, filetransfer ganz am Ende

> Gruß
> Fabian
>   

Gruß Oliver
> _______________________________________________
> WLANware mailing list
> WLANware at freifunk.net
> https://freifunk.net/mailman/listinfo/wlanware
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin
>   

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin