Der unsachgemäße Umgang mit Fragen der Netzneutralität ...

Zur Zeit wird auf EU Ebene eine Gesetz verhandelt, in dem es darum geht, das regeln soll wie in Zukunft die Geschäftsmodelle rund um das Internet aussehen sollen. Das dabei extrem viel Mist erzählt wird, zeigt eine Video eines Piraten



Aber das ist nur die Halbe Wahrheit. Denn ich bin selber Internetanbieter. Ich betreibe eine Kleines WLAN das einen Stadtteil mit breitbandigen Internet versorgt. Erstanden ist dieses Netz im September 2001 weil ich mit die Kosten meinens Monopolübertragungsweges nicht mehr leisten konnte und wollte, und so habe ich einen Großteil der Entwicklung des Internets an vorderster Front mitbekommen.

Das Internet und seine Anwendungen waren in der Vergangenheit immer auch eine Maximal effektive Ausnutzung knapper Ressourcen hin ausgelegt. Es haben auch immer alle Mitgemacht, weil sich Anbieter und Konsumenten die Kosten für das Internet geteilt haben. Jeder bezahlte den Teil des Weges bis zum Austauschpunkt, an dem die Daten von einem Anbieter zum nächsten weitergeben werden. So hatte jeder einen Ansporn zu sorgfältigem Umgang mit den Ressourcen.

Das hat sich aber im Laufe der Jahre extrem gewandelt. Anbieter - bezogen auf das Verkehrsaufkommen - gibt es kaum noch. Das sind im Wesentlichen die Großen Konzerne wie Apple, Microsoft, Google, Facebook, ... sowie die Medienanstalten, öffentlich Rechtliche wie Private. Diese haben längst Standleitungen zu den Austauschpunkten, sind also wenn man so will ihr eigener Internetprovider. Die Leistungsfähigkeit der Glaskabel und der dazugehörigen Router ist in den letzten Jahren so explodiert, das die Kosten für sehr viel mehr Verkehr verschwindend gering sind gegenüber denen, die nötig sind die Effizienz der Dienste zu verbessern. Sehr schön lässt sich das im Videobereich belegen, bei dem eben nicht versucht wird, das Optimum an Kompression aus den Vorhandenen Codecs herauszuholen oder sogar auf neue Entwicklungen zurückzugreifen, welche mit nur einem Bruchteil der Übertragenen Daten das gleiche erreichen.

Und genau an dieser Stelle muss ... soll sinnvolles Wirtschaften für Internetprovider überhaupt noch möglich sein, dieses ein Mittel an die Hand gegeben werden, mit dem sie auf Anbieter einwirken können, eben doch Geld in die Hand zu nehmen, um die Effizienz ihrer Systeme zu Steigern. Diese Effizienz kann zum Beispiel in der Cachebarkeit der Daten liegen. Konnte ich am Anfang meiner Tätigkeit als ISP noch über 80% des Traffic aus dem Proxy Cache bestreiten, sind es heute nicht mal 20% Prozent. Das ist ganz wesentlich vier Entwicklungen geschuldet:

1. Durch den Fortwährenden Spionageterror durch die NSA gehen immer mehr Anbieter dazu über, Software per https:// zu verteilen. Dabei nutzt das nichts, weil sich aus IP und der Menge der übertragenen Daten welche vom https nicht geschützt ist, sich schon eindeutig Festellen lässt wer welchen öffentlich zugänglichen Inhalt heruntergeladen hat. Neben dem Vermeidlich Vorteil der Verschlüsselung erspart es den Anbieter aber auch den Aufwand, die Integrität der Übertragung gesondert zu überprüfen ... verhindert aber das Caching.
   
   Microsoft - hier muss ich sie mal ausnahmsweise und auch noch öffentlich lobend erwähnen - hat deshalb eine Initiative gestartet für ein httpi:///, das die Integrität der Übertragung sichert aber Caching zulässt. Nur Leider ist Verschlüsselung durch in die Prozessoren eingelassene Hardware so billig geworden und so viele Kunden bei Ex Monopolanbieter, das dieses keine Resonanz gefunden hat.
2. Durch die super idiotische Vorgabe der EU, das Benutzer vom Inhalteanbieter über das Setzen von Cookies zu Informieren sind, sind viele Anbieter denen die EU aus welchen gründen auch immer nicht Arsch vorbeigeht um die Benutzer nicht mit Blödsinnigen Juristensültz zu vergraulen dazu übergegangen, ihre Angebote so zu erstellen, das es sie im Internet unendlich oft gibt. Wo es früher http://server.domain.de/path/file.xxx gab wird der Webserver so Programmiert das er auf http://server.domain.de/besuchernummer/path/file.xxx weiterleitet, und jeder Besucher so seine eigene Kopie des Content vorgesetzt bekommt. Damit ist aber die Cachebarkeit beim Teufel, weil das ist nicht Standardisiert ist.
   
   Die Behandlung der Cookies ist Sache der Software. Dummerweise wenn man wie ich z.B. eine Funktion Nutzt alle Cookies am ende einer Session zu entsorgen, dann wird man bei vielen Anbieter jedes mal mit dem Jurasülz der Hausjuristen dieser Anbieter belästigt. Die Technologie jedem Besucher seine eigene Suppe zu kochen ist auch in sofern ein Problem, als das dann die Einheitlichkeit des web nicht mehr gegeben sein muss. Wer sagt denn, das sich die Inhalte nur in den Besuchernummern in den internen Links unterschieden? Das könnten zum Beispiel für IP aus Muslimischen Ländern bestimmte Dinge im Wege der Sebstzensur entsorgt werden (Alkohol, Schinken, ...) und vieles andere Mehr.
3. Die Ideologische Ablehnung von jeder Form der Kopie die kein Geld in die Kasse bringt seitens der Content Industrie. Ausnahmslos alle bezahl Video on Demand Dienste Senden Ihr Material so, das es nirgendwo gecached wird, nicht mal im Endgerät. Jeder Schnippsel wie eine DNS Anfrage wird aus Traditionellen gründen lokal gecached ... was auch Probleme macht weil immer wieder Regierungen versuchen diese Caches wenn möglich manipulieren zu lassen ... nur die HD und 4kHD Videos sollen bei jedem Ansehen in epischer Breite durch das Netz geprügelt werden? Dazu werden dann proprietäre Protokolle verwendet, die obendrein noch verschlüsselt sind.
   
   Würde ein Film verschlüsselt an einer Stelle publiziert, und die Lizenznehmer alle auf diese url Bezug nehmen und nur noch ihren Schlüssel zum Entschlüsseln des Materials individuell verschlüsselt übertragen ... so wie es auf der Blu Ray Disk gemacht wird ... könnten sehr wohl die Interessen der Content Anbieter mit denen der ISP in Einklang gebracht werden. Da aber Filmbosse bei dem Wort Kopie Pickel am Gesäß bekommen, bedarf es hier eine über den §§44a UHRG hinausgehende Hilfestellung durch den Gesetzgeber.
4. Ideal für die Verbreitung von Videos wäre, wenn es einen optimalen Videostandart gäbe. Optimaler weiße sollte der sogar so aufgebaut sein, das es für die Unterschiedlichen Qualitäten eine Basisdatei und weitere zur Stufenweise Erhöhung der Auflösung geben sollte. Praktisch würde das dann so aussehen, das bei begrenzter Kapazität Filme um so genauer Aufgelöst wird, je öfters er angesehen wird, weil sich immer mehr Stufen auf der Leiter zu höheren Auflösungen im Cache sind. Bedingt durch Pantentzickereien zwischen den Großen Anbietern sieht die Realität ganz anderes aus. Im Gegensatz zu Bildern braucht man so ziemlich für jedes Gerät eine Eigne Version des an sich gleichen Inhalts. Auch ein eklatanter Missstand!
   

Ein weiteres Wesentliches Problem der Netzneutralität ist die Verträglichkeit der Anwendungen. Auch hier gibt es Leute, die nichts von Netzneutralität halten und versuchen mit allerlei Tricks sich einen Vorteil zu verschaffen. Wird kein weiteres Management wie das statistical Fair queing getroffen, so ist die Einfachste alle Masnamen, in einem Programm einfach 100 TCP/IP Parallel zu öffnen. Dann bekommt an in einem Nadelöhr eben auch 100 Anteile anstatt nur einen. Noch sehr viel effektiver ist es, einen speziellen modifizierten TCP/IP Stack zu benutzen, der mittels zusätzlicher Forward Error Correction einzelne Pakete ohne sie erneut Anzufordern Rekonstruieren kann. Da dieser mit Paket Verlust leben kann, kann er die anderen Rausdrücken. Als Beispiel für eine gelungene Vordrängelimplementierung kann die Downloadplattform Steam betrachtet werden. Ein Netz in dem ein Download mit Steam läuft, ist für die anderen Nutzer tot.

Folglich muss ein Provider der wie ich auf Einheitlichen Verbindungen beruht, den Zugang einzelner Benutzer zu den Ressourcen künstlich sehr weit verringern, damit an jeder Verzweigung kein "Kanal voll mit Steamdaten" auftreten kann. Schade, denn wenn das Netz zum Beispiel Nachts leer ist könnte ein Benutzer auch mit allen Ressourcen beglückt werden. Das setzt aber im Interesse der anderen Nutzer aus, das Ego-Anwendungen wie Steam auf ein Sozial verträgliches Maß gedrosselt werden können.

Noch ein paar Worte zu dem Arzt der eine Fern-Op macht. Da wird man hoffentlich Mietleitungen verwenden. Aber ich hatte einen Arzt als Kunden, der Radiologe ist. Der hatte Bereitschaftsdienste, die er per Remote Desktop Anwendung gemacht hat. Diese Anwendung reagiert ziemlich schlecht auf Überlastungen im Netz. Für ihn war es in die der Beurteilung wichtig, einen Ebene des CT durch den Körper bewegen zu könne. Da aber kein video Runtergeladen wurde sondern dieses nur per Remote Desktop gemacht wurde, ging das nur bei relativ leerem Netz. Es kam also vor, das er wegen großem Datenverkehrsaufkommen in die Klinik fahren musste, und das kann unter extrem unglücklichen Umständen Tatsächlich zum Tod eines Patienten führen. Er ist dann auch - sobald das möglich war - vermutlich zu LTE at Home umgestiegen, die einen Vorrangtransport machen können. Und jeden Arzt der Bereitschaftsdienst hat mit einer Standleitung auszustatten, das können sich die Kliniken nicht Leisten. Netzneutralität erfordert auch eine gewisse Disziplin bei der Erstellung von Software, so das diese mit Kapazitätsengpässen adäquat umgeht.

Es wäre sehr wünschenswert, wenn administrative Maßnahmen dazu führen würden, das Content wieder mehr Cachebar ist. Mit Satelliten kann man einen sehr schnellen Zugang zum Internet herstellen, der auch jeden Winkel abdeckt. Aber das setzt voraus, das großer und beliebter Content per Multicast an Tochter Proxy verteil wird. So funktioniert sky Video on Demand. Ansonsten muss das Kontingent streng rationiert werden. Wer sein X-GB verballert hat, kriecht den Rest des Monats. Und Videoanwendungen die wenn möglich Full oder 4K HD senden, saugen so ein Kontingent binnen Minuten Leer. Da ist manch einer froh um ein automatisches Management, das solche Anwendungen zur Sparsamkeit anhält. Im LTE Steigen die maximalen Datenraten sehr viel schneller an als es die Gesamtübertragungskapazität in der Funkzelle tut. Sollen diese Netze nicht hoffnungslos verstopfen, muss es auch zu einer Verbreitung von häufig nachgefragten Content in die Caches der Geräte kommen. Dafür eignen sich ... das beweist dbv-t jeden Tag, die terrestrischen TV-Frequenzen besonderes gut.

Zum Schluss möchte ich noch auch die Cloud Backup und Sync Services eingehen. Android zum Beispiel: Backup zu Google, Sync über Google. Überall ist automatisch NSA und FISA mit drin. Hier muss eine Gesetzliche Reglung her, die es dem Kunden ermöglicht lokales Equipment zu nutzen. Sei es eine FTP-NAS in der einen Wohnung (z.B. Friz-Box) oder sei es ein lokaler Speicher mit Profi Raid beim lokalen ISP-Knoten. Je näher der Speicher am Kunden dran ist, desto besser, werden doch bei einem Recover binnen kurzer Zeit Tausende Giga Byte an Traffic gebraucht.

Nachtrag 22.05: Unfassbar wie mache Inhalte Anbieter mit den Ressourcen eines Netzwerks Umgehen. Blizzard.com hat die Unverschämtheit, im ms Sekundentakt neue Verbindungen auf zumachen um dann grosse Dateien in ungefähr KB großen Happen zu holen. So kann man jeden Proxyserver zu lasten aller anderen Nutzer blockieren.

Ich habe auch schon Transfers auf Port 179 - das ist der des BGP mit dem das Internet gesteuert wird - gesehen. Netneutralität kann es nicht ohnne strege Regulierung für Downloadprogramme geben, denn ohne müsse ISP solche Penner bremsen können.

1432229171.458     55 172.16.20.165 TCP_MISS/206 1127 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.252     18 172.16.20.165 TCP_MISS/206 1129 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.253     18 172.16.20.165 TCP_MISS/206 1285 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.303     51 172.16.20.165 TCP_MISS/206 1285 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.308     55 172.16.20.165 TCP_MISS/206 1129 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.353     49 172.16.20.165 TCP_MISS/206 1285 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.486     12 172.16.20.165 TCP_MISS/206 1315 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.492     15 172.16.20.165 TCP_MISS/206 4544 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.543     50 172.16.20.165 TCP_MISS/206 1145 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.283     16 172.16.20.165 TCP_MISS/206 1287 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.290     23 172.16.20.165 TCP_MISS/206 1800 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.347     63 172.16.20.165 TCP_MISS/206 3836 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.347     57 172.16.20.165 TCP_MISS/206 3097 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.397     49 172.16.20.165 TCP_MISS/206 1131 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.645     14 172.16.20.165 TCP_MISS/206 7159 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.650     13 172.16.20.165 TCP_MISS/206 4524 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream