Internet Traffic Modelling

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik 4 Prof. Dr. Otto Spaniol Ahornstraße Aachen Seminar Datenkommunikation und Verteilte-Systeme SS 2003 Internet Traffic Modelling Oliver Rattay Matrikelnummer Oliver.Rattay@gmx.net Betreuer: Markus Fidler 4. Mai 2003

2 Inhaltsverzeichnis 1 Einleitung 3 2 Klassische Warteschlangentheorie M M M G Verkehrsmodellierung Ein einfacher Ansatz Dienste im Überblick Messung Modellierung WWW-Modell Network-Game-Modell Telnet-Modell Zusammenfassung Fazit Literaturverzeichnis 25 2

3 1 Einleitung Durch das Internet werden heute eine Vielzahl von Kommunikationsdiensten ermöglicht, die teilweise sehr komplex zu charakterisieren sind. Der durch Anwendungen und Applikationen erzeugte Datenverkehr unterscheidet sich in vielen Punkten voneinander, so dass es unmöglich ist, den Verkehr mit einem einheitlichen Modell zu beschreiben. Eine weitere Beobachtung ist, dass die Anzahl der über das Internet realisierten Dienste stetig ansteigt. Dabei erhalten Vorhersagen über die erreichbare Qualität der Dienste für die bestehenden Netztopologien eine immer wichtigere Bedeutung. Um den Datenverkehr einigermaßen korrekt vorhersagen zu können, wurden mit der Zeit für diverse Dienste verschiedene Verkehrsmodelle entwickelt. Bereits seit dem frühen 20. Jahrhundert wurden auf Basis der Beobachtungen des Verhaltens von Telefonteilnehmern mathematische Modelle erstellt, um damit die notwendige Anzahl von Leitungen zum Erreichen einer festgelegten Dienstgüte zu bestimmen. Das Hauptziel der Verkehrsmodellierung ist es, geeignete Verkehrsbeschreibungen zu finden, mit denen die Erzeugung einer realistischen Last auf ein zu modellierendes System möglich ist. Die Modelle sollten immer möglichst einfach gehalten werden, um die Komplexität der Simulation zu begrenzen. Aus diesem Grund gibt es bei den verschiedensten Modellen immer eine Abstraktion auf wesentlichen Merkmale beziehungsweise Parameter. In den frühen Jahren der Verkehrsmodellierung wurden zum Beispiel Zwischenankunftszeiten von Datenpaketen im Internet häufig durch Poissonprozesse modelliert. Die zu den Poissonprozessen gehörenden Exponentialverteilungen sind einfach zu handhaben und haben nur einen Parameter. Im Laufe der Zeit hat sich jedoch herausgestellt, dass Zwischenankunftszeiten nur sehr selten exponentialverteilt sind. Poissonprozesse erreichen akzeptable Ergebnisse, wenn es darum geht, durch Menschen initiierte Verbindungen oder Aktivitäten zu modellieren. Zum Beispiel werden nutzerinitiierte TCP- Verbindungen 1 (zum Beispiel Telnet) durch Poissonprozesse beschrieben. Der größte Teil des Internetverkehrs wird jedoch automatisch (nicht direkt durch den Nutzer) generiert und enthält viele Abhängigkeiten, die nicht direkt von Poissonprozessen berücksichtigt werden. Wenn es darum geht Zwischenankunftszeiten für das Eintreffen von Datenpaketen zu modellieren, hat sich herausgestellt, dass der Verkehr von Diensten mit kleineren Datenmengen, wie zum Beispiel (SMTP) und Newsgroups (NNTP) in der Regel nicht durch Poissonprozesse modelliert werden kann, da sie häufig automatisch erzeugt werden. Der Benutzer initiiert zwar das Überprüfen seines -Postfachs, aber der - Client überprüft dann automatisch die -Konten nach neuen s und lädt diese 1 Transmission Control Protocol wurde 1974 entwickelt und stellt eine sichere Ende-zu-Ende Verbindung auf der Transportebene her 3

4 nacheinander herunter. Aber auch Dienste, die größeren Datenverkehr erzeugen, werden nur schlecht durch Poissonmodelle modelliert. Wie oben erwähnt, können die Ankünfte der Kontrollverbindungen beim Dateitransfer 2 (FTP) durch Poissonmodelle wiedergegeben werden. Realistische FTP-Datenverbindungen können dagegen nicht durch Poissonmodelle modelliert werden. In Abschnitt 3 werden einige Gründe genannt, warum Poissonprozesse nur zur Modellierung von nutzerinitiierten Verbindungen (Telnet-Verbindung, FTP-Kontrollverbindungen,... ) geeignet sind und für andere Ankunftsprozesse in Wide Area Netzwerken völlig ungeeignet sind. Paketankunftsprozesse in WAN werden zum Beispiel deutlich besser durch selbstähnliche Prozesse modelliert. Diese Ausarbeitung gliedert sich in drei Teile. Im Abschnitt 2 wird eine kurze Einführung in die klassische Warteschlangentheorie gegeben. Hier werden unter anderem die Formeln, auf denen die Poissonmodelle basieren, kurz beschrieben. In Abschnitt 3 wird ein einfacher Ansatz zur Modellierung und Zusammenhänge beziehungsweise Ursachen für den Internetverkehr erläutert. Daraufhin werden dem Leser verschiedene Internetdienste beziehungsweise Applikationen und ihre Besonderheiten vorgestellt. Es werden verschiedenen Methoden zur Verkehrsmessung erläutert und drei einfache Modelle für verschiedene Dienste vorgestellt. In Abschnitt 4 erfolgt abschließend eine kurze Zusammenfassung. 2 File Transfer Protocol ist ein Internet-Standard zur Übertragung von Dateien und benötigt zwei TCP-Verbindungen (Kontroll- und Datenverbindung) 4

5 2 Klassische Warteschlangentheorie Ein wesentlicher Bestandteil bei der Modellierung von Internetverkehr sind Wartesysteme. Sie stellen die Basis für Verkehrsmodelle dar. Im Allgemeinen ist ein Wartesystem die Kombination einer Warteschlange mit einer oder mehreren Bedieneinheiten. Im Internet handelt es sich dabei meist um Verbindungen, die durch Router genutzt werden. Die im Router eintreffenden Datenpakete werden in einer Warteschlange zwischengespeichert und der Reihe nach abgearbeitet. Warteschlangen können in der Kendallschen Notation spezifiziert werden: Verteilung der Zwischenankunftszeiten Verteilung der Bedienzeiten # Bedieneinh. Für die Verteilung der Zwischenankunftszeiten und der Bedienzeiten können folgende Abkürzungen verwendet werden: M Exponentialverteilung (Markov-Eigenschaft) G Allgemeine Verteilung E k Erlangverteilung mit k Phasen H k Hyperexponentialverteilung mit k Phasen D Deterministische Verteilung (konstante Zeitintervalle) Außerdem kann noch zusätzlich eine Bedienstrategie festgelegt werden. Sie gibt an, welches Paket aus der Warteschlange als nächster bedient wird. Es existieren diverse Standardstrategien, auf die hier nicht weiter eingegangen werden soll: FIFO (First-In-First-Out) LIFO (Last-In-First-Out) SIRO (Service-In-Random-Order) RR (Round Robin) Das Ziel der Analyse von Wartesystemen ist die Ermittlung von Werten für Auslastung, Durchsatz und Wartezeit. Die Analyse eines Wartesystems ist im wesentlichen abhängig von der Ankunftsrate λ und der Bedienrate µ. Exponentialverteilte Zwischenankunftsund Bedienzeiten stellen den einfachsten Fall dar. Der Zustand n eines Wartesystems wird durch die Anzahl der Pakete im System zu einem bestimmten Zeitpunkt definiert. Dabei wird nicht unterschieden, ob das Paket gerade bearbeitet wird oder sich noch in der Warteschlange befindet. Das Verhältnis zwischen Ankunftsrate und Bedienrate wird Last ρ genannt. Die Wahrscheinlichkeit, dass sich gerade n Pakete im Wartesystem befinden, wird durch p(n) gekennzeichnet. 5

6 2.1 M M 1 Bei einem M M 1-System gibt es exponentialverteilte Ankunfts- und Bedienzeiten. Beide Prozesse sind gedächtnislos. Zum einen heißt dies, dass die Ankünfte der einzelnen Pakete völlig unabhängig voneinander erfolgen. Zum anderen ist die Bedienzeit eines Paketes unabhängig davon, wieviel Bedienzeit es schon erhalten hat. Außerdem existiert nur eine einzige Bedieneinheit im System. Dieses System ist auch heutzutage noch oft die Grundlage für Verkehrsmodelle im Internet. Die mittlere Anzahl von Paketen in einem M M 1-System wird mit folgender Formel berechnet: E[N] = n p(n) = ρ 1 ρ n=0 Die Varianz der Anzahl der Pakete berechnet sich wie folgt: V ar[n] = E[N 2 ] (E[N]) 2 = ρ (1 ρ) 2 Die Wahrscheinlichkeit, dass sich n oder mehr Pakete im System aufhalten, wird wie folgt ermittelt: P ( n Pakete im System) = p(i) = (1 ρ) ρ i = ρ n i=n i=n Das sogenannte Little sche Gesetz stellt eine direkte Beziehung zwischen der mittleren Verweilzeit, der Ankunftsrate und der mittleren Paketanzahl im System her. Die mittlere Kundenzahl wird durch das Produkt aus Ankunftsrate und mittlerer Verweilzeit berechnet. Eine direkte Beziehung zwischen Warteschlangenlänge, Abgangsrate und mittlerer Wartezeit lässt sich durch geschickte Umformung herstellen. Die mittlere Warteschlangenlänge ist dann gleich dem Produkt der Abgangsrate und der mittleren Wartezeit im System. 2.2 M G 1 In einem M G 1-System sind die Ankünfte exponentialverteilt. Im Gegensatz zu M M 1- Systemen ist der Bedienprozess nicht gedächtnislos. Das heißt, dass die Zeit bis zum nächsten Abgang eines Pakets von der schon erhaltenen Bedienzeit des aktuellen Pakets abhängt. Die Bedienzeit ist zwar bekannt, hat aber eine beliebige Verteilung (gegeben durch eine Verteilungsfunktion oder durch einen Mittelwert und eine Varianz). Bei diesem System ist der Bedienprozess nicht mehr so stark eingeschränkt, wie bei den M M 1-Systemen. Auch im M G 1-System gibt es nur eine Bedieneinheit, welche die Warteschlange nach dem FIFO-Prinzip abarbeitet. Das Interesse gilt nun der mittleren Anzahl von Paketen im M G 1-System. Nach Berechnung dieser Werte, können mit dem Little schen Gesetz weitere Werte bestimmt werden. 6

7 Ein eintreffendes Paket findet im Mittel E[N] Pakete im System vor. ρ Pakete sind in der Bedieneinheit, während E[N] ρ Pakete warten. E[S Rest ] bezeichnet die mittlere Bedienzeit (Restzeit), die das aktuelle Paket noch bedient wird. Die mittlere Systemzeit eines neuen Pakets ergibt sich somit aus: E[S] := Restbedienzeit + Bedienung der wartenden Pakete + eigene Bedienung E[S] := ρ E[S Rest ] + (E[N] ρ) 1 µ + 1 µ Mit Hilfe des Little schen Gesetzes gilt nun: E[N] = λ E[S] Nach einsetzen und umformen nach E[N] ergibt sich: E[N] = ρ + λ E[S Rest ] ρ 1 ρ Da die Restbedienzeit E[S Rest ] durch E[x2 ] 2 E[x] ersetzt werden kann, ergibt sich: E[N] = ρ + λ E[x 2 ] 2 E[x] ρ 1 ρ Die Bediendauer wird durch x dargestellt, so dass die mittlere Bediendauer E[x] = 1 µ beträgt. Somit kann ρ durch λ ersetzt werden und es ergibt sich für die mittlere Anzahl E[x] von Paketen im System: E[N] = ρ + λ2 E[x 2 ] 2 (1 ρ) Mit Hilfe des Little schen Gesetzes können noch weitere Varianten der sogenannten Pollaczek-Khinchin-Formeln 1 hergeleitet werden: Mittlere Wartezeit: W = λ E[x2 ] 2 (1 ρ) Mittlere Systemzeit: E[S] = 1 µ + λ E[x2 ] 2 (1 ρ) Durchschnittliche Warteschlangenlänge: E[N q ] = λ W = λ2 E[x 2 ] 2 (1 ρ) In den Formeln ist erkennbar, dass die mittlere Wartezeit mit der Streuung der Bedienzeit E[x 2 ] wächst. Die P-K-Formel wurde lange als Grundlage für die Modellierung von Systemen verwendet. Man ist davon ausgegangen, dass diese Formel realistischen Verkehr erzeugen, beziehungsweise modellieren kann. In Abschnitt 3.4 wird jedoch gezeigt, dass 1 nach den beiden Erfindern Pollaczek und Khinchin, die unabhängig voneinander Anfang der dreißiger Jahre die Verteilung der Wartezeiten für M G 1-Systeme bestimmt haben 7

8 realer Internetverkehr auch eine unendliche Varianz haben kann. Die P-K-Formel erzeugt in diesem Fall jedoch keine endlichen Ergebnisse, da E[x 2 ] im Zähler der P-K-Formeln vorkommt. Dies gilt auch, wenn das System stabil ist, also ρ < 1. Ein weiterer Nachteil ist, dass die P-K-Formel ausschließlich M G 1-Systeme beschreibt. Für die Praxis wäre eine Beschreibung eines G G 1-Systems wünschenswert. In diesem System wäre neben dem Bedienprozess auch der Ankunftsprozess nicht gedächtnislos. Diese Korrelationen sind in realem Internetverkehr häufig anzutreffen. Ein typisches Beispiel für die Korrelationen im Ankunftsprozess ist das MPEG-Video-Streaming. Bei einem Video werden die einzelnen Bilder mit einer konstanten Bildrate übertragen. Der Zeitabstand zwischen zwei Bildern ist also im Idealfall konstant. Diese Eigenschaft verletzt aber die Gedächtnislosigkeit, so dass Videoverkehr nicht durch ein M G 1-System beschrieben werden kann. 8

9 3 Verkehrsmodellierung 3.1 Ein einfacher Ansatz Um Modelle für realen Internetverkehr erstellen zu können, ist es notwendig sich zuerst über den grundlegenden Aufbau Gedanken zu machen. Es hat sich als praktisch erwiesen, zwischen den Aktivitäten von Benutzern, Anwendungen und Protokollen zu unterscheiden. Auf jeder Ebenen gibt es verschiedene Modellierungsansätze für Verkehrsmodelle. In Abbildung 3.1 sind die einzelnen Aktivitätsebenen übersichtlich dargestellt. Die Abbildung stellt noch kein Modell dar. Sie dient lediglich als Denkansatz, um die Abhängigkeiten einzelner Ebenen besser zu erkennen. Die Zusammenhänge der einzelnen Ebenen erklären sich dadurch, dass eine Ebene eine vergrößerte Teilansicht der darüberliegenden Ebene ist. Einwahl Zugangssitzung Zugangssitzungsebene Anwendungssitzung Anwendungssitzung Anwendungssitzung Anwendungssitzungsebene Client Server Anforderung Antwort Anforderung Antwort }Dialogebene Verbindung Verbindung Verbindungsebene bidirektional Burst Burst Burst Burst Burst Paket Paket Paket Paket Paket Burst-Ebene Paketebene Abbildung 3.1: Zusammenhang der einzelnen Aktivitätsebenen Zu Beginn wählt sich der Nutzer in das Internet ein, um Zugang zu erhalten. Während einer Zugangssitzung können verschiedene Anwendungen ( -Client, Webbrowser,... ) auf das Internet zugreifen. Jedes dieser Programme erzeugt eine, beziehungsweise mehrere Anwendungssitzungen. In einer Anwendungssitzung können diverse Dialoge zwischen den verbundenen Rechnern ablaufen (zum Beispiel s senden, s empfangen,... ). Diese bestehen aus einer Client-Anforderung und einer entsprechenden Server-Antwort. Die einzelnen Dialoge können zu Verbindungen zusammengefasst werden. Das Transmission Control Protocol (TCP) stellt dabei eine gesicherte, virtuelle Ende-zu-Ende-Verbindung auf Basis des verbindungslosen Paketübermittlungsdienstes Internet Protocol (IP) im Internet bereit [T02]. 9

10 Innerhalb einer Verbindung werden dabei in der Regel Pakete in beide Richtungen ausgetauscht. Sowohl Anwendungen als auch das Transportprotokoll TCP benötigen den bidirektionalen Datentransfer, um zum Beispiel die Bestätigung zu erhalten, dass das soeben gesendete Datenpaket auch tatsächlich angekommen ist. Wie in Abbildung 3.1 zu sehen ist, ergeben sich für den Datenaustausch im Internet selten gleichmäßige Datenströme. Datenpakete werden häufiger in sogenannten Bursts übertragen. Ein Grund für diese Bursts ist der Flusskontrollmechanismus im TCP-Protokoll. In Abbildung 3.2 ist zu sehen, das TCP bei erfolgreicher Übertragung die Fenstergröße 1 solange vergrößert, bis eine Bestätigung für den Erhalt eines Paketes nicht mehr angekommen ist und von einem Paketverlust ausgegangen wird. Die Fenstergröße wird dann wieder auf ein Minimum gesetzt. Ein weiterer Grund für die Entstehung von Bursts liegt in den Anwendungsprotokollen. Beim File Transfer Protokoll (FTP) wird zum Beispiel zuerst mittels kleinerer Datenpakete in das gewünschte Verzeichnis gewechselt, um dann anschließend größere Datenmengen herunter- oder hochzuladen. Fenstergröße (in Kilobytes) Treshold TCP setzt die Fenstergröße auf kleinsten Wert Paketverlust (Überlast vermutet) neuer Treshold Übertragungsfenster Abbildung 3.2: Paketgrößen im TCP-Protokoll Das User Datagram Protocol (UDP) ist gegenüber dem TCP-Protokoll sehr einfach gehalten. UDP ist, wie auch IP, verbindungslos und unzuverlässig. Es gibt also keine gesicherte Ende-zu-Ende-Verbindung. Durch die geringe Zuverlässigkeit erreicht UDP jedoch einen schnellen Austausch von Informationen. Im Gegensatz zu TCP werden im UDP-Protokoll keine Bestätigungen für empfangenen Pakete versendet. Bei UDP werden die durch Prüfsummen erkannten fehlerhaften Pakete einfach verworfen. Falls eine Neuübertragung notwendig ist, muss diese von der Anwendung selbst durchgeführt werden. Im UDP-Protokoll sind hierfür keine Mechanismen verfügbar. Auch bei Verwendung des UDP-Protokolls entstehen häufig Daten-Bursts. Die meisten Modelle für die verschiedenen Ebenen können in Nutzer-, Anwendungs-, 1 die Fenstergröße beschreibt die Anzahl von Bytes beziehungsweise Paketen, die vom Sender losgeschickt werden können, ohne dass eine Bestätigung für den Erhalt der vorherig gesendeten Pakete angekommen ist 10

11 Transportprotokoll- und Netzmodelle eingeteilt werden. Zwischen jedem dieser Teilmodelle kann ein bidirektionaler Informationsfluss stattfinden. Es bestehen zwei grundlegende Möglichkeiten, den gesamten Verkehr an einem Punkt im Netz nachzubilden. Die erste Möglichkeit besteht darin, Modelle zu verwenden, welche eine Anwendung eines einzelnen Nutzers modellieren. Durch Addition mehrerer Instanzen solcher Modelle kann der Gesamtverkehr schließlich nachgebildet werden. Eine andere Möglichkeit besteht darin, Modelle für den Summenverkehr zu erstellen, die den Verkehr für eine größere Anzahl von Nutzern und Anwendungen modellieren. Die Summenmodelle kommen mit nur wenigen Parametern aus, da sie sonst zu komplex würden. In der Praxis hat sich herausgestellt, dass die Ergebnisse schlechter sind, wenn Parameter von einzelnen nutzer- und anwendungsbezogenen Modellen auch für Modelle verwendet werden, die den Gesamtverkehr beschreiben. Es ist besser die Parameter direkt aus repräsentativen Gesamtverkehrsmessungen zu bestimmen. 3.2 Dienste im Überblick Bei der Modellierung von Internetverkehr sollte immer berücksichtigt werden, dass sich der Gesamtverkehr aus einer Vielzahl von Diensten und Applikationen zusammensetzt. Vor einigen Jahren bestand der Gesamtverkehr noch im wesentlichen aus World-Wide- Web- (HTTP), - (SMTP) und Dateitransfer-Verkehr (FTP). Tabelle 3.1 zeigt die Anteile der einzelnen Dienste für das Jahr 1997 [TMW97]. Aber spätestens mit der großflächigen Durchsetzung von Breitbandzugängen (ADSL, Kabelmodem,... ) und pauschalen, unbeschränkten Internetzugängen hat sich die Zusammensetzung deutlich verändert. Heutzutage spielt der Verkehr, der durch Peer-To-Peer-Netze, Multimediastreaming und Netzwerkspiele verursacht wird, eine immer größere Rolle. Dienst Anteil (in %) an Bytes Paketen WWW SMTP 5 5 FTP 5 3 NNTP 2 <1 DNS 1 3 Tabelle 3.1: Verkehrszusammensetzung (Stand: 1997) Der Verkehr, der durch Netzdienste wie Namensauflösung (DNS) entsteht, sollte dabei nicht vernachlässigt werden. Immerhin benötigen so gut, wie alle oben genannten Dienste die Namensauflösung, um die IP-Adressen der Webserver, server oder auch Gameserver festzustellen. Ferner gibt es noch interaktive Dialogkommunikation, wie zum Beispiel Telnet, Internet-Relay-Chat (IRC) oder Sprach- und Videokommunikation. In lokalen Netzen kann es noch zusätzliche Dienste und Kommunikationsarten geben. Zu den populärsten zählen 11

12 hier beispielsweise Datei- oder Druckserver. Diese Anwendungen spielen jedoch für den globalen Internetverkehr nur eine untergeordnete Rolle. Die typische Charakterisierung von Verkehr auf einer gegebenen Ebene wird in erster Linie durch den Zeitpunkt des Eintreffens und der Größe einer Anforderung, beziehungsweise der damit verbundenen Bearbeitungsdauer beschrieben. Für die Messung und Modellierung von WWW-Verkehr sind zum Beispiel die Verteilung der Dateigrößen, die Anzahl der angeforderten Dateien pro Sitzung und die Anzahl der angeforderten Dateien pro Webseite wichtig. Hier muss jedoch beachtet werden, dass nicht alle Dateien direkt vom Nutzer angefordert werden. Der Nutzer fordert in der Regel nur die Datei einer Webseite (zum Beispiel index.html) an. Der Webbrowser des Nutzers fordert dann selbständig die Dateien der Inline-Objekte (Frame-Dateien, Bilder, Animationen,... ) der aufgerufenen Seite an. Hierdurch entstehen Daten-Bursts, die nur schlecht in klassischen Wartesystemen berücksichtigt werden. Wichtige Parameter auf der Nutzerseite sind die Geduldsspanne für das Laden von Seiten und die Dauer des Lesevorganges bis zum Aufruf der nächsten Seite. Die zu beobachtenden Paketgrößen sind wegen der Funktionsweise von TCP und IP nicht nur durch die besonderen Anforderungen oder Eigenschaften des betrachteten Dienstes bestimmt, sondern auch durch technische Eigenschaften und Konfigurationsparameter der Endsysteme und Netzkomponenten. Dies sollte bei allen Messungen und Modellierungen berücksichtigt werden. Auch die Reihenfolge der Datenpakete wird zu einem großen Teil durch die Anwendungen auf Client- und Serverseite bestimmt. Zum Beispiel erlauben manche Browser beziehungsweise Webserver die Dateien einer Webseite mit den dazugehörigen Inline-Objekten parallel durch mehreren TCP-Verbindungen zu laden. Andere Browser laden die Dateien nacheinander in einer einzigen TCP-Verbindung. Beim Verkehr der durch Netzwerkspiele verursacht wird, herrscht eine grundsätzlich andere Situation als beim WWW-Verkehr. Netzwerkspiele, wie zum Beispiel das weit verbreitete Counter Strike, erzeugen ein sehr gleichmäßiges Transfermuster. Die meisten Echtzeitspiele verwenden das UDP-Protokoll, da hiermit kürzere Antwortzeiten erzielbar sind. Der Gameserver sendet die aktuellen Statusinformationen an alle Client-Rechner. Diese werten die Statusinformationen dann lokal aus. Sie ergänzen ihren lokalen Spielstatus, führen die Spieleranweisungen aus und schicken sogenannte Update-Datenpakete, welche die Spielerbewegung und die neuen Statusinformationen enthalten, an den Gameserver. Sowohl die Statusinformationspakete vom Server, als auch die Updatepakete der Clients bestehen in der Regel nur aus wenigen Bytes. Abbildung 3.3 zeigt einen typische Verkehrsverlauf für Server und Clients bei Netzwerkspielen. Die gleichmäßige Verteilung des erzeugten Client-Verkehrs ist deutlich zu erkennen. Die Einschnitte, in denen kein Verkehr vom Client erzeugt wird, sind durch Rundenende und Level-Wechsel zu erklären. Der durch den Gameserver erzeugte Verkehr ist dagegen zwar wesentlich variabler, so sind aber auch hier die einzelnen Spielrunden noch zu erkennen. Insgesamt ergaben Messungen in [F02], dass der Gameserver eine durchschnittliche Datenrate von 16,4 kbit/s je Client und die Clients eine durchschnittliche Datenrate von 15,7 kbit/s erzeugten. Neben den Datenraten ist das Eintreffen von Verbindungen für Modelle ein weiterer wichtiger Punkt. Bei Vergleichen der Verbindungsankunftsraten verschiedener Dienste 12

13 Server packet rate [1/s] data rate [kbit/s] Client time [min] Figure 1: Example of server and typical client traffic of a 1h session consider busy periods. This means that we have only considered interarrival times less than 1 second in the following evaluations. Figure 2 shows the probability density function f(x) of the packet interarrival time from server to client. Only 8 out of 27 clients active in the first match are depicted in this figure. While 3 clients probability density function probability density function Abbildung 3.3: Beispiel des Server- und Clientverkehrs clearly have a smaller packet interarrival time (client 2 and 3 in the figure) the other 24 clients show almost exactly the same density function. An evaluation of all clients results in a peak at 55 ms and a mean of 62 ms. The coefficient of variation is around 0.5. wurden deutliche Unterschiede festgestellt. Zum Beispiel häufen sich - und Telnet- Verbindungen während der Arbeitszeit. Bei Dateitransfer-Verbindungen wurde dagegen auch noch ein Anstieg der Verbindungsrate in den Abendstunden festgestellt. Dies wird auf die günstigeren Internettarife in den späten Abendstunden zurückgeführt. Die Vari anz der Verbindungsrate verhindert1 in den meisten Fällen eine vernünftige Modellierung durch Poissonprozesse. Verbindungen 4 für Newsgroup-Dienste (NNTP) sind dagegen fast völlig ohne zeitlichen Schwerpunkt -1 6und verteilen sich sehr konstant über den Tag. Sie 7 haben dafür jedoch eine sehr Extreme(55,6) starke Burst-Charakteristik In [PF95] wurde eine Möglichkeit getestet, um weiterhin -2 0Poissonmodelle verwenden zu können. Da Poissonmodelle konstante Ankunftsraten erzeugen, 2 setzte man voraus, dass innerhalb eines festgelegten Zeitintervalls (zum Beispiel eine 4 Stunde) die Ankunftsrate konstant sei. So bestand die Möglichkeit die Ankunftsprozesse 6 innerhalb dieser Zeitinter- durch homogene Poissonprozesse zu modellieren. Es 7 0valle 10-4 Extreme(55,6) stellte sich jedoch heraus, dass lediglich die Zwischenankunftszeiten für Telnet- und FTP-Kontrollverbindungen eini- packet interarrival time [ms] packet interarrival time [ms] germaßen korrekt wiedergegeben wurden. Die Zwischenankunftszeiten für Newsgroup-, Figure 2: Probability density function of WWW-, server packet - interarrival und time FTP-Daten-Verbindungen per client waren dagegen nicht durch Poissonmodelle beschreibbar packet size [byte] Figure 4: Probability density function of server packet size per client complementary distribution function complementary distribution function Figure 3: Complementary cumulative distribution function of server packet interarrival time per client Die Zwischenankunftszeiten von Paketen 0 können nicht 0 durch Poissonmodelle beschrieben werden, da die Burst-Eigenschaften 2 zu ausgeprägt sind. Bei FTP-Datenverkehr wird die Burst-Eigenschaft dadurch 4 erzeugt, dass 10-1 der Nutzer mehrere Dateien zum herunterladen auswählen kann. Diese 6 werden dann schnell hintereinander durch die 7 FTP-Datenverbindung transferiert. Extreme(120,36) Neben den Datenpaketen können aber auch Verbindungen in Bursts auftreten. Zum Beispiel initiiert -2 der 0 Nutzer bei Newsgroup- und Verkehr eine erste Verbindung, die dann unter Umständen 2 sehr viele nachfolgende Verbindungen nach sich zieht Extreme(120,36) 3.3 Messung packet size [byte] Figure 5: Complementary cumulative distribution function of server packet size per client Die Verkehrsmessung dient im wesentlichen der Bestimmung einzelner Parameter für Modelle des Summenverkehrs. Bei jeder Messung sollte das Ziel klar definiert sein, da- 13

14 mit nicht unnötige Daten protokolliert werden. Die benötigten Messgrößen werden im wesentlichen durch die betrachtete Ebene festgelegt. Messungen auf höheren Ebenen sind in der Regel nicht direkt durchführbar, da die Daten in TCP- beziehungsweise IP-Pakete zerlegt werden. Aus diesem Grund werden die meisten Messungen auf IP-Ebene durchgeführt. Wichtige Messgrößen sind Ankunftszeitpunkte von Paketen, Protokolltyp und IP-Adressen. Manchmal ist es jedoch nicht möglich von den Messungen auf der IP-Ebene auf vernünftige Werte der höheren Ebenen zu schließen. Zum Beispiel ist die Bestimmung von nutzergenerierten HTTP-Anfragen im WWW-Verkehr kaum möglich. Auf IP-Ebene kann nicht zwischen den von Benutzern generierten HTTP-Anfragen und den automatisch vom Browser generierten Anfragen für Inline-Objekte unterschieden werden. Dieses Problem kann durch die Verwendung der Zwischenankunftszeit der HTTP- Anfragen beseitigt werden. Anfragen, die sehr schnell hintereinander eintreffen werden den automatisch erzeugten Anfragen zugeordnet [M97]. Diese Abschätzungen sind sicherlich nicht sehr exakt, helfen aber, brauchbare Ergebnisse zu erzielen. Die Art und Weise, wie diese Größen gemessen werden hängt von der gewünschten Messqualität ab. Eine einfache Möglichkeit ist die Verwendung von implementierten Logbuchfunktionen auf einem Gateway-Rechner. In diesem Fall protokolliert der Rechner jedes passierende Paket. Dies kann jedoch zu Messfehlern führen, da Rechenzeit für die Protokollierung benötigt wird. Gerade in Phasen mit hoher Netz- und Kapazitätsauslastung führt dies unter Umständen zu erheblichen Messfehlern. Eine bessere Möglichkeit stellt die Verwendung von passiven Messgeräten dar. Die speziellen Messgeräte können den Verkehr passiv mitprotokollieren. Somit ist eine Verfälschung der Messung durch zusätzliche Belastung ausgeschlossen. Weitere, wichtige Entscheidungen ist die Festlegungen von Messort, Messzeitpunkt und Messdauer. Je nach Verwendungszweck der Messdaten empfiehlt es sich, den Messort genau zu wählen. Bei Messungen für WWW-Verkehr kann ein Messpunkt entweder näher am Server oder näher an den Clients gewählt werden. Je nach Wahl des Messpunktes entstehen unterschiedliche Verzögerungen in den Anfragen und Antworten von Client und Server. Zudem ändert sich die Zusammensetzung des Verkehrs mit dem Messort. Messungen, die näher am Client durchgeführt werden, repräsentieren den Verkehr einzelner Nutzer, während Messungen, näher am Webserver, eher die Auslastung der Server beschreiben. Zur Messdauer bleibt zu sagen, dass sie entsprechend den Anforderungen gewählt werden sollte. Soll eine repräsentative Durchschnittsmessung durchgeführt werden, sollte die Messdauer mindestens so lange sein, dass besondere Variationen, wie beispielsweise Wochenendnutzung, Tag- und Abendnutzung mehrmals berücksichtigt werden. 3.4 Modellierung Wie schon in Abschnitt 3.2 beschrieben, setzt sich der Internetverkehr in der Praxis aus dem von verschiedenen Diensten und Anwendungen erzeugten Datenverkehr zusammen. Aus diesem Grund werden meist Modelle für einzelne Dienstarten erstellt, die sich gut dafür eignen, dienstbezogene Leistungsmerkmale, wie zum Beispiel die erreichbare 14

15 Dienstgüte (Quality of Service) bei verschiedenen Warteschlangenstrategien und in verschiedenen Netztopologien zu modellieren. Die getrennte Betrachtung von Diensten ist sinnvoll, da die Anteile des Verkehrs einzelner Dienste sehr unterschiedlich sind (siehe Tabelle 3.1). In den folgenden Abschnitten werden drei Modelle für verschiedene Dienste genauer betrachtet WWW-Modell In [CFV02] wurde ein reaktives WWW-Verkehrsmodell auf Paketebene vorgestellt, das sich in Nutzer-, Anwendungs- und TCP-Ebene unterteilt. Abbildung 3.4 zeigt den im Modell nachgebildeten zeitlichen Ablauf des Abrufs einer WWW-Seite mit allen Inline- Objekten durch alle drei Ebenen. Der Benutzer startet den Abruf durch das Anklicken eines Links. Nachdem der Webbrowser die durch den Anwender erzeugte HTTP-Anfrage an den Webserver gesendet hat, erwartet dieser vom Server eine Antwort mit dem HTML-Objekt (Initial-Objekt). Dieses erste Objekt wird dem Anwender durch den Browser angezeigt. Der Browser überprüft das HTML-Objekt auf weitere eingebettete Objekte (Inline-Objekte) und erzeugt selbständig weitere Anfragen für diese Objekte. Nutzer Klick Dienst & Browser parallele TCP Verbindungen Anfrage Initial - Antwort Antwort Ungeduld Inline 4 Inline 1 Inline 2 HTML Inline 3 Seitenabruf abgeschlossen Inline 5 Betrachtungsdauer Klick... Abbildung 3.4: WWW-Verkehrsmodell 15

16 In der Realität dauert es maximal eine feste Zeitspanne bis der Nutzer einen neuen Link anklickt, nachdem er einen Link angeklickt hat. Diese Zeitspanne gibt die Ungeduld des Nutzers an. Der Timer wird beendet, falls alle eingebetteten Objekte vor Ablauf der Ungeduldsspanne eintreffen. Danach beginnt eine zweite Zeitüberwachung. Sie gibt die Betrachtungsdauer des Nutzers an und wird sofort beendet, wenn ein neuer Link angeklickt wurde. Es ist nicht genau bestimmbar, wann die Betrachtungsdauer des Nutzers anfängt. Häufig werden schon nach Eintreffen des ersten HTML-Objekts, Texte oder Strukturen der Webseite durch den Nutzer wahrgenommen. Andere Webseiten benötigen wiederum das Fertigladen aller eingebetteten Objekte, damit der Nutzer die Webseite betrachten kann. Die Ungelduldsdauer und die Betrachtungsdauer werden in diesem Modell als Parameter verwendet. Um den WWW-Verkehr bestmöglich modellieren zu können, müssen für jede der drei Ebenen mehrere Parameter definiert und bestimmt werden. Wie in Abschnitt 3.3 schon beschrieben, können nicht alle Parameter exakt bestimmt werden. Aus diesem Grund werden häufig Heuristiken zur Abschätzung solcher Parameter genutzt und durch Auswertung von Verkehrsmessungen bestimmt. Viele charakteristische Parameter von realem Internet-Verkehr weisen extrem hohe Varianzen auf. In den Abbildungen 3.5 und 3.6 sind die komplementären Verteilungsfunktionen für die Größe der Anfragenachrichten, die Größe der Antwortnachrichten, die Anzahl der eingebetteten Objekte pro Seite sowie die gemessene Dauer bis zum nächsten nutzergenerierten Seitenabruf abgebildet. Die abgebildeten Daten stammen von Messungen am Zugangsknoten des Hochgeschwindigkeitsnetzes Selfnet e.v. [Selfnet] der Studentenwohnheime der Universität Stuttgart. Abbildung 3.5 (links) zeigt, dass etwa 99% aller Nachrichten wesentlich kleiner als 1460 Bytes sind. Bei der üblicherweise verwendeten Paketgröße (Maximum Transmission Unit) von 1500 Byte können diese in einem einzigen IP-Paket transportiert werden. Im Mittel waren die beobachteten HTTP-Anfragen 380 Bytes groß. 1 1 Komplementäre Verteilungsfunktion 0,1 0, Komplementäre Verteilungsfunktion 0,1 0,01 0,001 Initiale Antwort Inline Antwort 0,001 0,01 0, HTTP Anfragegröße [Bytes] HTTP Antwortgröße [Megabytes] Abbildung 3.5: Größenverteilung der HTTP-Anfragen und -Antworten Die Antwortgrößen zeigen eine deutlich größere Spannweite als die Anfragegrößen. Angefangen von wenigen hundert Bytes bis hin zu mehreren Megabytes. Die rechte Seite der Abbildung 3.5 zeigt, dass die Initial-Objekte, die normalerweise nur HTML-Code enthalten, umfangreicher sind als die Inline-Objekte. Bei den Messungen wurden allerdings keine Initial-Objekte beobachtet, die größer als drei Megabytes waren. Für beide 16

17 Parameter wurden sehr große Varianzen gemessen, weshalb die Angabe eines Mittelwerts nicht sinnvoll ist. Ein Ansatz die Varianz zu verkleinern ist die Unterscheidung nach verschiedenen Dateitypen (Text, Bild, Video, Binär,... ). Wie Abbildung 3.6 (linker Teil) zeigt, variiert die Anzahl der eingebetteten Objekte von null bis zu fast 1000 referenzierten Objekten. Die Verteilungsfunktion weist für große Werte ein deutliches Abfallen nach dem Potenzgesetz auf. Die Hälfte aller Klicks fordert Webseiten mit weniger als drei Inline-Objekten an. Komplementäre Verteilungsfunktion 1 0,1 0,01 0,001 0, Anzahl von Inline-Objekten Komplementäre Verteilungsfunktion 1 0,1 0,01 0,001 Klick Zwischenankunftszeit Betrachtungsdauer Seitenabrufdauer 0, HTTP Antwortgröße [Bytes] Abbildung 3.6: Verteilung der Anzahl der Inline-Objekte in einer Anforderung sowie die Zwischenankunftszeit der Klicks, Betrachtungsdauer und Dauer eines Seitenabrufs Unabhängig davon, ob die Betrachtungsdauer bereits nach Eintreffen des ersten Objektes oder erst nach dem Laden aller eingebetteten Objekte beginnt, ist sie direkt messbar. Die Nutzerungeduld ist hingegen nicht direkt feststellbar. Sie tritt nur unmittelbar in Erscheinung, wenn die Ungeduldsspanne kürzer als die Seitenabrufdauer ist. Um diese Größe ausreichend abschätzen zu können, muss eine genauere Auswertung der Messung erfolgen, welche die in Abbildung 3.6 (rechts) dargestellten zusätzlichen Größen für diese Entscheidung benötigt. Die Abbildung zeigt die Verteilungsfunktionen für die beobachtete Dauer zwischen zwei Klicks, die Betrachtungsdauer sowie die Dauer eines Seitenabrufs. Das WWW-Modell besteht nun aus den drei vorgestellten Ebenen, die jeweils durch Parameter bestimmt werden können. Das einfache Modell könnte an verschiedenen Stellen erweitert werden. Das Verhältnis zwischen Aufwand und Qualität sollte jedoch dabei nicht unberücksichtigt bleiben, da eine Erweiterung durch zusätzliche Mechanismen nicht selten einen überdurchschnittlichen Aufwandszuwachs bedeutet. Zum Beispiel könnte das Modell noch verfeinert werden, indem die Abhängigkeiten der Betrachtungsdauer und der Ungeduld von der übertragenen Datenmenge eines Abrufs (Anzahl und Größen der Inline-Objekte) berücksichtigt werden Network-Game-Modell Der Verkehr der durch Netzwerkspiele verursacht wird, ist deshalb so interessant, weil er sich grundlegend vom in Abschnitt beschriebenen WWW-Verkehr unterscheidet. Aufgrund von Echtzeitanforderungen ist es notwendig die zu übermittelten Daten 17

18 so klein wie möglich zu halten. Da die Verwendung des TCP-Protokolls durch die enthaltenen Sicherungsmechanismen zu aufwendig wäre, verwenden die meisten Netzwerkspiele das echtzeitfähige UDP-Protokoll. In [F02] wurde ein einfaches Verkehrsmodell für Echtzeit-Netzwerk-Spiele vorgestellt. Netzwerkspiele zeigen starke Korrelationen bezüglich der versendeten Daten (Spielstatus, Bewegungsinformationen,... ). Diese Abhängigkeiten führen dazu, dass nur geringe Schwankungen im Verkehr existieren. Aus diesem Grund ist es möglich den Gesamtverkehr zum einen durch unabhängige Verkehrsdatenströme von jedem Client zum Game- Server und zum anderen von einem Burst-Datenstrom des Servers zu den Clients zu modellieren. Wie Abbildung 3.3 zeigt, existieren auch Phasen in denen keine, beziehungsweise nur wenig Daten ausgetauscht werden. Diese Phasen werden vom Modell nicht berücksichtigt. Das Modell modelliert nur die aktive Spielphasen. Wahrscheinlichkeitsdichtefunktion 0,12 0,1 0,08 0,06 0,04 0,02 gemessene Daten Extremwert (55,6) Komplementäre Verteilungsfunktion gemessene Daten Extremwert (55,6) Paket Zwischenankunftszeiten [ms] Paket Zwischenankunftszeit [ms] Abbildung 3.7: Dichtefunktion und komplementäre kumulative Verteilungsfunktion für Zwischenankunftszeiten des Gameservers Das vorgestellte Modell besteht aus zwei unabhängigen Teilen: dem Client-Verkehrsmodell und dem Server-Verkehrsmodell. Um das Modell mathematisch zu formalisieren, muss eine Verteilungsfunktion gefunden werden, deren Gestalt den gemessenen realen Daten, so weit es geht, ähnelt. Mehrere Messungen haben ergeben, dass die Extremwertverteilung am ehesten diese Anforderungen erfüllt. Aber auch die verschobene logarithmische Normalverteilung oder die verschobene Weibullverteilung erzeugen akzeptable Ergebnisse. Die Extremwertverteilung benötigt zwei Parameter: a und b. Diese wurden durch die Methode der kleinsten Quadrate für die Dichtefunktion mit Hilfe realer Messdaten in [F02] für Echtzeitspiele bestimmt. Die Formeln für die Extremwertverteilung und die dazugehörige Dichtefunktion lauten: F C x a (x) = e e b f(x) = 1 b x a e b x a e b e b > 0 Das Modell beschreibt zum einen die Zwischenankunftszeit für Pakete und zum anderen die Paketgröße der Datenpakete. Als Server-Modell eignet sich die Extremwertverteilung mit den Parametern a = 55 und b = 6 für die Zwischenankunftszeiten und den Parametern a = 120 und b = 36 für die Paketgrößen. Wie in den Abbildungen 3.7 und 3.8 zu sehen ist, stimmt die Extremwertverteilung nur bis zu einem bestimmten Bereich mit den 18

19 gemessenen Daten überein. Da dieser Teil jedoch den Hauptverkehr abdeckt, kann die Extremwertverteilung als ausreichend angesehen werden. Für das Client-Modell hat sich herausgestellt, dass die Zwischenankunftszeit von Datenpaketen am besten durch eine deterministische Verteilung wiedergegeben werden. Die Paketgröße ist für alle Clients ähnlich, so dass eine Extremwertverteilung mit den Parametern a = 80 und b = 36 geeignet ist. Wahrscheinlichkeitsdichtefunktion 0,06 0,05 0,04 0,03 0,02 0,01 gemessene Daten Extremwert (120,36) Komplementäre Verteilungsfunktion gemessene Daten Extremwert (120,36) Paketgröße [Bytes] Paketgröße [Bytes] Abbildung 3.8: Dichtefunktion und komplementäre kumulative Verteilungsfunktion für Paketgrößen des Gameservers pro Client Das Modell bildet den durch Netzwerkspiele erzeugten Verkehr durch die oben beschriebenen Größen nach. Dabei kann sowohl der Verkehr in einer Verbindung von und zu einer Gruppe von Clients, als auch in einer Verbindung vom und zum Server beschrieben werden. Das Modell kann jedoch keine Variation in der Anzahl der Clients während einer Simulation berücksichtigen. Die Anzahl der Clients (teilnehmenden Spieler) und auch die Dauer des Spiels müssen vorher festgelegt werden. Das vorgestellte Modell beschreibt ausschließlich den Verkehr, der durch den Austausch von Statusinformationen erzeugt wird. Zusätzliche Datenströme, wie zum Beispiel Sprachkommunikation oder ähnliches werden nicht berücksichtigt. Dieses Modell ist recht einfach und eignet sich, um die Tauglichkeit von Netzwerken für die Verwendung von Echtzeit-Netzwerkspielen einzuschätzen Telnet-Modell In [PF95] wurden 24 Wide-Area-TCP-Messungen zur Analyse von Telnet-Verkehr ausgewertet. Bei der Verwendung von poissonbasierten Modellen wurde festgestellt, dass die Burst-Eigenschaft des Datenverkehrs im Gegensatz zum gemessenen Verkehr nicht ausreichend wiedergegeben wird. Die einzige Größe, die durch einen Poissonprozess einigermaßen korrekt modelliert wird, ist die Verbindungsankunftsrate bei vorher festgelegten Zeitintervallen. In [DJ91] und [DJC*92] wird die Tcplib-Bibliothek beschrieben, bei der es sich um ein Werkzeug handelt, welches in der Lage ist, realistischen TCP/IP-Netzwerkverkehr zu generieren. Tcplib hat die Möglichkeit verschiedene Dienste zu modellieren. Unter anderen können durch die Bibliothek FTP-, SMTP-, NNTP- und TELNET-Verkehr generiert werden. Die Paketankunftsrate für Telnet-Verbindungen wird am besten durch die Verwendung der Tcplib-Bibliothek modelliert. 19

20 Wie schon in Abschnitt 3.2 erwähnt, können Telnet-Verbindungsankünfte bei Verwendung von stündlichen Zeitintervallen, in denen die Ankunftsrate konstant ist, durch homogene Poissonprozesse modelliert werden. Die einzelnen Verbindungsankünfte repräsentieren dabei individuelle Telnet-Nutzer. Wichtig ist auch der Paketankunftsprozess während einer Telnet-Sitzung. Zur Vereinfachung werden nur Pakete vom Nutzer zum Telnet-Server berücksichtigt. Diese Pakete werden durch den Nutzer generiert und sind aus diesem Grund unabhängig von eventuellen Engpässen oder sonstigen dynamischen Netzwerkeigenschaften. Sie hängen lediglich von der Eingabe der Nutzerbefehle ab. In verschiedenen Verkehrsmessungen hat sich herausgestellt, dass die empirische Verteilung der Paketzwischenankunftszeiten heavy tailed ist. Das bedeutet, dass große Werte in der Verteilung eine wichtige Rolle spielen und die Paketzwischenankunftszeiten nicht durch einfache Poissonmodelle beschreibbar sind. Durch die Verwendung einer Poissonverteilung für die Paket-Zwischenankunftszeiten würde die Burst-Eigenschaft extrem unterschätzt. Auch wenn die großen Werte außer Acht gelassen werden, entspricht die gemessene Verteilung der Zwischenankunftszeiten nicht einer Exponentialverteilung. Ein großer Teil der beobachteten Verteilung würde zum Beispiel deutlich besser durch eine Paretoverteilung beschrieben. Stellt sich die Frage, was passieren würde, wenn die Paketankünfte trotzdem durch ein Poissonmodell beschrieben würden. Abbildung 3.9 zeigt die Unterschiede zwischen exponentialverteilten und heavytailed -verteilten Zwischenankunftszeiten modellierter Telnetverbindungen. Zum Vergleich wurde eine Verbindung modelliert, die stochastisch unabhängige Zwischenankunftszeiten einer Tcplib-Verteilung enthält (je erste Zeile). In der zweiten Zeile sind die Zwischenankunftszeiten einer Exponentialverteilung festgehalten. Das Eintreffen eines Paketes wurde jeweils mit einem Punkt gekennzeichnet. Die obere Hälfte der Abbildung zeigt die ersten 200 Sekunden, die untere Hälfte die vollständigen 2000 Sekunden der Simulationen. Es ist deutlich zu erkennen, dass die Pakete bei der Tcplib-Verteilung viel stärker gehäuft sind und die Burst-Eigenschaft viel besser wiedergeben. Tcplib: Exp.: Tcplib: Exp.: Zeit (in Sekunden) Zeit (in Sekunden) Abbildung 3.9: Vergleich zwischen Tcplib- und Exponential-Zwischenankunftszeiten Die Verteilung, die sich durch Nutzung der Tcplib-Bibliothek ergibt, hat sich ebenfalls für die Modellierung von Summenverkehr als vorteilhaft herausgestellt, da die Burst- Eigenschaft auch erhalten bleibt, wenn die Verteilung auf mehrere Telnet-Verbindungen hochgerechnet wird. Um einschätzen zu können, ob die Burst-Eigenschaft auch bei ver- 20

21 schiedenen Zeitintervallen ausreichend gegeben ist, eignet sich die Verwendung des sogenannten Variance-Time Plot. In [PF95] wurden verschiedene Paketankunftsprozesse modelliert und mit gemessenen Daten verglichen. Jede einzelne Telnet-Verbindung des gemessenen Datensatzes hat in jeder Simulation dieselbe Startzeit und dieselbe Größe. Eine Simulation verwendete die Tcplib-Bibliothek (TCPLIB) und eine andere Simulation die Exponentialverteilung mit einem Durchschnitt 2 von 1.1 (EXP) für die Paketankünfte während einer Telnet- Verbindung. Die Simulationen wurden für einen Zeitrahmen von zwei Stunden generiert. Alle 0.1 Sekunden wurden die angekommenen Pakete gezählt, so dass insgesamt Werte zustande kamen. Die Varianz dieser Werte gibt an, wie stark die Paketankünfte in Bursts erfolgen. In einem Variance-Time Plot werden die Varianzen der realen Messdaten und der beiden Simulationen für verschiedene Aggregationsstufen aufgezeichnet. Durch die Aggregationsstufen, können die Zeitintervalle verschieden groß gewählt werden. Durch Zusammenfassen von jeweils 100 Werten entsteht so zum Beispiel ein Messintervall von zehn Sekunden. normalisierte Varianz 10-1, ,6 10-0,2 gemessene Daten TCPLIB-Daten EXP-Daten M (Aggregationsgröße) Abbildung 3.10: Variance-Time-Plot für Telnet-Paketankunftsprozesse In Abbildung 3.10 sind die beiden oben erwähnten Simulationen und eine echte Messung aus [PF95] eingezeichnet. Der unaggregierte Prozess (M = 1) entspricht der vollständigen Betrachtung aller Werte. Auf der Y-Achse wird die Varianz des aggregierten Prozesses abgebildet. Die Varianz wurde dabei durch das Quadrat der durchschnittlichen Pakete pro 0.1-Sekunden-Intervall normalisiert. Die Normalisierung erlaubt einen Vergleich der verschiedenen Datensätze, da sie eine unterschiedliche Anzahl von Ankünften enthalten. In Abbildung 3.10 ist deutlich zu erkennen, dass die Varianz der durch die Tcplib-Bibliothek erzeugten Daten der Varianz der tatsächlichen Messdaten eher entspricht. Die Varianz der exponentialverteilten Daten ist über alle Aggregationsgrößen deutlich kleiner. Die Telnet-Verbindungsgröße in Bytes wird durch eine logarithmische Extremwertverteilung ausreichend gut modelliert. Wenn die Verbindungsgröße aber in Paketen gemessen wird, wird sie besser durch eine logarithmische Normalverteilung modelliert. Der Unterschied zwischen den Verbindungsgrößen in Bytes und in Paketen liegt darin begründet, dass in einem Telnet-Datenpaket auch mehrere Bytes enthalten sein können. 2 der Durchschnitt wurde so gewählt, damit beide Verteilungen die gleiche Anzahl von Paketen erzeugen 21

22 Dies ist zum Beispiel der Fall, wenn der Telnet-Client des Nutzers im sogenannten Line- Mode läuft. In dieser Einstellung wird erst nach drücken der Eingabetaste die ganze Zeile versendet und nicht, wie sonst üblich, jedes Zeichen einzeln übertragen. Als gutes Modell für die Verbindungsgröße in Bytes wird in [PF95] eine logarithmische Normalverteilung mit dem log 2 -Mittelwert E[x] = log und einer log 2 -Varianz von σ = 2, 24 vorgeschlagen. normalisierte Varianz 10-1,4 10-1,2 10-1,0 10-0,8 10-0,6 10-0,4 10-0,2 10-0,0 gemessene Daten TELNET-Modell 1 TELNET-Modell 2 TELNET-Modell M (Aggregationsgröße) Abbildung 3.11: Vergleichender Variance-Time-Plot für das Telnet-Modell und echten Messdaten Alles zusammen genommen ergibt nun ein Modell für Telnet-Verkehr. Die Zwischenankunftszeiten der Verbindungen werden durch ein Poissonmodell, die Zwischenankunftszeit der Datenpakete durch Verwendung der Tcplib-Bibliothek und die Verbindungsgröße (in Paketen) durch eine logarithmische Normalverteilung modelliert. Der einzige Parameter des Modells ist die Verbindungsankunftsrate. Abbildung 3.11 zeigt, wie ähnlich der durch das Modell erzeugte Verkehr, dem echten, gemessenen Telnet-Verkehr ist. In der Abbildung sind zum besseren Vergleich drei synthetisch durch das Modell erzeugte Telnet-Verkehrsdatensätze eingezeichnet. Die vom Modell erzeugten Verkehrsdaten haben lediglich eine leicht höhere Varianz für Aggregationsgrößen größer

23 4 Zusammenfassung Der Datenverkehr im Internet ist wesentlich schwieriger zu modellieren, als der Verkehr in klassischen Telekommunikationsnetzen. Dies hängt nicht zuletzt von der Vielfalt verschiedenster Dienste ab, die alle unterschiedliche Datenmengen erzeugen und unterschiedliche Anforderungen an die bestehende Infrastruktur stellen. In durchgeführten Messungen verschiedenen Studien [CB97, PF95], ergaben sich Verteilungen mit sehr großer Varianz für die Dateigrößen, der Dauer von TCP-Verbindungen, der Anzahl geladener Elemente pro Verbindung, pro Web-Seite und pro Web-Sitzung. Die Varianzen vergrößerten sich zudem mit zunehmender Beobachtungsdauer. Würden die Daten mit den großen Varianzen zur Modellierung von Summenverkehr extrapoliert, so bestünde für gewisse Konstellationen die Möglichkeit, dass eine unendliche Varianz oder ein unendlicher Erwartungswert erreicht würde. Die in Abschnitt 2.2 vorgestellte und in der Praxis häufig verwendete P-K-Formel zur Berechnung gesuchter Größen, erzeugt jedoch für unendliche Varianzen keine endlichen Ergebnisse. Aus diesem Grund ist die P-K-Formel für die Berechnung von Werten für realistischen Internetverkehr ungeeignet. Generell können Poissonprozesse die Burst-Eigenschaften von realistischem Internetverkehr nicht korrekt wiedergeben. Dieses Manko wird durch die Bündelung zum Summenverkehr noch verstärkt. In Abschnitt wurde ein Modell für Web-Verkehr mit Rückkopplungen zwischen mehreren Modellierungsebenen vorgestellt. Die Modellparameter wurden, so weit es geht, durch Messungen bestimmt. An den Stellen, an denen die Parameter nicht direkt nachgemessen werden konnten, helfen Heuristiken, um die Parameter ausreichend genau zu bestimmen. Es bleibt jedoch abzuwarten, ob der WWW-Verkehr auch in Zukunft den größten Anteil am weltweiten Datenverkehr im Internet stellt. Für die Zukunft spielt der durch Peer-To-Peer-Netze erzeugte Verkehr eine immer wichtigere Rolle, so dass die Modellierung der auf Peer-To-Peer-Netze basierenden Dienste und deren Verkehr für die Untersuchung von Internet-Systemen immer wichtiger wird. Die in Abschnitt verwendeten Messdaten stammen aus Messungen in einer LAN- Konfiguration und charakterisieren den Verkehr des Computerspiels Counter Strike. Ganz allgemein kann sich der durch Computerspiele im Internet erzeugte Datenverkehr vom hier modellierten LAN-Verkehr unterscheiden. Das Modell kann mit ein paar Modifikationen aber auch zur Modellierung von Multiplayer-Internetverkehr genutzt werden. Der Einfachheit halber wurde das Modell in ein Server- und ein Client-Modell unterteilt. Das beschriebene Modell eignet sich auch für andere Action-Multiplayer-Spiele. Andere Spielegattungen benötigen dagegen andere Verkehrsmodelle. Während sich im Laufe der Zeit die Grafik und der Realismus vom Computerspielen immer rasanter entwickelt hat, hat sich der von Multiplayer-Spielen erzeugte Datenverkehr jedoch kaum verändert. 23