Mit Einführung des neuen Tarifierungsmodells beim Deutschen Forschungsnetz (DFN) erfolgte eine mengenmäßige Erfassung und Einschränkung des verursachten Datenvolumens der am DFN angeschlossenen Einrichtungen. Der TU Chemnitz wurde beispielsweise eine Datenmenge von 3000 GByte pro Monat zugestanden (mittlerweile sind es 6000 GByte), wofür jährlich 550.000 DM entrichtet werden mussten. Die nächste Kategorie wäre um 200.000 DM teurer gewesen, hätte aber außerdem mit dem Zweck für Forschung und Lehre begründet werden müssen. Bei einer Überschreitung der monatlichen Grenze hätte die TU mit Mahnungen und letztendlich einer Bandbreitenbeschränkung rechnen müssen.
Der erste Ansatz war nun, dieses "Traffic-Limit" auf die Nutzer des Chemnitzer Studentennetzes (CSN) umzulegen, die einen nicht unerheblichen Teil des monatlichen Gesamtvolumens der von der TU verursachten Datenmenge ausmachen. Der tägliche Traffic wurde gemessen, bei einer Überschreitung der festgelegten Grenze von 250 MByte/Tag wurde der Nutzer erst verwarnt und im Wiederholungsfall für 2 Wochen gesperrt.
Probleme gab es dabei, wenn man doch einmal eine größere Datenmenge benötigte. Ein weiteres Problem war die Ausnutzung des Limits bei Ablauf der Gültigkeitsfrist, so dass die 250 MByte am Ende das tages noch schnell "voll gemacht" wurden. Außerdem ist die Verwarnung und Sperrung von Nutzern weder für diese noch die CSN-Mitarbeiter angenehm. Deswegen wurde als Ausweg ein intelligenteres Bandbreiten-Management gesucht und im Rahmen einer Diplomarbeit in Angriff genommen.
Die Nutzer werden jetzt abhängig von ihrer verursachten Datenmenge in Gruppen mit unterschiedlicher Bandbreite eingeteilt. Je höher das Datenvolumen, desto weniger Bandbreite steht dem betreffenden Nutzer zur Verfügung. Nach und nach wird dieser Nutzer wieder einer Gruppe mit höherer Bandbreite zugewiesen.
| Gruppe | Ab Menge | Bandbreite | Tage | Begrenzung | Sofort |
|---|---|---|---|---|---|
| 1 | 100 MByte/Tag | 10 MBit/s | 2 | - | - |
| 2 | 200 MByte/Tag | 5 MBit/s | 4 | X | - |
| 3 | 300 MByte/Tag | 3 MBit/s | 6 | X | - |
| 4 | 400 MByte/Tag | 500 KBit/s | 8 | X | - |
| 5 | 500 MByte/Tag | 100 KBit/s | 10 | X | X |
Als Vorteil ist auch der geringere Verwaltungsaufwand zu nennen, es müssen jetzt keine Verwarnungen oder Sperrungen mehr vorgenommen werden.
Die Parameter der Gruppen sind über ein Webinterface einstellbar, ebenso die Ausnahmeregelungen für WWW- und FTP-Server, um Anreize zu schaffen, diese internen Ressourcen stärker zu nutzen. Auch für die Nutzer steht ein Webinterface zur Verfügung, über das sie ihre aktuellen Daten wie Gruppe und Datenmenge erfahren können. Bei Einordnung in Gruppe 5 erhält der betreffende Nutzer außerdem noch eine Benachrichtigung per E-Mail.
Um die dem CSN monatlich zugestandene Datenmenge möglichst optimal auszunutzen, jedoch ohne sie zu überschreiten, erfolgt eine automatische Regelung der Bandbreiten für die einzelnen Gruppen. Dazu wird das bisher erzeugte Datenvolumen auf den Monat hochgerechnet und mit dem Monatslimit verglichen. Liegt die Hochrechnung darüber, werden die Bandbreiten gesenkt, ansonsten erhöht. Ist die Bandbreite einer Gruppe höher als ein festgelegter Schwellenwert, wird sie temporär vom Shaping ausgenommen.
Die Management- und Informations-Schnittstellen sind per HTTP/HTML plattformunabhängig realisiert. Für die internen Management-Schnittstellen findet XML-RPC Verwendung, ein RPC-Protokoll auf der Basis von XML und HTTP. XML-RPC ist ein sehr einfaches Protokoll, d.h. es ist einfach zu verstehen und einfach zu implementieren. Der große Vorteil ist seine Sprachunabhängigkeit, so dass Daten zwischen Applikationen in verschiedenen Programmiersprachen ausgetauscht werden können.
Der Manager dient zur Verwaltung des DynShapers. Er legt die Parameter für die verwendeten Interfaces, Pfadnamen zu Programmen und eine Monatsobergrenze fest, stellt die Werte für die einzelnen Gruppen ein und definiert Ausnahmeregelungen.
Mit dem Watcher ist es den einzelnen Nutzern möglich, ihre aktuellen Werte wie die verursachte Datenmenge, die Gruppe, der sie momentan zugeordnet sind sowie deren Parameter abzufragen.
Durch den Configurator erfolgt die Konfiguration des DynShapers. Er verwaltet die Konfigurationsdaten und beantwortet XML-RPC-Anfragen, die Konfigurationsoptionen lesen oder schreiben wollen.
Der Evaluator wertet das Verkehrsaufkommen der Nutzer aus und ordnet die Nutzer bei Bedarf einer anderen Gruppe zu. Dazu führt er einmal pro Stunde eine Abfrage der aktuellen Werte durch. Weiterhin dient der Evaluator zur automatischen Regelung der Bandbreiten für die Gruppen, damit die festgelegte Monatsobergrenze nicht überschritten werden kann.
Der DynShaper dient zur eigentlichen Begrenzung des Verkehrs. Er wertet die vom Configurator erzeugte Konfiguration aus und legt Queuing Disciplines, Verkehrsklassen und Filterregeln fest:
Seit August 2001 befand sich das System im Testbetrieb, der zufriedenstellend verlief, so dass es am 23.10.2001 offiziell in Betrieb genommen wurde. Damit verbunden war der Wegfall der alten 250-MByte-Limits. Im Laufe des Einsatzes wurden noch diverse Bugs und Features entdeckt, die korrigiert werden mussten. Weiterhin gab es anfangs einige Akzeptanzprobleme, die zum Teil auf eine ungünstige Begriffswahl zurückzuführen waren.
Einige Nutzer aus Gruppe 5 fanden sehr schnell heraus, dass die verfügbare Bandbreite fair auf offene Verbindungen und nicht auf Nutzer verteilt wird. Durch viele offene Verbindungen war es ihnen deshalb möglich, unverhältnismäßig viel Bandbreite zu bekommen und die anderen Nutzer dieser Gruppe stark zu behindern. Mit der Queuing Discipline HTB statt CBQ ist es aber möglich, für jeden Nutzer in einer Gruppe eine eigene Verkehrsklasse anzulegen, so dass sich die Bandbreite jetzt auf die Nutzer verteilt.
Ein weiteres Problem ist, dass gedroppte TCP-Pakete nochmal gesendet werden müssen und dadurch zum einen mehrfach gezählt werden und zum anderen auch für eine höhere Netzlast sorgen. Allerdings sorgt die Flusskontrolle von TCP dafür, dass die Datenrate gedrosselt wird und der Effekt nicht so stark in Erscheinung tritt.
Die Anzahl der Verkehrsklassen hat keinen Einfluss auf den Durchsatz, bei sehr vielen Filterregeln sinkt er jedoch. Das liegt an dem linearen Durchlauf dieser Regeln. Abhilfe kann zum Beispiel durch Hashing Filters geschaffen werden.
Es erfolgt eine gleitende Zählung (Durchschnitt über letzte 14 Tage) der Datenmenge, um Trafficspitzen, die durch einmalige Transferaktionen verursacht wurden, abzuschwächen und die Nutzer dafür nicht so hart zu "bestrafen", wenn sie sich sonst zurückhalten. Die Auswertung und die Einordnung in die Gruppen erfolgt stündlich neu, es gibt also auch keine Verweildauer in den Gruppen mehr. Die Nutzer werden anhand ihrer Datenmenge sortiert und so aufgeteilt, dass jede Gruppe in etwa die gleiche Datenmenge verursachen kann. Neben der Bandbreitenregelung hat man jetzt also auch noch die Nutzerverteilung als weitere Einflussmöglichkeit.
Die Gruppenanzahl wird auf 10 erhöht, um eine feinere Aufteilung der Nutzer zu ermöglichen. Bei einer Aulastung von 100% würden in Gruppe 10 für jeden Nutzer 24 KBit/s zur Verfügung stehen, die reale Auslastung liegt sogar nur bei ca. 80%. Die Initialbandbreite von Gruppe 10 wird so festgelegt, dass sie nur 1/10 des erlaubten Datenvolumens verursachen kann; Gruppe 1 erhält die Bandbreite des Interfaces. Die Bandbreiten der anderen Gruppen gestalten sich wie folgt:
| Gruppe | Bandbreite | Nutzer | Ab Menge | Vorher Klasse | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | |||||
| 1 | 98 MBit/s | 949 | 55,4% | 0 MByte/Tag | 925 | 11 | 7 | 4 | 2 | 0 |
| 2 | 53 MBit/s | 222 | 13,0% | 17 MByte/Tag | 193 | 18 | 7 | 2 | 1 | 1 |
| 3 | 29 MBit/s | 151 | 8,8% | 29 MByte/Tag | 113 | 23 | 5 | 8 | 1 | 1 |
| 4 | 15 MBit/s | 111 | 6,5% | 40 MByte/Tag | 53 | 24 | 18 | 8 | 8 | 0 |
| 5 | 8400 KBit/s | 82 | 4,8% | 54 MByte/Tag | 27 | 12 | 33 | 6 | 3 | 1 |
| 6 | 4500 KBit/s | 64 | 3,7% | 69 MByte/Tag | 5 | 10 | 25 | 11 | 8 | 5 |
| 7 | 2500 KBit/s | 49 | 2,9% | 92 MByte/Tag | 4 | 4 | 15 | 14 | 4 | 8 |
| 8 | 1300 KBit/s | 39 | 2,3% | 114 MByte/Tag | 0 | 0 | 9 | 16 | 9 | 5 |
| 9 | 720 KBit/s | 30 | 1,8% | 150 MByte/Tag | 1 | 1 | 4 | 14 | 5 | 5 |
| 10 | 390 KBit/s | 16 | 0,9% | 223 MByte/Tag | 0 | 0 | 1 | 2 | 11 | 2 |
Die Datenmengengrenzen für die einzelnen Gruppen, die sich anhand von realen Daten so ergeben haben, liegen deutlich unter denen des alten Systems. Dabei darf aber nicht vergessen werden, dass es sich hier um Durchschnittswerte handelt. Als Verbesserung ist deutlich zu sehen, dass Nutzer, die bisher für einmalige Transfers zu stark bestraft wurden (oberhalb der Diagonale in der Gegenüberstellung alte Klasse - neue Gruppe), nun eine höhere Bandbreite zur Verfügung haben, während Nutzer, die die Grenzen immer nahezu ausgenutzt hatten (unterhalb der Diagonale) jetzt auch entsprechend behandelt werden.
Für die Regelung der Bandbreiten wird jetzt auch ein gleitender Durchschnitt eingesetzt, allerdings nur über 7 Tage, um schneller reagieren zu können. Durch den Durchschnitt können kurzzeitige Einflüsse wie am Wochenende abgefangen und ein "Schwingen" der Bandbreiten verhindert werden.
Um schnell reagieren zu können, wird das Verhältnis aus 7- und 14-Tage-Durchschnittstraffic des gesamten CSN herangezogen. Im Diagramm ist gut zu sehen, wie bei der Erhöhung des Datenaufkommens zum Semesterbeginn diese beiden Durchschnittswerte auseinanderlaufen, so dass der Abstand dazwischen als ein gutes Kriterium gelten kann, wann die Bandbreiten nachgeregelt werden müssen.
Für die Zukunft ist geplant, den DynShaper auch an mehreren Hochschulen einzusetzen. Dazu muss er von lokalen Abhängigkeiten befreit werden. Außerdem sollen Einrichtungen unterstützt werden, bei denen es keine 1:1-Zuordnung zwischen Nutzer und IP-Adresse gibt. Die Installation müsste dann auch besser unterstützt werden, zur Zeit ist noch viel Handarbeit erforderlich. Eventuell könnte sogar ein eigener Trafficzähler mit Datenbank integriert werden, so dass man ein Komplettpaket zur Zählung und Behandlung von Netzverkehr erhält.
| Jan Horbach, April 2002 |