Die Sache mit der Netzneutralität und den TCP/IP Stacks

Noch einige Ausführungen zu den Regeln des Internets. Die Erfinder des TCP/IP Protokolls haben die Regeln des Internets in den RFC so formuliert, das der Datenfluss in den Entstellen einer Verbindung reguliert werden. Wenn eine Verbindung belegt ist, dann werden die Datenpakete in eine Warteschlange gesteckt. Wird die Warteschlange zu lang, dann werden die Pakete vernichtet.

Der Empfänger stellt fest, das Ihm Pakete fehlen, und fordert diese vom Sender zur nochmaligen Aussendung an. Durch diese Transaktionen stellt der Sender im Normalfall fest, das er zu viele Daten sendet und verlangsamt die Aussendung, so lange bis keine Pakete verloren gehen. Dann beginnt er wieder sukzessive mehr Daten zu senden, und so entsteht ein Zyklus mit dem die Sendegeschwindigkeit so geregelt ist, das genau so viele Pakete gesendet werden, wie durch die engste Verbindung passen.

Wenn jetzt mehrere Nutzer eine TCP/IP Verbindung über einer Leitung haben, die voll ist, dann passiert in Normalfall das Folgende, das sich die Kapazität gleichmäßig auf die Nutzer verteilt. Werden also 130% der Kapazität einer Leitung angefragt, so erhält jede Verbindung 77% der angeforderten Kapazität.

Eine Möglichkeit sich gegenüber anderen Nutzer durchzusetzen ist, einfach viele Verbindungen zu benutzen. Anstatt eine 300 MB Datei mit einer einzigen langen http Transaktion zu laden, sind viele Anbieter dazu übergegangen, diese Datei in 60 Stücke a 5 Megabyte gleichzeitig zu laden. Möglich wird das durch eine Erweiterung des HTTP Protokoll von der Version 1.0 auf 1.1. die es ermöglicht, nur Teile einer Datei zu laden. Ursprünglich war diese Funktion dafür gedacht, damit zum Beispiel der Adobe pdf Viever schneller etwas anzeigen kann. Anstatt alles zu Laden, wird nur der Kopf geladen und dann die Daten der Seiten, die gerade anzuzeigen sind.

Mit dieser Technik kann sich ein Anbieter der Download Applikationen nutzt einen Vorteil erhaschen. Das führt zu einem regelrechten Rüstungswettlauf. Und die nächste Stufe des Rüstungswettlaufs ist schon passiert. Bestimmte Anbieter, wie zum Beispiel einzelne USENET Anbieter, senden bei jeder TCP/IP Verbindung mindestens 10% mehr Daten als möglich sind.

Ist die Enge Stelle die letzte Meile zum Kunden, dann sorgt das Verfahren dafür, das diese Leitung voll ausgeschöpft wird und alle anderen Anwendungen zurückgedrängt werden. Das wird in diesem Fall den Kunden wenig stören. Wenn jetzt aber die enge Stelle irgendwo anderes im Internet auftritt, dann wird der Anbieter mit dem veränderten TCP/IP Stack sich so viel herausnehmen, wie die Kapazität zu seinem Kunden ist. Der Grund dafür ist, das die 10% Überschusspakete bei den Anderen Verbindungen einen statistischen Überhang an Paketverlusten erzeugen, die dafür Sorgt, das die anderen Verbindungen so ab geregelt werden, das die sich Teilen was übrig bleibt.

Wenn jetzt die Drängler eine Leitung des Backbone Bereichs, also dort wo die Daten mehrerer Kunden transportiert werden, füllen, dann wird es richtig Kriminell. In dem Moment geht für die Normalen Kunden genau nichts mehr. Aus diesem Grund kann man als Internet Provider, wenn man nicht mit den Monsterkapazitäten der Glasfasern einsetzt, wo Daten verschiedener Kunden gemeinsam Transportiert werden, nicht die Packte alle gleich behandeln. Mann muss die Drängler dann in die Schranken weißen.

Das ist übrigens gar nicht so einfach. Mann hat als kleiner Provider in der Regel die Wahl zwischen einem Leistungsfähigen Volumenzugang, wo man pro GB zahlt, und für das gleiche Geld eine sehr begrenzte Flatrate mit Wiederverkaufserlaubnis. Die Drängler habe sich nun was cleveres einfallen lassen. Wird die Verbindung gedrosselt, so vergrößert sich der Überschussanteil, so das drosseln nicht wirtschaftlich ist - es sein denn man ist noch cleverer und drosselt den Upstream in Abhängigkeit des Downstreams.

Ganz besonderes problematisch ist die Drängelei für Internet Provider die wie ich mit WLAN arbeiten. Das Senderecht wird bei WLAN nach dem Motto wer zuerst kommt malt zuerst. Das Problem ist die Endlichkeit der Lichtgeschwindigkeit. Nährt sich ein WLAN seiner Kapazitätsgrenze dann wird die Funkdisziplin instabil, so das sich die Kapazität aufgrund von sich ändernden Parameter um System zur Vermeidung von Kollisionen verringert.

Könnte man Sagen, das ist eine Ausnahme ist? Nein! Dort wo dies keine Probleme macht, wenn ein Kunde über eine begrenzte einzel Verbindung wie DSL mit dem Glasfasernetz verbunden ist dessen Kapazität größer ist als die Summer der Kunden DSL Verbindungen, da wird es aber auch nicht gebraucht, weil es nichts zu drängeln gibt.

Anderes sieht das aus, wenn ein Kunde z.B. LTE hat oder über das TV-Kabel an das Internet angebunden ist. Dort wird mit der Drängelei Kunden aus dem Netz gedruckt, weil sich die Kunden einen Bandbreitenpool teilen. Wenn die Drängler mehr Kapazität brauchen wie das Netz hergibt, dann werden die anderen Kunden ganz aus dem Netz gedrückt. Insoweit ist Netzneutralität im sinne der Gleichbehandlung aller Pakete nicht mit einem guten Internet Produkt zu vereinbaren.

Nachtrag 20.02: Es ist nicht zu fassen, was Programmierer von Downloadprogramme alles Verbrechen. Heute komme ich ins Büro, das Netz hakt mal wieder. Wie sich herausstellt habe ich eine massiven Traffic auf Port 179. Dieser Port ist dem Protokoll BGP zugeordnet. Das BGP ist für den Austausch der Router im Internet zuständig, es Regelt wo welche Datenpakete hin geschickt werden. Fällt eine Leitung aus, so müssen sich die Router darüber unterhalten, wie das Internet weiter funktionieren kann. Und das, wenn die ausgefallene Verbindung ausgefallen ist, mit reduzierter Kapazität. Es ist deshalb logisch, das aus Stabilitätsgründen Pakete mit dem BGP Port mit Vorrang transportiert werden, damit zurück gestauter Verkehr nicht die Reorganisation behindert.

08:39:24.582950 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 116680:117704, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.589458 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 99510, win 64625, length 0
08:39:24.590138 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 101558, win 64625, length 0
08:39:24.598391 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 103606, win 64625, length 0
08:39:24.598914 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 105654, win 64625, length 0
08:39:24.599342 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 106754, win 63525, length 0
08:39:24.602237 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 112898:113922, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.602426 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 113922:114946, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.602588 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 114946:115970, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.602720 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 115970:116994, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.602854 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 116994:118018, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.602984 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 118018:119042, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.603114 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 119042:120066, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.603244 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 120066:121090, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.603372 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 121090:122114, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.610673 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 101587, win 64625, length 0
08:39:24.611100 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 103635, win 64625, length 0
08:39:24.611633 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 105340, win 64625, length 0
08:39:24.612104 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 122114:123138, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.612292 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 123138:124162, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.612455 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 124162:125186, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.612587 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [.], seq 125186:126210, ack 104, win 17388, length 1024: BGP, length: 1024
08:39:24.612718 IP 50.117.61.███.179 > 195.52.22.███.55001: Flags [P.], seq 126210:126887, ack 104, win 17388, length 677: BGP, length: 677
08:39:24.624283 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 117704:118728, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.624592 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 118728:119752, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.624730 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 119752:120776, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.624891 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 120776:121800, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.625025 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 121800:122824, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.625156 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 122824:123848, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.625285 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 123848:124872, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.625895 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 108802, win 64625, length 0
08:39:24.626619 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 110850, win 64625, length 0
08:39:24.640618 IP 195.52.22.███.55001 > 50.117.61.███.179: Flags [.], ack 112898, win 64625, length 0
08:39:24.641201 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 107388, win 64625, length 0
08:39:24.641603 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 109436, win 64625, length 0
08:39:24.657866 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 111484, win 64625, length 0
08:39:24.658369 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 112584, win 63525, length 0
08:39:24.659365 IP 195.52.22.███.55096 > 50.117.61.███.179: Flags [.], ack 114632, win 64625, length 0
08:39:24.670964 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 124872:125896, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.671149 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 125896:126920, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.671312 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 126920:127944, ack 136, win 12328, length 1024: BGP, length: 1024
08:39:24.671443 IP 50.117.61.███.179 > 195.52.22.███.55096: Flags [.], seq 127944:128968, ack 136, win 12328, length 1024: BGP, length: 1024

Diesen Port mit Gigabyte Content zuzumüllen ist ein direktes Verbrechen an der Stabilität des Internets. Ich habe deshalb den Zugriff auf diesen Port erst mal für alle Kunden gesperrt. Die Vorgehensweise des Anbiehters ist echt schräg, zumal seine Kunden gar nicht wissen was sie da anrichten. Für den Kunden sieht das so aus, wie bei jeder anderen Installation. Ein Download einer kleineren exe, einmal den Start der Exe abnicken und dann dürfte ein Fenster aufgehen mit einem Zeitbalken. Das es ein Programm ist konnte ich daran erkennen, das dieses Flux auf einen anderen heiklen Port ausgewichen ist.

09:13:35.923268 IP 195.52.22.███.55546 > 216.172.135.██.105: Flags [.], ack 126836, win 64625, length 0
09:13:35.939109 IP 216.172.135.██.105 > 195.52.22.███.55546: Flags [.], seq 129908:130932, ack 137, win 13400, length 1024
09:13:35.939330 IP 216.172.135.██.105 > 195.52.22.███.55546: Flags [.], seq 130932:131956, ack 137, win 13400, length 1024
09:13:35.939471 IP 216.172.135.██.105 > 195.52.22.███.55546: Flags [P.], seq 131956:132693, ack 137, win 13400, length 737
09:13:35.956813 IP 195.52.22.███.55546 > 216.172.135.██.105: Flags [.], ack 128884, win 64625, length 0
09:13:35.957423 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [P.], seq 104:138, ack 123824, win 64625, length 34
09:13:35.966804 IP 195.52.22.███.55546 > 216.172.135.██.105: Flags [.], ack 130932, win 64625, length 0
09:13:36.014013 IP 195.52.22.███.55546 > 216.172.135.██.105: Flags [.], ack 132693, win 64625, length 0
09:13:36.068485 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 123824:124848, ack 138, win 12328, length 1024
09:13:36.068671 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 124848:125872, ack 138, win 12328, length 1024
09:13:36.068833 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 125872:126896, ack 138, win 12328, length 1024
09:13:36.068967 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 126896:127920, ack 138, win 12328, length 1024
09:13:36.069097 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 127920:128944, ack 138, win 12328, length 1024
09:13:36.069226 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [P.], seq 128944:129625, ack 138, win 12328, length 681
09:13:36.069526 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 129625:130649, ack 138, win 12328, length 1024
09:13:36.069672 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [P.], seq 130649:131077, ack 138, win 12328, length 428
09:13:36.087560 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 125872, win 64625, length 0
09:13:36.098012 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 127920, win 64625, length 0
09:13:36.111775 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 129625, win 64625, length 0
09:13:36.112328 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 131077, win 64625, length 0
09:13:36.145330 IP 195.52.22.███.55549 > 216.172.135.██.105: Flags [P.], seq 103:137, ack 132692, win 63880, length 34
09:13:36.190935 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 131077:132101, ack 138, win 12328, length 1024
09:13:36.191132 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 132101:133125, ack 138, win 12328, length 1024
09:13:36.191272 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 133125:134149, ack 138, win 12328, length 1024
09:13:36.191407 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 134149:135173, ack 138, win 12328, length 1024
09:13:36.191535 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 135173:136197, ack 138, win 12328, length 1024
09:13:36.207768 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 133125, win 64625, length 0
09:13:36.215088 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 136197:137221, ack 138, win 12328, length 1024
09:13:36.215373 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 137221:138245, ack 138, win 12328, length 1024
09:13:36.215519 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 138245:139269, ack 138, win 12328, length 1024
09:13:36.215681 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 139269:140293, ack 138, win 12328, length 1024
09:13:36.215812 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 140293:141317, ack 138, win 12328, length 1024
09:13:36.215941 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 141317:142341, ack 138, win 12328, length 1024
09:13:36.240768 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 135173, win 64625, length 0
09:13:36.250906 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 137221, win 64625, length 0
09:13:36.251443 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 139269, win 64625, length 0
09:13:36.251865 IP 195.52.22.███.55550 > 216.172.135.██.105: Flags [.], ack 141317, win 64625, length 0
09:13:36.257245 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [.], seq 132692:133716, ack 137, win 12328, length 1024
09:13:36.257435 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [.], seq 133716:134740, ack 137, win 12328, length 1024
09:13:36.257596 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [.], seq 134740:135764, ack 137, win 12328, length 1024
09:13:36.257729 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [.], seq 135764:136788, ack 137, win 12328, length 1024
09:13:36.257860 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [.], seq 136788:137812, ack 137, win 12328, length 1024
09:13:36.257989 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [P.], seq 137812:138493, ack 137, win 12328, length 681
09:13:36.258114 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [.], seq 138493:139517, ack 137, win 12328, length 1024
09:13:36.258243 IP 216.172.135.██.105 > 195.52.22.███.55549: Flags [P.], seq 139517:139945, ack 137, win 12328, length 428
09:13:36.274564 IP 195.52.22.███.55549 > 216.172.135.██.105: Flags [.], ack 134740, win 64625, length 0
09:13:36.312257 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 142341:143365, ack 138, win 12328, length 1024
09:13:36.312498 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 143365:144389, ack 138, win 12328, length 1024
09:13:36.312639 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 144389:145413, ack 138, win 12328, length 1024
09:13:36.312797 IP 216.172.135.██.105 > 195.52.22.███.55550: Flags [.], seq 145413:146437, ack 138, win 12328, length 1024

Der Port 105 gehört zum csnet-ns Mailbox Name Nameserver Protokoll. Da dieses auch Zugriffe im Internet steuert, kann man annehmen, das es auch schnell transportiert wird. Aber immerhin ist das nicht ganz so super kritisch wie sich auf den BGB Port zu klinken.