Grundlast

Eine häufige, besonders auch von Neueinsteigern gestellte Frage ist:

"2 GB pro Tag nur für das Freifunk Routing ist ja Wahnsinn! Kann man da nichts machen?"

Problematik

Im Unterschied zum ursprünglichen Layer-3 B.A.T.M.A.N. arbeitet das von uns eingesetzte "B.A.T.M.A.N. advanced" (batman-adv) auf Layer-2: Das komplette vermaschte Netz wird somit in einen riesigen, virtuellen Switch (ohne VLANs) verwandelt. Durch die Aufteilung in Hoods haben wir die Broadcast Domäne immerhin schon in kleinere Teile aufgeteilt, dennoch erzeugen von Nutzern versendete Layer-2 Multicast Pakete und von batman-adv generierte Originatornachrichten (OGM Broadcasts) eine konstante Datenrate von üblicherweise 10-30 KiB/s auf den VPN Schnittstellen. Diese Grundlast ist sehr abhängig davon, in welcher Hood man ist, wieviele Clients verbunden sind und was diese Clients im Netz so treiben. Fairerweise muss man sagen, dass es natürlich auch im gesamten Internet eine durch Protokoll-Overhead verursachte Last gibt, wovon man jedoch üblicherweise nichts mitbekommt.

Die Freifunk Grundlast wird häufig auch als Grundrauschen bezeichnet. Dies mag vieleicht auch daher kommen, dass Freifunk das Wort "Funk" im Namen trägt, was eine (analoge) Übertragung über einen Kanal impliziert, dessen Bandbreite beliebig und ohne weitere Kosten mit Daten gefüllt werden kann. Allerdings kommunizieren derzeit (noch!) die geografisch zu weit voneinander entfernten Freifunk Router über fffVPN und damit über das Internet. Und hier sprechen wir nicht mehr über unsere Funkschnittstelle, sondern von digitaler Vermittlungstechnik bei Providern, die letztlich auch finanziert werden muss. Zum einen ist da der Stromverbrauch; aber steigender Traffic macht auch Investitionen in Infrastruktur notwendig: Glasfaserkabel, zusätzliche Ports und Karten in Switchen und Routern etc. Internetverkehr kostet entgegen der landläufigen Meinung Geld und daher sollte jede Generierung von Traffic auch einen Sinn haben.

Das ist bei der Freifunk Grundlast zunächst gegeben: Originatornachrichten dienen dazu, Knoten im Netz bekannt zu machen und die Link-Qualitäten zu den direkten Nachbarn zu messen (Transmit Quality, TQ-Wert). Layer-2 Multi-/Broadcast ist von Nutzern erzeugter Verkehr und darf daher laut Pico Peering Agreement nicht gefiltert werden. Allerdings muss man hinterfragen, ob wirklich aller Protokollverkehr (z. B. die per Multicast verteilten Datei- und Druckerfreigaben von Nutzern) beabsichtigt und in der Datenrate nötig ist.

Freifunk Franken

Da Freifunk Franken aus mehreren Hoods besteht, stellt sich die Situation bei uns unterschiedlich dar. Im Januar 2016 ergab sich auf Knoten mit 0.5.1 und 0.5.2 Firmware für fffVPN folgendes Bild:

Hood	Tx	Rx	Rx/24h
fuerth	3 KiB/s	15 KiB/s	1.3 GiB
nuernberg	4 KiB/s	35 KiB/s	3.0 GiB
erlangen	6 KiB/s	29 KiB/s	2.5 GiB
nbgland	4 KiB/s	16 KiB/s	1.4 GiB
ansbach	2 KiB/s	7 KiB/s	0.6 GiB

Tendenziell sieht man hier den Einfluss der Hoodgröße (Ansbach ist beispielsweise relativ klein), allerdings spielt auch die Anzahl von Knoten mit älterer Firmware eine Rolle (Nürnberg?). (Hinweis: Nicht nur auf den fffVPN, sondern auch auf den w2mesh Schnittstellen gibt es eine Grundlast. Diese schwankt allerdings stark - auch in Abhängigkeit der Linkqualität.)

Es gibt natürlich gute Gründe, weshalb uns eine monatliche Grundlast von 90 GB direkt betrifft:

• Solange der DSL Anschluss, an dem Freifunk betrieben wird, schnell genug ist, ist die Grundlast kein großes Problem. Mit DSL 768 sieht es jedoch ganz anders aus...
• Die Drosselung von DSL Anschlüssen ist nach wie vor aktuell. O2 DSL mit 100 GB Drosselung ist für Freifunk nicht sinnvoll; auch der Tarif mit 300 GB Drosselung könnte in bestimmten Hoods knapp werden.
• Energie und Bandbreite sind bei autarken Freifunk Stationen, die als Backup dienen können, immer knapp. Traffic kostet Energie und verbraucht das knappe GB Volumen eines eingebauten UMTS-Sticks.
• Mittel- bis langfristig soll das "Backbone" des Freifunknetzes ebenfalls über Funk laufen. Bevor das Netz aber nur noch mit sich selber beschäftigt ist, brauchen wir eine Lösung.

Lösungsansätze

Wie schon erwähnt, sind Hood-interne Multi- und Broadcasts das eigentliche Problem. Nun kann man, wenn mehr Knoten dazukommen, die Hoods immer weiter aufteilen und so die Broadcast Domäne verkleinern. Aus Städten werden dann Stadtteile und irgendwann vielleicht einzelne Straßenzüge. Dafür sind aber auch weitere Gateways notwendig bzw. wünschenswert. Allerdings hat nicht jeder Freifunker Lust, einen eigenen Gateway Server zu betreiben (Skalierung besteht hier nicht nur aus der Technik sondern auch aus Menschen!). Sich in der Entwicklung befindende Konzepte, z.B. [1], bieten Lösungen für den Zwang zu kleineren Hoods, sind aber bislang nicht in stabiler Form verfügbar.

Seit Firmware 0.5.1 filtern wir viele Client-initierte Multi- und Broadcasts (siehe /etc/firewall.user). In [2] (Kapitel 4) ist beschrieben, wie dies in Zukunft noch weiter verfeinert werden könnte. Zudem besteht die Möglichkeit der stochastischen Filterung, die immer nur einen Prozentsatz der Multicastpakete durchlässt, aber die prinzipielle Funktion erhält.

In [3] (Kapitel 1.2) gibt es Statistiken von Freifunk Hamburg aus dem Jahr 2014. Es wird gezeigt, dass Layer-2 Broadcasts mit der Anzahl der Clients skalieren, OGMs hingegen nicht. Da OGMs dennoch einen erklecklichen Teil der Grundlast ausmachen, sollten auch diese reduziert werden. Eine naheliegende Idee ist die Verringerung des OGM Broadcast Intervalls. Eventuell kann man das Intervall auch vom verwendeten Interface abhängig machen: Router, die als Endpunkte nur über WLAN angebunden sind, müssen wahrscheinlich nur selten broadcasten. Generell wurde eine teilweise Reduktion der OGM Broadcasts mit der Einführung des Echo Location Protocols (ELP) [4] in batman-adv 2014.0.0 erreicht (wir verwenden derzeit noch Version 2013.4.0). Im Link finden sich auch noch andere Vorschläge zur Reduzierung von B.A.T.M.A.N. OGM Broadcasts.

In [5] sind weitere Ideen beschrieben, wie der Broadcast Verkehr verringert werden kann. Ein Beispiel ist die Implementierung von Caches für ARP und Neighbor Discovery. Zusätzlich könnte man das Intervall anpassen. Und unter der Annahme, dass weiter entfernte Router an bestimmten Broadcasts weniger interessiert sind, könnten Nachbarrouter mit höherem Intervall versogt werden als der Rest.