[Berlin-wireless] olsrd-bmf plugin / mDNS plugin

[Henning Rogge]

Am Dienstag 15 Dezember 2009 09:54:57 schrieb Rolf Pfeiffer:
> Nochmal im Ernst: in einem Funkmesh ist einiges anders. ZB ist es
> normal, dass geforwardete Multi-/Broadcasts mehrfach empfangen werden.
> 
> Ich gehe mal davon aus, dass die Entwicklwer eines Plugins für einen
> Mesh-Routing-daemon das wissen - und deshalb Buch führen und jede
> nachricht nur einmal forwarden. Aber - tun sie das wirklich?
Sowohl BMF als auch mDNS benutzen eine Sequenznummer um Duplikate zu erkennen 
so das jedes entsprechende Paket nur 1x pro Node wieder ausgesendet wird.

Wobei BMF da noch ein paar Tricks probiert und manchmal auf mehrfachen Unicast 
(anstatt eines Broadcasts) umschaltet.

> Ich bin nicht so skeptisch gegen zeroconf, sondern allgemein gegen die
> Kombination Multicast plus direktes forwarding - wie wir es zB auch bei
> batman haben. Dort haben die Entwickler -aus gutem Grund- das
> Originatorintervall einstellbar gemacht.
Das Problem ist in unserem Fall (egal ob bei OLSR oder bei BATMAN) die 
Grundannahme von Zeroconf/Avahi das alle verbundenen Nodes ziemlich direkt (am 
besten über einen Switch/ect.) am selben Netz liegen und damit die Multicast-
Kommunikation zwischen den Nodes schnell, zuverlässig und billig ist.

Diese Annahme ist beim Fluten 
 
> Das Paketaufkommen in der Luft hängt natürlich von der Anzahl der
> Originalpakete/Node, der Meshgrösse, und ganz besonders von der
> Reichweite (in Hops) zum Quadrat ab - für ein mesh mit homogener
> Knotendichte.
Wenn man bedenkt das jedes Paket alle Knoten in Funkreichweite abhält was zu 
senden (wenns nicht sowieso zu einer Kollision kommt) sind die Kosten für das 
Netz um ein mDNS-Paket zu übertragen ziemlich hoch.

> In unserem inhomogenen Netz hätten wir in Bereichen mit hoher
> Knotendichte ein überproportional höheres Aufkommen von
> Broad-/Multicasts. Und da gibt es einen Punkt, wo "geht perfekt" in
> "alles dicht" umschlägt.
Exakt. Die Anzahl der Kollisionen wird irgendwann so hoch das "mehr 
Übertragungsversuche" zu "weniger ankommenden Paketen" führen. WLAN-basierte 
Mesh-Netze gehen halt nen gutes Stück früher in eine Überlast-Zone.
 
> Itunes, pidgin und Co wissen aber nichts von dieser Problematik und
> multicasten munter drauf los. Also ist der Grundbaustein und allererste
> Aufgabe eines Multicast-Forwarders eine EFFEKTIVE BREMSE! Und bitteschön
> dynamisch sich an die Netzgegebenheiten anpassend! Hat BMF sowas?
Nein. BMF und mDNS wissen nicht was sie Forwarden... da wird weder eine Bremse 
noch sonst irgend eine Traffic-Shaping gemacht.

Wobei das Bremsen auch ein Problem ist. Wenn eine Zeroconf-Instant 10 Pakete 
die Sekunde sendet, muss man Pakete verwerfen um die Datenrate auf ein 
vernünftiges Niveau zu senken. Und ohne wissen was für Pakete das sind 
verwirft man da schnell die falschen.

> Es mag Szenarien und Anwendungen geben, wo Multicast diesen ganzen foo
> wert ist. Aber dann möchte ich vorher eine quantitative Abschätzung oder
> Simulation sehen. Zum "einfach Ausprobieren" ist das Schadenspotential
> einfach zu hoch - imho -
Ich persönlich bin mir sicher das BMF und Zeroconf (oder mDNS) in der jetzigen 
Ausführung ein größeres Mesh an den Rand des Zusammenbruchs bringen können. 
Oder darüber hinaus.

Henning Rogge
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 198 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20091215/58bce4e9/attachment.pgp>