Das Fairness-Bit

P2P-Filesharern wird oft vorgeworfen, Bandbreite zu Lasten anderer Nutzer an sich zu reißen. In der IETF diskutieren Entwickler eine Ergänzung zum Transmission Control Protocol, mit der sich die Übertragungskapazität gerechter verteilen ließe.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 12 Min.
Von
  • Richard Sietmann
Inhaltsverzeichnis

Der große Vorteil der paketvermittelten Übertragung ist die effiziente Nutzung der Leitungskapazität, die sich mehrere Teilnehmer durch die Verschachtelung ihrer Datenströme teilen können; darüber hinaus hat das Internet noch den großen Vorteil, dass der tatsächliche Anteil an Übertragungskapazität vom Sender zum Empfänger nicht vom Netzbetreiber zugeteilt wird, sondern die Endgeräte durch einen in das Transmission Control Protocol (TCP) eingebauten Algorithmus ihre Datenraten dynamisch an die Netzauslastung anpassen. Dieses in Software gegossene Kooperationsverhalten ist ein Ergebnis der ersten Krise des Internet, als 1986 und 1987 der Verkehr mehrmals zusammenbrach. Die damalige TCP-Version (RFC 793) hatte verloren gegangene Pakete einfach noch einmal gesendet, wenn das Acknowledgement (ACK) als Empfangsbestätigung ausblieb – mit der Konsequenz, dass sich Staus nun erst richtig aufschaukelten und der Durchsatz nur noch tröpfelte, weil der gesamte Verkehr nahezu völlig aus Retransmissions bestand.

Bei ECN erfährt ein Netzknoten von Verstopfungen durch die im Upstream überlasteten Router. Bei re-ECN gibt der Sender diese Information ins Netz zurück.

Abhilfe brachte ein 1987 von Van Jacobson entwickelter adaptiver Algorithmus, mit dem TCP die Übertragungsrate kontinuierlich so lange erhöht, bis irgendwo auf dem Weg zum Empfänger Pakete verloren gehen (RFC 2581). Sobald die ersten Acknowledgements auf einen Paketverlust schließen lassen, gilt dies als Anzeichen für Verstopfung, und darauf reagiert das Protokoll umgehend mit der Halbierung der Bitrate. Nach diesem Prinzip – freie Kapazität nutzen, aber zurücktreten, wenn andere Nutzer ebenfalls Kapazität benötigen – arbeiten seither viele hundert Millionen Hosts weltweit.

Jacobsons Patch fügte sich nahtlos in die Design-Prinzipien des Internet: Die Steuerung des Verkehrsaufkommens findet dank TCP in den Endgeräten statt, während die IP-Router im Netz die Pakete ohne Ansehen des Inhalts umdirigieren und weiterleiten. Doch diese „end to end“-Philosophie (e2e) ist heute bedroht. Denn wenn ein Anwendungsprogramm mehrere TCP-Verbindungen gleichzeitig aufmachen kann, wie das beim P2P-Filesharing regelmäßig der Fall ist, hat es jeder Endnutzer in der Hand, seinen Anteil an der Übertragungskapazität zu Lasten der anderen zu vervielfachen – im Fall von Staus wird jeder Flow von den Routern gleich behandelt.

Für Provider haben sich die Filesharer schon zu einem Feindbild entwickelt, weil die schwergewichtigen P2P-Anwendungen und Video-Downloads die Leistungsfähigkeit des Netzes mindern und damit andere Kunden verprellen könnten. Vielfach gehen sie dagegen vor, indem sie durch „Deep Packet Inspection“ (DPI) die Zahl der vom User gleichzeitig geöffneten TCP-Ports ermitteln und begrenzen, die Bandbreite der „heavy user“ zu Spitzenzeiten gezielt drosseln – faktisch also einzelne Nutzer gezielt diskriminieren – oder pauschal das monatliche Download-Volumen für alle Nutzer beschränken.

Das Problem bei Verstopfungen im Internet seien nicht die Peer-to-Peer-Protokolle, sondern die TCP-Zuteilungsregeln, meint Bob Briscoe von BT.

Doch was im Internet wirklich zählt, ist nicht, wie viele Gigabyte man herunterlädt, sondern wieviel man herunterlädt, während gleichzeitig alle anderen dasselbe versuchen. „Das Problem sind nicht die Peer-to-Peer-Protokolle; es sind die TCP-Zuteilungsregeln“, meint Bob Briscoe, Forschungsdirektor im Innovationszentrum Adastral Park von BT in Martlesham Heath bei Ipswich. „Fairness sollte man als Beziehung zwischen Menschen definieren, nicht zwischen Data Flows.“ Er hat in der Internet Engineering Task Force (IETF) eine Ergänzung des TCP zur Diskussion gestellt [1], die seiner Ansicht nach die durch willkürliche Eingriffe der Netzbetreiber in den Datenverkehr der Kunden gefährdete e2e-Architektur des Internet bewahren könnte.

Der Vorschlag beruht im Wesentlichen auf zwei Gedanken: * Der Endnutzer nimmt eine Gewichtung seiner TCP-Transportströme vor, sodass wichtige Datentransfers in Engpässen einen höheren Anteil der Bandbreite erhalten; * die Provider könnten dann mit geeigneten Anreizmodellen – etwa in Gestalt einer belastungsabhängigen Preisdifferenzierung („Congestion Charging“) – dafür sorgen, dass nicht alle Nutzer allen ihren Datenströmen die höchste Priorität geben.

Das Verfahren würde das bisherige Verwerfen von Paketen in überlasteten Routern durch einen geregelten Lastabwurf ersetzen. Dazu stützt es sich im Prinzip auf ein System mit Bonus- und Malus-Punkten: Der Sender muss dem Datenstrom ausreichend Bonuspunkte mitgeben, wenn er ihn trotz absehbarer Staus downstream durch den Flaschenhals zwängen will. Auf dem Wege zum Empfänger kann jeder Netzknoten bei drohender Überlastung eintreffende IP-Pakete verwerfen, sofern er in dem Fluss nicht genügend Bonuspunkte detektiert, sowie Maluspunkte vergeben, indem er die ausgehenden Pakete entsprechend markiert. Neutrale nicht markierte Pakete unterliegen dem bisherigen Regime.

Damit der Sender überhaupt auf Engpässe downstream reagieren kann, muss er davon wissen. Deshalb informiert ihn der Empfänger mittels einer Feedback-Schleife über die mit einem Stauvermerk erhaltenen Pakete. Je nachdem, ob er nun den weiteren Datenfluss mit „Bonuspunkten“ versieht oder nicht, können nun die Edge-Router der Zugangs-Provider wie auch jeder andere Netzknoten unterwegs die Zustellung der Pakete aufrechterhalten oder die Mechanismen zum Lastabwurf greifen lassen. So bliebe das Staumanagement transparent und im Rahmen der Priorisierung würden alle Datenströme ungeachtet des Typus im Netz gleich behandelt. Die Priorisierung nimmt der Endnutzer vor – dies natürlich im Wechselspiel mit den Tarifmodellen oder Anreizmechanismen des Zugangs-Providers, doch das Verfahren bietet beiden Parteien mehr Flexibilität als starr vorgegebene Volumenbegrenzungen oder einseitiges Traffic Shaping des Providers.

Das weithin umstrittene „Congestion Charging“ müsste jedenfalls nicht zwangsläufig zur lastabhängigen dynamischen Tarifierung führen, es könnte auch innerhalb eines Flatrate-Tarifs erfolgen, betont Briscoe. Zu jeder Flatrate könnte etwa ein monatliches Guthaben an Bonuspunkten gehören; erst wenn es ausgeschöpft ist, würden in Spitzenzeiten die P2P-Flüsse ausgebremst werden – und das ohne DPI, also ohne Ansehen des Inhalts. „Ein Stau lässt sich neutral behandeln, BitTorrent nicht“, unterstreicht der BT-Forscher. Er ist überzeugt, dass Filesharer von dieser Art der Verkehrsregulierung kaum etwas merken und Video-Downloads kaum länger dauern würden als heute. Natürlich eröffneten sich auch den Providern neue Freiheitsgrade in der Gestaltung ihrer Tarifmodelle. Denkbar sei etwa, dass Serverfarmen oder Heavy User Quoten hinzukaufen, während Gelegenheitssurfer bei Verzicht auf die Bonuspunkte die Flatrate günstiger angeboten bekommen. Aber man sollte tätig werden, bevor die Netzbetreiber die dynamische Belastungstarifierung mit proprietären Techniken einführen und die Neutralität gegenüber dem Typus der Datenflüsse weiter untergraben.

Im Detail sei Briscoes Vorschlag „eine ziemlich komplizierte Sache“, mit der selbst viele in der IETF Schwierigkeiten hätten, meint Michael Welzl, Associate Professor für Netze und verteilte Systeme an der Universität Oslo und Vorsitzender der Internet Congestion Control Research Group im Forschungszweig der IETF. Dabei sei die Grundidee recht einfach. „Der Sender erhält ein Feedback über den Stau, den er verursacht hat und gibt diesen Feedback wieder ins Netz hinein, sodass ein Upstream-Router über den Stau, der weiter downstream entstehen wird, schon Bescheid weiß.“ Dieser Mechanismus des „re-inserted feedback of Explicit Congestion Notification“ (re-ECN), nach dem das Verfahren benannt ist, sei „der Schlüssel zu dem gesamten Mehrwert“.

Mit der Rückkoppelung des Empfänger-Feedbacks über Stauprobleme in das Netz überwindet re-ECN ein Manko, das die letzte Erweiterung von TCP zur Verbesserung der Überlastregelung noch enthält. Im Jahr 2001 hatte die IETF in RFC 3168 die „Explicit Congestion Notification“ (ECN) als e2e-Vorwarnung über sich abzeichnende Staus definiert. Danach setzen ECN-aktivierte Router, wenn sich ein Link der Belastungsgrenze nähert, und noch bevor sie anfangen, Pakete tatsächlich zu verwerfen, ein bestimmtes Bit in den IP-Paketheadern, um im Downstream die heraufziehende Überlastung zu signalisieren. Der Endhost teilt dann per TCP/ACK die erhaltene Stauwarnung dem Sender mit; darauf reagiert dieser genauso wie nach dem alten Verfahren bei einem festgestellten Paketverlust, nämlich mit der Halbierung der Übertragungsrate.

Dabei erfahren die Netzknoten von der Stausituation, wie sie der Empfänger wahrnimmt, jedoch nichts; der sendende Host behält sein Wissen quasi für sich. ECN verwendet zwei freie Bits im TOS-Feld der IPv4-Header, wobei das erste anzeigt, ob ECN aktiviert ist oder nicht, während die eigentliche Stauwarnung in dem zweiten, dem sogenannten CE-Bit steckt („Congestion Experienced“); auf dem Rückkanal nutzt ECN zwei reservierte Bit in den TCP-Headern. In der Praxis hat sich die Protokollerweiterung jedoch bisher nicht durchgesetzt. Sie kommt nur zum Tragen, wenn beide Endgeräte das „ECT“-Bit gesetzt haben (ECN-Capable Transport), doch obwohl die meisten aktuellen Betriebssysteme ECN implementiert haben, ist es in der Regel nicht als Grundeinstellung aktiviert.

Briscoes re-ECN baut auf der ECN-Überlastsignalisierung auf, indem es das letzte noch nicht festgelegte Bit in den IPv4-Headern in Verbindung mit dem CE-Bit nutzt. Wie bei ECN markiert und zeigt ein Router downstream die Überlastung über das gesetzte CE-Bit an, durch das er einen Teil der transferierten Pakete quasi negativ markiert. Der Empfänger misst den Anteil der negativ deklarierten Pakete und teilt diesen Messwert über einen Feedback-Kanal, zum Beispiel per TCP/ACK, dem Sender mit. Dieser kann die Information jetzt in dem gesendeten Datenfluss nutzen, um mit dem vorgesehenen Header-Bit denselben Anteil von Paketen „positiv“ zu markieren. Der Flow enthält nun eine Information darüber, mit welcher Netzbelastung er es auf seinem Weg durch das Internet zu tun haben wird.

Im Unterschied zu ECN – bei dem ein Netzknoten die eigene Überlastung zwar den nachfolgenden Knoten mitteilt, ihm selbst jedoch stromabwärts auftretende Engpässe verborgen bleiben – erhalten die Netzknoten bei re-ECN dank des rückgekoppelten Feedback auch Informationen über Staugefahren im Downstream-Path. Denn ein Router irgendwo auf diesem Pfad, der den Anteil N- der upstream negativ markierten Pakete am Gesamtfluss vom Sender zum Empfänger misst, erkennt daran die Belastung stromaufwärts. Der Anteil N+ der bei ihm eintreffenden und vom Sender positiv markierten Pakete kennzeichnet die Staubelastung, wie sie der Empfänger für den gesamten Pfad gemessen hat. Die Differenz (N+ minus N-) ergibt dann ein Maß für die Stausituation im Downstream. Auf diese Weise wird die Staubelastung den gesamten Pfad entlang sichtbar.

„Wenn irgendwo im Internet eine Überlast auftritt, beispielsweise in einem Peering-Punkt, dann weiß das Netz relativ wenig über den Verursacher und hat außer dem Verwerfen beziehungsweise Markieren von Paketen bisher nur wenig Eingriffsmöglichkeiten“, meint Michael Scharf vom Institut für Kommunikationsnetze und Rechnersysteme der Universität Stuttgart, der sich seit langem mit Problemen der Überlastregelung und der Transportschicht im Internet beschäftigt. „An diesen Stellen wird re-ECN sehr interessant, weil es eine gewisse Transparenz schafft und verhindern kann, dass sich einzelne Nutzer einen unfairen Vorteil verschaffen können, indem sie viele aggressive Verkehrsflüsse generieren.“

Im Zugangsbereich könnte re-ECN vor allem dort für mehr Netzneutralität sorgen, wo Bandbreite-Sharing-Mechanismen zum Einsatz kommen – etwa im Kabelnetz oder bei der Überbuchung von DSL-Anschlüssen im Metrobereich, die von der Voraussetzung ausgeht, dass praktisch immer nur ein Bruchteil der Teilnehmer gleichzeitig online ist und damit zu Ressourcenengpässen führen kann. Im Mobilfunk hingegen, glaubt Scharf, werden die Betreiber unabhängig von der Stauvermeidung auch weiterhin DPI einsetzen, schon um das konkurrierende VoIP aus ihren Netzen fernzuhalten. Seine Quintessenz: „Ein Netzbetreiber, der bestimmte Dienste blockieren will, wird anstelle eines Mechanismus wie re-ECN auch weiterhin DPI zur Verkehrssteuerung einsetzen.“

Zur Zeit ist re-ECN nur einer der Discussion Threads zur Runderneuerung von TCP in der IETF, wenngleich ein prominenter. Doch so viel hat sich bereits herausgestellt: Wer die Fairness der Ressourcenverteilung thematisiert, berührt nicht nur grundsätzliche Architektur-Prinzipien des Internet, sondern die Geschäftsmodelle der Netzbetreiber – und seitdem diese an den Fundamenten rütteln, wackelt das ganze Gebäude.

Literatur

[1] Internet capacity sharing for packets not flows (PDF) (jk)