|
NETZAGENTUR NRW
|
![]() |
|
Projektgruppe im Auftrag des MSWF und der Hochschulen
des Landes NRW
|
|
|
an der Universität - Gesamthochschule Essen
|
|
|
|
|
|
Dr. B. Lix (Universität - GH Essen)
|
|
|
Prof. Dr. H. Obrecht (Universität
Dortmund)
|
|
|
R. Bauer (Universität Dortmund)
|
|
|
A. Clauberg (Universität zu Köln)
|
|
|
H. Herker (Universität - GH Essen)
|
|
|
F. Klapper (Universität Bielefeld)
|
NRWWissWeb
Das B –WiN in NRW
Stand und voraussichtliche Entwicklung des Auslastung
bis Februar 2000
1. Arbeitsbericht der Netzagentur, Juni 1998
1 Einführung1.1 Auftrag2 Zusammenfassung3.1 Stand4 Aktuelle Verkehrsprofile und zugrundeliegende Datenbasis6.1 Flexibilisierung der BandbreiteAnhang A: Anschlußverteilung NRW WissWeb6.1.1 Technische Probleme / Zuleitungen6.2 Reduzierung des Verkehrs durch Proxy-Server6.1.3 Gemeinschaftsanschluß mit variabler Bandbreitenzuteilung
Anhang B: Servicequalität im Internet
B.1 Begriffsbestimmungen: Quality of Service und Class of ServiceAnhang C: Prognose bis Februar 2000
1 Einführung
"In den letzten Wochen sind mir unterschiedliche Zahlen zur Auslastung der B-WiN-Anschlüsse in NRW zugetragen worden.... Diese Daten sind meines Erachtens interpretationsbedürftig. Die Durchsatzzahlen machen möglicherweise eine größere Flexibilisierung erforderlich, um die Auslastung besser zu verteilen.
Ich sehe die Notwendigkeit, die an den Gemeinschaftsanschlüssen anliegende Kapazität bedarfsorientiert zu verteilen. Möglicherweise ergeben sich hierdurch Kostenvorteile.
Zudem sollte die Weitergabe von Kapazitäten an noch nicht bediente Einrichtungen (LDS, Schulen, Bibliotheken) in diesem Zusammenhang unbedingt geprüft werden.
Ich bitte die Netzagentur, diese Situation näher zu untersuchen und Vorschläge für eine grundlegende Verbesserung möglichst bis Ende Mai 1998 vorzulegen."
Die Netzagentur hat sich in mehreren Sitzungen mit diesem
Auftrag beschäftigt und legt als Ergebnis diesen Bericht vor. Sie
konnte sich noch nicht damit befassen, konkrete Gespräche mit Dritten
über die Weitergabe von Kapazitäten zu führen.
Das zugrunde liegende logische Denkmodell ist die Aufteilung in einen lokal zwingend erforderlichen Grundbedarf und einen virtuellen landesweiten Kapazitätspool. Die quantitativen Aussagen über die Mindestkapazitäten der einzelnen Anschlüsse sind nur sinnvoll innerhalb dieses Denkmodells. Sie können nicht zu Aussagen über die feste Begrenzung einzelner Anschlüsse auf diese Mindestkapazitäten mißbraucht werden.
Die allgemein vorliegenden Daten (WiN-Labor, CNM) sind daraufhin zu untersuchen, wieweit sie zu Aussagen innerhalb dieses Modells herangezogen werden können. Angesichts der Kürze des zur Verfügung stehenden Zeitraumes konnten eigene Messungen nur zur Bestätigung, Ergänzung und Interpretation dieser Daten herangezogen werden.
Um diese Ziele zu erreichen, wird
Deshalb wurden seit Mitte 1995 Kontakte auch mit anderen Anbietern als DFN/Telekom gesucht, um eine möglichst kostengünstige Versorgungsstruktur für das ganze Land zu erreichen. Diese Kontakte führten zu Gesprächen mit ISIS, RWE Telliance und Vebacom. Trotz teilweise intensiver Verhandlungen kam es zu keinem Angebot für ein Landesnetz NRW oder Vergleichbares. Mit dem definitiven Rückzug der Vebacom am 1. 3. 1996 war endgültig klar, daß keine Alternative zum Anbieter DFN/Telekom existierte. Aus den Gesprächen mit RWE Telliance ist die Hochgeschwindigkeitsverbindung Essen - GMD hervorgegangen.Die Gespräche mit DFN/Telekom wurden teilweise im Rahmen der ad hoc - Kommission "Regionale Netze" ("Pralle - Kommission") geführt, die von der 30. Mitgliederversammlung des DFN - Vereins am 4. 12. 1995 in Bonn eingesetzt wurde. Sie standen unter den folgenden Randbedingungen:
Es werden verschiedene Netztopologien diskutiert, zuerst allesamt auf der Basis von geteilten 34 Mb/s - Anschlüssen ("Gemeinschaftsanschlüssen") mit Anschlußkapazitäten zwischen 8 und 32 Mb/s pro Universität und 2 Mb/s pro Fachhochschule. Mit der realen Verfügbarkeit von 155 Mb/s - Anschlüssen werden auch diese in die Planung einbezogen. Es ergibt sich überraschenderweise, daß bei optimierter Netztopologie fast eine Verdopplung der Gesamtkapazität für das Land bei 34 Mb/s pro Universität und 2 Mb/s pro Fachhochschule mit Verringerung der Gesamtkosten bis zum Ende der Laufzeit (28. 2. 1999) gegenüber den vorherigen Modellen realisiert werden kann.realisierbar sind nur Anschlüsse nach den Bedingungen des B-WiN gemäß Vertrag DFN/Telekom;
es stehen nur 34 Mb/s und 155 Mb/s - Anschlüsse zur Verfügung;
sofern Zuleitungen anderer Anbieter integriert werden sollen, übernimmt der DFN-Verein bzw. seine Beauftragten das Management bis zum Endkunden, d. h. keine Integration fremd gemanagter Teilnetze;
das nach langen Verhandlungen erreichte (und gegenüber den Monopolpreisen um etwa 50% vergünstigte) Paketangebot der Telekom für die Zuleitungen wird ausdrücklich nur als "Huckepack" zum B-WiN-Vertrag, also nicht als selbständig (z. B. in Bezug auf die Laufzeit) zu verhandelnder Zusatzvertrag angeboten;
wegen der zu diesem Zeitpunkt noch ganz unübersichtlichen Gesamtentwicklung des B-WiN besteht der DFN - Verein darauf, daß Anschlüsse vollständig abgenommen werden, also keine freien Teilkapazitäten übrig bleiben. Daß die wesentlich leistungsfähigere Alternative sogar zu einer Verringerung der Gesamtkosten führt, hat im wesentlichen drei Ursachen:
In der folgenden Tabelle ist die vom WAL ausgewählte Alternative 4 des Angebots des DFN-Vereins auf der Basis geteilter 34 Mb/s - Anschlüsse (Fax vom 16. 4. 1996) dem Angebot des DFN-Vereins (Fax vom 10. 6. 1996) gegenübergestellt, das schließlich Grundlage der jetzt gültigen B-WiN-Verträge wurde:
- die Kosten der Zuleitungen skalieren nicht: Zuleitungen werden nur mit 2 Mb/s oder mit 34 Mb/s angeboten.
- 1Mb/s an 34 Mb/s ist wesentlich teurer als 1 Mb/s an 155 Mb/s
- ein Anschluß wird um so teurer, je feingranularer er aufgeteilt wird ("Bauchigkeit").
- die beiden letzten Effekte werden für 1998 verstärkt durch die für dieses Jahr vorgesehene Preiserhöhung.
|
|
|
|
||||||
|
Gesamtkapazität
|
|
|
||||||
|
Kosten 97
|
Kosten
98
|
Kosten 99
|
Kosten 97-99
|
Kosten
97
|
Kosten
98
|
Kosten 99
|
Kosten 97-99
|
|
| Kapazitäten |
5.535.000
|
8.965.000
|
1.494.167
|
5.142.000
|
7.478.000
|
1.246.333
|
||
| ATM Mgmt. |
1.050.000
|
1.050.000
|
175.000
|
1.050.000
|
1.050.000
|
175.000
|
||
| Zuleitungen |
1.868.820
|
1.868.820
|
311.470
|
2.607.998
|
2.607.998
|
434.666
|
||
| Gesamt o. MwSt |
8.453.820
|
11.883.820
|
1.980.637
|
8.799.998
|
11.135.998
|
1.856.000
|
||
| Gesamt m. MwSt |
9.721.893
|
13.666.393
|
2.277.732
|
25.666.018
|
10.119.998
|
12.806.398
|
2.134.400
|
25.060.795
|
Tabelle 1: Kostengegenüberstellung DFN-Angebote 34 Mb/s, 155 Mb/s
Rechnet man den Zeitraum bis Februar 2000 mit ein, so erhöht sich der Kostenvorteil auf insgesamt DM 1,5 Mio. Das MWF übernimmt die zusätzlichen Kosten, die sich aus dem Modell WissWebNRW ergeben und ermöglicht es so allen Hochschulen, im Laufe des Jahres 1996 Verträge mit dem DFN-Verein abzuschließen, die auf diesem Modell basieren.
4 Aktuelle Verkehrsprofile und zugrundeliegende Datenbasis
Die Nutzung des B-WiN wird in drei öffentlich zugänglichen Datenbasen dokumentiert:
Die jeweilige Eignung dieser drei Datenbasen für
die Analyse der B-WiN-Nutzung durch die einzelnen Hochschulen in NRW wird
folgendermaßen bewertet:
Die weitere Analyse beruht daher auf den Tagesstatistiken der CNM-Gruppe. Diese liegen ab Ende Januar 1998 vor.
Zur Ermittlung des aktuellen Bandbreitenbedarfs der einzelnen Hochschulen wurde auf Basis der Tagesstatistiken der CNM-Gruppe ein Modell entwickelt. Dieses kann unter Berücksichtigung des Wachstums der B-WiN-Nutzung fortgeschrieben werden, so daß eine Prognose (s. Kapitel 5) über die benötigte Bandbreite der einzelnen Hochschulen in der Zukunft möglich wird.
Das Modell wird exemplarisch an den Statistiken des B-WiN-Anschlusses
der Universität zu Köln vom 13.05.98 erläutert. Im CNM ist
für den 13.05.98 folgendes Tagesprofil veröffentlicht:
Abbildung 1: CNM Tagesprofil Universität zu Köln, 13.5.1998
Charakteristisch ist, daß der Verkehr vom B-WiN zur Hochschule hin immer deutlich größer ist als der Verkehr von der Hochschule zum B-WiN. Dies gilt für alle betrachteten Hochschulen. Die benötigte Bandbreite der einzelnen Hochschulen entspricht daher immer der benötigten Bandbreite für vom B-WiN empfangenen Verkehr. Die Gegenrichtung (zum B-WiN hin senden) muß nicht untersucht werden.Ebenso sieht man bei allen Hochschulen, daß der Verkehr in der Woche größer ist, als am Wochenende. Für die weiteren Untersuchungen wird daher der Verkehr an normalen Arbeitstagen (i.A. Montag bis Freitag) zugrunde gelegt.
Betrachtet man den Maximalwert der 5-Minuten-Mittel (hier 7,8 MBit/s), so entspricht dieser in Näherung dem zweifachen des Tagesdurchschnitts (hier 4,4 MBit/s). Dies gilt in ähnlicher Weise für alle 14 betrachteten Hochschulen. Dabei liegt der Faktor bei den Hochschulen mit hohem Tagesdurchschnitt (wie hier bei Köln) eher leicht unterhalb von 2, während er bei den Hochschulen mit geringem Tagesdurchschnitt (Hagen, Siegen und Wuppertal) zum Teil deutlich über 2 liegen kann.
Hierzu tragen insbesondere folgende Faktoren bei:
bei geringer Grundlast (entspricht geringem Tagesdurchschnitt), macht sich der Einfluß einzelner bandbreitenintensiver Anwendungen im Verhältnis zur Grundlast stärker bemerkbar;
die oben genannten Hochschulen mit den niedrigsten Tagesdurchschnittswerten haben nachts praktisch kein Datenaufkommen. Dies vermindert den Tagesdurchschnitt. Abbildung 2a zeigt das Tagesprofil der Universität Wuppertal vom 6.5.1998, zum Vergleich zeigt Abbildung 2b das Tagesprofil der Universität zu Köln vom selben Tag.
Abbildung 2a: Tagesprofil Universität Wuppertal 6.5.98
Abbildung 2b: Tagesprofil Universität zu Köln, 6.5.98
Die 5-Minuten-Mittel verteilen die verschiedensten Bandbreitenanforderungen einzelner Anwendungen gleichmäßig über jeweils 5 Minuten. In der Realität treten deutlich höhere Spitzen auf. Die Netzagentur hat dazu bei den B-WiN-Anschlüssen der Universitäten Bielefeld und Köln die 5-Minuten-Mittel mit den 5-Sekunden-Mitteln verglichen. Die Messungen am 13.05.98 am Anschluß der Universität zu Köln sind für die Ergebnisse charakteristisch. Sie ergaben folgendes Bild:
Abbildung 3: 5 Sekundenprofil, Universität zu Köln, 13.5.98. Es werden die vom B-WiN empfangenen Daten angezeigt. Die Einheit ist Octets (Byte) pro Sekunde. Dabei zeigt die durchgezogene Linie die 5-Minuten-Mittel, die gestrichelte Linie das Maximum der 5-Sekunden-Mittel in den betreffenden 5 Minuten und die gepunktete Linie das Minimum der 5-Sekunden-Mittel in den betreffenden 5 Minuten an.
Man findet häufig Stellen, bei denen das 5-Sekunden-Mittel deutlich mehr als Doppelte des 5-Minuten-Mittels ausmacht. Vereinzelt treten auch wesentlich höhere Lastspitzen auf. Die Bewertung der Spitzen bei den 5-Sekunden-Mitteln ist schwierig, da die B-WiN-Anschlüsse von vielen, für die Betreiber des Anschlusses oftmals unbekannten Anwendungen, gleichzeitig genutzt werden.
Ein zu starkes Beschneiden der Kurzzeitspitzen führt im jetzigen B-WiN ohne Kontrolle der Servicequalität für einzelne Anwendungen (QoS) bzw. für Anwendungsklassen (CoS) (s. dazu Kapitel 6.3 und Anhang B) zu Paketverlusten für alle Anwendungen.
Das Queueingverhalten in den vermittelnden Systemen (Router, Switches) kann vereinfacht mit dem Prinzip eines löchrigen Eimers (leaky bucket) dargestellt werden. Pakete fließen normalerweise sofort durch die entsprechend der subskribierten Bandbreite des WiN-Anschlusses dimensionierten "Löcher" ab. Treffen pro Zeiteinheit mehr Pakete ein als abfließen können, stauen sich die Pakete, bis der "Eimer" (Puffer) schließlich überläuft und Pakete verlorengehen. Dabei gehen Pakete aller zur Zeit aktiven Anwendungen verloren (Tail Drop Queueing), es sind nicht nur die Pakete der Anwendung mit hoher Lasterzeugung betroffen. Das in Internetanwendungen i.A. verwendete TCP-Protokoll reagiert auf diesen Paketverlust indem es die Senderate heruntersetzt. Da alle aktiven Anwendungen vom Paketverlust betroffen waren, setzen alle TCP-Sender ihre Senderate herunter. Um das Netz optimal auszulasten, tasten die Anwendungen sich nach dem Slow-Start Mechanismus wieder an die Auslastungsgrenze heran und erhöhen die Senderate stufenweise bis zum nächsten Paketverlust. Dieses periodische Auf- und Abschaukeln wurde extrem im unterdimensionierten Schmalband-Wissenschaftsnetz beobachtet. Das Verhalten führt dazu, daß keine interaktive Nutzung von Ressourcen über das Netzwerk mehr möglich ist.Das Vertiefen des "Eimers" (Puffers) bringt keine Lösung des Problems, es erzeugt vielmehr eine größere Verzögerung bzw. Schwankung der Verzögerung (Jitter) der Pakete. Eine interaktive Nutzung eines entfernten Rechners bzw. Echtzeitanwendungen wie Telefonie, Videokonferenzen, Übertragungen von Vorlesungen werden so unmöglich.
Gleichzeitig kann aus wirtschaftlichen Überlegungen heraus aber auch nicht beliebig viel Bandbreite vorgehalten werden. Die Netzagentur empfiehlt daher, für den lokalen Grundbedarf Bandbreite vorzuhalten, die doppelt so hoch ist, wie die Tagesmaxima der 5-Minuten-Mittel sind. Dies führt zu einer 1/2/4 Regel zur Bestimmung der Anschlußkapazität (4) aus dem Tagesmittel (1), dem 5-Minutenmittel (2-faches Tagesmittel). Zum Ausgleich der Unterschiede im Tagesprofil der Hochschulen wird die minimal benötigte Bandbreite für eine Universität mit 6 Mb/s angesetzt, andernfalls würden speziell in Essen, Hagen, Siegen und Wuppertal die am Tage auftretenden Spitzen zu stark beschnitten. In anderen Bereichen wird teilweise mit einem 1:10 Verhältnis zwischen Tagesmittel und Spitzenlast gerechnet, der hier benutzte Ansatz ist recht konservativ und stellt den absolut minimalen Wert für die lokal ständig benötigte Bandbreite dar. Die darüber hinaus vorhandene Bandbreite sollte unter überregionalem Aspekt gesehen und zur flexiblen Verteilung innerhalb des Landes zur Befriedigung temporär oder längerfristig erhöhten Bedarfs vorgesehen werden.
Damit errechnet sich die für den ständigen lokalen Grundbedarf empfohlene Bandbreite für die einzelnen Hochschulen im Verhältnis 1/2/4 aus den Tagesdurchschnittswerten. Legt man die von der CNM-Gruppe ermittelten Tagesdurchschnittswerte für die Arbeitstage (i.A. Montag bis Freitag) vom 28.01.98 bis zum 15.05.98 zugrunde, ergibt sich nach diesem Modell aktuell folgender minimaler Bandbreitenbedarf für die einzelnen Hochschulen aus NRW für den Monat Mai 1998:
|
Mbit/s
|
|
| Aachen |
21
|
| Bielefeld |
6
|
| Bochum |
12
|
| Bonn |
10
|
| Dortmund |
13
|
| Düsseldorf |
9
|
| Duisburg |
7
|
| Essen |
6
|
| Hagen |
6
|
| Köln |
18
|
| Münster |
12
|
| Paderborn |
9
|
| Siegen |
6
|
| Wuppertal |
6
|
Tabelle 2: Minimaler ständiger lokaler Grundbedarf an Bandbreite der NRW Universitäten, Mai 1998
5 Prognosen
Auf der Basis der aus den CNM-Messungen gewonnenen Daten über die aktuell genutzten Bandbreiten der einzelnen Universitäten muß zur Prognostizierung des zukünftigen Bedarfs die monatliche bzw. jährliche Entwicklung für das zu erwartende Datenvolumen in die Berechnungen einfließen.Die CNM-Daten selbst können hierfür nicht herangezogen werden, da diese noch nicht für einen hinreichend langen Zeitraum vorliegen und zudem noch aktuell durch zwischenliegende vorlesungsfreie Zeiten im Frühjahr verfälscht sind.
Ein naheliegender Ansatz ist es, individuelle Aussagen über Verkehrsentwicklungen für die einzelnen Hochschulen aus den seit April 97 vorliegenden monatlichen Gesamtvolumina des Erlanger WiN-Labors entnehmen.
Hierzu muß festgestellt werden, daß die dort veröffentlichen Zahlen teilweise offensichtlich mit Fehlern behaftet (so sind z.B. für die Universität Münster im Februar 1998 keine Daten vorhanden), und einige Meßdaten lückenhaft sind (z.B. wird für die RWTH Aachen im Januar 1998 nur rund 50% des Dezember 97 bzw. 30% des Volumens von Februar 98 ausgewiesen).
Nimmt man solche fehlerhaften Daten aus der Betrachtung heraus, so ergibt sich im Landesmittel ein mittlerer Zuwachs von Jahr zu Jahr um nahezu den Faktor 2,8. Dieser läge somit wesentlich höher als der Faktor 2, der an Hand der vom DFN veröffentlichten Zahlen über den Gesamtverkehr des B-WIN ermittelt werden kann. Da nicht ausgeschlossen werden kann, daß durch äußere Einflüsse (US-Konnektivität, DE-CIX) und die oben beschriebenen nicht hinreichenden Grunddaten der "Landesfaktor" zu hoch ausgewiesen ist, wird für die Prognose ein Zuwachs analog der allgemeinen Entwicklung im B-WIN angesetzt.
Eine über einen längeren Zeitraum geführte Statistik (seit Anfang 1994) lag von der Universität Dortmund vor. Hier war zugleich der Sonderfall vorhanden, daß diese Universität bis Ende 1997 ihren internationalen IP-Verkehr über einen kommerziellen Provider abwickeln konnte, und somit von äußeren Beschränkungen wie die nicht ausreichende Kapazität der Transatlantikleitung des DFN-Vereins nicht betroffen war. Die dort errechnete jährliche Steigerung beläuft sich sogar auf 2,94.
Von daher muß eine Prognose auf der Basis einer jährlichen Steigerung um den Faktor 2 als moderater Ansatz angesehen werden, der für Abweichungen nach unten oder oben offen ist. Er bedarf daher einer Überprüfung und ggf. Korrektur an Hand der in der Zukunft verfügbaren Verkehrsdaten.
Auch in der Zukunft muß von einem weiteren Anwachsen des Verkehrsvolumens / Bandbreitenbedarfs ausgegangen werden. Gründe hierfür sind:
Diesem Bandbreitenzuwachs muß eine Prognose Rechnung tragen; sie zu vernachlässigen hieße die Konkurrenzfähigkeit, Effizienz und Vorreiterrolle von Wissenschaft und Forschung aus der zu Hand geben.die immer noch nicht abgeschlossenen Entwicklungen im Bereich der Anbindungen aller Arbeitsbereiche an die lokalen Hochschulnetze (vgl. "Campus-Online") und die damit verbundenen Neuanschlüsse und -nutzer;
die technischen Weiterentwicklungen im Bereich der Inhousenetze der Hochschulen (Migration von lokalen 10 Mbit/s- zu 100 Mbit/s-Netzen, damit Wegfall von lokalen Bandbreitenengpässen);
steigende Leistungsfähigkeit der Endsysteme;
die Ausbreitung der "Fertigkeit" zur Netznutzung in immer weitere Arbeitsbereiche und Nutzergruppen;
die wachsende Zahlen der Netznutzung von zu Hause, als Beispiel seien Heimarbeitsplätze oder Internetzugänge für Studierende genannt;
die Weiterentwicklungen im Bereich des Internet-Angebotsspektrums. Als Beispiel sei das WWW als meistgenutzte Anwendung genannt, bei welchem die Angebote ständig aufwendiger und damit bandbreiten-intensiver werden (z.B. wird beim Aufruf des CNM ein Applet von rd. 1,3 Mbyte übertragen);
die Entwicklungen im Multimediabereich, welche erst am Anfang stehen;
Bandbreitenbedarf durch vielfache Nutzung von neuen "Jedermann-Applikationen", welche, jede für sich, mit relativ kleinen Anforderungen verknüpft sind die sich dann durch die vielfache Nutzung summieren. Hier die nächsten Applikationen vorherzusagen nahezu unmöglich: ein nächster Schritt ist vielleicht im Bereich der "easy-to-get" und "easy-to-use" Conferencing Systeme zu erwarten, bei dem Arbeitsplatzsysteme mit der gleichen Selbstverständlichkeit mit Mikrophon und Kameras wie heutzutage mit CD-Laufwerken ausgestattet werden.
In der beigefügten Berechnung (Anhang C) ist der jeweils zu erwartende Bandbreitenbedarf für die einzelnen Hochschulen mit der oben beschriebenen jährlichen Steigerungsrate berechnet. Hierbei wird für die Fernuniversität Hagen und die Universitäten in Essen, Siegen und Wuppertal ein Bandbreitenbedarf von derzeit 6 Mbit/s angesetzt. Damit wird berücksichtigt, daß diese, wie im Abschnitt zuvor bereits ausgeführt, eine relativ geringe Grundlast ausweisen und der Durchsatz zu den Hauptverkehrszeiten nicht durch das Modell abgebildet wird.
Die folgende Tabelle soll verdeutlichen, in welchen Zeiträumen und an welchen Hochschulen in der Zukunft mit Engpässen bei ihrer Außenanbindung gerechnet werden muß. Selbstverständlich sind die dort genannten Monate nur als ungefährer Zeitraum zu verstehen, der sich, auch abhängig von der individuellen Steigerungsrate, verschieben kann.
|
|
|
|
||||||||||||||||||||
|
Mai
|
Jun
|
Jul
|
Aug
|
Sep
|
Okt
|
Nov
|
Dez
|
Jan
|
Feb
|
Mär
|
Apr
|
Mai
|
Jun
|
Jul
|
Aug
|
Sep
|
Okt
|
Nov
|
Dez
|
Jan
|
Feb
|
|
|
AC
|
K
|
DO
|
BO
|
MS
|
||||||||||||||||||
Tabelle 3: Überlastungszeitraum der bestehenden Anschlüsse
|
Mbit/s
|
|
| Aachen |
70
|
| Bielefeld |
21
|
| Bochum |
40
|
| Bonn |
33
|
| Dortmund |
41
|
| Düsseldorf |
28
|
| Duisburg |
22
|
| Essen |
21
|
| Hagen |
21
|
| Köln |
59
|
| Münster |
38
|
| Paderborn |
29
|
| Siegen |
21
|
| Wuppertal |
21
|
Tabelle 4: Zu erwartender Bandbreitenbedarf der NRW Universitäten, Februar 2000
Summa summarum bleibt festzuhalten, daß das hier gewählte Modell in seinen Aussagen eher die Untergrenze der zu erwartenden Entwicklung darstellt.
6 Zukünftige Netzplanung
6.1 Flexibilisierung der Bandbreite
Auf Basis der unter Kapitel 3 entwickelten Prognose kalkuliert sich der zu erwartende aggregierte Bandbreitenbedarf für alle NRW Hochschulen im Februar 2000 zu 465 Mb/s. Verglichen mit der momentan zur Verfügung stehenden aggregierten Bandbreite von 548 Mb/s ergibt sich ein rechnerischer Spielraum durch eine potentielle Verschiebung bzw. Flexibilisierung der Bandbreitenverteilung.Dem stehen jedoch einige Probleme entgegen.
6.1.1 Technische Probleme / Zuleitungen
Die Zuleitungen zu den Gemeinschaftsanschlüssen sind von der Deutschen Telekom AG oder von alternativen Anbietern nur in Einheiten von 2 Mb/s, 34 Mb/s, 155 Mb/s oder zukünftig 622 Mb/s bzw. 2,48 Gbit/s zu bekommen. Zwischenbandbreiten sind nicht möglich. Das führt auch dazu, daß B-WiN Basisanschlüsse lediglich in 34 Mb/s oder 155 Mb/s Technik realisiert werden können.Unter Beibehaltung der gegenwärtigen Anschlußstruktur könnte daher lediglich die Kapazität für die Universitäten Dortmund, Düsseldorf und Köln erhöht werden. Der 34 Mb/s Anschluß an der RWTH Aachen müßte zur Lösung der Aachener Lastprobleme auf 155 Mb/s umgerüstet werden bzw. Aachen mit einer 155 Mb/s Zuleitung an einen bestehenden 155 Mb/s Anschluß mit freier Kapazität angebunden werden. Bei der gegenwärtigen Verkehrsentwicklung wäre ein 155 Mb/s Einzelanschluß für die RWTH und FH Aachen überdimensioniert.
6.1.2 B-WiN Betriebsmodell
Die Bandbreitenaufteilung an einem B-WiN Gemeinschaftsanschluß ist zur Zeit starr. Um jedem Teilnehmer eine garantierte Dienstgüte bieten zu können, wird eine permanente ATM Verbindung (PVC) der Verkehrsklasse VBR zwischen dem beim Teilnehmer aufgestellten WiN-Router (WR) über den ATM-Kunden-Service-Switch (KSS) und zentralen Service-Switch (ZSS) zum zentralen Router (ZR) geschaltet. Der ATM-Verbindung wird eine feste Bandbreite zugewiesen. Verbindungen zwischen den Teilnehmernetzen werden über die teilnehmereigenen Kundenrouter (KR) zum WR, von dort via ZR, WR zum KR des anderen Teilnehmers geführt.Eine gegenseitige Beeinflussung verschiedener Teilnehmer an einem Gemeinschaftsanschluß wird so ausgeschlossen. Auf den WiN-Routern werden u.a. die IP-Accountingdaten gewonnen. Um eine Überlastung eines WiN-Routers zu vermeiden, werden zusätzlich zu einem Teilnehmer mit hoher Anschlußkapazität (> 4 Mb/s) lediglich Teilnehmer mit einer Anschlußbandbreite von 2 Mb/s angebunden. Die Abbildung 4 zeigt diese Struktur am Beispiel des Kölner Gemeinschaftsanschlusses (am Standort Köln sind nur 3 der 7 Teilnehmer mit Bandbreiten bis 4 Mb/s gezeigt).
Eine Flexibilisierung der Bandbreite ist in diesem Modell sehr aufwendig zu realisieren, eine Dynamik ist bedingt durch den Aufwand zur Schaltung von PVCs durch die DeTeSystem und die entsprechende Routerkonfiguration durch das DFN-NOC nicht möglich.
![]()
Abbildung 4: Struktur eines B-WiN Gemeinschaftsanschlusses
6.1.3 Gemeinschaftsanschluß mit variabler Bandbreitenzuteilung
Aus den unter 6.1 geschilderten Gründen ist eine variable, dynamische Bandbreitenzuteilung an einem B-WiN Gemeinschaftsanschluß wünschenswert. Dem entgegen steht die damit drohende gegenseitige Beeinflussung der Teilnehmer. Mitnutzer eines zukünftigen Gemeinschaftsanschlusses mit variabler Bandbreitenzuteilung müßten einer derartigen Nutzung daher explizit zustimmen und sich mit etwaigen Einschränkungen einverstanden erklären. I.A. ist das nur bei Teilnehmern aus dem Hochschulumfeld zu erwarten. Probleme sind dabei vor allem an den Gemeinschaftsanschlüssen in Dortmund (MPIs, FhG) und Köln (MPIs, DLR, WDR) zu erwarten.Die Abbildung 5 zeigt eine mögliche Struktur eines derartigen Anschlusses. Gegenüber dem jetzigen Angebot wird ein zusätzlicher Router (Gemeinschaftsanschluß-Router GR) benötigt. Der GR nimmt eine dem ZR ähnliche Stellung zwischen den beteiligten WRs war. Vom GR aus wird ein ATM PVC mit der aufsummierten Bandbreite der teilnehmenden Einrichtungen zum ZR geschaltet. Vom GR zu den teilnehmenden WRs wird ein PVC mit der Bandbreite der Anschlußleitung geschaltet. Eine Mitnutzung des WRs der Einrichtung bei der der Gemeinschaftsanschluß betrieben wird als GR ist bedingt durch die zusätzlichen Aufgaben eines WR im Bereich Accounting und Sicherheit nicht möglich.
Nicht an der flexiblen Bandbreitenaufteilung beteiligte Einrichtungen (im Beispiel Köln sei dies für die DLR angenommen) werden auf dem alten Weg ohne Nutzung des GR angebunden. Die flexible Bandbreitenaufteilung bleibt für sie ohne Folgen.Ein derartiger Anschluß gehört zur Zeit nicht zum Angebot des DFN-Vereins, über eine Realisierung, eventuell in Testform, müßte daher verhandelt werden.
Zu beachten ist, daß bei der hier vorgeschlagenen Lösung der Teilnehmer, bei dem der Gemeinschaftsanschluß installiert ist (Dortmund, Düsseldorf, Köln) gegenüber den anderen Teilnehmern am Anschluß durch die fehlende Begrenzung durch die Zuleitungskapazität leicht bevorteilt wird.
Das Modell ist nur auf die 155 Mb/s Gemeinschaftsanschlüsse anwendbar, das Problem der Überlastung des Aachener Anschlusses wird nicht gelöst.
![]()
Abbildung 5: Mögliche Struktur eines B-WiN Gemeinschaftsanschlusses mit flexibler Bandbreitenzuteilung
6.2 Reduzierung des Verkehrs durch Proxy-Server
Eine Alternative zur Schaltung neuer Kapazitäten stellt natürlich die Senkung des Verkehrsaufkommens dar. Da Erfahrungen aus der Vergangenheit haben jedoch gezeigt, daß eine derartige "Verkehrsberuhigung" immer nur von kurzer Dauer ist.Die meisten Hochschulen setzen zur Zeit WWW-Proxy-Server ein, um häufig wiederholte WWW- oder ftp-Transfers von Daten aus dem Internet aus einem lokalen magnetplattenbasierten Zwischenspeicher zu beantworten. Die Benutzung eines derartigen Servers wird zur Zeit lediglich von der Universität Wuppertal durch Sperrung des direkten WWW-Zugriffs für alle Endsysteme erzwungen. In Wuppertal können ca. 60% aller Transfers aus dem lokalen Cache befriedigt werden, an anderen Hochschulen liegt die Rate bei ca. 30 bis 40%.
Der Betrieb eines skalierbaren Proxy-Servers für große Einrichtungen stellt sich als sehr problematisch dar. Nur sehr leistungsfähige Unix-basierte Systeme sind für die Verwaltung von mehreren zehntausend geöffneten Verbindungen/Transaktionen ausgelegt. Als Alternative bietet sich die Aufteilung der Aufgabe auf mehrere parallel betriebene Server. Hier ergibt sich ein Administrationsproblem durch den gestiegenen Aufwand zur Betreuung der Systeme. Proxy-Server sind in der Lage, persönliche Daten zu speichern (u.a. Nutzungsprofile) und müssen dementsprechend sorgfältig unter Beachtung der Datenschutzgesetze betreut werden.
Ein generelles Erzwingen der Nutzung eines Proxy-Servers ist durch die Forderung einiger Informationsanbieter nach direktem Zugriff ohne Zuschaltung eines Caches (u.a. betrifft dies Veröffentlichungen im Fachbereich Physik) zur Vermeidung von Lizenzproblemen problematisch.
Die sehr hohen Investitions- und Betriebskosten sprechen gegen eine derartige Lösung zur Reduzierung des Verkehrs.
6.3 Einführung von Verkehrsklassen
Die bisher geschilderten Maßnahmen bringen keine dauerhafte Lösung des Problems. Dadurch, daß keine Unterscheidung des Datenverkehrs möglich ist, führt eine Überlastung eines Anschlusses zu Auswirkungen auf alle Anwendungen.An einem gemäß 6.1.3 betriebenen Gemeinschaftsanschluß mit flexibler Bandbreitenzuteilung verschlimmert sich das Problem noch. Eine Auslastung des Anschlusses durch eine Anwendung bei einem Partner führt zu Störungen für alle Anwendungen bei allen Partnern an diesem Anschluß.
Da die Hochschule nicht in der Lage ist, den Verkehr zu klassifizieren, kann ein derartiger Überlastungszustand unter Umständen durch nur eine Anwendung herbeigeführt werden. Ein vollkommen unwichtiger Transfer von Werbebildern aus dem Internet kann so zum Beispiel wichtige Studien- oder Forschungsarbeiten empfindlich stören.
Eine mittel- oder langfristige Lösung des Problems muß daher den Hochschulen Möglichkeiten geben, Verkehr entsprechend zu qualifizieren bzw. Bandbreite für bestimmte Anwendungen oder Anwendungsklassen zu reservieren oder speziell einzukaufen.Da praktisch alle Anwendungen auf dem IP-Protokoll aufbauen ist es unerläßlich, diese Qualitätsmerkmale auf der IP-Ebene anzubieten. Die Nutzung von ATM bringt keine Vorteile, da IP und ATM-Qualitätsmerkmale nicht aufeinander abgebildet werden können.
Im Rahmen der Internet Engineering Task Force (IETF) werden seit mehreren Jahren entsprechende Betriebsmodelle und Konzepte ausgearbeitet. Ergebnis ist u.a. das Resource Reservation Setup Protocol RSVP, mit dem für einzelne Verbindungen in einer begrenzten Internetumgebung Bandbreite reserviert werden kann. Eine Internet-weite Nutzung dieses Protokolls ist durch die damit verbundenen Skalierungsprobleme auf den Backbone-Routern nicht möglich.Eine Klassifizierung des Verkehrs und die Zuweisung von Bandbreite bzw. bestimmten Queueingverhalten zu den Verkehrsklassen ist skalierbar und wird auch Internet-weit angedacht. Erste Produkte, die die Realisierung eines derartigen Class of Service-Routings ermöglichen, sind seit Anfang 1998 verfügbar. Class-of-Service-basiertes Routing wird weltweit bisher nur in Laborumgebungen eingesetzt. Eine Nutzung in Produktionsnetzen ist von einigen Internet Service Providern für das 3. Quartal 1998 geplant.
Die Konzepte Quality of Service und Class of Service sind im Anhang B detailliert erklärt.
Mit einem derartigen Konzept ist es denkbar, daß eine Hochschule beim Diensterbringer (DFN-Verein) einen Anteil einer garantierten Bandbreite einkauft. Die Hochschule qualifiziert die Pakete, die dieser Bandbreitengruppe zuzuordnen sind, selbst. Die Bandbreite wird vom Diensterbringer auch im Kernnetz und auf internationalen Zubringerleitungen zur Verfügung gestellt. Ein weiterer Anteil wird vom Diensterbringer an die Hochschule als "best effort" Verkehrsklasse verkauft. Diese nicht klassifizierten Daten werden nur weitergeleitet, wenn entsprechende Kernnetzkapazität bzw. Kapazität auf den internationalen Leitungen zur Verfügung steht.
Die Hochschule kann auf diese Weise selbst bestimmen, welche Daten mit welcher Priorität durch das Netz geleitet werden. Von Überlastzuständen sind in diesem Modell nur die "best effort"-Anwendungen betroffen. Die für den Studien- und Forschungsbetrieb notwendigen Anwendungen sind bis zum Eintreten eines Überlastzustands in ihrer Verkehrsklasse unbeeinflußt. Bei gleichem Mitteleinsatz kann das Netz so deutlich effizienter genutzt werden.
Das Land NRW sollte mit dem DFN-Verein verhandeln, derartige Konzepte so schnell wie möglich auf einen Betriebseinsatz im B-WiN oder im Nachfolgenetz G-WiN zu untersuchen. Eine Testinstallation in NRW ist anzustreben. Das Konzept kann lokal auch ohne Auswirkungen auf das Kernnetz zusammen mit dem unter 6.1.3 vorgestellten Konzept getestet werden.
Zu beachten ist, daß derartige Techniken zur Zeit nur von einem Hersteller (Cisco Systems) verfügbar sind. Die im B-WiN eingesetzten Router stammen von diesem Hersteller, so daß eine Nutzung möglich ist. Teilweise sind zum Einsatz dieser Technik ohne Geschwindigkeitseinbussen Hardwareaufrüstungen der Router notwendig. Die Software befindet sich noch in einer relativ frühen Phase, an einen generellen Produktionseinsatz ist nicht vor dem 3. Quartal 1998 zu denken.
Die Hochschulen müssen den Verkehr selbst qualifizieren. Zur Zeit stehen dafür nur wenige Werkzeuge zur Verfügung, so daß für ca. 1 Jahr personeller Aufwand zur Administration kalkuliert werden muß.
Auch dieses Modell löst die Überlastung des Einzelanschlusses an der RWTH Aachen nicht.
Anhang A: Anschlußverteilung NRW WissWeb
Anhang B: Servicequalität im Internet
Paketvermittelte Netze auf Basis des Internet Protokolls IP arbeiten i.A. auf Basis des "Best Effort" Prinzips. Bei der Entwicklung des Protokolls stand die Einfachheit und Schnelligkeit (Skalierbarkeit) im Vordergrund. Im Gegensatz zu verbindungsorientierten Protokollen wie X.25 wird bei IP die Paketauslieferung nicht garantiert, so können z.B. bei Überlastzuständen Pakete verloren gehen. Höherliegende Protokolle wie das Transmission Control Protocol (TCP) reagieren auf derartige Paketverluste, wiederholen das verlorengegangene Paket, setzen die Senderate zunächst herab und erhöhen sie dann stufenweise wieder (TCP Slow-Start), um damit das Netz optimal auszunutzen.
Durch die Paketwiederholung tritt bei TCP-basierten Anwendungen eine hohe Verzögerung auf, das Netz wird durch den Slow-Start Mechanismus in der Folge eines Paketausfalls zunächst nicht optimal ausgenutzt. Eine Unterscheidung zwischen verschiedenen Anwendungen oder Anwendungsklassen findet hierbei normalerweise nicht statt, im Falle eines Überlastzustandes sind alle Anwendungen gleichartig betroffen, die nicht optimale Ausnutzung des Netzes multipliziert sich somit noch. Bei anhaltender Überlast kommt es durch den TCP Slow-Start Mechanismus zu Oszillationen der Paketausfälle bzw. der Netznutzung.
Abbildung 1: Netzdurchsatz in Abhängigkeit der offerierten Last
IP-basierte Netze können ohne weitere Maßnahmen daher nicht am Rande der Maximalauslastung betrieben werden. Eine gewisse Überdimensionierung der IP-Netze ist damit notwendig, aus wirtschaftlichen Gründen aber natürlich unerwünscht. Dies betrifft sowohl die Internet Service Provider (ISP) in ihren Backbonenetzen, als auch die ISP Kunden bezüglich ihrer Anschlußdimensionierung.
B.1 Begriffsbestimmungen: Quality of Service und Class of Service
Als Servicequalität (Quality of Service, QoS) bezeichnet man die Fähigkeit eines Netzes, einer Anwendung eine bestimmte Bandbreite, Verzögerung und Variation in der Verzögerung (Jitter) zur Verfügung zu stellen.
Die dafür notwendige anwendungsbezogene Reservierung von Ressourcen im Netzwerk erzeugt Zustand auf jedem vermittelnden Gerät auf dem Pfad zwischen Sender und Empfänger und ist daher schlecht skalierbar.
Die Reservierung von Ressourcen für eine Klasse von Anwendungen (Class of Service, CoS) nutzt die 3 Precedence Bits im IP-Header zur Festlegung von Anwendungsklassen. Hiermit können insgesamt 6 Serviceklassen gebildet werden (2 Bitkombinationen sind in der IP Spezifikation reserviert). Dieses Verfahren ist unabhängig von der Zahl der Anwendungen und damit sehr gut skalierbar.
B.2 Class of ServiceZur Realisierung eines CoS Dienstes ist eine entsprechende Klassifizierung der Pakete und ein intelligentes Warteschlangenmanagement in den vermittelnden Geräten notwendig, das entsprechend auf die Serviceklassen eingeht.
Pakete können abhängig von der genutzten Anwendung (TCP bzw. UDP Portnummer), IP Adresse oder Layer 2 Adresse klassifiziert werden (Commited Access Rate). Die Pakete können durch den Service-Anbieter oder durch den Kunden klassifiziert werden.
Die unterschiedlichen Serviceklassen können beispielsweise im Queueing unterschiedlich behandelt werden, auf diese Weise werden Pakete einer schlechteren Serviceklasse im Überlastzustand zuerst fallengelassen
Um Lastspitzen auszugleichen, werden in den vermittelnden Geräten (Router, Switches) Puffer eingesetzt. Bei einer Puffergröße von Q bytes, einer Übertragungsrate auf dem Medium von T bits pro Sekunde und einer Paketankunftsrate von A bits pro Sekunde, tritt ein Paketverlust nach (8 * Q) / (A – T) Sekunden ein.
In diesem Zustand wird jedes Paket um (8 * Q) / T Sekunden verzögert.
Bei einer Vergrößerung der Warteschlange sinkt die Wahrscheinlichkeit für einen Paketverlust, durch das Auftreten von kurzzeitigen Verkehrsspitzen variiert jedoch die Paketlaufzeit. Dies führt zu einer Instabilisierung der TCP Round Trip Timer. TCP kann sich so nicht mehr optimal auf die verfügbare Netzbandbreite einstellen.
Das normalerweise eingesetzte FIFO-Queueing (First In, First Out) ohne Management der Warteschlange führt zu dem oben beschriebenen Tail-Drop Queueing; in Überlastsituationen gehen alle eintreffenden Pakete, unabhängig von der Anwendung, verloren.
Das von Van Jacobsen und Sally Floyd (Lawrence Berkeley Lab) vorgeschlagene Random Early Discard Verfahren nutzt die Steuerungsmittel von TCP um vor vollständiger Auslastung einer Warteschlange die Last abzubauen. Steigt die Auslastung der Warteschlange über die minimale Schwelle, werden einzelne Pakete einer Anwendung vernichtet. TCP reagiert auf diesen Paketverlust mit der Herabstufung der Sendeleistung (Slow Start), der Überlastzustand sollte sich wieder abbauen. Bei weiterem Anhalten der Überlastung werden zunehmend mehr Pakete vernichtet, bis schließlich an der maximalen Schwelle alle Pakete vernichtet werden.
Abbildung 2: Random Early Discard vs. FIFO Queueing
Das Weighted-RED Verfahren nutzt für unterschiedliche Serviceklassen verschiedene minimale und maximale Schwellwerte.
![]()
Abbildung 3: Weighted RED
Beim Weighted Fair Queueing (WFQ) wird Paketen von Verkehrsflüssen mit niedriger Bandbreitennutzung eine höhere Priorität in der Warteschlange gegeben. Man erreicht dadurch eine vorhersagbare Reaktionszeit des Netzes für derartige Anwendungen, unabhängig von Überlastzuständen, die beispielsweise durch Dateitransfers ausgelöst werden.
Abbildung 4: Weighted Fair Queueing
Die anwendungsbezogene Reservierung von Ressourcen wird im Rahmen der Internet Engineering Task Force (IETF) von der Integrated Services (intserv) Gruppe standardisiert. Im Rahmen dieser Arbeitsgruppe wurde eine Anwendungsarchitektur zur Reservierung von Ressourcen geschaffen.
Das Resource Reservation Setup Protocol RSVP wird benutzt, um die Qualitätsanforderungen einer Anwendung auf dem Netzwerkpfad zwischen Sender und Empfänger bekannt zu machen. Jeder Router auf dem Pfad muß entsprechende Reservierungen vornehmen. Im Gegensatz zur statischen Reservierung von Bandbreite in einem ATM-Netzwerk verteilt dieses Verfahren die Ressourcen in einem Router durch intelligentes Queuemanagement dynamisch.
Die Reservierung von Ressourcen wird bei Nutzung von RSVP ausschließlich vom Empfänger gesteuert. RSVP verwaltet lediglich unidirektionale Ressourcen, für eine bidirektionale Kommunikation müssen zwei Reservierungen vorgenommen werden.
Durch den hohen notwendigen Verwaltungsaufwand in den vermittelnden Geräten und einem potentiellen Einfluß auf die Vermittlungsleistung eines Routers rät die IETF dazu, RSVP lediglich in begrenzten lokalen Netzen einzusetzen, ein B-WiN-weiter oder gar Internet-weiter Einsatz ist mit der gegenwärtigen Technologie nicht möglich.
Die Basiseigenschaften der gegenwärtigen IP Version 4 und der in Entwicklung befindlichen nächsten Version IP Version 6 im Bereich Quality of Service sind gleich. Die weit verbreitete Aussage, IP Version 6 biete einen "magischen Knopf" zur Realisierung von Quality of Service erweist sich leider als absolut falsch.
Im IPv6 Protokoll sind zwei Elemente enthalten, die eine Realisierung eines Class of Service Dienstes erleichtern. Zum einen ist im Header ein 4-bit Prioritätsfeld enthalten, dies ist funktionell gleich dem 3-bit langem Precedence-Feld im IPv4 Header. Die zweite Komponente ist ein Flow Label im Header, das es erleichtern soll, Pakete die zu einem Verkehrsfluß gehören, zu identifizieren. Eine gleichartige Technik wurde aber inzwischen in vielen Routern schon auf Basis von IPv4 entwickelt, das zusätzliche Headerfeld erweist sich also als überflüssig.
Eine Quality of Service wird unter IPv6 genau wie unter IPv4 mit Hilfe von RSVP realisiert, die unter B.3 geschilderten Skalierungsprobleme treffen somit auch für IPv6 zu.
Zur Zeit werden QoS oder CoS Technologien noch nicht in großem Umfang eingesetzt. Die unter B.3 aufgeführten Skalierungsprobleme lassen dies für die Nutzung von QoS auch in Zukunft als unwahrscheinlich erscheinen.
Verschiedene ISPs bereiten zur Zeit den Einsatz von CoS Techniken in ihren Netzen vor. Seit Ende 1997 ist zumindest von einem Hersteller (Cisco Systems) eine Implementierung verfügbar die in der Lage ist, alle für CoS notwendigen Merkmale ohne Leistungseinschränkung bei voller Leitungsbandbreite bis hin zu 155 Mb/s zu unterstützen. Eine echte Bewährung der Technik in Produktionsnetzen steht noch aus. Die mit CoS mögliche kontrollierte Auslastung des Netzes bis nahe an 100% führt dazu, daß die Technik aus wirtschaftlichen Gründen spätestens im 4. Quartal 1998 breitflächig eingesetzt wird. Die Anbieter im Bereich der Sprachübertragung in IP-Netzen werden die Technik bereits im 3. Quartal 1998 in Produktion einsetzen.
Ein besonderes Problem stellt dabei die Festlegung der Anzahl von Serviceklassen dar. Die meisten Provider beabsichtigen zur Zeit, lediglich eine Serviceklasse zusätzlich zum reinen best-effort Service anzubieten.
Die Überwachung der Servicequalität für den Kunden ist zur Zeit noch ungeklärt. Konventionelle Methoden wie ping oder traceroute scheitern im Falle von CoS, da derartige Pakete u.U. vom Netzwerk in einer anderen Serviceklasse behandelt werden.