[Berlin-wireless] SmartGateWay...!

[Alexander Morlang]

Am 29.01.2015 um 16:09 schrieb Bastian <fly at d00m.org>:

> On 01/29/2015 03:47 PM, Alexander Morlang wrote:
>> Am 28.01.2015 um 15:27 schrieb Bastian <fly at d00m.org>:
>>> eigentlich bin ich gegen unfertige Software die unkontrolliert
>>> Tunnel-Interfaces hochzieht und bin bisher konnte mich auch niemand mit
>>> sinnvollen Argumenten davon überzeugen, dass wir diesen SmartGateWay
>>> unbedingt brauchen.
>> 
>> Die Smartgateway Funktionalität ist eine Reproduktion der Gatewayfunktionalität von B.A.T.M.A.N.:
>> 
>> Die beiden Relevanten Komponenten sind:
>> * das Announcieren von Gateways einschließlich Bandbreiteninformation durch einkodieren in ungenutzte Felder des HNA.
>> * Ein Plugin, welches automagisch ein Gateway auswählt, falls der Nutzer dies nicht selbst macht (der normalfall)
>> 
>> Ziel ist es, dem Grundsatz der Netz&Serviceneutralität gerecht zu werden, und dem Nutzer die Auswahl des Gateways zu erlauben.
> 
> Naja, gezielt einen Gateway auszuwählen ist ja bekanntlich nicht
> möglich.

Das ist so nicht richtig. Ich bin irritiert, das wir hier eine Debatte von 2009 wieder aufmachen, aber so sei es.

> Man kann evtl. mit einstellen von irgendwelchen obskuren Werten
> zufällig auf vielleicht dem einen gewünschten Gateway landen, aber das
> ist IMHO mehr oder weniger dem Zufall überlassen.
> Eine konkrete Gateway-Selection durch den User existiert nicht.
> 
> AFAIK wurde die Gatewayfunktionalität in B.A.T.M.A.N. (Layer3!)
> implementiert um flapping-gateways aufgrund Verschlechterung der Metrik
> wegen weniger Airtime/high traffic zu vermeiden:

Die Möglichkeit, sich den Gateway auszusuchen wurde auch wegen flatternden Gateways implementiert, aber auch, um sich das bessere Gateway 1 Hop weiter aussuchen zu können.

Batman verwendet in der ursprünglichen Version asymmetrische IPIP Tunnel, um die Pakete zum Gateway zu bringen. Das funktioniert nur, weil die Fähigkeit zum Handling dieser Pakete per Definition Teil des Gateways ist.

Ein Olsrknoten, der mittels der Smartgatewayfunktionalität seine Bandbreite announciert, folgt dieser Konvention. Er kann IPIP Pakete annehmen und verarbeiten. Er ist ein Gateway, den Mensch sich aussuchen kann. Im primitivsten Falle durch händisches konfigurieren des IPIP Tunnelanfanges. Im automatischen Falle durch das Plugin.


> Wir haben in unserem Mesh keine flapping-gateways.
> 1) AirOS sorgt für 1.0/1.0 ETX whatsoever
> 2) Wir setzen TC für OLSR-Broadcasts, damit bei high-traffic der Link
> nicht zu schlecht wird
> 3) Wir sind sowieso alle mit unserem Public IP-Space online (BBB oder
> vpn03) und damit tritt flapping wegen broken NAT nicht ein

Dieser Satz von Annahmen ist meines Erachtens nach irreführend:
1) Die Netzwerkkabel zwischen den Nodes addieren (bei IPv4) einen Wert von 1.0 auf die Metrik, d.h. Metriken sind verfälscht.
2) Ich setze kein AirOS ein
3) Ich verwende statt eines VPNs Zivilcourage (und im Moment Immunität) und halte es auch für katastrophal, wenn das saubere funktionieren des Internetzuganges vom Funktionieren eines VPNs abhängt.


> 
> Ob es wirklich Sinn macht, auf unsere wegen AirOS kaputte ETX-Metrik
> auch noch eine Bandwith-Metrik oben drauf zu legen, seit zusätzlich in
> den Raum gestellt.

Ja klar, wenn die Bandbreite im Mesh da ist, will ich den VDSL Gateway per 5GHz anfunken, auch wenn das 3 Hops mehr sind, von denen eh wieder nur einer Kabel ist.

> Und solange die Bandbreiten-Metrik nicht dynamisch ist, sich also mit
> der Auslastung des Gateways anpasst, ist der wirkliche Sinn auch nicht
> gegeben.

Darüber kann Mensch trefflich streiten, aber nicht auf einer Mailingliste. Wir haben das ja lange diskutiert in verschiedenen Kontexten, bevor es so gemacht wurde.

> 
> Ich habe jedoch Verständnis dafür, dass manche Menschen hoffen, mit
> SmartGateWay irgend wann mal einen wirklich sinnvollen (technisch und
> praktisch) Mechanismus zum selektieren des idealen Internet-Uplinks zu
> haben. Die Entwicklung von SGW scheint auch wieder fortgeführt zu
> werden, zumindest deutet der Changelog[1] von OLSRd 0.6.8 darauf hin.
> 

Wie bereits vorher geschrieben, es geht auch um Grundsätzliches, um die Netz&Serviceneutralität. Es gibt viele Gründe, seine Gateway auswählen zu wollen und es obliegt uns Techies nicht, darüber zu urteilen.

So lange es keine Mechanismus dafür gibt, werden halt weiter kaputte LQ Multiplier genutzt; das kann nicht in unserem Sinne sein.


> [1]:
> http://olsr.org/git/?p=olsrd.git;a=blob;f=CHANGELOG;h=fd0444d6ad052327ce7d50df71cc54a612a43600;hb=51ac86b22ee2bdb1077c889859ad3ca5a39aa079
> 
> Gruß
> Bastian

Gruß, Alex

P.S.:
Wir dürfen den Luxus von netten VPNs, öffentlichen IP-Adressen und direkten Links zum B-CIX nur als netten Luxus betrachten, im Kern _muss_ das NEtz auch ohne diese Spielzeuge funktionieren.

1) das kann alles sehr schnell ausfallen, AFAIK ist der Bus-Faktor unserer BGP-Router zwei, d.h. wenn 2 Menschen ausfallen, gibt es keine Admins mehr. Auch kann die politische Stimmung sehr schnell kippen und damit der support von MABB&Unternehmen innerhalb kürzester Zeit kippen.

2) Auch ist es eine politische Frage, ob Community sich von solcher Infrastruktur abhängig machen will.

3) Freifunk ist und war immer Technologieexport: Die Knoten, die dezentrale Map, die gesamte Technologie konnte immer auf der grünen Wiese betrieben werden, mit nur einem (bzw. wenigen) Internetanschlüssen. Wenn Mensch das funktionieren der Knoten im Feld von zentraler Infrastruktur abhängig macht, werden viele Communities auf dem flachen Land und in zweit&drittweltländern abgekoppelt. Das möchte ich nicht mit verantworten

Meines Erachtens nach muss ein Freifunknetz auch immer ohne die ?Komfortfunktionen? funktionieren, auch wenn das heisst, das es nur noch NAT an den Gateways und die dezentrale Karte gibt.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 203 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150131/95919a80/attachment.pgp>