Prinzipiell gab es von uns drei Motivationsgründe für BATMAN V:
- Durchsatz- vs. Packetverlust-Metrik
Mit zunehmenden WLAN Geschwindigkeiten, wird es immer schwieriger anhand von Packetloss eine sinnvolle Entscheidung zu treffen. I.d.R. stellen wir ja eine fixe WLAN multicast Rate von 12, 18 oder 24Mbit/s ein. Sobald ein Link aber dann über dem Wert ist, hat man (meistens) auch wenig Packetverlust. Und es wird für BATMAN IV dann schwierig zu entscheiden, ob es z.B. die Route mit 50Mbit/s oder die mit 150MBit/s nehmen soll. Auch bei den Tests beim Battlemesh v8 zeigte OLSRv2, welches als erstes eine Durchsatz-Metrik von den gängigen Protokollen implementierte, eindrucksvoll, dass dieser Ansatz sehr großes Potential hat. In Durchsatztests schnitt OLSRv2 dort am besten ab.
Eigentlich, theoretisch, wäre dies auch gerade für 60GHz Gigabit-WLAN praktisch, damit batman-adv solch einem performanten WLAN-Backbone mehr Beachtung schenkt.
Aber wie schon im Thread erwähnt, gibt es dort dann noch zur Zeit das Problem, dass dort BATMAN V von den 60GHz Geräten noch nicht die Bandbreite mitgeteilt bekommt.
Was hier helfen würde: a) Mehr 60GHz Geräte auf OpenWrt portieren und sicherstellen, dass deren WLAN-Treiber ein „expected throughput“ reporten. b) Eigentlich war die ursprüngliche Idee, dass auch BATMAN V, wenn es keine sinnvollen Werte geliefert bekommt, dann selber mit selbst generiertem Traffic misst. Eine abgespeckte TCP Variante ist dafür auch im BATMAN V implementiert und kann mit „batctl throughputmeter“ benutzt werden. Jedoch fehlt dafür noch der Automatismus, dieses Feature selbstständig allein im Kernel zu benutzen, ua. weil es etwas schwierig abzuschätzen ist, wie oft zu welchen Nachbarknoten man messen soll. Denn man will ja auch nicht alles an nutzbarer Bandbreite nur für’s Messen verschenken. Gerne kann aber mit dem batman-adv „throughputmeter“ im user-space herumgespielt werden. Wenn jemand eine gute User-space Implementierung dafür dann finden sollte, würde uns das schon sehr helfen und wir könnten es dann vll. auch in den Kernel übernehmen.
- OGM ↔ ELP Split
Mit BATMAN V sollten auch die Aufgaben für OGM Pakete weiter aufgeteilt werden. Insbesondere in frühen Zeiten von BATMAN IV wurden diese zum Verteilen aller möglichen Informationen benutzt. Unabhängig davon, wie dringend deren Verteilung/Updates waren. Ursprüngliche Idee: OGMs zum Beispiel nur noch alle 15s durch’s Mesh fluten, während ein neuer Pakettyp, „ELP“ (Echo Location Protocol) Pakete dann z.B. jede Sekunde nachbarn anpingt, um die Packetloss Rate zu ermitteln. Auch wenn Packetloss-Metrik am Ende doch durch Throughput-Metrik ersetzt wurde, hat ELP Einzug gefunden. Um z.B. „später“ einen reaktiven Routen-Update-Mechanismus wie bei Babel zu implementieren: RIP - batman-adv - Open Mesh. Leider bisher nicht über dieses Konzept hinaus gekommen.
Trotzdem hat die Aufteilung von OGM und ELP auch schon ein paar kleine, einfache Overhead Reduktionsmechanismes ermöglicht: In bestimmten Fällen, wo ELP vorher die Nachbar-Knoten auf einem Link detektiert hat, werden OGM rebroadcasts vermieden:
https://git.open-mesh.org/batman-adv.git/commit/a00797d8fa8fd147
Bei BATMAN IV kann/wird dieser Mechanismus nur für die verkapselteten, per „classic flooding“ verteilten Broadcast Ethernet Frames benutzt, nicht aber für OGMs. In BATMAN V wird es für beides benutzt.
- Aufgeräumter Code
Der Routing-Code von BATMAN IV ist über die Jahre in batman-adv sehr gewachsen und etwas schwer erweiterbar geworden. Der BATMAN V Code ist viel, viel übersichtlicher und aufgeräumter, insbesondere weil wir ihn erst auf Papier und im Wiki genau spezifiert haben. Und dann daran BATMAN V sauber heruntergecoded wurde. Dadurch sollte, zusammen mit 2) BATMAN V theoretisch in Zukunft besser erweiterbar sein als BATMAN IV.
Leider hat der ganze BATMAN V Umbau aber auch eine Menge Energie gekostet. Was vll. auch ein Grund war, warum dann obwohl anfangs eine Menge toller Ideen da waren, was man auf BATMAN V dann alles aufbauen könnte, dann als BATMAN V dann fertig war, die Energie/Motivation/Zeit fehlte, diese spannenden, weiterführenden Ideen noch umzusetzen.
