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

Fr Mär 23 03:05:56 CET 2007

On Thu, Mar.22. 20:53 +0100, Rolf Pfeiffer wrote:

> Mit der Routenmetrik ETX wurde ein Durchsatz vergleichbar dem Original 
> erzielt. Die dicksten Brocken zur Verbesserung waren eine eigene 
> Bitratenkontrolle, und die Routenmetrik - die diese auch nutzt (ETT ~ ETX x  
> Bandbreite).

in 802.11s ist als eine option "RA-OLSR" (radio-aware OLSR) genannt.

habe dazu bislang nur presentations-level info gefunden:
  http://netlab18.cis.nctu.edu.tw/html/wlan_course/powerpoint/802.11s.pdf

darunter kommt dann bald das stichwort "Common Channel Framework(CCF)";
auch laut [3] die option, daß ein wifi-device zeit-slot-artig auf einen
anderen kanal wechselt, um einen transfer zu genau einem gegenüber, das
synchron mitgewechselt hat, abzuwickeln.

der "common channel" dient als default-Kanal, auf den alle teilnehmer
zyklisch oder nach individuellem transfer-ende zurückkehren, abhängig
davon, welches "proposal" man liest (Wi-Mesh oder SEEMesh).
(IMO ist eine archilles-ferse, daß einfache devices den common-channel
 auch für data-transfers nutzen dürfen, bottle-neck)
erinnert ein bißchen an ISDN mit (steuer-) D-Kanal und transfer B-kanälen

auch paßt (noch) einiges nicht zusammen, meinen die wirklich meshing? :

  "RA-OLSR  - Radio Aware- Optimized Link State Routing Protocol
    OLSR algorithm is optimized for:
      - radio broadcast efficiency
        data must physically go as far as possible in one hop, 
        to maximize speed and efficiency while minimizing latency
      - removal of duplicates
        nodes physically between communicating nodes need to discard packets 
        not intended for them, and possibly provide error correction
      - minimal frequency overlap
        stations use different frequencies while minimizing overlap and 
        crosstalk in order to maximize cross-section bandwidth "

und im proposal der SEEmesh ("handy-fraktion" Nokia, Motorola) ist von funk-
strukturen mit sende-masten etc. zu lesen.  na ja, zum daumen-drauf-halten
braucht es zentralistische elemente.

und, während

> [...] eine agressive Retry-Strategie: nicht 
> übertragene Pakete werden nicht verworfen, sondern wieder in die 
> Sendewarteschlange gestellt.

"nur" eine modifikation des IP-stacks bedingt, also soweit im open-source
context "machbar" ist, setzt 802.11s leider auf MAC-ebene an, erfordert also
eine modifikation der radio-firmware.  auch die implementierung eines
"bit-rate selection algorithms" wie den älteren varianten oder dem vom
author in [6] vorgeschlagenen SampleRate-algorithmus fällt in letztere ebene.

beides, mods an MAC-layer und IP-stack schränkt die auswahl an devices, damit
letzlich den teilnehmer-kreis am mesh, massiv ein. (u.a. als stichworte "ältere
hardware", für die selbst der support im open-source bereich dünn wird, und
modernes geraffel, das man doch gern verwursten würde, z.B. rangelan2 stuff
hier oder die radar-awareness problematik mit ad-hoc auf 5GHz dort)

allgemeinere ansätze wie westwood (tcp-stack optimierung f. congestion-
behaftete netz-segemente) haben dem gegenüber auch einen nicht nur auf funk-
netze beschränkten anwendungsbereich, damit eine breitere interessenten-gruppe,
mehr entwickler support.

selbst, wenn wie im beispiel des "Onoe rate-algorithm" eine open-source
implemtierung existiert (atheros, linux), bleibt eine riesige zahl existenter
(hard-mac-) wifi-devices davon ausgenommen, obwohl sie unter linux, *BSD 
auf treiber-ebene unterstützt werden.

sollte angesichts dessen eine für freifunk-artige mesh-netze pragmatische
link-layer optimierung nicht soweit wie möglich "treiber-unabhängig" passieren?

in hinblick auf das thema "bit-rate selection algorithms" -> [6] würde ich
folgende kritik unter FF-aspekten anbringen:

  - seine einteilung vom links in kategorien ist ein plausibles schema, das sich
    auch in der praxis immer wieder zeigt:

    (jeweils von langsameren zu höheren bit-rates betrachtet:)

       "steep drop-off" - bit-rates work perfectly until they do not work at all

                 (almost 40% of the outdoor 802.11b links classifed as lossy)
                 bit-rates achieved at least 90% of their possible throughput
                 or less than 10% of the maximum throughput

       "gradual"       - fall-off in throughput after e.g. maximum

                         (most of the links)
                         best performing bit-rate is the highest one
                         that has more than 50% delivery rate

       "lossy"         - all bit-rates are lossy, but fastest still provides
                         the highest throughput
                         best bit-rate has lower than 50% delivery rate

       "other"

    (leider ist zugriff auf re-transmit info, BER info,
     also MAC-layer interna meistens nicht gegeben)

  - 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

  - auswirkungen der in kauf genommenen 50% packet-loss auf andere links?
    optimiert dies zwangsläufig auch die overall-performance im mesh?

  - untersuchungen in [6] fehlt komponente, notwendige links aufrecht zu
    erhalten, oder ausgefallene zu ersetzen, die aber ein ganz wesentliches
    element von mesh-networks darstellt:
    seine untersuchungen beziehen sich letztlich auf ein wifi-netz (im lab),
    wo jeder teilnehmer zur not auch das ethernet-kabel in die wand stecken
    kann:

    im stadt-mesh kann ein 100KByte/s link von stummel-zu-stummel vllt. nicht
    eine grade ausgefallene, parallele "autobahn-brücke" a la
        20db-conifer  zu   3m-Sat-Schüssel   über 150m ersetzen,
    aber zumindest das abrufen von e-mails sicherstellen.
    will sagen, selbst wenn die beiden stummel sonst in ihrer lokalen wolke mit
    >24M-rate rum-funken sollten, bieten sie eben im fall der fälle ggfs. mehr
    nutzen, und wenn bloß einer die antenne dreht...

    eben, welche rolle eine node innerhalb der topologie spielt
      z.B. "dumme" end-geräte (pda´s, laptopf´s ohne routing-daemon) anzubinden

was man _jetzt_ machen könnte, ohne eine elegantere lösung zu blockieren:

   trennung von routing-algo  und link-layer optimierung
     der routing-daemon kriegt einen kompanion-prozeß,
     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 (und TX-power runter usw.)

   info über link-layer anderen nodes via routing-proto message type bekannt machen
     (? gateway-bandwidth als virtuelle node im inet behandeln ?  ;-)
     routing-messages an nachbarn erweitern um
       "auf welchem kanal funke ich"
       "mit welcher bit-rate"
       "wieviel % auslastung hatten meine interfaces"

   inidviduelle bit-raten behandlung von nachbarn aufgeben,
   dafür nachteile der aktuellen rate-automatik loswerden

     -> treiber-unabhängig, rate bei allen hardware-/treiber-kombies fix einstellbar

     -> in hinsicht auf mögliche nachbar-anzahl evtl. sogar einfach reeller
        (wg. beschränkung gleichzeitig individuell verwalteter link-param. in
         broadcom-radios)

     -> weniger overhead/traffic durch routing-proto

     -> vereinfachung, weniger aufwand für routing-daemon bei der berücksichtigung
        von link-bandbreiten

   gzielt verschiedene modulations-arten anprobieren, wenn wenig los ist

   routing-algo : path-cost berechnung erweitern um link-layer info
     -> freifunk-aware-OLSRd
     -> batman-üng

wenn man das auch noch hinbekommt, ohne den leuten ihren vertrauens-vorschuß in
freifunk zu vergällen,

könnte spaß machen, marco

[1] SrcRR: A High Throughput Routing Protocol for 802.11 Mesh Networks (DRAFT)
  http://pdos.csail.mit.edu/~rtm/srcrr-draft.pdf

[2] 802.11 TGs - Simple Efficient Extensible Mesh Network
  http://netlab18.cis.nctu.edu.tw/html/wlan_course/powerpoint/802.11s.pdf

[3] ct 05/2007, S.208

[4] 802.11s  - unapproved IEEE 802.11 amendment for Mesh Networking
  http://www.ieee802.org/802_tutorials/nov06/802.11s_Tutorial_r5.pdf
  s.a. http://en.wikipedia.org/wiki/IEEE_802.11s

[5] SEEMesh proposal
  http://dpeecs.nctu.edu.tw/.files/MeshRelay_20060520.pdf
  OFDM Frame Structure with TDD  - möchten gern DECT einbauen
                                   HomeRF rotiert im Grab ;-)
  relay stations  - zentrale sende-masten

[6] Bit-rate Selection in Wireless Networks
  http://pdos.csail.mit.edu/papers/jbicket-ms.pdf

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