[WLANnews] Providerselbstjustiz und Leistungs-Metriken (Was: Re: Bitte um Feedback: Freifunk als Thema im Bundestagsausschuss Digitale Agenda)

[Achim 'ahzf' Friedland]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am 11/11/15 um 13:17 schrieb Allan Wegan:
> 
> Dass Pakete ankommen, sollte TCP sicherstellen, so lange die
> Verbindung nicht vollständig abbricht.

Es gibt so viel mehr als nur TCP im Netzverkehr ;)



> Und wenns immens wichtig ist, rechtfertigt es eine eigene Leitung.

Nur, dass "eigene Leitungen" heutzutage "digital geführt" sind, also
nichts weiter als irgendein Virtualisierungsprotokoll das mit Hilfe
von Priorisierung und Bandbreitenreservierung so tut als ob das eine
physikalische Leitung wäre. Was meist auch gut ist, denn damit kann
man die Baggerfahrerresistenz deutlich erhöhen.

Und ob ein IP-Paket Inter- oder Intranet ist kann man meist maximal am
IP-Subnetz und/oder dem VLAN-(o.ä.)-Header davor unterscheiden.

Warum sollte all das nicht auch in "freien Netzen" machbar sein
solange es einen _guten_ Grund dafür gibt?



> Deshalb haben Stromnetzbetreiber eigene Netze.

s.o.



> Ja, man kann QoS-Markierungen und Portnummern zur Priorisierung 
> heranziehen - bis dann irgendwann der ganze Traffic nur noch über
> Port 22 mit Echtzeit-QoS-Markierung geht.

Das das ein Katz-und-Mausspiel ist... keine Frage. Aber darum geht es
ja nicht. Es geht mehr darum, dass Du es grundlegend ablehnst und ich
meine, dass es gute Gründe gibt es anzuwenden.



> Seitdem gibts überall, wo es die Programme gibt, auch (oft
> verblüffend gut gemachte) Anleitungen, wie man den Port ändert (und
> in den heimischen Router als Forwarding-Regel einträgt).

Seitdem gibt es Deep-Packet-Inspection und alles was nicht "gut" ist
kommt in die Holzklasse ;)



> Es geht hier um ein offenes Netz. Das sollte robust sein. Wenn ich
> mir durch simpelste Täuschungsmaßnahmen die Überholspur sichern
> kann, ist es das für die anderen Nutzer nicht mehr.

Nun, wäre es nicht viel sinnvoller zu sagen, dass der Missbrauch
dieser Features "kein Freifunk" mehr ist, als ein Werkzeug, dass man
wie nun mal jedes andere auch halt auch missbrauchen kann?



> Es gibt trotz allem natürlich auch technisch notwendige 
> Datenverkehrbeeinflussung. Beispielsweise werden in manchen 
> Batman.adv-basierten Freifunknetzen wohl einige Broadcast-Pakete 
> verworfen, weil es zu geschwätzige Anwendungen gibt, die von eher 
> kleinen Layer-2-Segmenten ausgehen und deren Brodcasts in Segmenten
> mit mehreren hundert Knoten zu viel Grundrauschen erzeugen.

Nun, es gibt sicherlich auch Filter gegen IP-Spoofing... etc.pp
Defacto wird wahrscheinlich jedes Netz gegen eine harte Auslegung der
Netzneutralität verstoßen. Wozu also Regeln die praxisfern sind?



> Die Versuchung ist groß, softwareseitig mehr Usability aus einem
> Netz zu holen. Aber das kann nur eine Notlösung sein. Wenn das Netz
> überlastet ist, muss es wachsen. Wenn Bufferbloat Latenzprobleme
> verursacht, muss man die Puffer kleiner machen...

Hilft auch nur bedingt... kleinere Buffer == weniger Effizienz, da
Packetaggregation gerade auf Funkkanälen schlechter funktioniert und
kleinere Buffer == mehr Packetloss was zu mehr aufwendigen
Retransmissions führt, welche das Netz dann noch mehr belasten.



> Ich bin nicht grundsätzlich gegen Traffic-Priorisierung im Freifunk
> - aber abseits von temporärer Emergency-Response sehe ich kein
> sinnvolles Einsatzgebiet.

Nah, ich würde mal sagen, dass alles was unter "Emergency-Response"
verbucht werden kann, der Sinn&Zweck von Netzen ist. Alles andere ist
mehr so Convenience, weil man ja so ein Netz schon mal da hat.


Gruß aus Jena
 Achim

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWQ5PFAAoJEH3mX7dvm8SQNxQP+wbtaXTFbOMzhi4PGc0/BNN/
j9GZ2jfebSOR8gOZPSYQGywyPl1IJKSvfLMRlc0hSwjk9QRoKzmU5GYb9AGQnfzE
usHIC4ndN9f8E+vxoHaZNCXa41WywZhwFwMgBJhfkTnPeCDERxTKwxPc7CxOnHrq
A7oXqziyIJk82aR0gXtlNZVst/lKgiuiNMAFxcD8pdE0GzTFZ2Mp2+WwPG3Gg4fl
/nC+bT0V7LPNHOd75/QaAEJiPwC+Zn7Mq7WYUTHzhUUb3MZRuOrD4OMvGdCYYIiw
QKxSCTGQRT1kUN53hJGxKo+89CZYSBiHsw4NFQTt+MVPthz66G28egWVrKIW0OrH
WEsiPuN+xU6SwCJOcnt08mldhrZcX+JDpNDTTX2fiwlyQbiFOhk7P4Wf0gDO6N/b
QykgVruE2alswm9gX2C8Ief99HhnXAyCU3EI0ujuUqpm8U38L1hAyFUzaGTKdvEz
LOt4TxYFgXDdtr8jvUW2NQe9h52imzrgf6RP5FEKfuDYwvvqvpzVfXHAmrIwyDGY
XwD0bg4+84bcRV5qIuocm12Qbo3ZsvytyTcbsmPxSLcCR1f4o4gMEZ5QxwhMQ/vF
WHQs7KDInoRmbUYxExoRhOD2AlG01Y2vKVbpUjLXd8lGHM/l+H0U0iItRQMJ5kNh
iy1AQxnBpmYTrG10VdmI
=FLed
-----END PGP SIGNATURE-----