[Berlin-wireless] [technix] Bitratenkontrolle, traffic-mengen- und radio-aware routing

[Rolf Pfeiffer]

Hallo Marco!

Ganz ohne Boshaftigkeit - ich glaube, du siehst die Welt aus der 
Kopfstand-Perspektive. Vielleicht bin ich es auch, der auf dem Kopf steht - 
ich schreib mal, wie es für mich aussieht.

Konkret hast du eine Vorstellung, wie Netzstruktur und Links sein SOLLTEN und 
versuchst das von Oben nach Unten auf allen Layern "durchzudrücken" - 
angefangen von der Einteilung in wichtige und unwichtige Links, massiven 
Einsatz von Filtern und LQs, Manipulationen am TCP-Stack, bis zu fixen 
Bitraten.

Du möchtest also ein geplantes, strukturiertes, kontrolliertes Netz. Das ist 
aber von einer Person in einem sich ständig wechselndem Umfeld gar nicht zu 
leisten und führt irgendwann zwangsläufig zum Kollaps. (Sama ??)

Auf die Füße gestellt sieht das aber so aus: Die physikalischen Bedingungen 
sind ersteinmal gegeben, und ändern sich ständig (gedrehte Antennen, lose 
Stecker, neue Nodes...)

Die Bitratenautomatik soll dort das Mögliche herausholen, so gut oder schlecht 
sie es vermag - und basierend auf diesen Gegebenheiten soll der Routingdaemon 
seine Entscheidungen treffen - nicht umgekehrt.

Allen Unkenrufen zum Trotz macht der olsrd diesen Job gar nicht schlecht, wenn 
man ihn nur läßt. Jedenfalls waren viele Probleme auf unabgesprochene (und 
zum Teil vergessene) LQ- und Filtereinstellungen, Zwangs-Default-Routen uä. 
zurückzuführen und verschwanden auf wundersame Weise, sobald der ganze foo 
gelöscht war.

Zum Thema:

>  - das raten switching muß langsamer ablaufen, als das routing-proto für die
>   anpaßung der routen benötigt, bzw. braucht nicht schneller zu sein
Kopfstand - das raten-switching soll so schnell sein, wie sich die phys. 
Bedingungen ändern. Der Routingdämon muß entscheiden, ob er einen Link mit 
wechselner Qualität beibehalten will.

>  - auswirkungen der in kauf genommenen 50% packet-loss auf andere links?
>    optimiert dies zwangsläufig auch die overall-performance im mesh?
Je schneller die Übertragung (egal bei wieviel Packetloss), desto kürzer die 
notwendige Zeit desto weniger Beeinträchtigung anderer Links.

Schnelle Übertragung braucht aber hohe Pegel und hat deshalb eine höhere 
Störreichweite. Steht aber auf einem anderen Blatt (optimale Senderadien).

>  - untersuchungen in [6] fehlt komponente, notwendige links aufrecht zu
>    erhalten, oder ausgefallene zu ersetzen, die aber ein ganz wesentliches
>    element von mesh-networks darstellt
Kopfstand - widerum Job des Routingdämons - eine Bitratensteuerung kann nur 
das phys. Mögliche bestmöglich nutzen.

> was man _jetzt_ machen könnte, ohne eine elegantere lösung zu blockieren:
>    trennung von routing-algo  und link-layer optimierung...
Ack. 

>   (Companion)...der die seitens des routing-daemons getroffene
>   nachbar==link-entscheidung optimiert, d.h. die bit-rate soweit
>   hoch-fährt, daß die minimal notwendigen links noch gut funktionieren ...
Kopfstand - der Routingdaemon kann die Entscheidungen erst treffen, wenn die 
Linkqualität ermittelt (und evtl. optimiert) ist. Dasselbe Problem hat 
übrigens das Rostocker Script zur Sendeleistungs-Anpassung

>  info über link-layer anderen nodes via routing-proto message type bekannt
>  machen ...
Ack. Ich wünsche mir besonders die Empfangspegel.

>   (? gateway-bandwidth als virtuelle node im inet behandeln ?  ;-)
Ack. Dazu braucht es LQ/NLQ für die Verbindung ff-gateway-node -> inet. Sollte 
auch mit olsr gehen.

>   inidviduelle bit-raten behandlung von nachbarn aufgeben,
>   dafür nachteile der aktuellen rate-automatik loswerden 
NAck! Das wäre ein zu hoher Preis. Stell dir einen Knoten vor mit 2 Nachbarn, 
jeweils 100m u. 1km entfernt. Entweder du hängst den einen ab oder bremst den 
anderen aus. Und wenn ein Knoten dazukommt oder wegfällt, sieht wieder alles 
ganz anders aus. Kopfstand.

>     -> in hinsicht auf mögliche nachbar-anzahl evtl. sogar einfach reeller
>     (wg. beschränkung gleichzeitig individuell verwalteter link-param. in 
>     broadcom-radios) 
Wieviel verwaltet er denn? Eigentlich wollen wir sowieso eine begrenzte 
Nachbar-Zahl - ich zumindest.

Die Bitratenautomatik vorhandener Treiber können wir evtl. austricksen. Das 
Hauptproblem bei Broadcomm liegt (in meinen Augen) darin, daß er bei 
Nichtaktivität auf viel zu hohe Bitraten schaltet - und dann eine Weile 
braucht, bis das erste Paket durchkommt.

Wenn wir alle paar Sekunden zu jedem Nachbarn (wir wollen nur wenige) ein 
Unicast-Paket schicken (das sehr kurz sein kann), können wir das vielleicht 
verhindern. Und wenn wir clever sind, benutzen wir das gleich zur 
Bandbreitenbestimmung. Scheint mir jedenfalls den Versuch wert :-)

Mit batman haben wir ein Protokoll, das Linkeigenschaften und Routing sehr eng 
verknüpft - und gerade daraus seine elegante Einfachheit zieht. Ob sich dort 
die Bandbreite einzubeziehen lässt, ohne den Algorithmus über den Haufen zu 
werfen ???

Gruß Rolf



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