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

[Marco Tidow]

Hallo Rolf,

On Fri, Mar.23. 07:52 +0100, Rolf Pfeiffer wrote:
> 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 ??)

aehm, schreibst Du das auf meinen beitrag?  zu allem ein klares NEIN.
aber erstmal der reihe nach:


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


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

genau betrachtet, liefern batman oder olsrd derzeit eine aussage darüber, wiegut
broadcast-packets von einem zum nachbar-node durchgehen, ohne RTS und TACK (gibt´s
bei broadcasts ja nicht), und mit der mode-typischen basic-rate, also 1M oder 6M.

allein der CSMA/CA (carrier-sense, multiple-access / collison-avoidance) und
contention-window back-off auf elementarstem MAC-layer hindert nodes, diese
broadcasts rauszusenden.  trotzdem passieren auch hierbei kollisionen (wegen
hidden-node szenarien).

die bit-raten automatik spielt hierbei überhaupt keine rolle, sie wirkt nur für
unicast-packets (noch genauer: auch nur ihren payload-anteil).

bei der tx-power automatik bin ich mir dagegen sicher, daß sie auch broadcasts
betrifft. (auf broadcom-radio´s mit binary-wl driver bezogen)
sobald man sie ausschaltet, also einen festen wert != 255 vorgibt, verschwinden
artefakte wie sporadisch einseitige LQ==0.00 .


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

Ack.  aber das setzte ich sowieso voraus.  mit "ff_lqmult" _kann_ man eine menge
störungen durch temporäre, mobile nodes raushalten, muß das aber homogen auf
allen fest-installierten routern durchziehen (<fixe-nodes>:1.0;default:0.1)


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

kein kopfstand.  derzeit hat der routing-daemon bei automatischer tx-bit-rate
fast keine info zu vermuten, wie gut ein link tatsächlich sein wird.  s.o.,
er bewertet _broadcasts_, die mit _fixer_ + niedriger bit-rate versandt werden.

wenn ich die reale unicast bandbreite eines links mit in die routing-entschei-
dung einbeziehen will, muß ich dem routing-daemon die nötige zeit lassen, auf
schrittweise änderungen der tx-rate (<= phys. bedingungen) richtig zu reagieren.
falls die bedingungen sich schnell ändern, muß ich trotzdem ein "schwingen" der
beiden regel-kreise dämpfen.

nur für den fall, das unicasts auch mit einer der broadcast-rate nahezu
identischen bit-rate + modulations-typ versendet werden, sagt der LQ etwas
der realität nahe kommendes aus, taugt die routing-entscheidung derzeit was;
und genau dann, ja, _dann_ funktioniert das routing _super_ gut.

wahrscheinlich resultiert die hohe latenz-schwankung in links aus dem umstand,
daß nachdem ein packet einen weg eingeschlagen hat, sich die betreffenden nodes
langwierig und fast packet-weise neu darauf "zurücknehmen" müssen, anstelle
mit 54M doch nur mit einer der broadcast-rate vergleichbar niedrigen unicast-
rate zu senden.

aber auch wiederum nur, wenn unicasts ebenfalls auf RTS verzichten, sonst kommt
zusätzliche unbestimmtheit ins spiel, abgesehen von der anfälligkeit der RTS-
steuerung für sich nicht ebenfalls RTS-bedienende nachbar-netze (was den
typischen fall darstellt, wahrscheinlich zu 99%, weil hersteller-vorgabe).


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

eben, deshalb mein fragezeichen.  von ihrer rolle innnerhalb der sich dyna-
misch ergebenden topologie der nodes "weiß" die lokale bit-raten selection
nichts.

intensiver traffic zwischen zwei nahen nodes muß nicht aus einem fern-link
dahinter stammen, kann von lokalen clients der beiden stammen; und zöge damit
den fern-link erheblich in mitleidenschaft.


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

nö:  eine bitratensteuerung hat das potential, dem routing-daemon selbst
essentielle links weg-zuoptimieren ;-)
sie muß deshalb auf die aktuelle routing-konstellation ihrer node reagieren,
letzteres vermeiden.

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

;-) henne-ei problem: die bit-rate optimierung muß wissen, 

 1) ob es überhaupt derzeit einen nachbarn gibt, sonst runter mit den raten
    und ggfs. sogar rauf mit der sende-leistung, damit der routing-daemon zum
    zug kommen kann

 2) welche nachbarn die bis dato vom routing-daemon als die besten eingestuft
    wurden, um _dann_ genau so weit bit-rate und sende-leistung zu verändern,
    daß sich ein minimum an sendeleistung + maximum an lokaler unicast bit-rate
    ergibt  (=> hohe lokalität, Du nennst es minimal nötiger sende-radius)

    ABER, ohne ein absolutes minimum notwendiger links dabei einzubüßen,
    denen richtung inet-gateway einerseits,
    solche zu anderen node-häufungen aber _auch_ (anhand der 2-hop neigbours,
    die mal vorhanden waren)

 beides erfährt sie aus der routing-table + abfrage der ermittelten LQ zu
 unmittelbaren nachbarn...

 3) und sie muß berücksichtigen, wenn z.b. olsr-lose gesellen in der nähe
    auf zuwendung angewiesen sind, ob sie sich ggfs. selbst entsprechend
    "weit-sichtig" verhalten sollte


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

tja, an dieser stelle greife ich mal Deine eingangsfragen nach meiner
intention bzgl. ob top-down topologie-planung etc. wieder auf.

punkt 2 des henne-ei problems oben fragt eben nicht nur, ob eine default-route
zum nächsten inet-gateway existiert.  schwieriger, aber IMO im sinne eines
"stadt-weiten intranets" ebenso gefordert ist, innerhalb einer node-gruppe
mit untereinander gut und schnell funktionierender links

  1. festzustellen, daß man eine insel bildet und

  2. zu probieren, ob man wirklich allein ist, oder ob´s
     auch andere erden im universum gibt ("ich will hier raus" ;-)

und eben _deshalb_ _muß_ mindestens ein knoten runter mit der rate, und rauf
mit der sende-leistung, bis entweder feststeht:

   sorry, wir funken auf helgoland  => no chance to berlin  ;-)
     (wir gucken aber alle halbe stunde, ob helgoland nicht vllt. doch
      neben berlin liegt!)

   oder welcher der insel-gruppe mit geringsten einbußen eine fern-brücke
   für die ganze gruppe schlagen kann


nochmal:
letzteres passiert derzeit bei auto-bitrate überhaupt nicht.  man bleibt
einfach insel.  nix mit stadtweitem intranet bislang oft, obwohl in der
technik beim derzeitigen node-ausbau meistens eben doch mehr brauchbare links
drinstecken, mehr leute einbezogen werden könnten.


dieser einwand mag manch einen zu der vermutung bringen, ich wolle "das netz
top-down durchorganisieren".  nö.  aber inseln sind blöd, wenn sie zwar
brücken haben, diese aber (automatisch) nur halb ausfahren.



sehe uns derzeit eher so:

es gibt z.z. die einen, die stellen autobahn-brücken in die berliner wlandschaft.
das ist nützlich.  man kann mit einer diskette bis zur nächsten brücke latschen,
eine leiter anstellen, oben mit dem ferrari in null-zeit zum anderen ende in
100m entfernung düsen, wieder die andere leiter runter, und zu fuß die zwei
kilometer zur nächsten autobahn-brücke durch den matsch latschen.

ich bevorzuge dagegen, feldwege mit kopfstein-pflaster der marke
"1M" oder "2M" anzulegen, und die brücken-enden auf bordstein-niveau runter-
zubrechen.  so kommt man wenigstens per fahrrad voran, ohne abzusteigen;
auch wenn ich kopfstein-pflaster persönlich hasse.

quer-verkehr an kreuzungen seitens der firma "managed-mode", der frech alle
ampeln der polizei RTS ignoriert, bringe ich schon mal mit ganz kleinen
steinchen-fragmenten in´s hoppeln, um zwischen seinen breiten reifen einfach
flink hindurch zu huschen.  auf RTS pfeife ich mittlerweile ebenso, auch wenn´s
manchmal weh tut.

tja:

die ferrari-feti´s mögen mich nicht, zuviel fuß-volk? sorry : shit happens
auch to your feet, if you wanna be part of this concert.

die firma "managed-mode" hat mittlerweile angst um ihre blöden video-konserven,
mag die dosen auch nicht nach jeder kreuzung wieder neu sortieren und ist auf
andere straßen ausgewichen.


the end  ;-)


o.k., im zweifel zugunsten eines durchgängigen netzes, um es kurz zusammen
zufassen, selbst wenn´s erstmal langsam läuft.  anhand dessen zeigen sich
dann automatisch die strecken, die per antennen-technik gepuscht, das ganze
netz flüssiger machen können, that´s all.



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

nix genaues ahnt niemand, die rede war von 4 individuell gleichzeit in chipset-
registern (oder firmware-daten-strukturen?) möglichen link-parameter-sets,
laut Sven-Ola, nach welcher Quelle?


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

Ack.

> 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 :-)

Ack.  arping´s reichen schon.

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

da bin ich leidenschaftslos, wer zuerst das nötige macht.

> Gruß Rolf
Gruß, marco


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