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

[Fabian Melzow]

Hallo Oliver!

On Wed, 29 Mar 2006 18:21:39 +0200
Oliver Brill <oliver-brill at web.de> wrote:

> Mit Interesse habe ich deinen Text gelesen und finde ihn auch gut.

Ich finde deine Verbesserungsvorschläge auch richtig gut!
Ich weis jetzt nicht, ob du auch auf der WLANware-Liste bist, weil
zum Teil habe ich manche Sachen auch schon in meinen Postings zur
Bandbreitenbestimmung angedacht (ich schick dir die gerne oder mach
gleich hier einen Repost), nur da wußte ich noch nicht, das man
vor hat, daß Routingprotokoll eh neu zu machen.

> Aber Batman ist noch jung, und was ja nicht ist, kann ja noch werden ;)

Klar ist das nicht gleich zu Anfang perfekt und man muß eben auch mal
neue Ansätze versuchen, aber mich hat irgendwie trotzdem gestört,
das das jetztige Protokoll sich quasi im Kaffeekränzchen erdacht wurde
und man sich dann auch noch hinstellt und sagt, das "nur noch kleine
Optimierungen" gemacht werden müssen, so nach der Devise: Jetzt ist es
fertig und nun testet mal!

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

Klar, zumindest fürn die stationären Knoten könnte man optional
angegebenen GPS-Koordinaten mit auswerten. Es gibt ja auch schon
Routingprotokolle, die mit Geokoordinaten arbeiten, die müßte man
sich mal genauer ansehen, ob man davon nicht etwas zur Optimierung
einbauen kann, gerade wenn laut Sven-Ola eh mehr statische Knoten
im Netz vorhanden sind.

> 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".

Das Lösungen der Amateufunker sind da durchaus interessant, da gibt's 
ja das Problen der Datenübertragung durch die Luft schon länger.
Die Variante setzt aber auch viel Verwaltungsaufwand voraus, weil man
muß die Karte mit den Koordinatenfeldern ja jeweils erst mal haben
und kann den Knoten dann auch nicht mit sich herumtragen ohne die
Einstellungen ständig zu ändern.

> 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.

Es reicht ja ein Feld in der Firmware, wo man seine GPS-Koordianten
eintragen kann. Wenn man dort was einträgt kann man ja explizit
davon ausgehen, das der Knoten stationär ist, man sollte da aber
noch eine Backupmöglichkeit zum Routing haben, so daß man sich
nicht auf die Koordinaten verlassen kann, wenn man sie hat, ist
eben das Routing nur optimaler.

> > * 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.

Ich glaube du meintest ausgelastete Links, weil bei Links mit hohem
Paketverlust, muß man das ja eher die Routinginfos noch häufiger senden.
Wenn man eh die Bandbreite und den Paketverlust mißt, ist das natürlich
sehr sinnvoll.

> > * 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.

Jupp, und wenn du die Bandbreite weist, kannst du auch gleich so routen,
daß man nicht den Link benutzt, der schon fast "voll" ist und wo die
Last bei der letzten Messung noch gestiegen ist und damit zu erwarten
ist, daß die Daten nicht mehr auf das Stück Luft "passen", ohne gedoppt
zu werden.

Bei mir sind bei einen WLAN-Link folgende Eigenschaften wichtig:
Zuerst einmal gibt es immer mehr oder weniger Paketverlust.
Die Pakete, die nicht bei Kollisionen mit Nachbars Mikrowelle
oder AP drauf gegangen sind, kommen dann als bestimmter Prozentsatz
beim Gegenüber an. Den Prozentsatz bekommt man relativ gut durch das
ETX-Verfahren heraus, Dort gibt es aber den Nachteil, das die
Kollisionen mit der Paketgröße zunehmen, weil die Pakete trotzt
Hardwarefragmentierung der WLAN-Karte länger in der Luft sind. 

Dann weis man, das z.B. 40% der Pakete ankommen, aber damit
weis man noch lange nicht, wie der wirkliche Durchsatz ist, denn
woher soll ein hardwareunabhängiges Routingprotokoll wissen,
ob die Karte z.B. gerade im 1 mbit oder im 11 mbit Modus arbeitet?

OK, man kann das altbekannte Verfahren der Laufzeitmessung benutzen,
aber dieses geht implizit davon aus, daß die Linkeigenschaften immer
die gleichen sind, z.B. weil es TP-Kabel, Glasfasern, etc. sind und
eben keine nicht konstante Luftschnittstelle.

Um herauszufinden, wie die momentane Bandbreite auf dem Link gerade
ist, muß man diese über die Halbierung der Paketumlaufzeit, für eine
bestimmte bekannte Paketgröße, bestimmen. Das Problem dabei ist aber,
daß Switche und gebündelte Verbindungen (z.B. ISDN-Kanalbündelung)
mit weniger Kapazität gemessen werden, als sie wirklich haben.
Bei Switchen deshalb, weil der Switch zumindest den Paketheader kurz
zwischenspeichern muß, was Zeit verbraucht, aber die Bandbreite nicht
negativ beeinflußt. Bei Mehrkanalverbindungen geht das Paket nur durch
einen Teilkanal und man mißt nur dessen Kapazität.

Um aber solche Links besser messen zu können, verschickt man 2 
unterschiedlich große Pakete, die auf dem Link direkt aufeinander
folgen und mißt nur ihren zeitlichen Abstand zueinander und weiß
dann durch den bekannten Größenunterschied, wie lange genau diese
Differenzdatenmenge auf dem Link unterwegs war, woraus sich dessen
Bandbreite ergibt. 

Und was, wenn die Pakete doch nicht direkt aufeinander folgen?
Man hat für dieses "packet tailgating"-Verfahren auf Kabellinks
schon gemessen, das die Pakete in 99% der Fälle wirklich direkt
aufeinander folgen. Für das 1% nimmt man dann eben einfach die
möglicherweise schlechtere Messung der Paketumlaufzeit. Wenn 
nämlich wirklich Switche im Link sind, ist die gemessene Zeit
wesentlich kleiner und wenn nicht, maximal gleich groß wie die
Paketumlaufzeit, in einer brauchbaren Messung niemals aber
größer!

Da B.A.T.M.A.N eh ein Antwortpaket an seinen Nachbarn zurückschickt
ist das ganze auch leicht zu realisieren. 

> > * 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.

Kritische Anmerkung: Die TTL bestimmt die maximal mögliche Linklänge
in Netz.

> > * 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.

Dadurch kann man ohne Probleme jederzeit Erweiterungen vornehmen,
ohne das einem bestehende Nachrichten in die Quere kommen, nur
innerhalb des gleichen Nachrichtentyps kann ein Versionsfeld evtl.
trotzdem sinnvoll sein.

> 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

QoS macht so imho für WLAN keinen Sinn, denn was bringt dir z.B. der 
Versuch, die Latenzzeit garantieren zu wollen, wenn die Pakete über einen
Link mit um die 50% schwankendem Paketverlust gehen und die zu
übertragende Datenmenge nur gering ist?

Imho müßte man dafür auch jedes Paket einzeln auf seine Eigenschaften
prüfen, wofür man unter Linux z.B. eine Kernelmodul braucht, wenn ich
da noch richtig informiert bin. Überlastvermeidung ist imho
realistischer als QoS.

Auch wenn es eine direkte Mail an mich war, ich baue es trotzdem mal
hier mit ein, weil es vielleicht auch für andere interessant sein
könnte.

On Wed, 29 Mar 2006 20:59:04 +0200
Dirk Bossenz <tigger at lipsia.de> wrote:

> könnten eigendlich nicht auch Domänen gebildet werden (gleichwohl auch 
> im Fall dynamischer), z.B. Stadtteilweise o. allgem. eine feste Zahl an 
> Knoten. Oder ist dies ein Dogma (im positiven Sinne) was nicht angerührt 
> werden sollte ?

Es gibt Adhoc-Routingprotokolle, wo ein Oberknoten jeweils mehrere
Unterknoten verwaltet, so das eine Art Backbone entsteht, aber die
habe ich mir noch nicht genauer angesehen. Das ganze soll aber nicht
so wirklich toll funktionieren, weil der ganze Traffic auf das
dynamisch bestimmte Backbone geleitet wird und auf den restlichen
Links kaum Last ist.

Falls sich das auf die IP-Vergabe bezieht, könnte man auch versuchen,
per Routingprotokoll automatisch IP-Adressbereiche zu größeren 
Netzen zusammenzufassen. Ich bilde mir ein, das man das auch bei IPv6
vor hatte, aber wenn nicht, dann kann man dort vielleicht auf der
Grundlage von PACMAN (http://pacman-autoconf.sf.net) etwas passendes
zusammen stricken. 

Gruß
Fabian
_______________________________________________
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