Sind die zufaellig migriert worden? Handelt es sich um VMs von einem Hoster? Hier koennte eine vermehrte Nutzung der CPU durch andere Kunden die Antwort sein.
Anyways: Falls noch wer bei Myloc/Webtropia hostet: Ich rate dringend zur Migration.
1 „Gefällt mir“
wir ziehen jetzt um auf eigenes Blech, mal sehen, wie es dann ist.
Eine Fehlersuche in der Domain xy oder z hat aber nun wirklich nichts mit der Frage der Störerhaftung zu tun und was man dann zukünftig technisch anders machen könnte.
Die Tatsache, dass bestimmter Traffic zukünftig lokaler gehalten werden könnte, also im Sinne von „weniger Hops im Freifunk“ ist in jedem Fall erstrebenswert. ganz gleich wie gut oder noch perfekter der FFRL-Backbone läuft.
Und auch wenn Airtime ein Problem ist: Wir sollten die Effektivität auf allen Ebenen im Blick halten. Und etwas nur zu tun, weil wir es können und weil Resourcen dafür gerade im Übeschuss vorhanden sind: Zumindest für mich keine Rechtfertigung.
3 „Gefällt mir“
Effektiv ist das Vorhaben Traffic lokal auzuleiten sicher nicht. Das ist ja genau mein Punkt. Es haette keinen Effekt. AS201701 hat mitlerweile wohl bessere Konnektivitaet zu Content Anbietern als die meisten Hoster. Dazu kommen noch direkte Verbindungen zu eben diesen Hostern. In Summe macht das im Worst Case einen Router Hop mehr der aber genau so gut auch einer weniger sein kann. Hetzner z.B. verfuegt eben nicht ueber ein direktes Google Peering. Und selbst wenn waere der Umweg in Frankfurt < 0.1ms (dies bezieht sich auf Supernode Ausleitung).
Bei lokaler Ausleitung kann das ganze noch schlimmer aussehen. Angenommen $HOSTER bezahlt die $ISP fuer Traffic und verfuegt daher ueber hinreichend Kapazitaet, der FFRL hat genug Kapazitaet zu $CONTENT und zu $HOSTER, und $CONTENT hat keine vernuenftige Konnektivitaet zu $ISP dann fuehrt die lokale Ausleitung direkt in diesen Flaschenhals.
Und etwas nur zu optimieren weil Menschen glauben dass dadurch irgendwas besser wuerde ist absolut ineffektiv und ineffizient. Die Nutzung wird durch die lokale Ausleitung nicht steigen weil andere Flaschenhaelse vorhanden sind. Aber was rede ich auf Ignoranten ein…
P.S. Hier werden dinge „verbessert“ weil man kann, nicht weil man muss. Und das ist das Problem.
1 „Gefällt mir“
Da liegt ein Misverständnis vor.
Es geht mir nicht um die Ausleitung bei den Hostern. Sondern um Ausleitung bei den Plasteroutern, die DSL/DOSIS-Uplink haben.
Und ich lese Postings von jemanden, der meine Posts nicht verstehen will.
Ja, es mag szenarien geben in denen es schneller ist, wenn der Weg von Unitymedia->FFRL->Netflix geht statt direkt von Unitymedia->Netflix.
Aber zumindest im Durchschnitt steigt erstmal der Hopcount.
Danke für Deine ausführlichen Erläuterungen zu Peering & Co.
Mal für mich als ambitionierter Laie:
Wenn also $FREIFUNKUSER sich ein HD-Youtube-Video über (s)einen ff-Knoten ansieht und der Video-Datenstrom vom Freifunk-Knoten ausgeleitet wird zur lokalen Internetanbindung (z.B. FritzBox bei 1&1/Telekom/whatever), dann ist das für die Freifunk-Infrastruktur kein Vorteil? (weil z.B. erst gar kein Traffic via lokalemSupernode bzw. beim Freifunk-Provider FFRL bzw. Berlin.e.V entsteht).
In Kassel z.B. sind wir erst einmal froh, wenn der gesammelte ff-Traffic im monatlichen, zweistelligen TB-Bereich nicht „exorbitant“ wächst, was bei HD oder demnächst 4K-Videos leicht passieren kann.
Oder verstehe ich da grad was nicht?
LG
Jörg
1 „Gefällt mir“
Widerspruch in sich. Wenn ich optimiere, ist es optimaler als vorher, ansonsten ist es nur Kosmetik. 
Bei mir hakt YT selbst über Kabel, Offloader under fine 50 Mbit/s-Leitung. Auf dem Supernode ist nich genug frei.
Speedtests sagen 50 Mbit/s wie auch iperf zum Supernode.
Über „normales“ Unitymedia LAN geht es.
Wo kann da der Flaschenhals sein wenn nicht im Backbone?
OT…
Unsere Supernodes stehen in RBX. Der Ping von Unitymedia → RBX → BB ist grauenvoll.
Routenverfolgung zu tungsten.ffgl.eu [91.121.133.94] ber maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 12 ms 11 ms 12 ms e120-scsto1.netcologne.de [195.14.226.59]
3 11 ms 11 ms 11 ms swrt-sto7-te1-5.netcologne.de [81.173.197.73]
4 11 ms 11 ms 11 ms core-sto1-vl430.netcologne.de [78.35.18.17]
5 15 ms 16 ms 16 ms 81.173.192.18
6 * * * Zeitberschreitung der Anforderung.
7 25 ms 23 ms 25 ms be10-1184.rbx-g1-a9.fr.eu [94.23.122.76]
8 25 ms 26 ms 25 ms be101-24.rbx1-3a-a9.fr.eu [37.187.231.100]
9 22 ms 21 ms 22 ms tungsten.ffgl.eu [91.121.133.94]
nicht „im“ Backbone, sondern die Anbindung des Backbone beim DC ist das Problem anscheinend. Da kann CPU und gekaufte Bandbreite noch so gut sein. Allerdings für mich eher ein Argument mehr dafür, möglichst früh die harten Sachen (Yahoo & Co.) rauszuwerfen. (defecte CD=ON „Ich will meine 50 Mbit/s wieder haben“
Wenn die Störerhaftung weg ist, dann sollten wir uns mit unserer Freifunk-Infrastruktur (supernodes, Backbone) auf das beschränken, was
a) Mehrwert bringt (Karten/Stats/Updateserver, evtl auch mal die viel beschworenen „internen Dienste“)
b) als Traffic nach wie vor problematisch werden kann für Knotenaufstellende und auch problematisch für Mietserver-Verträge.
P.S: und ich bitte nochmal dringend darum, Eure nervige „Warum ist gerade meine Domain so langsam“-Debatte woanders zu führen. Das ist hier völlig deplatziert. (Da keine Teilthreads mehr verschoben werden sollen, werde ich dazu übergehen, es entsprechend gehässig zu kommentieren.)
3 „Gefällt mir“
Ist die Frage fuer wen. Fuer den Betreiber der Infrastruktur moeglicherweise (Sofern der Traffic tatsaechlich ein Problem ist, koennte man das so entlasten. Es gibt allerdings Hoseter wie OVH die juckts nicht).
Fuer den User kann der Exit ueber ein Drittnetz sinnvoll sein.
premature optimization is the root of all evil
- Donald Knuth
ACK. Wer performance Probleme im/zum Backbone vermutet der darf gerne ein Ticket oeffnen und/oder einen neuen Thread. Ich denke ich habe meinen Standpunkt hier hinreichend dargelegt und verabschiede mich hier nun.
„Alles was über den FF-Router geht, wird durch deinen privaten Router per VPN durchgeleitet.“ So habe ich bisher argumentiert. Sollte die Störerhaftung tatsächlich kippen und wir entscheiden uns, den massiven Traffic direkt über den privaten Anschluss auszuleiten, werden sicher die meisten Aufsteller abspringen. Das möchte hier einfach niemand. Es geht da nicht mal um Bandbreitengeiz, sondern um das ungute Gefühl.
Wenn so eine Lösung, dann mit Wahlmöglichkeit. Wie mit der Bandbreitenbegrenzung.
Dieser Aussage kann ich mich anschließen:
3 „Gefällt mir“
Das würde ich so auch unterstützen. Ein-/zwei erklärende Sätze im config-Mode mit Häckchen zur bewussten Auswahl und dann kann man das sicherlich auch gut kommunizieren.
nein, sehe ich nicht, ist eine Frage, wie klar vertändlich man das ausdrückt. Das Hauptargument ist bei uns jedenfalls nicht das „alles VPN“ sondern dar Identifikationsschutz durch den Verein (Gateway). Wo aber der sowieso nicht vakant ist oder wg. HTTPS Nutzung das Verschüsseln sowioe nicht ein zweites Mal stattfindet, ist das möglicherweise sicherheitsneutral, und das lässt sich dem Aufsteller n.m. Erfahrung sehr leicht vermitteln, wenn man nicht von vornherein den Argumentationsstring falsch aufgesetzt hat.
Wichtig ist aber in jedem Fall, dass das sehr transparent und für User Supergaudoof verständlich dargelegt und veröffentlicht ist, nicht in Freak-Genglisch oder Nerd-Slang
Eine Wahlmöglichkeit erscheint mir technisch schwierig umsetzbar und verwirrt u.U.mehr, als sie hilft, weil die individuell richtige Entscheing ja davon abhängt, ob das verstanden wurde, und da sind wir wieder oben. D. h., hat er es verstanden, sagt er ja, hat er es nicht verstanden, war das unser Erklärungsfehler, also zurück zu LOS, gehe nicht zur Schlossallee, erkläre neu.
Das kein Satz.
Der Zusammenhang zwischen der Nachvollziehbarkeit der Quelle einer Verbindung, welche dann eine Ermittlung gegen $Anschluss-Inhaber auslösen könnte, und HTTPS finde ich sehr spannend.
@pinky erläuchte uns!
1 „Gefällt mir“
war meihne Kuruzantwort auf die Annahme, dass ein Ausleiten Aufsteller abschrecken würde.
Wenn man darlegt, dass z.B. eine https-Verbindung sowieso nicht doppelt verschlüsselt wird und die Verbindungssicherheit das https ist, oder Videostreaming bei Yahoo ja auch über eine direkte server-client-Verbindung geht (wenn ich recht informiert bin), also auch Verschlüsseln unnötig ist, bzw. Vrschlüsselung sowieso erst ab den letztn Node (VPN) an Internetzugang greift, aber nicht vorher bei WLAN, und das alles nur gemacht wird, um evtl. gierigen Abmahnanwälten das Abmahnziel (= IP) vorzuenthalten, dann versteht der Aufsteller m.E. sehr schnell, dass eine Unterscheidung sinnvoll ist und alles, was für die Abmanschutzproblematik unrelevant ist, auch nicht extra verschlüsselt werden muss.
Also: es hängt davon ab, wie man das kommuniziert.
Zurück zum Topic bedeutet das, dass u.U. man eine Liste machen kann, derjenigen Services, die direkt ausleitbar sind, alles andere bleibt, wie es ist. Die müsste dann mit Erläuterungen veröffentlicht werden, von denen die diesen Weg gehen wollen. Wenn das per Node direkt gemacht werden kann, dann ggf. pro Node.
Transparenz und Verständlichkeit sind die Schlüsselwörter.
Edit
Identifikationsschutz bei z.B. Yahoo TV oder Online-Banking sind ja wohl sowieso das Aus für den User, weil er sich natürlich beim Banking oder beim Streaming identifizieren muss, um in den Account zu gelangen.
Wo sorgt HTTPs jetzt dafür, dass die Quelle einer Verbindung nicht nachvollziehbar ist?
andersrum: sie ist immer nachvollziehbar, wg. end to end
Soso, HTTPs macht also die Quelle einer Verbindung immer nachverfolgbar? 
/me deaktiviert dann mal SSL über das TOR-Netzwerk
3 „Gefällt mir“