[WLANware] Routing-Protokoll und Layer2

[Fabian Melzow]

Hallo Leute!

On Fri, 31 Mar 2006 13:44:00 +0200
Dirk Bossenz <tigger at lipsia.de> wrote:

> es gibt IMHO schon div. Routing-Protokoll-Konzepte für dynamische oder 
> quasi-statische Funknetze, es ist ja auch ein aktuelles Thema, wenn 
> gleich nicht mit dem Hintergrund wie wir es bei dem Freifunk-Netzen 
> vorfinden. Eine Idee eines Protokolles so wie es den Anfoderungen am 
> nächsten kommt habe ich hier gefunden, es ist das TERA-Routing-Protkoll:
> http://deposit.ddb.de/cgi-bin/dokserv?idn=967248957&dok_var=d1&dok_ext=pdf&filename=967248957.pdf

Original + mehr interessantes Zeug: http://www.ralphjansen.de/pub.html
TERA wurde ja wohl eher dafür gemacht, um Bandbreite zu sparen. Soweit
ich das sehe, ist bei Freifunk aber als erstes die Rechenleistung der
begrenzende Faktor.

> Im weiteren bin ich zu dem Schluß gekommen (nachdem andere bereits vor 
> mir), das ein ideal perfektes Routing-Protokoll nix nützt wenn auf der 
> darunter liegenden Ebene immer noch zu viel unkoordinierter Rabatz 
> herrscht.

Ja, aber man kann ja die Auswirkungen der Linkstörungen im Routing-
protokoll mit spezifischen, auf die Störungen hin optimierten
Verfahren, messen. Man muß da imho nicht auf Layer 2 runter!

> Ebenso bin ich am überlegen ob es nicht Sinnvoll 
> ist mit dynamischen MTUs zu arbeiten, denn kleiner Pakete auf instabilen 
> Verbindungen bzw. hoher Störanfälligkeit wirken sich dann weniger 
> dramatisch aus, bzw. kann der Link denoch genutzt werden ohne jetzt 
> gleich als schlecht bewertet zu werden.

Das ist ja auch mein Eindruck, der auch logisch erscheint, daß kleine
Pakete potenziell leichter über den Link können. Klar pfuscht da einem
noch die evtl. aktivierte Layer 2-Fragmentierung der WLAN-Karten ins
Handwerk, aber die Auswirkungen davon sollten das Gesamtergebnis nicht
all zu sehr beeinflussen.

Das Problem bei der MTU-Regelung ist, daß man schlecht testen kann
(geht imho nur mit raw-/packet-Sockets), ob man wieder größere Pakete
über den Link bekommt, wenn die MTU heruntergeschraubt wurde.

Das ist vielleicht auch der Grund, warum man sich bei srcRR dann dafür
entschieden hat, die L2-Bitrate aktiv zu regeln. Nur das ist imho nicht
sehr portabel, weil ich mir nicht vorstellen kann, das es für die
Bitratenregelung von WLAN-Karten unter Windows ein einheitliches
Treiberinterface gibt.

> Nun hab ich aber auf der Suche nach weiterer Information über BSSID-Hack 
> bzw. nach Einblicken und Pseudoschnittstellen zum wl.o Treiber auch 
> gelesen, das großartige Veränderungen am Layer2 nicht wirklich Sinnvoll 
> sind, da sich diese in einem hetrogenen Netz nicht "so einfach" 
> gestalten wie bei den Layer3 Implentationen.

Zumindest bei allen HostAP-fähigen Karten kommt man ja wenigstens zum
Teil auf den MAC-Layer runter. Ich schließe mich da an, das der Aufwand,
eine Verwaltung auf layer 2 zu machen sicher größer wäre, als der Nutzen,
wenn man die Summe der Störungen auf layer 3 berücksichtigt.

> Konkret es mir darum auch einen gewissen Rahmen abzustecken wo ich Ideen 
> auch zu theoretischen Vollendung durchdenke um dann evl. auch je nach 
> eignen Fähigkeiten und prinzipellen Möglichkeiten auch umzusetzen.

Mich interessieren vor allem die derzeitigen Probleme (Sind sie
systematisch, z.B. abhängig von der Paketgröße?) und die
Anforderungen an den Routingalgorithmus.
Soweit ich das mitbekommen habe, sind das zur Zeit generell:
1. möglichst geringe CPU-last, damit das Routing auch auf jeder
Streichholzschachtel läuft.
2. geringer Speicherbedarf (weil die WRTs haben ja nicht so viel)
3. geringe Linkbelastung (da dort von einem eher statischen Netz aus-
gegangen wird, ist Overhead bei Strukturveränderungen, im Gegensatz zu
den meisten wissenschaftlichen Änsätzen, nicht so schlimm)

> Meine Ansätze sind:
> richtiges Zeitmultiplex mit In oder Out-Band Steuerung zum anderen 
> Generell einen einheitlichen Kanal für Steuerung und die Knoten suchen 
> sich dann einen Kanal für den Payload oder eine Adaption im Sinne von 
> ATM oder ... was mir sonst noch einfällt.

Eine Kanalbelegungssteuerung ist doch imho genau das, was CTS/RTS
jetzt schon macht, wenn es eingesetzt wird.

> Den Ansatz mit dynamischer 
> Paketgröße würde ich entweder Abhängig machen von der 
> Fehlerwahrscheinlichkeit des Payloads (und dann entsprechend 
> Runterregeln) oder da die Störungen prinzipell über das gesamte Band 
> gehen mit über den Steuerungskanal.

Austesten der maximal möglichen Paketgröße, der Paketverlustrate
(paketgrößenabhängiges ETX) und nach Möglichkeit auch der max. Bandbreite
und momentanen Auslastung, halte ich derzeit für die sinnvollste
Lösung.

ETX mit unterschiedlich großen Paketen gibt es ja schon bei srcRR, aber
soweit ich das beim überfliegen gesehen habe, benutzen sie dort nur
zwei feste Paketgrößen für die Testpakete, wobei eine die MTU ist.

Für mich drängst sich aber da aber eine vereinfachte Abwandlung des
TCP-Sliding-Window-Verfahrens ja schon fast auf. :-)

Das stelle ich mir so vor, das man bei einer bestimmten Fehlerrate
die Paketgröße halbiert bzw. versucht. ob man sie verdoppeln kann,
wenn das verdoppeln fehlschlägt, der Link aber weiterhin stabil
bzgl. des tolerierten Paketverlustes ist, versucht man es mit
der Hälfte des vormaligen Verdopplungswertes usw.
Wenn man dort in der Praxis etwas testet, bekommt man sicher auch
gute Grenzwerte für den tolerierbaren Paketverlust usw. heraus.

Gruß
Fabian