Alle Pakete sind gleich - Ein technischer Blick auf das Thema Netzneutralität

Anders Henke

Alle Beiträge

Um in derartigen Situationen die "wichtigsten" und "dringendsten" Datenpakete weiterzuleiten, legte man sich in der frühen Zeit des Internet Protokolls IPv4 ein Bit-Feld für den Type of Service zurecht: die sendende Anwendung setzte in diesem Header vier Bits für die "Wichtigkeit" eines IP-Pakets und eines oder mehrere von drei weiteren Bits, um für dieses Paket eine möglichst geringe Latenz, einen möglichst hohen Durchsatz oder eine möglichst hohe Zuverlässigkeit zu gewährleisten. Die Idee dahinter: hat ein Router viel zu tun oder ist die Leitung "voll", kann er mit diesen Bits schnell entscheiden, welche Pakete er bevorzugt über welche seiner Peerings weiterleitet und welche Pakete er stattdessen zuerst wegwirft. Wenn dem Absender das Paket wichtig gewesen sein sollte, wird er es nach einem kurzen Timeout erneut verschicken.

In der Praxis hat die Idee von Type-of-Service ein Problem: das ToS-Feld muß nicht verpflichtend ausgewertet werden und kaum eine Anwendung setzt dieses Feld heute auf "sinnvoll", daher wird das ToS auch von vielen Routen nicht mehr beachtet. In den letzten 20 Jahren hat die Bandbreite zwischen den Providern so stark zugenommen, dass oft kein Bedarf dafür da war, Traffic gezielt zu bevorzugen oder andere Daten abzustrafen. In mehreren Ansätzen gab es immer wieder Versuche, das Type-of-Service-Feld oder ähnliche Techniken wieder aufleben zu lassen, in der Regel ohne spürbaren Nutzen und daher eher erfolglos. Die Einführung des ECN-Bitfeldes im Type-of-Service-Feld wurde z.B. zum Fehlschlag, da viele Firewalls diese ECN-Bits nicht kannten und Pakete mit gesetzten ECN-Bits als  "potentiell gefährlich" blockierten. Einige Internet Service Provider nutzten die Techniken um "Quality of Service" eher dazu, gezielt bestimmte Dienste wie z. B. Bittorrent abzustrafen.

Die Motivation für eine derartige Funktion ist aber immer wieder aktuell. Zwischen der Anbindung eines Internet Service Providers und dem heimischen DSL-Anschlusses gibt es zum Beispiel deutliche Unterschiede, und einige Details lassen einen gewissen Bedarf für die "Nicht-Abstrafung" bestimmter IP-Pakete aufkommen.

Über Peerings verbinden sich die Provider direkt oder an großen Austauschpunkten wie etwa dem DE-CIX miteinander, tauschen IP-Pakete aus und tragen in der Regel jeweils anteilig die Kosten für ihren Teil der "Leitung" und der Technik des Austauschpunkts. Die Grundidee beim Peering ist aber einfach: einer fordert Daten an und möchte sie haben, ein anderer möchte die Daten zuschicken. Zwischen den Providern besteht eigentlich gar kein Anlass dafür, IP-Pakete abzustrafen: je schneller ein IP-Paket das eigene Netz verlassen hat, umso weniger belastet dieses Paket die eigenen Router und Server.

Je weiter man mit anderen Peeringpartnern verbunden ist, umso engmaschiger ist man mit allen verbunden, und umso leistungsfähiger und stabiler ist auch das eigene Netz: in der Summe profitiert man durch diese Peerings.

In seltenen Fällen profitiert eine der beiden Parteien vom Peering stärker als die andere, dann zahlt eine Partei auch für die übertragenen oder empfangenen Daten. Die immer wiederkehrende allgemeine Forderung einiger Provider, sich die Kommunikation mit bestimmten Peers bezahlen zu lassen, ist aber aus Technikersicht nur schwer nachzuvollziehen.

Bei einem Internet Service Provider ist es beispielsweise üblich, dass Leitungen in Sende- und Empfangsrichtung identisch schnell und möglichst nicht dauerhaft hoch ausgelastet sein sollten, schon ab 40 bis 50 Prozent Auslastung plant man die Erweiterung der Uplinks. Ab etwa 70 bis 80 Prozent Auslastung treten teilweise sehr komplexe Überlastungsprobleme in Erscheinung, die sich dann aber auf beide Richtungen auswirken können.

Auch beim heimischen DSL-Anschluss können derartige Effekte auftreten: private DSL-Anschlüsse sind in der Regel in Sende- und Empfangsrichtung unterschiedlich schnell und viele Anwendungen versuchen, beide Richtungen möglichst "gut" zu füllen.

Eine einfache Form von Überlastungsproblemen kann zum Beispiel beim Download einer großen Datei auftreten: der Download wird in kleine Datenpakete zerteilt, jedes  empfangenen Datenpaket muß vom Empfänger bestätigt werden. Ist die Senderichtung aber bereits mit anderen Datenpaketen "voll", kommen diese Empfangsbestätigungen verspätet oder eben gar nicht an. Im Ergebnis wird das (große) Datenpaket vielleicht mehrfach verschickt und erst "irgendwann" bestätigt. Schickt man seine Uploads nicht mit maximaler Bandbreite, sondern etwa nur mit 80 Prozent der verfügbaren Bandbreite, verbleiben rund 20 Prozent für die Empfangsbestätigungen der Downloads, die Downloads werden so zuverlässiger bestätigt und schneller durchgeführt - das Problem ist behoben.

Wenn ein Provider also der Meinung ist, das Peering auf Gegenseitigkeit und damit einen wichtigen Teil der Netzneutralität aufheben zu müssen, hat er dafür eigentlich kaum einen Grund: wenn die Leitung durch einen anderen Peeringpartner "voll" ist, bemerkt auch der Peeringpartner Sättigungsprobleme und sollte selbst daran interessiert sein, seinen ausgehenden Datentransfer entsprechend zu senken.

Ein typischer Webserver wie de Apache belegt etwa initial rund 30 MB an RAM und 8 MB pro weiterer Verbindung, mit einem GB RAM kann man also rund 128 Download-Verbindungen halten. Webbrowser und Download-Beschleuniger öffnen hingegen oft 4 bis 8 Verbindungen parallel, um die Bestätigungspausen und Pausen kleiner Downloads besser zu nutzen und so ein wenig mehr an Leistung herauszukitzeln. Der Effekt bedeutet aber für den Content-Anbieter, dass er mit einem GB RAM statt 128 Usern nur 16-32 "Poweruser" parallel bedienen kann. Um mit wenig Arbeitsspeicher auszukommen, sollten die User daher den Content möglichst schnell erhalten.

Ist nun eine Peering-Leitung "voll", kann der Webserver diese Daten nicht ausliefern und muss länger warten. Gleichzeitig merken die User, dass die Downloads langsam sind und wechseln vermehrt auf "Download-Beschleuniger"-Software. Diese aber belegen noch mehr Webserver-Verbindungen beim Content-Anbieter, benötigen damit noch mehr RAM. Im Ergebnis beklagt der User die langsamen Downloads, der Access-Anbieter klagt über die vom Content-Anbieter gefüllte Leitung und der Content-Anbieter stellt mehr Server als nötig bereit, um die langsame Leitung kompensieren zu können. Auf technischer Ebene könnte nun der Content-Anbieter Trafficshaping einsetzen und so die Leitung weniger stark füllen; das bringt aber nur dem Access-Anbieter Entlastung, belastet weiterhin die Server und stellt  die User nicht zufrieden. Die typische Lösung für Provider an der Stelle ist: mehr Bandbreite zwischen Access- und Content-Anbieter schalten.

Der Access-Provider könnte auch den Content-Anbieter weiter entlasten und die User erfreuen, indem nicht nur die Bandbreite zum Content-Provider erhöht wird, sondern auch die Benutzer mit schnellerem DSL versorgt werden. An der Stelle kämen aber derart hohe Kosten auf, dass sich dies beim hohen Wettbewerbsdruck im DSL-Markt aber nicht mehr finanzieren ließe. Anscheinend versuchen sich nun einige Provider daran, an den Grundprinzipien des Netzes zu rütteln und möchten gerne die Content-Anbieter zur Kasse bitten, um darüber  die Gewinnmarge zu erhöhen, den Ausbau der eigenen DSL-Netze voranzutreiben oder aber einfach nur die Nutzung dieser Dienste unattraktiv zu machen. Einige Mobilfunkanbieter schließen die Nutzung von Internet-Telefonie mit Smartphones pauschal aus, selbst, wenn nur über WLAN und DSL-Anschluss telefoniert wird.

Das Problem der Sättigung tritt nicht nur beim Server, sondern auch beim DSL-Anschluss viel schneller ein, als man auf den ersten Blick vermutet. Bei der Internet-Telefonie etwa kann die Upstream-Bandbreite eines "kleinen" DSL-Anschlusses zu einem großen Teil durch ein Telefonat belegt werden.

Ich wohne z. B. in einem Wohngebiet mit langer Leitung zum DSLAM, habe daher nur 768 kbit Downstream an Bandbreite und 128 kbit Upstream. Mit Trafficshaping im DSL-Modem habe ich die Möglichkeit, beim Senden von Daten zwischen "wichtigen" und "weniger wichtigen" Datenströmen zu unterscheiden und entsprechend gezielt Pakete zu verzögern, so eine Anwendung auszubremsen und die andere Anwendung bei "normaler" Geschwindigkeit betreiben zu können.

Welche Daten wichtig sind, entscheidet sich oft sehr individuell, aber bei der Telefonie macht keiner Abstriche. Gäbe mein DSL-Modem nicht den IP-Paketen meines Telefongesprächs den Vorzug, so könnte allein der parallele Versand einer großen E-Mail das Verfahren für die Sprachkompression herunter regeln, meine Stimme klänge blechern und käme verzögert an. Beim Empfang von Daten hat mein DSL-Modem aber keine Kontrolle mehr. Habe ich parallel  mehrere große Downloads laufen, verzögert die "Gleichbehandlung" der Telefon-Pakete zu den Download-Paketen das Telefongespräch und ich höre meinen Gegenüber etwas zeitversetzt.

Könnte mein Gegenüber nun seine Pakete so markieren, dass sie gegenüber meinen Downloads bevorzugt werden, wäre das Telefongespräch besser. Andererseits könnte der Download-Server seine Pakete genauso markieren (und das als Feature ansehen). Im Ergebnis hätte ich wieder nichts gewonnen.

Auf der Ebene des Internet Protokolls allein kann ich das Problem aktuell also nicht lösen. Für IPv6 gibt es hier ein paar Ansätze, solange IPv4 und IPv6 aber parallel auf der gleichen Leitung betrieben werden, könnte eine volle IPv4-Verbindung in der Praxis die guten IPv6-Ansätze im Keim ersticken.

Beim Thema Telefonie sind diese Probleme (blecherne Stimme, verzögertes Gespräch, ggf. auch Hall) so groß, dass wir uns hier etwas ausdenken mussten: bei 1&1 Komplettanschlüssen konfigurieren wir auf ATM-Ebene eine zweite "virtuelle Leitung" mit 256 kbit garantierter Bandbreite. Auf diesem Kanal wird eine eigene Internet-Verbindung mit eigener IP-Adresse aufgebaut und ausschließlich für Internet-Telefonie genutzt.  Man kann das kritisch sehen, denn immerhin enthalten wir den Kunden jeweils 256 kbit an Bandbreite vor bzw. verwenden diese "nur" für Internet-Telefonie. Die Praxis hat aber gezeigt, daß wir um diese Maßnahme aktuell nicht herumkommen, wenn wir gleichzeitig hohe Qualität bei Telefonie und schnelle Downloads anbieten wollen.