Dann ist Kotzapp jetzt ja auch nicht mehr anonym weil es end to end ist
könnte sein, dass ich da was verwechselt habe, müsste noch mal die docs nachlesen, ist zu lange her dass ich mich damit beschäftigt habe.
also markier meinen Beitrag als Senf.
Ich finde Deine Einsicht super! Nicht falsch verstehen.
Spontan fällt mir dazu aber nur Folgendes ein:
stimmt, ist ja auch mein Spruch, nur, wenn man meint, Ahnung zu haben und dann was verwechselt, ist’s mit dem Fresse halten nichts, kann man ggf. nur ein Sorry ausdrücken. Passiert, wenn man älter wird und aus der Materie tageaktuell raus ist, wird Dir auch noch passieren
Müsst ihr eigentlich jeden Thread so lange derailen, bis irgendwer ihm zusperrt (weil ja Offtopics hier nicht mehr ausgelagert werden dürfen.)
OT, aber mittlerweile im dem Thread auch egal: Netflix betreibt sein eigenes CDN für die Datenauslieferung [1], »nur« das Ganze drumherum haben sie in die Amazon-Wolke gepackt.
root@bgp4:~# traceroute 8.8.8.8 ; ip route add 8.8.8.8 via 100.64.1.146 ; traceroute -s 185.66.193.67 8.8.8.8 ; ip route del 8.8.8.8 via 100.64.1.146
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 dorfl.uu.org (144.76.59.36) 0.092 ms * *
2 static.33.59.76.144.clients.your-server.de (144.76.59.33) 0.427 ms 0.403 ms 0.379 ms
3 core24.hetzner.de (213.239.229.61) 0.379 ms 0.373 ms 0.352 ms
4 core21.hetzner.de (213.239.203.177) 0.353 ms core1.hetzner.de (213.239.203.153) 4.950 ms 4.940 ms
5 de-cix20.net.google.com (80.81.193.108) 5.296 ms 5.296 ms core1.hetzner.de (213.239.245.218) 4.899 ms
6 216.239.56.110 (216.239.56.110) 5.729 ms google.fra.ecix.net (62.69.146.14) 5.576 ms 216.239.46.94 (216.239.46.94) 5.274 ms
[…]
12 google-public-dns-a.google.com (8.8.8.8) 13.910 ms 13.718 ms *
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 100.64.1.146 (100.64.1.146) 20.550 ms 20.527 ms 20.508 ms
2 google.ber.ecix.net (194.9.117.34) 89.921 ms 89.908 ms 89.891 ms
3 72.14.239.115 (72.14.239.115) 21.502 ms 72.14.234.227 (72.14.234.227) 21.270 ms 72.14.239.113 (72.14.239.113) 21.253 ms
4 google-public-dns-a.google.com (8.8.8.8) 21.189 ms 21.168 ms 21.146 ms
Kürzer ist nicht immer schneller, wobei ich zugebe, Falkenstein-Berlin ist sicher nicht ganz optimal, wenn man RTTs vergleichen will, müßte man FRA oder DUS nehmen, leider hat BGP bei uns BER ausgewählt (und einen FRA-Peer von FFRL habe ich nur in GUT).
Aber zurück zum Thema; das mit der besseren Performance über ein anderes Netz kenne ich schon lange, ich konnte zuhause jahelang wählen, ob ich direkt über mein T-VDSL25 gehe oder darüber über den Tunnel ins RZ. Und ja, YT war teilweise problemloser über den OpenVPN-Tunnel vom Telekom- ins Telefónica-Netz, was eben an den Netzübergängen liegt (YT <> Telekom: verstopft, YT <> Telefónica: frei). Insofern wäre eine lokale Ausleitung dann interessant, wenn es über den FFRL-Backbone zu bestimmten Zielen Probleme gäbe. Davon scheint man eher weit entfernt zu sei, siehe takts Ausführungen.
Aus meiner Sicht gibt es keine direkten Auswirkungen, fiele die Störerhaftung komplett. Wie an anderer Stelle schon ausgeführt wurde, seine Rechnerausstattung konfiziert zu sehen, weil über den eigenen DSL-Account KiPo transportiert wurde — das Risiko mag kaum einer tragen. Es wird absehbar immer sicherer sein, über einen Tunnel die Daten zu transportieren, als sie über den jeweiligen Zugang abzukippen.
Was mit in der Diskussion auch arg fehlt, ist der Netzgedanke. Klar, v4 & NAT ist mehr so ein Selbstgänger, aber wie wollt Ihr die (FVFN/FFRL/PI-) v6-Adressen lokal abwerfen? v6-NAT? Prefix-Translation?
Das Ziel muß sein, kleinteiligere, intelligente Netze zu bauen. Also solche, die selbst erkennen, daß hier ein zusammenhängendes Mesh besteht im Gegensatz zu Hotspots alle 2-3 km. IMHO. YMMV.
[1] Netflix Shifts Traffic To Its Own CDN; Akamai, Limelight Shrs Hit