Home

und Leistungsanalysen von Netzwerkemulatoren

1. In der darauffolgenden Zeile ist die vollst ndige Konfiguration zu sehen Nachweis 2 fehlerhafte Angaben Neben diesen eher offensichtlichen Fehlern sind es oft die fehlerhaften Konfigurationen welche zu falschen Messwerten f hren Als Beispiel wird die MAC Adresse soweit manipuliert dass diese keine g ltige MAC Adresse mehr darstellt Das System meldet daraufhin ValueError Given Value is not a valid MAC Address 7 Validation 98 erfasste Paketabst nde beim Sender erfasste Paketabstande beim Sender d 2al Wireshark Erfassung Wireshark Erfassung o 24 EE Eigene Erfassung 2 Eigene Erfassung E 122 Sa d ez 2 SE a ne Ze geg 18 gis 16 d 16 4b E 64 512 1024 1500 64 512 1024 1500 Paketl nge in Byte Paketl nge in Byte a vorgegebener Paketabstand 20 us b vorgegebener Paketabstand 120 us erfasste Paketabst nde beim Sender erfasste Paketabst nde beim Empf nger Wireshark Erfassung T Wireshark Erfassung 1040 wall s eee E g Eigene Erfassung sa Eigene Erfassung e 1020 i p Sch ZE u e ee St EE EES 2 III erg a B St i 980 4 D bel 1 1 A Oo g 1 1 960 es i f 940lL__ 0 Bes i 64 512 1024 1500 64
2. Bei VB dagegen werden lediglich die ben tigten Ressourcen virtualisiert und aufgeteilt Ein Beispiel daf r ist das unter FREEBSD verf gbare Lars 13d welches eine Partitionierung in mehrere kleine Instanzen des System erlaubt Ein Emulator kann so mehrere Kv unter einem Betriebssystem erstellen Dennoch ben tigt auch in diesem Fall die Virtualisierung selbst einen Teil der Ressourcen Die Skalierbarkeit eines Emulators bezieht sich im Fall von NLE auf die Anzahl der Pfadab schnitte hops unter der Betrachtung der maximal m glichen Paketrate W hrend bei VNE zus tzlich die Anzahl der Endpunkte betrachtet werden kann 2 6 Zusammenfassung In diesem Kapitel wird zun chst der Begriff der Emulation klar von dem der Simulation und SEmulation abgegrenzt Anschlie end werden traditionelle Klassifikationen f r Emulatoren er weitert um grundlegende Unterscheidungsmerkmale zu erl utern Diese Merkmale werden dabei in feststehende und messbare unterschieden Die feststehenden Eigenschaften werden einzeln aufgef hrt sowie diesbez gliche Vor und Nachteile aufgezeigt F r die messbaren Eigenschaften werden entsprechende Metriken vorgestellt welche in einem eigenen Messkonzept Anwendung finden Gleichzeitig l sst sich aus den Erkl rungen und Angaben eine eigene angepasste Taxono mie erhalten Mit Hilfe der vorgestellten Taxonomie lassen sich im Vorfeld Einsatzgebiete und Anwendungsm glichkeiten f r Emulatoren bestimmen Die Aussagen z
3. Eingabe ees SSS m Haora in Bezug auf Maximalwert Arbeitsbereich Stabilitaet Abweichung Erwartungswert Last Effekt min max 10 Versuchen MAD relative Abbildung 4 3 Ein und Ausgabem glichkeit der geforderten Endergebnisse beispielsweise in Form einer nachgestellten Verbindung zu betrachten FM 5 und FM 6 Zur Untersuchung der Skalierbarkeit bzw Leistung werden je nach Netzwerkeffekt unterschied liche Paketgr en Paketraten Anzahlen an seriellen und parallelen Pfadabschnitten verwendet F r letztere bietet es sich an Erwartungswerte zu berechnen FM 4 um Referenzpunkte f r die Betrachtung der Genauigkeit zu erhalten Ein Beispiel f r eine m gliche Programmeingabe und ausgabe der Endergebnisse ist in Abb 4 3 zu sehen 56 4 Anforderungsanalyse 4 1 3 Implementation Die praktische Umsetzung des Messkonzepts als Software ist ein weiteres Hauptziel dieser Arbeit Mit dieser sollen die Analysen zur Genauigkeit sowie Leistung durchgef hrt werden und eine Auswertung der Ergebnisse m glich sein Zus tzlich zu diesen grundlegenden Forderungen bzw Musskriterien bestehen weitere Wunschkriterien welche die Handhabung und Ausgabe erweitern k nnten Musskriterien Neben der Eingabe der zu verwendenden Metrik muss das Programm be stimmte Einstellungsm glichkeiten bieten Diese lassen sich indirekt aus den Beschreibungen zur Vorgehensweise bei den Messungen in den vorgestellten Studien und Publikation
4. H 12 2 Nachbildung von Netzwerkverhalten m maximale C H verf gbare A m Datenraten H Durchsatz TCP BTT m Einwege OWD H Verz gerungen H Umlauf RTD Variation AOWD Verlust Effektqualit t Metrik H Paketeffekte Dopplung Neuordnung o empirisch d E semiempirisch modell P 4 deterministisch rn hard Mobilfunk H Handover P e soft r idle timer zufalliger O Unterbrechung H Abbruch zuf lliger Auf und Abbau Abbildung 2 5 Kategorie Effektqualit t mit den verwendeten Metriken Im einfachsten Fall beschr nkt ein Emulator diese physische C auf den geforderten Wert durch zus tzliche Paketverz gerungen Einige Emulatoren sind in der Lage Hintergrundverkehr engl Cross Traffic CT nachzuahmen welcher indirekt ber die verf gbare Datenrate engl Available Bandwidth A gemessen werden kann Diese ist zeitabh ngig und wird direkt vom CT beeinflusst Der Wert von CT entspricht der Auslastung engl utilization u des jeweiligen Teilabschnittes und beschr nkt die zugeh rige Datenrate A Die Werte von u liegen im Bereich 0 lt u lt 1 In einem Pfad muss nicht zwingend der Teilabschnitt mit der minimalen C auch die geringste verf gbare Datenrate beinhalten Die Formel f r A bzgl der G
5. ist daher nicht ganz passend gew hlt Die Pfadvorgaben werden mittels Topologie an MODELNET bergeben Der Emulator unter st tzt daf r mehrere Formate wie z B GT ITM 13m Vor einer Emulation wird die vorgegebene Netzwerktopologie in vier Phasen konvertiert vereinfacht bersetzt und verteilt In Yoc 02 werden diese Phasen als Create Distill Assign und Bind bezeichnet In der Create Phase wird die Topologievorgabe in das GML Format graph modeling language konvertiert und es entsteht ein entsprechender Netzwerkgraph Anschlie end wird in der Distill Phase anhand dieser Graphdefinition eine Menge von pipe Konfigurationen erstellt Optional 3 2 Produktpublikationen und dokumentationen 35 k nnen in dieser Phase Vereinfachungen durchgef hrt werden welche Verarbeitungskosten bzw Emulationskosten einsparen In der Assign Phase werden diese Konfigurationen an die Core Router verteilt Als letzten Schritt vor der Emulation werden in der Bind Phase die VNs erstellt und an die Core Router gebunden Zudem werden an dieser Stelle die zuvor verteilten Konfigurationen der pipes umgesetzt Die Validation von MODELNET geschieht in zwei Experimenten Wobei der Versuchsaufbau im ersten Experiment einen einzelnen Core Router und im zweiten vier Core Router enth lt Leistungsanalyse F r die Erfassung der Leistungsdaten auf Paketebene entwickelten die Verfasser von Yoc 02 ein Tool welches im Kernelbereich arbeitet Erfasst wird u a d
6. siehe S 31 Ivanov Svilen et al Experimental validation of the ns 2 wireless model using simulation emulation and real network In Communication in Distributed Systems KiVS 2007 ITG GI Conference VDE 2007 S 1 12 siehe S vi 4 41 42 JURGELIONIS Audrius et al An empirical study of netem network emulation func tionalities In Computer Communications and Networks ICCCN 2011 Proceedings of 20th International Conference on IEEE 2011 S 1 6 siehe S 37 KAL TAY Hemanta Kumar et al WANem 2 0 Wide Area Network Emulator Perfor mance Engineering Research Centre In TATA Consultancy services 2008 siehe S 39 Ka itay Hemanta Kumar et al Designing wanem A wide area network emulator tool In Communication Systems and Networks COMSNETS 2011 Third Internatio nal Conference on IEEE 2011 S 1 4 siehe S 38 KOHLER Eddie et al The Click modular router In ACM Transactions on Computer Systems TOCS 18 2000 Nr 3 S 263 297 siehe S 42 Lucio Gilberto Flores et al Opnet modeler and ns 2 Comparing the accuracy of network simulators for packet level analysis using a network testbed In WSEAS Transactions on Computers 2 2003 Nr 3 S 700 707 siehe S 3 McCANNE Steven et al Network simulator ns 2 1997 siehe S 35 Minuas Tahir Nawaz et al Quantification of packet delay variation through the coefficient of throughput variation In Proceedings of the 6th International Wireless C
7. 4 6 1 2 3 46 1 2 314 6 Lgem 2 2 2 34 212 213 4 212 2 3Jl4 Vergleich 3 3 As Ende von Lgem erreicht i Verluste 1 1 1 6 AM Dopplungen 2 2 2 2 2 2 Abbildung 5 10 Beispiel f r die Analyse von Paketverlusten und dopplungen das fehlende Paket mit der Nummer 1 entdeckt da die aktuelle erwartete Paketnummer 1 kleiner als die aktuelle gemessene Paketnummer 2 ist Der Wert 1 wird gespeichert und Lerw wird im n chsten Schritt nach links verschoben w hrend die aktuelle Position in Lgem erhalten bleibt In dieser Position stimmen beide Paketnummern wieder berein so dass keine weiteren Behandlung notwendig wird Im dritten Schritt wird daher die aktuelle Position nach rechts verschoben Die erwartete Nummer ist in diesem Fall gr er als die Gemessene Somit handelt es sich um eine Dopplung Die Paketnummer wird zusammen mit einem Z hler gespeichert und Lyem wird f r den n chsten Schritt nach links verschoben Hierbei wird ebenfalls eine Dopplung erkannt und der Z hler wird erh ht Im f nften sowie sechsten Schritt stimmen beide Paketnummern berein und lediglich die aktuelle Position wird verschoben Gleichzeitig wird das Ende von Le erreicht was bedeutet dass die verbleibende Paketnummer 6 in Lerw f r einen weiteren Paketverlust steht und dementsprechend zur Liste der Verluste hinzugef gt werden Das Ergebnis sind zwei Listen wobei eine alle Paketnummern der Paketverluste enth lt und die andere die Paketnummern zu
8. 8 0 1432 5 0 1194 D T 0 0955 0 0717 Een 0 0478 A 0 0240 3 H T i i L T i i i i i H t T i i l L 1 H 64 512 1024 1500 64 512 1024 1500 64 512 1024 1500 Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte Abbildung 8 1 Box Diagramme f r die gemessenen Grundverz gerungen unter Verwendung der verschiedenen Stromeigenschaften am Beispiel von FREEBSD 7 3 KAUNET Grund daf r k nnte in der Weiterleitungsstrategie von FREEBSD 7 3 zu finden sein welche ein Bucket System nutzt D h bei einer sehr geringen Paketrate f llen sich die Puffer nicht schnell genug wodurch zus tzliche Verz gerungen entstehen Das gleiche Verhalten zeigt sich bei den anderen Emulatoren vgl Anhang A 4 Auch hier bedeutet ein Abfallen der Paketrate ein Ansteigen der Grundverz gerung In Tabelle 8 3 sind die gemittelten Grundverz gerungen f r jeden Emulator zusammengefasst Diese Mittelwerte werden in den eigentlichen Messungen ber cksichtigt 8 1 2 maximale verlustfreie Paketrate Im Fall von KAUNET bzw FREEBSD 7 3 werden unabh ngig von der Paketrate keine Pakete vom Betriebssystem verworfen sondern stattdessen stark verz gert In Abbildung 8 2 sind die Box Diagramme der Verz gerungen f r die verschiedenen Paketraten zu sehen Es zeigt sich dass bei einer Rate von 500 KPkt s der zeitl
9. Ber 1999 S 1 20 siehe S 14 MICHAUT F QoSMet a Quality of Service Measurement Tool 2004 URL http michaut valerie free fr qosmet besucht am 23 12 2012 siehe S 37 PRASAD R et al Bandwidth estimation metrics measurement techniques and tools In Bd 17 6 IEEE 2003 S 27 35 siehe S 11 12
10. Es werden mit dieser Arbeit drei Ziele verfolgt Das erste Ziel soll es sein eine Klassifizierung f r die verschiedenen Emulatoren zu entwerfen um m gliche Gemeinsamkeiten zwischen den Emulatoren f r ein einheitliches Messkonzept zu finden und um die Konzeption in bestimmte Un tersuchungsbereiche einteilen zu k nnen Dazu sollen zun chst grundlegende Funktionsweisen und Einsatzgebiete von Emulatoren erl utert werden Das zweite Ziel ist es ein Messkonzept zu erstellen und umzusetzen welches es erm g licht die Genauigkeits und Leistungsanalysen durchzuf hren Diese L sung umfasst dabei den Versuchsaufbau und eine Anwendung zur Wertermittlung sowie Analyse Hierbei sollen die Messkonzepte von verwandten Arbeiten mit betrachtet und eine Analyse der Anforderung an ein solches Konzept vorgenommen werden Die Durchf hrung der Analysen bei verschiedenen Emulatoren mit Hilfe des Messkonzepts bzw dessen Umsetzung ist das dritte Ziel dieser Arbeit 2 Nachbildung von Netzwerkverhalten Testumgebungen sind ein wichtiges Hilfsmittel f r die Entwicklung und Validierung von An wendungen Durch diese ist m glich bereits im Vorfeld Anomalien zu erkennen Auch verhelfen Testumgebungen den Entwicklern zu einem distanzierterem Blick auf ihr Projekt Oft arbeitet ein Entwickler lediglich an einem Bereich der Software und erst in der Testphase werden alle Teile zusammengef gt Daher ist es entscheidend ad quate Testmethoden und Versuchsumgebungen
11. dass der Fehler 25 bis 100 us betr gt Leistungsanalyse Im zweiten Teil der Analyse wird auf die Messung der Leistungsf higkeit eingegangen Als Metrik wird dabei die Verarbeitungszeit je Paket engl Per packet Processing Time PPT benutzt welche dem Inversen der Paketrate engl Packet Per Second PPS entspricht Die Verarbeitungszeit setzt sich aus verschiedenen Einzelzeiten zusammen zu denen DuMMYNET jedoch lediglich die Abarbeitungzeit der Firewall Regeln und die Verz gerung durch die Emulation beitr gt Die anderen Zeiten sind Systemabhangig Um die Verarbeitungsdauer f r beide Teilabschnitte zu messen werden von einem lokalen Paketgenerator kleinstm gliche UDP Pakete versendet und je nach Experiment an bestimmten Stellen in der Verarbeitung verworfen Die Pakete werden vor und nach der Firewall sowie nach der Emulation verworfen Zus tzlich wird die Dauer der Paketverarbeitung f r das gesamte System gemessen und die Anzahl der Regeln sowie die Konfiguration der pipes als Einflussfaktor untersucht Das Schema in Abb 3 6 stammt aus CR10 und zeigt die Teilabschnitte sowie die Stellen an denen die Pakete verworfen werden F r die Berechnung der Verarbeitungsdauer der Firewall werden die gemessenen Zeiten der Durchl ufe mit einer einzeln und mit hundert Regeln verglichen Die Messungen zur Bestimmung der Verarbeitungsgeschwindigkeit der pipes werden zun chst ohne jegliche Beschr nkung dann 30 3 Verwandte Arbeiten Typica
12. dynamisch umgesetzt Im Falle einer Interrupt Verschmelzung k nnen auch mehrere Pakete pro Interrupt verarbeitet werden vgl B s13 10 2 Nachbildung von Netzwerkverhalten Explizit Im expliziten Fall werden die Werte f r bestimmte Netzwerkeffekte vgl Abs 2 4 vor einem Versuchsdurchlauf an den Emulator bergeben Statisch W hrend eines Testdurchlaufs k nnen diese Parameter nicht mehr angepasst werden Was dazu f hrt dass sich der Versuchsaufbau statisch verh lt und dieser kaum mit einem realen Netzwerk vergleichbar ist Der Vorteil f r den Entwickler ist jedoch dass dieser den Beobachtungsbereich f r ein bestimmtes Szenario seinen Anforderungen entsprechend einschr nken kann Dynamisch Bei ereignisgesteuerten Vorgaben wird der Manipulationsprozess des Emulators an eine bestimmte Begebenheit gekn pft Das k nnen beispielsweise eine gewisse Anzahl an empfangenen Paketen eine Taktrate oder pseudozuf llige Entscheidungen sein F r gr ere Szenarien mit vielen Ereignissen wird oft die SEmulation benutzt Diese Art der Vorgabe ist f r den generellen Funktionsnachweis eines Protokolls oder einer Anwendung besonders geeignet da sich die Eigenschaften des emulierten Netzwerks dynamisch verhalten und trotzdem reproduzierbare Ergebnisse gemessen werden k nnen W hrend eines Testdurchlaufs kann z B f r die Untersuchung eines Verkehrsleitsystems das Verhalten einer Netzwerkverbindung zu unterschiedlichen Tageszeiten
13. engl hops vgl Abb 2 4 Bei einer Emulation Tx PS P 24 i Il D Rx Abbildung 2 4 Pfad P mit den Teilabschnitten von i 1 bis i H Quelle B s13 werden diese Werte vorgegeben um so die Eigenschaft eines Testpfades weitestgehend zu kon trollieren Der Grad der Umsetzung dieser Vorgaben durch einen Emulator ist Gegenstand der Genauigkeitsanalyse Zu den in der Genauigkeitsanalyse betrachteten Netzwerkmetriken z hlen neben der Da tenrate auch Metriken welche speziell in paketbasierten Netzwerken auftreten Dazu geh ren Paketverlustraten und dopplungsraten sowie nderungen in der Paketreihenfolge Zudem ist die Paketverz gerung und deren Variation f r die Betrachtung der Genauigkeit eines Emulators entscheidend Eine bersicht der Metriken ist in Abbildung 2 5 zu finden Jede Einzelne davon wird im Folgenden definiert 2 4 1 Datenraten Die meisten Emulatoren bieten eine Einstellungsm glichkeit f r die maximal erreichbare ber tragungsrate an Diese kann Werte kleiner oder gleich der physischen Maximalrate annehmen Allgemein ist die maximale Daten bertragungsrate engl Capacity C einer Netzwerkverbindung zeitunabh ngig und wird durch die physische Kanalkapazit t beschr nkt Auf einen Verbindungs pfad bezogen ist C die minimale Einzeldatenrate C der Teilabschnitte Abb 2 6 Als Gleichung wobei Cp der Senderate entspricht vgl Pra 03 C min C 2 1 i 0
14. existierenden Netzwerkemulatoren Auswertung der Ergebnisse Verantwortlicher Hochschullehrer Vorsitzender Pr fungsausschuss IST Prof Dr rer nat habil Dr h c Alexander Schill Prof Dr Ing habil Martin Wollschl ger F r meine Liebsten Jessika und Eleonora R ckhalt und Freude Inhaltsverzeichnis Abk rzungsverzeichnis 2 2 2 uaaa aaa v Symbolverzeichnis 2 2 222 aaa ee ix Abbildungsverzeichnis 2 2 2 2 2 C Coon nn xi Tabellenverzeichnis 2 2 CC Con on nn xV 1 Einf hrung eee ew 2 8 0 aa wa i a ee sa ne een 1 LI Motivation aaa aa ch en an nk ES EE ER 2 1 2 Aufgabenstellung NEE ee R ET nenn anne 2 Nachbildung von Netzwerkverhalten 2 222 Come 3 2 1 Methoden zur Nachbildung 4 oka 225 OSES AER naeh 3 2 2 Taxonomiekonzept ss us 40 EE a 5 2 3 Funktionsweisen 6 2 3 1 Architektur 7 2 3 2 Arbeitsbereich 222222 ee 8 23 3 Zeitgeber vos a rar Een erregen 8 23 A Bedat EE en ee 9 2 35 Pfadvoftgabe aan tix oe oe ba SEES SRE HERE ERE EE SEES BO 9 2 4 Effektqualit t Netzwerkmetriken 11 24 10 D tenraten 2 wat he 5 0 wa wann anne 11 2 4 2 Verz gerung 2 Comm 13 2 4 3 Paketeffekte 2 22 Coon nn 15 2 4 4 Mobilfunk 16 2 5 Skalierbarkeit 18 2 6 Zusammenfassung Eee Ei a RESO 19 3 Verwandte Arbeiten 23 3 1 Auswahl der Emulatoren 23 3 2 Produktpublikationen und dokumentationen ooa oaaae 25 3 2 1 Linktropy 7500 pro ze 0 CN an a he ee bik e Hd
15. glicht der Wert von xp au erdem Aussagen ber das Schiefemaf der Verteilung zu treffen Dieses gibt einen Hinweis auf die Art der Verteilung Beispielsweise ist eine Poissionverteilung rechtsschief eine Normalverteilung symmetrisch und eine Binominalverteilung linksschief Ein Beispiel daf r ist in Abbildung 5 14 zu sehen Zur Vereinfachung sind bei diesem die einzelnen Verteilungen 80 5 Konzeption erste H lfte zweite H lfte Liste 1 2 4 5 7 8 9 300 1 Median 56 7 6 D DL Listefi 42 Abbildung 5 13 Beispiel fiir die Ermittlung des Median einer Liste mit gerader Anzahl an Ele menten allgemein grafisch als Verteilungsfunktion engl Probability Distribution Function PDF sowie als kumulierte Verteilungsfunktion engl Cumulative Distribution Function CDF dargestellt Linksschiefe Verteilung T Symmetrische Verteilung Rechtsschiefe Verteilung T T T T T T T T T T T H ufigkeit H ufigkeit D r 0 6 zp gt zos gt D gt T 0 2 0 0 0 0 8 F 0 6 Jr 0 2 0 8 H TD 0 5 D 0 6 F nit tp lt 5 lt D 0 0 0 0 8 0 6 0 4 0 8 0 6 0 4 Werte Werte Abbildung 5 14 Schematischer Verlauf von links rechtsschiefen sowie symmetrischen Vertei lungen Oben PDF Unten CDF Die Mehrzahl der vorgestellten Emulatoren besitzen Ei
16. konkretisiert 4 1 1 Verfahren Das Messkonzept bzw Messverfahren ist eines der angestrebten Ziele dieser Arbeit und beinhaltet neben der konkreten Vorgehensweise auch den Versuchsaufbau Vorgehensweise In den vorgestellten Studien hat es sich als vorteilhaft erwiesen bereits vor der eigentlichen Analyse Untersuchungen bzgl des Taktgebers FV 1 vgl Tab 4 3 und der Puffergr e FV 2 vgl Tab 4 3 des Emulators durchzuf hren Gleichzeitig sollten die Grundver z gerungen FV 3 des Versuchsaufbaus mit betrachtet werden Somit sollte auch im eigenen Messkonzept eine Vorfelduntersuchung eingeplant werden Ebenso sollte im Anschluss einer Messung neben der direkten Ausgabe zus tzlich eine Auswertung der Messwerte erfolgen Dazu z hlt beispielsweise eine H ufigkeitsverteilung FA 1 bei Verz gerungswerten Abbildung 4 1 fasst die geforderte Vorgehensweise anhand der genannten Punkte zusammen 54 4 Anforderungsanalyse Vorfeld Messungen J Auswertung untersuchung Abbildung 4 1 Grundlegende Vorgehensweise Versuchsaufbau Weiterhin geht aus den Erkenntnissen in Kapitel 3 hervor dass die Versuch sumgebung neben dem Emulator eine Paketquelle beinhalten muss Diese Quelle sollte dabei in der Lage sein Probepakete mit definierten Eigenschaften zu generieren um u a Paketstr me mit unterschiedlichen Raten nachbilden zu k nnen Der Paketgenerator FT 1 vgl Tab 4 3 sollte daher Einstellungsm glichkeiten bzgl
17. oO a 2 Berechi E t t FM 4 2 is ee Auswahl der Metriken FL1 E einzelne Netzwerkeffekte FM 5 i Zeit Messdauer Intervall FI 2 mehrere Netzwerkeffekte FM 6 g 8 i H 2 Messart Einwege Umlauf FI 3 Metriken FM 7 1 bis FM 7 7 FM 7 3 2 Verbindung Ports PLA H ufigkeitsverteilung FA 1 E E Paketgr e FI5 a CoTV FA 2 Protokoll UDP FL6 5 Minimum FA 3 amp Datenrate Paketrate FL7 5 Maximum FA 4 Toleranz FL8 a KI 2 Durchschnitt FA 5 E lt een amp sg vollautom Analysen Flw1 MAD FA 6 a GUI FI w2 relative Abweichung FA 7 2 S Diagramme Die Vergleich Emulatoren FI w4 Tabelle 4 3a Messverfahren Tabelle 4 3b Metriken und Implementation Tabelle 4 3 bersicht funktionale Anforderungen 60 61 5 Konzeption Bevor auf die Vorgehensweisen f r die Vorfelduntersuchungen und Messungen eingegangen wird werden zun chst die Komponenten des Versuchsaufbaus aus Hardware sowie Software technischer Sicht erl utert F r erstere wird dabei basierend auf den vorgestellten Arbeiten eine eigene L sung schrittweise konstruiert Bis auf die OWD k nnen die Konzepte zur Ermittlung der brigen Metrikwerte aus der Arbeit B s13 zum Analysewerkzeug Nora mit geringen Anpassungen bernommen werden Das fehlende Konzept und die Anpassungen sind Teil des letzten Abschnittes dieses Kapitels Zudem werden die Berechnungen der statistischen Werte FA 1 bis FA 6 im letzten Abschnitt vorgestellt Wobei neben dem CoTV al
18. tions 2013 siehe S 2 9 11 13 15 23 61 68 69 74 84 CARBONE Marta et al Dummynet revisited In SIGCOMM Comput Commun Rev 40 Apr 2010 Nr 2 S 12 20 Issn 0146 4833 por 10 1145 1764873 1764876 URL http doi acm org 10 1145 1764873 1764876 siehe S 23 28 30 GARCIA Johan et al KauNet A versatile and flexible emulation system In Procee dings of the 5th Swedish National Computer Networking Workshop SNCNW 2008 siehe S 30 Grau Andreas et al Time jails A hybrid approach to scalable network emulation In Principles of Advanced and Distributed Simulation 2008 PADS 08 22nd Workshop on IEEE 2008 S 7 14 siehe S 4 HALL Tomas et al Performance Evaluation of KauNet in Physical and Virtual Emulation Environments Techn Ber 2012 32 Karlstad University Department of Computer Science 2012 S 49 siehe S 32 33 61 62 HEMMINGER Stephen et al Network emulation with NetEm In Linux Conf Au Citeseer 2005 S 18 23 siehe S 36 37 130 B 9 Literaturverzeichnis HK05 Hur 12 IHL07 Jur 11 KN08 KN11 Koh 00 Luc 03 McC 97 MFA10 Mil92 Min 11 Nap08 NK11 Hag Furqan et al Simulation vs emulation Evaluating mobile ad hoc network routing protocols In Proceedings of the International Workshop on Wireless Ad hoc Networks IWWAN 2005 2005 siehe S 4 HURTIG Per et al KauNet 2 0 Design and Usage In 2012
19. tuellen Netzwerken siehe Seite 5 6 18 19 25 Wide Area Network dt Weitverkehrsnetz siehe Seite 25 38 viii Symbolverzeichnis SS amp x Uj X0 5 verfiigbare Datenrate in einem festen Zeitintervall 12 13 28 78 maximale Datenrate 11 13 25 27 39 42 101 Ausbreitungsverz gerung engl propagation delay 14 Warteschlangenverz gerung engl queuing delay 14 15 bertragungsverz gerung engl transmission delay 14 Anzahl der Teilabschnitte engl Hops eines Verbindungs pfades 33 89 Realer Netzwerkknoten 7 18 Virtueller Netzwerkknoten 7 19 Paketgr e bzw Anzahl Bits eines Pakets 28 67 Verbindungspfad 11 12 Empf nger 14 Sender 14 Verz gerungsvariation des j ten Paketes 14 15 25 27 37 39 43 67 74 77 81 Standardabweichung Ma f r die Streuung um den Er wartungswert einer Verteilung 79 i te Teilabschnitt eines Verbindungspfades 11 j te Paket in einem Paketstrom 14 Auslastung des i te Teilabschnitt eines Verbindungspfades 12 13 Zentralwert oder Median einer geordneten Liste Symbolverzeichnis XD 79 80 92 Modalwert oder Modus H ufigster Wert in einer Vertei lung 79 80 Xi Abbildungsverzeichnis Abb 2 1 Wasserfallmodell der Softwareentwicklung mit Einsatzm glichkeiten der drei Versuchsmethoden 2 2 2222 n none Abb 2 2 Hauptkategorien der entworfenen Taxonomie mit Angaben zu feststehen bzw messbare
20. 1 0 100000 Or ei 2 1363570980 000100 kt 2 0 100050 2 1363570980 100150 3 1363529989 000210 4 1363570980 100330H I 4 1363570980 000300 t 5 1363570980 100560 5 1363570980 000420 LI 4 0 100030 l 5 0 100140 Li 6 0 100010 6 1363570980 100500 6 1363570980 000490 5 1363570980 100560 Sortieren und Duplikate Verluste entfernen entfernen Abbildung 5 12 Beispiel f r das Vorgehen und die Berechnung der einzelnen OWD Werte zus tzlich die verf gbare Datenrate A ben tigt Die Vorgehensweise dazu wird komplett von Nora bernommen und beruht auf einer Trendanalyse der aktuellen Datenrate mit Hilfe des aktuellen Paketabstandes Ist der Paketabstand beim Empf nger gleich dem gesendeten Abstand so ist die aktuelle Rate kleiner als die verf gbare Datenrate Die verf gbare Datenrate entspricht derjenigen Rate bei welcher der Paketabstand ansteigt Die PPS berechnet sich f r die Menge der erfassten Pakete Mp mit M gt 1 wie folgt _ M 1 lend Istart PPS 5 1 Dabei entspricht Loan dem Zeitstempel des ersten und tena dem des letzten Paketes Doppelte Pakete gehen mit in die Berechnung ein w hrend Paketverluste nicht ber cksichtigt werden Bei der Bildung der Summe wird das erste Paket au en vor gelassen da der Zeitstempel erst nach Erhalt des letzten Bits vergeben wird Entspreche
21. 1 ms und ab 1 ms um 100 us verringert bis die relative Abwei chung der durchschnittlichen OWD gr er als 10 ist ungewollte Paketeffekte auftreten oder 6 3 Zusammenfassung 93 die vorgegebene Verz gerung kleiner oder gleich der Grundverz gerung des Versuchsaufbaus ist Die Granularit t ist f r beide F lle die vorhergehende OWD Jeder Pfadabschnitt erh lt die gleiche Vorgabe und es wird w hrend der Berechnungen die Tatsache ber cksichtigt dass sich Verz gerungen entlang des Gesamtpfades aufsummieren Dennoch entspricht die kleinste Verz gerung dem Vorgabewert Verz gerungen Wertebereich Die obere Grenze des Untersuchungsbereiches wird f r die Verz gerungen auf eine Sekunde festgelegt da diese OWD f r die Emulation einer Satellitenverbindung v llig ausreicht und eine einzelne Untersuchung mit 10000 Paketen bereits 2 7 Stunden dauert Gemessen werden die Verz gerungen mit den Vorgaben 15 ms 100 ms und 1000 ms f r jede Stromeigenschaft Als Ergebnis werden die Statistiken FA 1 bis FA 7 f r jede Vorgabe und Stromeigenschaft angegeben Zus tzlich werden eventuell auftretende ungewollte Paketeffekte aufgef hrt Datenraten Granularit t Die Vorgabewerte f r die einzelnen Stromeigenschaften beginnen bei 1 MBit s und werden solange schrittweise um 100 kBit s reduziert bis die relativen Abweichungen der durchschnitt lichen gemessenen Datenrate beim Empf nger gr er als 3 ist ungewollte Paketeffekte auftrete
22. 2 Einstel lungen bzgl der Paketgr e und rate m ssen weitestgehend genau und stabil umgesetzt werden um exakte Ergebnisse zu erhalten Daher sollten mindestens die verwendeten Paketraten und gr en am Generator getestet und Abweichungen dokumentiert werden Weiterhin sollte die Paketerfassung berpr ft und mit unabh ngigen Programmen wie WIRES HARK verglichen werden ON 31 Nur so kann sichergestellt werden dass die Messdaten korrekt aufgezeichnet werden Eventuell auftretende Fehlkonfigurationen sollten vom Messsystem gemeldet werden ON A F r den Nachweis einer Fehlerbehandlung sollte daher eine falsche Konfiguration bzgl der Netzwerkeinstellung und Messparameter gemeldet werden nicht funktionale Anforderungen Die Installation des Programms soll mit nur geringem Aufwand erfolgen D h alle ben tigten Programm Bibliotheken m ssen frei verf gbar sein oder mitgeliefert werden Der Versuchsaufbau muss weitestgehend unabh ngig von spezieller Hardware sein Daher d rfen keine besonderen Netzwerkkarten oder Router verwendet werden Au erdem d rfen nderungen von Messparametern oder zu untersuchenden Netzwerkeffekten keine nderungen am Versuchsaufbau mit sich ziehen Bei der Verwendung von fertigen Tools sollen diese in den Programmablauf integriert werden Das bedeutet dass der Nutzer nur einmal alle Eingaben t tigt und auch nur ein Programm startet Alle anderen Konfigurationen bernimmt die geforderte Implementati
23. 512 1024 1500 Paketlange in Byte Paketlange in Byte c vorgegebener Paketabstand 1000 us d vorgegebener Paketabstand 20 jus erfasste Paketabstande beim Empfanger erfasste Paketabstande beim Empfanger Se Wireshark Erfassung wl Wireshark Erfassung Weg 2 160 l i Eigene Erfassung g Eigene Erfassung e l i i e 1050 e J r e i J v i 8 Fr 8 Int B E Le e 100 ei g za i sol SS DEE EE E NEE TE a 1 1 1 1 A 1 1 i i 950 i 1 60 ert ci j T I j 1 40 E 64 512 1024 1500 64 512 1024 1500 Paketl nge in Byte e vorgegebener Paketabstand 120 us Paketl nge in Byte f vorgegebener Paketabstand 1000 us Abbildung 7 1 Messergebnisse der erfassten Paketabst nde durch WIRESHARK und der eige nen Implementation auf der Senderseite a c sowie Empf ngerseite d e als Boxplot f r die verschiedenen vorgegebenen Paketabst nde und gr en 7 4 Zusammenfassung 99 Gleiches gilt auch f r eine falsche Netzwerkkarten ID in Zeile 19 Anhang A 2 Error given rx_device_id not found on this system Eine weitere Fehlerquelle sind die Vorgaben innerhalb der Konfigurationsdatei f r die Messpa rameter Beispielsweise ist in Anhang A 3 die minimale PPS gr er als die maximale Bei der Initialisierung des Messsystems erscheint eine entsprechende Fehlermeldung ValueError maximum pps lt minimum pps or step width lt 1 Ein Probedurchlauf muss eine Mindestdauer
24. 64 512 102 1500 0 07 0 04 0 04 0 05 100 0 04 0 04 0 04 0 04 00 0 06 0 04 0 69 0 04 KauNet 80 0 00 0 00 0 00 0 00 70 0 00 0 00 0 00 0 00 60 0 00 0 00 0 00 0 00 NetEm 50 0 02 0 00 0 02 0 04 40 0 00 0 00 0 01 0 02 30 0 02 0 02 0 02 0 01 Dummynet 20 0 00 0 00 0 00 0 00 10 0 00 0 00 0 00 0 00 0 0 00 0 00 0 00 0 00 Linktropy d Vorgabe 1000 ms Tabelle 8 7 Abweichungen der mittleren emulierten Verz gerung bei verschiedenen Stromei genschaften des jeweiligen Emulators von der Vorgabe Pfadl nge 1 110 8 Durchf hrung oe PPS 50 0 KPkt s PPS 8 3 KPkt s PPS 1 0 KPkt s 002 F ij SEH F T j 7 F F F F EE 100 158 100 057 1 14 IL 99 955 L 99 853 9 751 i men 99 548 Are et ee 99 446 1 1 En AE 99 344 WE Lo EE le 99 141 1 Dat ale 99 039 L L i J4 F JN j I Heaths N ZS i i i i i i J4 E i i i i i i i i i gemessene OWD in ms I G d EE RS 64 512 1024 1500 64 512 1024 1500 64 512 1024 1500 Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte Abbildung 8 6 Gemessene Verz gerungen mit dem Emulator DumMYNET als Box Diagramm f r die verschiedenen Paketl ngen und raten bei 10 Pfadabsch
25. D Die Abh ngigkeit der Standardabweichung vom Durchschnitt wird dadurch aufgel st Messrei hen deren Probestr me h here Mittelwerte f r eine bestimmte Metrik annehmen k nnen als solche mit geringeren Werten beinhalten entsprechend auch h here Standardabweichungen Beispielsweise entstehen h here Abweichungen bei einer emulierten Verz gerung von 300 ms als bei einer Vorgabe von 1 ms Die Wertebereiche der Messergebnisse unterscheiden sich deutlich Um die Wertstabilit t einer Metrik innerhalb eines Paketstromes f r verschiedener Zeitspannen untersuchen zu k nnen wird die Berechnung des in Kapitel 3 vorgestellten CoTV angepasst Urspr nglich verwenden die Autoren von Sha 10 diesen als Ma einheit f r die Variation von Verz gerungen indem die empfangene Datenrate mit der Gesendeten f r unterschiedliche Zeitintervalle verglichen wird In dieser Arbeit werden neben der Datenrate ebenfalls direkt die Messwerte der OWD und der AOWD verwendet Anders als in MFA10 werden dabei f r die Mittelwertbildungen nicht mehrere feste Intervalle sondern jeweils ein einzelnes gleitendes Zeitintervall verwendet Abh ngigkeiten des Mittelwertes bez glich der Intervallgrenzen werden so aufgel st und die Gewichtung von vielen geringen Wertschwankungen gegen ber wenigen starken Schwankun gen nimmt mit steigender Intervall nge ab Das folgende Beispiel demonstriert das Vorgehen zur Berechnung des CoDVwBMA Betrachtet wird dabei die Stabilit t
26. Datei des Empf ngers mit Hilfe der zuvor beschriebenen Vorgehensweise ausfindig gemacht und vermerkt Im Beispiel tritt ein Verlust des dritten und eine Dopplung des ersten Paketes auf Die OWD kann bei verloren gegangenen Paketen nicht berechnet werden da kein Empfangszeitpunkt vorhanden ist Daher werden die betreffenden Pakete auch in der Senderliste verworfen Bei doppelten Paketen gilt dass immer das erste Vorkommen f r die Berechnungen verwendet wird Alle anderen werden verworfen da bei diesen kein Sendezeitpunkt existiert Nach dieser Behandlung werden f r die einzelnen OWDs die verbleibenden Zeitstempel des Senders von denen des Empf ngers abgezogen Das Resultat ist eine Liste von OWDs der einzelnen Pakete Datenraten F r die Auswertung wird haupts chlich die versendete und empfangene Paketrate PPS bzw Datenrate BPS verwendet Lediglich f r die Betrachtung von emulierten CT wird 78 5 Konzeption wt Paketnummer Sekunden seit Epoche Mikrosekunden Senderliste Sender Empf nger Eimpf ngerliste A 1 1363570980 000000 2 1363570980 000100 1 1363570980 100000 3 1363570980 000210 1 1363570980 100100 4 1363570980 000300 2 1363570980 100150 5 1363570980 000420 een 4 1363570980 100330 6 1363570980 100500 5 1363570980 100560 mme u Messung i 7 Auswertung Empfangerliste Senderliste Ergebnisliste 1 1363570980 100000 1 1363570980 000000 gt
27. Datenpakete fremder Anwendungen die die Probepakete kreuzen siehe Seite 12 27 28 42 50 77 First In First Out FIFO Warteschlangenabarbeitung sie he Seite 26 27 Global Positioning System unter Anderem zur Bereitstel lung eines einheitlichen Zeitsystems siehe Seite 37 38 Graphical User Interface dt grafische Benutzeroberfl che siehe Seite 40 56 64 Internet Control Message Protocol dt Internet Kontrollnachrichtenprotokoll f r Diagnosezwecke siehe Seite 45 Internet Protocol siehe Seite 26 34 Link emulator dt Netzknotenemulator siehe Seite 5 6 18 19 25 38 49 vi Abk rzungsverzeichnis MAD MLFFR MTU NTP OWD PCI PCIe PDF PDR PLR PPS PPT PRR RR RTD RTT mittleren absoluten Abweichungen engl mean absolute deviation MAD siehe Seite 56 79 maximum loss free packet forwarding rate dt maximale verlustfreie Paketrate Quelle IHL07 siehe Seite 42 43 50 70 71 90 91 93 101 103 105 Maximum Transmission Unit maximale erlaubte Gr e eines Netzwerkpaket siehe Seite 90 Network Time Protocol zur Zeitsynchronisierung von Ger ten im Netzwerk siehe Seite 63 One Way Delay dt Verz gerung in eine Richtung der Verbindung siehe Seite 14 27 30 34 36 39 42 43 47 54 61 62 67 69 71 77 81 91 93 101 103 Peripheral Component Interconnect Bussystem welches Hardware Steckkarten mit dem Rechner verbindet sieh
28. Es bestehen viele weitere M glichkeiten an das Messkonzept anzukn pfen Das Ergebnis die ser Arbeit bietet alle notwendigen Konzepte und Implementationen f r die Genauigkeits und Leistungsanalyse von Netzwerkemulatoren 118 119 Anhang A A 2 A 3 AA A 5 A 6 A 7 AS Nachweis Versuchsaufbau Ping antworten 120 Konfigurationsdatei f r die Netzwerkeinstellungen 121 Konfigurationsdatei f r die Angabe von Messparametern 12 Vorfelduntersuchungen Grundverz gerungen 2 22 22 123 Messung Datenrate sses su sudro EEN ana NEE 124 Messung Verz gerungen 125 Messung Neuordnung 126 Erkl rung zum Urheberrecht we se ae er aa eh 127 120 A 1 Nachweis Versuchsaufbau Ping antworten A 1 Nachweis Versuchsaufbau Ping antworten C gt ping S 10 0 0 2 n 5 1 100 i 2 10 0 0 1 Pinging 10 0 0 1 from 10 0 0 2 with 100 bytes of data Reply from 10 0 0 1 bytes 100 time lt lms TTL 64 Reply from 10 0 0 1 bytes 100 time lt lms TTL 64 Reply from 10 0 0 1 bytes 100 time lt Ims TTL 64 Reply from 10 0 0 1 bytes 100 time lt lms TTL 64 Reply from 10 0 0 1 bytes 100 time lt lms TTL 64 Ping statistics for 10 0 0 1 Packets Sent 5 Received 5 Lost 0 0 loss Approximate round trip times in milli seconds Minimum Oms Maximum Oms Average Oms C gt ping S 10 0 0 2 n 5 1 100 i 2 10 0 0 5 Pinging 10 0 0 5 from 10 0 0 2 with 100 bytes of data Reply fro
29. KAUNET anhand des Musters 0101 Quelle Hur 12 2 2 2222200 Abb 3 8 Funktionsprinzip von KAUNET mit dem Mustergenerator patt_gen Abb 3 9 Die drei Versuchsumgebungen f r die Analysen von KAUNET Abb 3 10 Schematischer Aufbau von MoDELNET am Beispiel mit drei virtual edge nodes VN auf zwei Realen Rechner und einem Core Router Cluster mit drei Rechnern VN 1 und VN 2 verbinden sich parallel ber teilweise unterschiedliche Pipes mit KOENEN Abb 3 11 Baumartige Struktur der qdisc Warteschlangen unter Linux Abb 3 12 Schema der Paketverarbeitung durch NETEM 22 22 2220 Abb 3 13 Leichtgewichtige Virtualisierung unter Imungs Quelle PM06 Abb 3 14 Versuchsaufbau in NRO9 2 2 11 12 13 13 14 15 18 24 24 26 27 28 30 31 31 xii Abbildungsverzeichnis Abb 3 15 Messergebnisse Einfluss der Taktrate auf die Genauigkeit bei der Emulation einer Paketverz gerung von 10 ms rechts H ufigkeitsverteilung Quelle NR09 45 Abb 3 16 Versuchsaufbau in Sha 10 angelehnt an die DPMI 47 Abb 3 17 Beispiel fiir die Visualisierung der Haufigkeitsverteilung und der verschie denen CoTV links H ufigkeitsverteilung Quelle Sha 10 48 Abb 4 1 Grundlegende Vorgehensweise 54 Abb 4 2 Grundlegende Anforderungen an den Versuchsaufbau 54 Abb 4 3 Ein und Ausgabem glichkeit der geforderten Endergebnisse 55 Abb 5 1 Erster A
30. Messungen zur Skalierbarkeit und Antwortzeit werden dazu auf einer Maschine innerhalb des Rechnerverbundes durchgef hrt welche neben den eigentlichen Emulationsaufgaben noch 3 2 Produktpublikationen und dokumentationen 41 zus tzliche Aufgaben erf llt Diese beinhalten die Verteilung der Nutzervorgaben an die anderen Verbundteilnehmer sowie den Start der Emulation F r die Skalierbarkeit werden die Auslastungen der CPU und des Arbeitsspeichers bei einer aufsteigenden Anzahl an Netzwerkelementen und Verbundrechnern gemessen Dabei zeigen sich deutliche Unterschiede zwischen der CPU und der Arbeitsspeicherauslastung W hrend die CPU kaum Reaktionen zeigt sind die Werte des Arbeitsspeichers f r steigende Verbundteilnehmer und Netzwerkelementen stark verschieden Die Antwortzeit bezieht sich auf die Wartezeit zwischen dem Signal zum Start und dem tats chlichen Beginn einer Emulation Dazu werden auch hier die Anzahl der Verbundteilnehmer erh ht und f r unterschiedlich viele Netzwerkknoten gemessen Es zeigt sich dass sich ab einer bestimmten Anzahl an Verbundrechnern kein Zeitgewinn mehr erreichbar ist F r die Verarbeitungszeit wird zun chst die RTD f r eine reale Verbindung mittels ping gemessen Diese Umlaufverz gerung wird als t bezeichnet Der Versuchsaufbau besteht dazu aus zwei Rechnern welche direkt miteinander verbunden sind Anschlie end wird dieser Aufbau mit IMuNEs auf einem der beiden Rechner nachgebildet Es wird e
31. Performance Evaluation of Computer and Telecommunication Systems 2008 SPECTS 2008 International Symposium on IEEE 2008 S 519 525 siehe S 40 41 Rizzo Luigi Dummynet a simple approach to the evaluation of network protocols In ACM SIGCOMM Computer Communication Review 27 1997 Nr 1 S 31 41 siehe S 26 27 SHAIKH Junaid et al Evaluation of delay performance of traffic shapers In Security and Communication Networks IWSCN 2010 2nd International Workshop on IEEE 2010 S 1 8 siehe S 44 46 48 50 61 62 81 SIMMONDS Rob et al Towards scalable network emulation In Computer Commu nications 26 2003 Nr 3 S 264 277 siehe S 4 5 TECHNOLOGIES Apposite Linktropy 7500 pro Hardware Guide Bd 5 apposite 2011 siehe S 26 TECHNOLOGIES Apposite Linktropy Wan Emulator User s Guide Bd 4 apposite 2013 siehe S 26 UNIVERSITY of Zagreb IMUNES Manual University of Zagreb 2012 siehe S 40 42 Yocum Ken et al Scalability and accuracy in a large scale network emulator In ACM SIGCOMM Computer Communication Review 32 2002 Nr 3 S 28 28 siehe S 33 35 Zec Marko et al Operating system support for integrated network emulation in imunes In 1st Workshop on Operating System and Architectural Support for the on demand IT InfraStructure OASIS 2004 S 3 12 siehe S 39 40 B 10 Quellenverzeichnis 12 Ihe Tcpdump and Libpcap Web site 2012 URL http w
32. Y Y Y classless qdisc A Em 1 2 classful qdisc 2 1 classless qdisc 3 1 Y classless qdisc 2 1 1 Netzwerkinterface Abbildung 3 11 Baumartige Struktur der qdisc Warteschlangen unter Linux NETEM ist bis zur Kernelversion 2 6 29 als classful qdisc implementiert In den sp teren Ver sion jedoch geh rt NETEM zu den classless qdisc Daher sind keine Pfadverkettungen wie bei DuUMMYNET mehr m glich Konfiguriert wird NETEM mittels dem Tool tc Au erdem existiert eine NETEM GUI 13p welche die Eingabe vereinfacht Der Emulator unterst tzt Paketverluste dopplungen neuordnungen sowie verz gerungen per H ufigkeitsverteilung und kann die maximale Datenrate beschr nken Daf r werden am Eingang der NETEM qdisc die betreffenden 3 2 Produktpublikationen und dokumentationen 37 Pakete durch einen Pseudozufallsgenerator ausgew hlt und verworfen bzw verdoppelt Anschlie end erhalten die verbleibenden Pakete einen Zeitstempel mit der Summe aus der aktuellen Zeit und der geforderten Verz gerung Mit diesem Sendezeitpunkt werden die Pakete in die eigentli che Warteschlange einsortiert und verweilen dort bis die jeweilige Verz gerung abgelaufen ist Eine Veranschaulichung dieses Arbeitsablaufes ist in Abbildung 3 12 zu finden NETEM Duplikate einsortieren Zeitstempel Neuordnung mit Sende zeitpunkt Pseudozufalls Haupt qdisc Se entscheidung Originalpa
33. a oe ee s WinPcap Funktion return 0 x H ee H k while res pcap_next_ex device _id c_nsniff sniffOnDevicd device_id 1 hr amp packet_header filter_string Dis amp pkt_data gt 0 timeout SS NM ee F _ py_result PyObject_CallFunction callback_func callback_func Ces Ee a ae di result PyInt_AsLong py_result if result 2 sender ist fertig Paketerfassungsprozess in Python N Abbildung 6 3 Beispiel f r die Prozessgenerierung der Paketerfassung sowie das Zusammenwir ken von Python und einem C Erweiterungsmodul 6 2 Vorgehensweise An dieser Stelle werden die Beschreibungen der in Abschnitt 5 2 erl uterten ersten beiden Phasen um explizite Wertangaben bzgl der Messparameter erg nzt In allen Untersuchungen zur Granularit t werden sofern der Emulator dies unterst tzt jeweils die Pfadl ngen H 1 10 30 verwendet Die Pfadl nge H3 30 orientiert sich an der maximalen Anzahl an messbaren Hops mittels des Tools TRACEROUTE F r die Ermittlungen des Wertebereiches wird ein einzelner Pfadabschnitt untersucht da sich die Vorgabewerte in Bezug auf den Gesamtpfad im Falle der Paketeffekte und Verz gerungen erh hen bzw im Fall der Datenraten nicht ver ndern Beispielsweise ergibt sich bei der Pfadl nge Hg einer vorgegebenen Verlustrate von 10 und ausgehend davon dass alle Abschnitte die gleiche Verlustrate besitzen eine Gesamtrate von H PLR gesamt le IJa PLR e Vorg
34. abstrakt darstellen Die Simulation beruht auf m glichst realit tsnahen Modellen die im vorgegebenen Ma bestimmte Ereignisse ausl st Reale Datenpakete treffen so auf simulierte Ereignisse In der englischen Literatur wird daf r die Bezeichnung Real time Discrete event Driven Simulation SU03 benutzt Bei der Kombination aus Simulation und Emulation werden Vorteile aus beiden Testverfahren ausgenutzt Allerdings berwiegen die Nachteile der Simulation je komplexer und detaillierter eine Netzwerkkomponente wird Daher kann die SEmulation nur bedingt eingesetzt werden 2 2 Taxonomiekonzept Nach diesem kurzen berblick ber die verschieden Versuchsmethoden l sst sich zusammenfas sen dass Emulationen berall dort eingesetzt werden wo eine kontrollierbare Testumgebung ben tigt wird die in Echtzeit reproduzierbare Versuchsergebnisse liefert Wobei der Versuchsauf bau aus realen oder virtuellen Netzwerkkomponenten bestehen kann Die Umsetzung der Netzwerkemulation geschieht mit Hilfe von Emulatoren Bei der Versuchs planung sollte ber cksichtigt werden dass die verschiedenen Emulatoren mit unterschiedlichen Schwerpunkten konzipiert wurden Um die Wahl des richtigen Emulators f r ein bestimmtes Testszenario zu erleichtern bietet es sich an die vorhandenen Emulatoren in ein Klassifikations schema einzuteilen In der Literatur wird oft zwischen einfachen Netzknotenemulatoren engl Network Link Emulator NLE und Emulatoren unterschi
35. anderen Umgebungen In beiden Systemen Arbeitsplatz und Server zeigen sich hnliche Werte Fazit Die Arbeit von Hall et al bietet wichtige Anhaltspunkte zum Versuchsaufbau und damit auch zur Anforderungsanalyse in Kapitel 4 So sollte beispielsweise der verwendete Paketgenera tor stabil mehrere Paketstr me generieren k nnen Die Messung der Verz gerungen am Ein und Ausgang mittels TCPDuMmP erh ht zus tzlich die Genauigkeit bei der Wertgewinnung Zudem sollte die Paketrate bei der Genauigkeitsbetrachtung von Paketverz gerungen gering gehalten werden um alle systembedingten Verz gerungen zu minimieren Die Anzahl von auftretenden Paketverlusten innerhalb des Emulators kann als Ma f r dessen Auslastung fungieren und zeigt an ab welcher Datenrate oder Anzahl an Emulationseinheiten ein Emulator berlastet ist 3 2 4 ModelNet Ein anderer Emulator namens MoDELNET Yoc 02 richtet den Fokus auf die Skalierbarkeit und basiert auf einer dezentralen Architektur mit DuMmMYNET als Kernkomponente In Yoc 02 wird gezeigt wie auf Grundlage eines Rechnerverbundes eine hohe Anzahl an Verbindungen mit bestimmen Charakteristiken emuliert werden kann Daf r wird jedoch auf 34 3 Verwandte Arbeiten Effektqualitat Angaben PLR Granularit t Paketeffekte PRR 0 100 f r einzelne Pakete BER Verz gerungen OWD 0 1 ms abh v Kernel Taktung Leistung Paketrate 50 KPkt s bei 500 Byte abh v Paketgr e Tabelle 3 4 Angaben z
36. bestimmte Instruktionen erfasst und auswerten kann Die Erfassung verl uft ohne Unterbrechung der betrachteten Instruktionen Eine umfangreichere Analyse von NETEM bietet die Arbeit Jur 11 aus dem Jahr 2011 Zu diesem Zeitpunkt ist NETEM bereits Teil des Kernels von Linux geworden Der Versuchsaufbau besteht in Jur 11 aus drei in Reihe verbundenen Laptops Als Paketge nerator wird das Tool D ITG AP12 genutzt Untersucht wird die Genauigkeit von NETEM bzgl der OWD AOWD und der Verlustrate Die ben tigten Werte werden mit dem Messwerkzeug OosMET Mic04 erfasst Die f r die Ermittlung der OWD notwendige Uhrensynchronisation wird durch den Einsatz von GPS umgesetzt Vor einer Messung wird sichergestellt dass alle nicht ben tigten Prozesse beendet wurden Au erdem wird zun chst die Grundverz gerung gemessen welche ohne den Einfluss von NETEM 38 3 Verwandte Arbeiten Effektqualitat Angaben PLR 3 PDR 0 100 E Paketeffekte ven gt 55 0 0000000232 Schrittweite 3 E BER Verz gerungen ege 0 1 ms abh v Kernel Taktung Tabelle 3 6 Angaben zur Granularit t von NETEM nach 13q existiert Der Mittelwert der Grundverz gerung wird in den folgenden Messungen heraus gerechnet F r jede der drei genannten Metriken werden in mehreren Versuchsdurchg ngen nacheinander aufsteigende Werte vorgegeben Jeder Durchgang umfasst eine bestimmte Anzahl an Probepaketen Die Genauigkeit ergibt sich aus den Abweichungen der ge
37. des Herstellers APPOSITE 13a zur Verf gung welcher bereits in einer vorangegangenen Arbeit B s13 als Referenzpunkt f r Genauigkeitsuntersuchungen diente Eine Publikation mit Analysen zu dessen Genauigkeit oder Leistung ist nicht auffindbar Allerdings werden in der zugeh rigen Produktdokumentation Angaben zu Abweichungen und zur Verarbeitungsgeschwindigkeit gemacht Mit diesen Wer ten lassen sich wiederum in eigenen Untersuchungen Vergleiche anstellen Daher wird dieser Hardware Emulator trotz fehlender Analysen mit betrachtet Alle folgenden Emulatoren sind Software basiert und k nnen als Anwendung Kernelpatch oder VM aus dem Internet heruntergeladen werden ber eine Trendanalyse von Internetsuchanfragen l sst sich eine erste Auswahl treffen und der Bekanntheitsgrad sowie der ungef hre Zeitpunkt der Ver ffentlichung ablesen In Abbildung 3 1 ist eine solche Analyse f r Suchanfragen an den Suchmaschinenbetreiber GooGLE zu sehen Der Zeitbereich beginnt im Januar 2004 da erst ab diesem Zeitpunkt die Daten zur Analyse ver ffentlicht wurden Zu sehen ist das DuMMYNET 13w einer der ersten und bekanntesten Emulatoren ist In der j ngsten Dokumentation CR10 dazu finden sich Aussagen zu weiteren Emulatoren wie z B KAUNET 13j MODELNET 13n oder EMULAB 13c welche allesamt auf DumMMyYNET aufbauen Eine andere Analyse welche mit Hilfe der f r wissenschaftliche Arbeiten spezialisierte Suchmaschine GOOGLE SCHOLAR 13e durchgef hrt wur
38. des Unterbrechenden Prozesses erneut angefordert Die Ska lierbarkeit des Emulators nimmt daher ab Eine m gliche L sung ist eine solch hohe Taktrate nur zeitlich begrenzt zu aktivieren bzw adaptive Zeitgeber zu nutzen Ein Beispiel daf r sind die High Resolution Timer unter Linux welche ereignisgesteuert die Taktung anpassen 2 3 4 Bedarf Der Bedarf umfasst die technischen Grundvoraussetzungen und die f r die Emulation ben tig ten Ressourcen zur Generierung dieser Effekte Dazu geh ren das Betriebssystem und oder die Kernelversion Teilweise sind zus tzliche Anpassungen des Betriebssystems n tig wie z B das Installieren eines Kernelmoduls oder einer weiteren Software Diese Angaben findet man auf der Internetseite der Entwickler oder in den Handb chern Die technischen Mindestanforderung wie CPU oder RAM dagegen finden sich zumeist nur in direkt im Evaluierungsteil der Ver ffentlichungen in den Angabe zum verwendeten Versuchsauf bau 2 3 5 Pfadvorgabe Die Definition einer Netzwerkverbindung kann explizit durch eine Liste von Werten vorgegeben oder implizit ber die virtuelle Topologie beschrieben werden Teile dieser Topologie k nnen variabel gestaltet werden um so z B Knotenausf lle und die damit verbundene Pfadumleitung nachzubilden Die implizite Pfadvorgabe kann daher weiter in konstante oder variable Topo logien eingeteilte werden Die expliziten Vorgaben wiederum werden entweder statisch oder ereignisgesteuert bzw
39. einhalten um Uberlappungen in der Paketerfassung zu vermeiden Zur Sicherheit wird daher eine Dauer von mindestens einer Sekunde gefordert Wird dennoch versehentlich ein geringerer Wert gew hlt muss das System dies erkennen F r den Nachweis wurde ein Mindestdauer von 100 Millisekunden eingestellt Daraufhin erscheint die Fehlermeldung ValueError The minimum duration is 1 sec Neben den vorgestellten Beispielen erkennt das Messsystem noch weitere Fehler Dadurch werden bereits im Vorfeld Messfehler weitestgehend vermieden 7 4 Zusammenfassung In diesem Kapitel wird die Funktionsf higkeit des Versuchsaufbaus Paketgenerators sowie der Paketerfassungen gezeigt Der Aufbau wird dabei mittels P nsG Anfragen und Antworten etappenweise vom Sender ber die beiden Netzwerkkarten des Emulators zum Empf nger kontrolliert Dem Paketgenerator werden mehrere Vorgaben bergeben und die daraus resultierenden Paketstr me werden mit Hilfe des Messtools WIRESHARK analysiert Die Ergebnisse zeigen dass der Generator zuverl ssig und sehr genau arbeitet Auch die Paketerfassungen auf der Sender und Empf ngerseite werden mit Aufnahmen von WIRESHARK verglichen Auch hierbei zeigen die Ergebnisse dass die Paketerfassungen zuverl ssig arbeiten Im letzten Abschnitt werden absichtlich einige Fehler in die Konfiguration der Netzwerkeinstel lung und der Messparameter eingebracht um die Fehlererkennung des Messsystems vorzustellen Diese Erkennung
40. f r das jeweilig Zeitintervall gebildet wird D h aus der Liste der Mittelwerte werden zum einen die Standardabweichung und zum anderen der Durchschnitt berechnet um anschlie end aus beiden das Verh ltnis zu bilden Als letzten Schritt werden die CoDVwBMA Werte des Senders und des Empf ngers im Diagramm in Abbildung 5 16 visualisiert Erkennbar ist die deutliche Instabilit t der Werte auf der 5 3 Zusammenfassung 83 Mittelwertlisten in ms o Mittelwert D CoDVwBMA Dig 2 25 2 5 2 5 2 5 2 5 2 25 0 1178 2 4166 0 0487 Dog 2 375 2 375 0 0 2 375 0 0 SG Dso 2 29 0 0 2 3 0 0 Dag 2 29 0 0 2 3 0 0 A Dso 2 29 0 0 2 3 0 0 Deo 2 29 0 0 2 3 0 0 Dio 2 5 2 3 2 5 3 40 2 5 3 13 0759 7 9762 1 6394 3 D 2 5 2 3 2 5 3 40 14 9683 10 0666 1 4869 amp Dap 2 5 2 3 2 5 3 40 14 9683 10 0666 1 4869 amp Dag 2 5 2 3 2 5 3 40 14 9683 10 0666 1 4869 E Dso 10 9 6 11 5 12 25 10 1 0225 10 67 0 09583 RA Deo 6 6 6 6 0 0 6 6666 0 0 Tabelle 5 3 Ergebnisse der Mittelwertberechnungen fiir die Betrachtung der Wertstabilitat mit Hilfe von CoDVwBMA Empf ngerseite f r die Zeitintervalle bis 50 ms W hlt man beispielsweise einen Betrachtungs bereich von 10 ms so betr gt die Streuung um den Mittelwert 164 Erst ab einem Intervall von 50 ms sinkt diese auf 10 Anders verh lt es sich auf der Senderseite Hier sind f r das erste Zeitintervall 5 zu erkennen Somit l sst sic
41. f r jeden Probestrom mehrere Probedurchl ufe durchgef hrt und die Ergebnisse gemittelt Die kleinstm gliche Rate ist erreicht wenn entweder der Probestrom eine L nge annimmt dessen Generierung nicht mehr m glich ist oder die Abweichungen au erhalb einer bestimmten Toleranz liegen Die kleinstm gliche Verz gerung ist abh ngig von der verwendeten Taktrate des Emulators Ist der Wert der Taktung bekannt so dient dieser als Ausgangspunkt f r die Untersuchung Alternativ wird eine geringe Verz gerung als Emulationsvorgabe gew hlt Die Vorgabe wird am Emulator stufenweise verringert und jeweils mit einer festen Anzahl an Paketen untersucht vgl Tabelle 5 1 Mehrere Probedurchl ufe sind nicht n tig da die Verz gerung jedes Paket in einem Paketstrom beeinflusst und bei entsprechender Stroml nge die Gewichtung von Ausrei ern verringert wird Die kleinstm gliche Verz gerung ist erreicht wenn entweder der Vorgabewert den Wert der gemittelten Grundverz gerung des Versuchsaufbaus annimmt oder die Abweichungen au erhalb einer bestimmten Toleranz liegen Die kleinstm gliche emulierbare Datenrate wird durch die kontinuierliche Verringerung der Wertvorgabe am Emulator bei gleichbleibender Paketrate und anzahl je Paketstrom ermittelt Es wird daher untersucht wie stark die emulierten Datenraten von den Vorgaben bei einer bestimmten generierten Datenrate abweichen Auch hier ist lediglich ein Probedurchlauf pro 74 5 Konzeption Paketeffe
42. finden Letztere fasst alle drei Untersuchungen in einer Tabelle zusammen und zeigt den geforderten Ablauf von Anfrage und Antwort jeder einzelnen Station zwischen dem Sender und Empf nger Alle Pakete wurden von jeder Netzwerkkarte beantwortet Daher ist der Versuchsaufbau funktionsf hig 7 2 Paketgenerierung und erfassung Durchf hrung Um die korrekte Funktion der Paketgenerierung f r die anschlie enden Mes sungen zu zeigen werden Paketstr me mit denjenigen Eigenschaften erzeugt und versendet welche auch in den eigentlichen Untersuchungen zum Einsatz kommen Im Detail ergeben sich daher die Paketstromeigenschaften wie sie in Tabelle 6 3 zu finden sind Die Paketanzahl 96 7 Validation No Quelle Ziel Info 1 10 0 0 2 10 0 0 1 Echo ping request seq 121 30976 2 10 0 0 1 10 0 0 2 Echo ping reply seq 121 30976 3 10 0 0 2 10 0 0 1 Echo ping request seq 122 31232 4 10 0 0 1 10 0 0 2 Echo ping reply seq 122 31232 5 10 0 0 2 10 0 0 1 Echo ping request seq 123 31488 6 10 0 0 1 10 0 0 2 Echo ping reply seq 123 31488 7 10 0 0 2 10 0 0 1 Echo ping request seq 124 31744 8 10 0 0 1 10 0 0 2 Echo ping reply seq 124 31744 9 10 0 0 2 10 0 0 1 Echo ping request seq 125 32000 10 10 0 0 1 10 0 0 2 Echo ping reply seq 125 32000 11 10 0 0 2 10 0 0 5 Echo ping request seq 126 32256 12 10 0 0 10 0 0 2 Echo ping reply seq 126 32256 13 10 0 0 2 10 0 0 5 Echo ping request seq 127 32512 14 10 0 0 5 10 0 0 2 Echo ping re
43. gesendeten Pakete Mr gibt Auskunft ber die jeweilige Rate F r die Paketverlustrate engl Packet Loss Rate PLR wird das Verh ltnis aus den beiden genannten Mengen gebildet Mpx Mr In der Praxis wird dieses Verh ltnis nicht erst am Ende einer Daten bertragung berechnet sondern es werden Zeitfenster und aufsteigende Paketnummern verwendet um so fr hzeitig Verluste zu erkennen Ein Paket gilt als verloren wenn Pakete mit einer h heren Nummerierung am Empf nger auftreffen und das Zeitfenster geschlossen ist Zeitfenstern k nnen jedoch zu einem weiteren Effekt f hren Ist das Zeitfenster zu klein gew hlt und wird ein verl ssliches Protokoll wie z B TCP verwendet so entsteht eine Wiederholungsrate engl Retransmission Rate RR welche gr er als die tats chliche PLR ist Dadurch kommt es zu Paketdopplungen Entsprechend l sst sich daher auch eine Paketdopplungsrate engl Packet Duplication Rate PDR PLR 1 2 7 16 2 Nachbildung von Netzwerkverhalten angeben die das Verh ltnis aus der Menge der empfangenen doppelten Pakete Dr und der Menge der versendeten Pakete darstellt Drx PDR Mr 2 8 Der dritte Effekt die Paketneuordnung wird bei Netzwerkmessungen h ufig anstelle der PDR betrachtet bzw es wird nicht explizit zwischen doppelten und neu geordneten Paketen unterschieden Entsprechende Analysetools z hlen daher alle doppelten Pakete zu den neu geordneten Da jedoch beide Raten getr
44. in anderen bereits vorgestellten Analysen beschrieben wird auch in NR09 die m gliche Datenrate zur Messung der Leistungsf higkeit verwendet F r die Untersu chungen wird das Messtool IPERF mit TCP Paketen eingesetzt Die Ergebnisse zeigen dass bis zu einer geforderten Datenrate von 500 MBit s alle drei Emulatoren akkurat arbeiten Erst ab dieser Rate werden Unterschiede deutlich welche auf die verschiedenen Implementierungen zur 46 3 Verwandte Arbeiten Ratenbegrenzung zur ckzuf hren sind DumMYNET und NISTNnET berechnen die n tige Verz ge rung und f gen diese bestimmten Paketen hinzu um die geforderte Datenrate zu erreichen Die Abweichungen entstehen dabei ebenfalls durch die taktgesteuerte Paketverarbeitung NETEM dagegen verwendet dazu Token Bucket Algorithmen Diese erf llen urspr nglich einen anderen Zweck und gestatten kurzfristige Paketraten welche ber der geforderten Rate liegen k nnen F r die Emulation hat diese Ausnahmeregelung eher negative Auswirkungen auf die Datenratenbegrenzung Fazit Die Arbeit von Nussbaum et al konzentriert sich berwiegend auf die Implementatio nen des Zeitgebers sowie der Warteschlangen der drei Emulatoren und zeigt wo aufgrund der jeweiligen Umsetzung bereits im Vorfeld Abweichungen entstehen k nnen Im Mittelpunkt der ersten Betrachtungen steht der Grad der Abweichung der Paketverz gerung bei unterschiedlichen Taktungen des Zeitgebers Anders als bei den Messungen zur Genauigkei
45. in der Arbeit von Shaikh et al der CoTV verwendet In der folgenden Anforderungsanalyse werden die aus den vorgestellten Analysen gewonnen Erkenntnisse weiter ausgef hrt um so ein eigenes Konzept zur Wertgewinnung zu erhalten 51 3 4 Zusammenfassung U9IoJenWwAg UdITYRMssne Jap USIFeydsuadtT spuayajs soj Jap YSISIEG OTE APEL A NA u WA SYPMZPN IPN uonepnwg 3 3 3109 UONEINWOUSIOUNZIN S SE Pe STPI Ba z YS prey JoAOpueH 2 S i PEE S F sunupsonay Bunjddog A Aatammg 5 5 SUPA RK E T oF T GMO UOPLA 5 E amo mau Er S LO gt ye L ssony z S O PIU Pq APULU B Joysnyy so Y sySTUTU J p S 4 oIed unou ored unou tun Tun Tun 0011 mm uapresdungrsra yssystpgego1d g E F a ayoepseqorazjnusg t4 PPS e suoy melu 3 E WA E Z A 74 A PROT eres mo 2 E 2 JA Wa Wa Ze TE Zar ep amp I I I I z T T 0 urugy mou 1S PUTN amp 3 Mon ee Ss 85 TVA EL X8 Zg aremp eH SA nur woIs sgqarmog a Sumo4 A D Dees ZHM OL pow ZH OL pow ZH OL Apow Ke SUPRIZ d i EE GER Ba we ee SEL SE Be TR rue YMSISASNOgIY Pr ae Ra ar Ka Be EE eg ER Ia mppyTyIy HIVJLIN SINANI WINVM WJLIN LINTAGOW LINAVy LINAWWAG AdOULANIT 52 53 4 Anforderungsanalyse Bevor mit der Konzeption f r ein Messverfahren und dessen Imple
46. me mit denjenigen Eigenschaften welche auch in den eigentlichen Messungen verwendet werden D h es werden verschiedene Paketgr en und unterschiedliche Paketabst nde berpr ft Sollen beispielsweise zehn ausgew hlte Paketraten f r f nf verschiedene Paketgr en gemessen werden so werden im Vorfeld die Grundverz ge rung f r ebenfalls diese Raten und Paketgr en ermittelt Die Grundverz gerung ist dabei die durchschnittliche Verz gerung aller OWDs des jeweiligen Paketstromes Die Ergebnisse dieser Voruntersuchungen werden von den ermittelten Verz gerungen in der eigentlichen Messung abgezogen um so die tats chliche Verz gerungen welche durch den Emulator verursacht werden zu erhalten Maximale verlustfreie Paketrate Neben der Grundverz gerung muss ebenfalls die maximal m gliche Datenrate innerhalb der Versuchsumgebung ermittelt werden Auch in diesem Fall geschieht die Untersuchung ohne den Emulator Gemessen wird die MLFFR des Versuchsaufbaus um eine Obergrenze f r die eigentliche Messung zu erhalten Dadurch wird sichergestellt dass es zu keiner Verwechslung zwischen der MLFFR des Emulators und der maximalen verlustfreien Paketrate des Versuchsaufbaus kommt Im optimalen Fall beschr nkt der Versuchsaufbau nicht die Leistungsf higkeit des zu testenden Emulators und die Obergrenze wird nicht erreicht Sollte dennoch der Fall eintreten dass diese Obergrenze in den eigentlichen Messungen erreicht wird so wird dieses in den E
47. nachgeahmt werden Implizit Eine andere M glichkeit bieten Netzwerkmodelle welche teils aus realen oder auch komplett aus virtuellen Komponenten zusammengesetzt werden Dadurch lassen sich f r den Versuchsaufbau Netzwerktopologien nachbilden die der sp teren Zielplattform entsprechen Die Bausteine bilden beispielsweise Router mit definierten Eigenschaften nach und k nnen zentral oder dezentral platziert sein Bei einer zentralen Installation werden zumeist die virtuellen Endpunkte auf einem einzelnen Rechner zusammengefasst und die emulierten Netzwerkknoten werden verteilt Versendet werden reale Datenpakete welche durch die Eigenschaften der realen oder virtuellen Komponenten beeinflusst werden Das globale Netzwerkverhalten und die Einfl sse innerhalb der emulierten Topologie setzen sich somit wie auch in der Realit t aus dem Verhalten der einzelnen Komponenten zusammen Konstant Bei diesen Topologien bleiben die Verbindungspfade aus Sicht der Endsysteme unver ndert Dadurch lassen sich Experimente durchf hren die den Fokus auf einen Pfad mit einer bestimmten Verkettung von Komponenten legen Beispielsweise bei der Nachbildung eines Feldbusses in der Geb udeautomatisierung Vorteilhaft ist die im Gegensatz zur variablen Pfadvorgabe h here Skalierbarkeit vgl Abschnitt 2 5 da keine redundanten Pfadverbindungen vorgehalten werden m ssen Es kann sich jedoch gleichzeitig als Nach teil erweisen wenn unterschiedliche Verkettunge
48. nglichen Pfadvorgabe ermittelt und an diese pipe bergeben Die Verz gerung dagegen ist die Summe aller Teilverz gerungen der urspr nglichen Vorgaben F r die resultierende Verlustrate wird das Produkt aller Einzelraten verwendet Gerade f r die Untersuchungen von konkurrierenden Verbindungen ist diese Vereinfachung jedoch nicht erw nscht Daher bietet MODELNET auch andere Abbildungsm glichkeiten an Der Nachweis ber die Genauigkeit dieser M glichkeit wird durch Vergleiche mit dem Simulator Ns 2 McC 97 erbracht Fazit F r dezentral gestaltete Emulatoren bietet es sich an zun chst alle Emulationseinheiten auf einem einzelnen Rechner zu installieren Dieser Rechner wird anschlie end einem Stresstest unterzogen bei dem zum einen die Verkettungsl nge und zum anderen die Anzahl paralleler Verkettungen erh ht wird Das Vorgehen hnelt dem Vorgehen bei KAUNET und es werden dabei ebenfalls die CPU Last die Paketrate und der Paketverlust gemessen Erreicht die CPU Last 100 und die Verlustrate steigt so ist die Kapazit t des Emulators erreicht Der Begriff Kapazit t l sst sich auf andere Emulatoren bertragen und kann als Ma f r die Skalierbarkeit verwendet werden In einem weiteren Experiment werden die Emulationseinheiten verteilt und es wird 36 3 Verwandte Arbeiten Effektqualitat Angaben ie PLR Granularit t Paketeffekte PRR 0 100 Verz gerungen OWD 0 1 ms abh v Kernel Taktung Leistung Paketrate 120 K
49. rungsanalyse werden dazu die vier Nachweise QN 1 bis QN 4 erl utert welche sicherstellen sollen dass die Probepakete mit der eingestellten Gr e sowie Rate ausschlie lich vom Emulator beeinflusst und vom Empf nger erfasst werden Fehlkonfigurationen sollen dabei vom System erkannt und angezeigt werden Dieses Kapitels gliedert sich entsprechend und beginnt mit dem Nachweise ber die korrekte Funktion des Versuchsaufbaus bzw des Netzwerkkonfiguration QN 1 Anschlie end werden die beiden Software Komponenten untersucht welche f r die Generierung sowie Erfassung der Messdaten sorgen und damit grundlegend f r alle Auswertungen sind QN 2 und ON 31 Abschlie end werden absichtlich m gliche Fehler in der Konfiguration bzgl der Netzwerkkonfiguration und Messparameter ausgel st und die Reaktion des Systems aufgezeigt 7 1 Versuchsaufbau Durchf hrung Der Versuchsaufbau wird jeweils mit f nf p nG Anfragen ICMP Requests zwischen dem Sender Tx 1 und der ersten Netzwerkkarte des Emulators E1 2 sowie dessen zweiter Netzwerkkarte E2 3 und abschlie end der Empf ngerkarte Rx getestet vgl Abb 6 2 F r die korrekte Funktion m ssen E1 E2 und Rx auf die Anfragen mit jeweils f nf p ng Antworten ICMP Reply reagieren Die Nachweise werden zum einen durch die Ausgabe des Programmes PING und WIRESHARK erbracht Ergebnisse Die Ausgaben der beiden Programme sind zum einen in Anhang A 1 und zum an deren in Tabelle 7 1 zu
50. siehe S 24 38 NetPath Pr sentation 2013 URL http pages cs wisc edu jsommers pubs netpath_slides pdf besucht am 09 09 2013 siehe S 24 NISTNet Home Page 2013 URL http www x antd nist gov nistnet besucht am 07 09 2013 siehe S 24 Ostinato Packet Traffic Generator and Analyzer 2013 URL https code google com p ostinato besucht am 02 12 2013 siehe S 68 Other Internet Traffic Generators 2013 URL http traffic comics unina it software ITG link php besucht am 02 12 2013 siehe S 68 Packet Crafter Apps 2013 URL http www packet craft net Apps besucht am 02 12 2013 siehe S 68 The dummynet project 2013 URL http info iet unipi it luigi dummynet besucht am 07 09 2013 siehe S 23 30 Ihe Genius of DAG 2013 URL http www emulex com products network visibility products the genius of dag features besucht am 06 10 2013 siehe S 47 Traffic Control HOWTO 4 Components of Linux Traffic Control 2013 URL http tldp org HOWTO Traffic Control HOWTO components html besucht am 09 09 2013 siehe S 36 WANem The Wide Area Network emulator 2013 URL http wanenm sourceforge net besucht am 09 09 2013 siehe S 24 winpcap 2013 URL http www winpcap org besucht am 13 02 2013 siehe S 87 ALMES G et al RFC 2679 A one way delay metric for IPPM Techn
51. und der Empf nger sowie der Emulator bilden die Endpunkte Das Projekt ist f r gro fl chige Forschungen im Bereich der verteilten Anwendungen entworfen worden und setzt sich zum Teil aus Cloud basierten VMs zusammen Die Vorteile eines solchen Systems sind die hohe Verf gbarkeit und Erweiterbarkeit F r die Untersuchung der Genauig keit und Leistung eines einzelnen Emulators sind jedoch die genannten Vorteile hintergr ndig Vielmehr sollten so wenige Netzwerkkomponenten wie m glich an der Versuchsdurchf hrung beteiligt sein um die Anzahl der ungewollten Paketeinfl sse zu minimieren Daher wird f r den 62 5 Konzeption eigenen Aufbau auf den Router verzichtet und die in Abb 3 14 gezeigte logische Verbindung physisch umgesetzt Der Emulator befindet sich dadurch direkt zwischen dem Sender und dem Empf nger Daf r kann der Emulator entweder mit zwei einzelnen Netzwerkkarten oder einer Dual Port Netzwerkkarte ausger stet werden Der erste Ansatz der eigenen Versuchsumgebung ist in Abbildung 5 1 dargestellt Sender Emulator Empf nger Abbildung 5 1 Erster Ansatz des eigenen Versuchsaufbaus Der n chste wichtige Punkt bei der Planung der Versuchsanlage beinhaltet die Anzahl und die Positionierung der Messpunkte Der Versuchsaufbau in Sha 10 basiert auf der DPMI und positioniert die beiden Messpunkte parallel zum Emulator vgl Abb 3 16 Diese zeichnen passiv den Datenverkehr zwischen den Endpunkten und de
52. von gesendeten und emp fangenen AOWDJ Werten vgl Tabelle 5 2 innerhalb von sechs verschiedenen Zeitintervallen AT 1 lt j lt 6 Zur besseren bersicht wurden f r das Beispiel lediglich zehn Messwerte gew hlt und der Betrachtungsbereich eher grob gew hlt blichweise sind die Wertemengen deutlich gr er und die Zeitintervalle beginnen bei 1 ms Im Beispiel tritt auf der Empf ngerseite eine hohe Abweichung mit dem Wert 40 ms und eine geringe Abweichung mit 5 ms auf In einem ersten Schritt wird f r jedes Zeitintervall eine Liste mit den gleitenden Durchschnitten gebildet Abbildung 5 15 veranschaulicht die Mittelwertbildung auf der Empf ngerseite Der erste Mittelwert des Zeitintervalls AT 10 ms wird ber die ersten vier Verz gerungsvariationen gebildet da diese aufsummiert gleich dem Wert von AT entsprechen und damit innerhalb dieses Zeitintervalls liegen Das Zeitfenster wird f r den zweiten Mittelwert um eine Stelle innerhalb der Liste verschoben Der zweite Durchschnitt wird ber den zweiten dritten und vierten Messwert gebildet Zwar liegt die Summe der einzelnen Messwerte unter dem Wert 82 5 Konzeption von AT jedoch w rde die Einbeziehung des f nften Wertes daf r sorgen dass die Summe au erhalb des Betrachtungszeitraumes liegt Gleiches gilt f r den dritten und vierten Mittelwert Der Fortlauf des Zeitfensters blockiert solange vor der f nften Stelle bis diese Stelle selbst durch die Iteration des Algorithmus
53. vor allem die Vorgehensweisen und Vorbetrach tungen interessant Die Funktionsweisen von DUMMYNET und NETEM wurden bereits in den vorhergehenden Abschnitten erl utert Einzig f r NISTNET sei zu erw hnen dass dieser als Zeitgeber die physikalische Uhr engl real time clock mit einer Taktung von 8192 Hz verwendet Diese Erw hnung ist wichtig da auch in NR09 auf die hohe Bedeutung des Zeitgebertaktes f r die Genauigkeit des Emulators hingewiesen wird Die erste Betrachtung bezieht sich daher zun chst auf unterschiedliche Taktungen bei einer fest vorgegebenen Paketverz gerung An schlie end werden Messung zur emulierbaren Datenrate welche ebenfalls auf Verz gerungen beruht durchgef hrt Die genaue Vorgehensweise dieser Genauigkeits und Leistungsanalyse sowie der Versuchsaufbau werden im Folgenden beschrieben Versuchsaufbau Die Versuchsumgebung besteht wie in Abb 3 14 veranschaulicht aus einem Switch mit zwei Endpunkten und einem Rechner der als Router f r die beiden Endpunkten fungiert Auf diesem Router werden die drei Emulatoren installiert und nach der Feststellung der Grundverz gerung sowie maximal m glichen Datenrate f r den jeweiligen Versuchsdurchgang ausgef hrt physische Verbindung ELCH logische Verbindung Endsystem 1 Router Endsystem 2 Abbildung 3 14 Versuchsaufbau in NR09 F r die Betrachtungen der unterschiedlichen Taktungen bei einer festgelegten Verz gerung wird
54. weiteren Veranschaulichung der Messergebnisse befinden sich in Abbildung 8 1 die entsprechenden Verteilungen als Box plot mit den Mittelwerten Sterne Minima und Maxima Antennen sowie dem jeweiligen Medianen mittlere Linie innerhalb der Box Erwartungsgem steigt die Verz gerung f r wachsende Paketl ngen Die Unterschiede bleiben auch f r sinkende Paketraten ann hernd gleich Zus tzlich ist zu erkennen dass die Grundverz gerungen f r geringere Paketraten h her ausfallen als bei den gr eren Raten Der C OWD PLR PRR PDR LINKTROPY X X X X X DUMMYNET X X X KAUNET x x X X NETEM X X X X Tabelle 8 1 bersicht ber die Funktionsm glichkeiten der ausgew hlten Emulatoren in Bezug auf die zu untersuchenden Netzwerkmetriken 102 8 Durchf hrung Paketgr e in Byte 64 512 1024 1500 20 91 103 133 161 120 111 119 146 172 1000 148 157 185 208 Paket abstand rei I g Tabelle 8 2 Durchschnittliche Grundverz gerungen in us des Versuchsaufbau f r die jeweilige Paketstromeigenschaft unter FREEBSD 7 3 KAUNET PPS 50 0 KPkt s PPS 8 3 KPkt s PPS 1 0 KPkt s 0 3340 0 3102 0 2863 i a 0 2625 Sib OR une a 0 2148 5 0 190891 Soe l l H 4 ele ae i i i i i i i i i i i i i i i i i i i i i i i TC i i i i f i i i i i i pat i i Loil n
55. z B die Zuordnung der IP Adresse und die Angabe des Gateways wichtig Da auch hier mehrere Angaben ben tigt werden stellt eine Konfigurationsdatei eine komfortable Eingabem glichkeit dar welche ebenfalls mittels GUI unterst tzt werden kann Datengewinnung Aus den versendeten und empfangenen Paketen werden jeweils der Zeit stempel und die zuvor eingef gten Paketnummer mittels passiver Paketerfassung extrahiert Die Zeitstempel umfassen zum einen den Sekundenanteil und zu anderen den Mikrosekundenanteil des Sende bzw Empfangszeitpunktes Eine geringere Aufl sung ist aufgrund der verwendeten Zeitgeber nicht m glich Die Zeitstempel werden f r die Analysen der Verz gerungen und Datenraten verwendet Die Paketnummern dagegen bilden die Grundlage f r Untersuchungen im Bereich der Paketeffekte Die Zeitstempel und die Paketnummern sind daher die Rohdaten f r alle weiteren Analysen Datenhaltung Eine sofortige Ausgabe der Ergebnisse nach jedem Probedurchlauf ist nicht gefordert Daher lassen sich die Messungen und die Auswertung separat hintereinander ausf hren Dazu ist jedoch eine Datenhaltung n tig um die erfassten Paketdaten bis zur Auswertung zu speichern Bei mehreren Versuchen mit mehreren Probedurchg ngen sammeln sich Rohdaten in Gr enordnungen von mehreren Gigabyte an Als Beispiel sollen in einem einzelnen Versuch Paketraten im Intervall von 1 KPkt s bis 200 KPkt s in 10 KPkt s Schritten mit jeweils 100 Probedurchl ufen unter
56. zur Verf gung zu haben Je nach Entwicklungsstufe des Softwareprojekts werden dazu oft Versuche mittels Realumgebung Simulation oder Emulation durchgef hrt In Abbildung 2 1 wird beispielhaft die Einsatzm glichkeit der jeweiligen Versuchsmethode am Wasserfallmodell gezeigt Eine Kombination aus den beiden letztgenannten Versuchsmethoden 4 Emulation Emulation Soss Test Debugging Simulation 777777 NA S Aa Realumgebung Abbildung 2 1 Wasserfallmodell der Softwareentwicklung mit Einsatzm glichkeiten der drei Versuchsmethoden wird ebenfalls f r bestimmte Testszenario verwendet und kann als SEmulation bezeichnet werden Dieser Begriff stammt urspr nglich aus dem Bereich der Schaltkreis und Systementwicklung und wird in dieser Arbeit f r eine m gliche Methode zur Nachbildung von Rechnernetzen verwendet Der Fokus dieser Arbeit liegt auf der Genauigkeits und Leistungsanalyse von Netzwerkemu lationen bzw deren unterschiedlichen Implementationen in Form von Emulatoren Bevor jedoch weiter auf Netzwerkemulatoren eingegangen wird werden zun chst die genann ten Methoden f r eine begriffliche Abgrenzung kurz umrissen 2 1 Methoden zur Nachbildung Simulation werden in der Regel als Vorhersage und Managementwerkzeug f r Netzwerke benutzt Dabei existieren zwei Ans tze Simulationen durchzuf hren Luc 03 Der erste An satz beruht auf mathematischen Modellen die Netzwerke und deren Einfl sse abstrahieren P
57. zwei Experimente durchgef hrt Beide unterscheiden sich in der Anzahl der verwendeten pipes Im ersten Versuch ist jede der eingesetzten pipes f r bestimmte Netzwerkeffekte zust ndig Im anderen Experiment dagegen verf gen mehrere pipes ber die gleichen Vorgaben In beiden F llen wird die m gliche Verarbeitungsgeschwindigkeit des Emulators getestet Die variablen Faktoren sind dabei die generierte Datenrate die Paketgr e und speziell im zweiten Versuch die Anzahl der pipes Bei den Betrachtungen mit mehreren bzgl des Effektes identischen pipes bei unterschiedlichen Datenraten und Paketgr en wird f r jede pipe ein Paketstrom erzeugt W hrend der Versuchsdurchf hrung werden zum einen die Paketverz gerungen am Ein und Ausgang des Emulators gemessen Dadurch befinden sich beide Messpunkte auf einer einzelnen 3 2 Produktpublikationen und dokumentationen 33 Maschine und eine Uhrensynchronisation ist berfl ssig Zum anderen wird die Verbindung an allen vier Messpunkten vgl Abb 3 9 auf ungewollte Paketverluste gepr ft Wodurch genau die Verluste ermittelt werden k nnen die tats chlich durch den Emulator verursacht wurden Die physische und hybride Umgebung zeigen die besten Ergebnisse Die empfangenen Da tenraten entsprechen den gesendeten Einzig beim hybridem Aufbau bei dem sich lediglich die Endpunkte in einer VM befinden entstehen wesentlich fter Paketverluste Abweichungen zwischen der Empfangs und Sendedaten
58. 000 s abh vom Betriebssystem Tabelle 3 2 timing Grad der Beeintr chtigung durch die genannten Faktoren Quelle CR10 emuliert werden entsteht zwischen diesen ein Wettbewerb um Betriebsmittel und es m ssen Wartezeiten hinzugef gt werden Im schwerwiegendsten Fall muss ein Paket dabei vgl CR10 T N 1 7 3 1 Sekunden warten Der Wert f r die Interferenz wurde experimentell mit Hilfe von p nG Tests unter verschiedenen Auslastungen der Arbeitsbereiche vgl Abschnitt 2 3 und f r verschieden viele Firewall Regeln er mittelt Als Ausgangswert werden die p nG Antworten eines im Leerlauf engl idle befindlichen Rechners f r keine eine und hundert Regeln gemessen Anschlie end wird der Nutzerbereich komplett ausgelastet und die Antwortzeit ebenfalls f r die drei Anzahlen an Regeln ermittelt Es stellte sich heraus dass die Auslastung des Nutzerbereichs keinen Einfluss auf die Antwortzeiten hatte Ganz anders verhielt es sich jedoch bei der kompletten Auslastung des Kernelbereichs Hierbei entstehen zus tzliche Verz gerungen welche mit zunehmender Regelanzahl ansteigen Der dritte Wert ist abh ngig von der eingestellten Taktrate des Zeitgebers Diese wird in Hz angegeben und bestimmt die Anzahl m glicher Systemoperationen pro Sekunde Paketverz ge rungen werden somit intern auf ein Vielfaches dieser Takte ab bzw aufgerundet Im Falle von DumMmYNET werden oft 10000 bis 40000 Hz veranschlagt was gleichzeitig bedeutet
59. 08 des Emulators aufgezeigt Die Werte beruhen zum Teil auf theoretischen Betrachtungen oder werden direkt vorgegeben WANEM unterst tzt die Nachbildung von Paketverlusten dopplungen neuordnungen und verz gerungen Letztere k nnen u a PARETO verteilt variieren und korrelieren Zudem k nnen Bitfehler und wie bereits erw hnt Unterbrechungen emuliert werden Zur besseren bersicht werden diese erreichbaren Werte als Tabelle in 3 7 dargestellt 3 2 7 Imunes Ein ganz eigenes Konzept setzt der Emulator ImuNEs ZM04 um Der Name steht f r Integrated Multiprotocol Network Emulator Simulator und soll andeuten dass IMUNEs sowohl IPv4 als auch IPv6 Verkehr emulieren kann und diverse Routing Protokolle unterst tzt Die Grundlage dieses Emulators bilden Netzwerktopologien welche mit Hilfe leichtgewichtiger Virtualisierungen unter FREEBSD umgesetzt werden Leichtgewichtig bedeutet dabei dass die Bausteine einer Topologie mit Hilfe von klonbaren Netzwerkstapeln und privaten Prozessen virtualisiert werden Jeder dieser Stapel besitzt eigene Ressourcen wie z B Routentabellen oder Netzwerkschnittstellen Die privaten Prozesse wiederum umfassen beispielsweise exklusive Zugriffe auf die CPU welche mittels BSD jail 13d erm glicht werden Pakete innerhalb der Topologie werden durch Zeiger Referenzen weitergeleitet und nicht wie blich durch Kopien Dadurch wird die Leistungsf higkeit von Imunss deutlich erh ht Abbildung 3 13 stammt
60. 6 4 BEN N Ki 5 6 7200 0 54000 0 61000 0 160000 0 Vorgabewerte am Emulator in KBit s relative Abweichung in So N Po 0 c Dummynet Abbildung 8 3 Auszug aus den Messergebnissen zur Betrachtung der Genauigkeit bei der Um setzung von verschiedenen vorgegebenen Datenraten f r einen einzelnen Pfa dabschnitt Die Paketgr e betr gt bei allen Darstellungen 512 Byte 8 2 Messungen 107 28 3 28 6 Vorgabe 7200 KBit s ER x PPS 50 0 KPkt s KauNet BEE 4 20 Dummynet EEE Linktropy z ze D c x x o a lt o 3 5L N 25 PPS 1 0 KPkt s 201 15 10 of 14 14 04 0 9 1 0 0 3 5L 64 512 1024 1500 Paketl nge in Byte Abbildung 8 4 Relative Abweichungen der gemessenen Datenraten bei unterschiedlichen Stro meigenschaften und einem einzelnen Pfadabschnitt Die vermeidlich fehlenden Balken in der Abbildung kommen dadurch zustande dass mit der jeweiligen Kom bination von Paketgr e sowie abstand nicht die geforderte Datenrate erreicht wird Vorgabe 7200 KBit s Hardware Emulator liegt f r Paketgr en oberhalb von 512 Byte innerhalb des vorher festgeleg ten Grenzbereichs 8 2 2 Verz gerung Bei den Messungen zur Genauigkeit von emulierten Verz gerungen heben sich besonders der LINKTROPY und NETEM durch ihre Stabilit t der Werte hervor Als Beispiel werden die CoDVwB MA We
61. 9 49 3 4 34 3 0 3 0 E 01295 Loss r D z PPS 8 3 KPkt s S 25l 3 5 20 ez Ka Sek 2 10 e St 46 46 33 33 29 29 0 S S 30 PPS 1 0 KPkt s 257 S N p N 10 D 3 9 28 28 28 25 25 0 ER N SS un oe I 64 512 1024 1500 Paketl nge in Byte Abbildung A 3 Gemessene Datenraten bei unterschiedlichen Stromeigenschaften und 10 Pfa dabschnitten Vorgabe 200 KBit s A 6 Messung Verz gerungen 125 Ap Messung Verz gerungen SON 0 0S Sdd SPAN 8 Sdd S d O L Scdd T T T T T T T PI T T T T T Lo TEL f JAO T T een a s ram cat oa L Ed 3 L or E 3 E Q 3 L s02 3 oO gt 90 10 D KE B vo IEN A Sm emm gm em m em m Paketl nge 1024 Byte gemessene OWD in ms Paketl nge 512 Byte gemessene OWD in ms Bee AER RH Paketl nge 64 Byte gemessene OWD in ms Linktropy L L L d L L L L L L L L 00 Si ge 2 2 Si o es 2 2 x o e oO a oO oO oO oO yay6yneH Veure yey6yneH Abbildung A A Verz gerungen als Verteilungsfunktion des jeweiligen Emulators f r die ver schiedenen Paketl ngen und raten bei einem einzelnen Pfadabschnitt Vorgabe Ims 126 A 7 Messung Neuordnung A 7 Messung Neuordnung Vorgabe 1 00 PPS 50 0 KPkt s Paketl nge in Byte PPS 8 3 KPkt s PPS 1 0 KPkt s oa Jouassoweab jyezuy Abbildung A 5 Erfasste Neuordnungen fiir die verschiedenen Paketlangen und raten bei einem e
62. AUNET pr fen zu k nnen und zum anderen f r die Visualisierung von z B Intervallen in denen ein Emulator Pakete gewollt bzw ungewollt verwirft verdoppelt oder neu ordnet 5 2 Vorgehensweise 75 Die genaue Vorgehensweise f r die Analyse der einzelnen Metrikwerte und die Berechnung der statistischen Werte werden dazu im Folgenden beschrieben Paketeffekte Die Algorithmen f r die Ermittlung der Paketverluste dopplungen und neu ordnungen sind in Nora daf r ausgelegt worden bereits w hrend des Versuches Ergebnisse zu liefern Anstelle der Ausgabe der konkreten Paketnummern wird dabei lediglich die Anzahl der Pakete ben tigt welche entweder verloren verdoppelt oder neu geordnet wurden Um jedoch auch die zugeh rigen Paketnummern zu erhalten werden die Algorithmen angepasst Paketverluste und dopplungen werden bisher mit Hilfe von Abst nden zwischen zwei aufeinanderfolgenden Paketnummern gez hlt Bei Dopplungen betr gt der Abstand gleich Null Paketverluste dagegen werden durch Abst nde gr er Eins gekennzeichnet Um an die betref fenden Paketnummern zu gelangen bieten sich drei M glichkeiten an Die erste M glichkeit besteht darin bei Abst nden ungleich Eins zus tzliche Routinen einzu f gen welche f r die Dopplungen einfach die beteiligten Paketnummern speichert bzw f r die Paketverluste die fehlenden Nummern zwischen den zwei aktuellen Paketnummern ermittelt und anschlie end speichert Diese L sung hat den Nachte
63. Diese Ressourcenaufteilung bedeutet jedoch nicht dass der Emulator in seiner Leistungsf higkeit eingeschr nkt wird Viele der vorgestellten Emulatoren wurden auf hnlichen oder schw cheren Systemen getestet vgl Tabelle 3 10 Au erdem bauen einige der Emulatoren auf Betriebssyste men auf welche neuere Prozessoren Bussysteme oder eine h here Arbeitsspeicherzahl nicht unterst tzen vgl ebenfalls Tabelle 3 10 Als Netzwerkkarten werden Intel Pro 1000 Karten verwendet wobei jeweils eine Karte ber den PCI Steckplatz und die andere ber den PCIe x1 Steckplatz angeschlossen ist Stan dardm ig ist der PCI Bus ein geteiltes Medium und hat eine theoretische bertragungsrate von bis zu 2 GBit s PCI 2 1 32 Bit in beide Richtungen In der Praxis liegt der Wert weit unter diesem theoretischen Maximum da sich alle angeschlossenen PCI Ger te und fest installierten on board Chips den PCI Bus bidirektional teilen Die Zuteilung des Busses geschieht ber ein Zeitmultiplex Verfahren D h selbst wenn lediglich zwei Gigabit Netzwerkkarten angeschlos sen sind w rden sich beide Karten den Bus teilen und so einander beeinflussen Um dieses zu vermeiden wird die zweite Netzwerkkarte per PCIe Bus angeschlossen Dieser Bus ist unabh n CPU RAM NIC 8 GByte mit Intel Pro GT 1000 Tx Messrechner Intel i7 820 2 93 GHz 1534 Ms DORE Intel Pro PT 1000 Rx 4 GByte mit Intel Pro GT 1000 E1 Emulator Intel Core 2 6600 2 4 G
64. EEBSD Systems D h auf diese network layer nodes k nnen eigenst ndige UNIX Konsolen ge ffnet und Programme ausgef hrt werden Dadurch sind u a Routen nderungen w hrend der Emulation m glich Die Verkn pfungen verbinden zwei Knoten und k nnen bestimmte Effektqualit ten wie z B die maximale Datenrate oder BER emulieren Eine konkrete Auflistung der Effekte mit ihren Be reichsgrenzen ist in Tabelle 3 8 zu finden Die Werte stammen aus dem Benutzerhandbuch Uni12 zu IMUNES Leistungsanalyse In der urspr nglichen Arbeit ZM04 zu ImuNEs stehen zum einen die Auswirkung der Virtualisierung und zum anderen die Anzahl der m glichen Pfadabschnitte engl hops im Mittelpunkt der Betrachtungen Die Auswirkung wird durch einen Vergleich mit einem unmodifizierten System berpr ft Gemessen wird dazu die erreichbare BTT f r verschiedenen Paketgr en Die m gliche Pfadl nge wird ebenfalls durch die BTT jedoch in diesem Fall f r aufsteigende Anzahlen von hops gemessen Gleichzeitig wird die Auslastung der CPU dokumentiert und mit der jeweiligen Anzahl an hops verglichen Eine Genauigkeitsanalyse wurde in ZM04 nicht durchgef hrt F r die dezentrale Erweiterung von IMUNES haben dessen Entwickler eine eigenst ndige Untersuchung PPM08 ver ffentlicht In dieser wird ebenfalls auf eine Analyse der Genauigkeit verzichtet und es wird vielmehr auf die Skalierbarkeit Antwortzeit Verarbeitungszeit und den Durchsatz TCP eingegangen Die
65. Genauigkeit in Abh ngigkeit zu dieser Last zu erstellen Einen direkten Vergleich zwischen verschiedenen Emulatoren gestattet die Messung unge wollter Paketverluste bei steigender Datenrate Einen Hardware Emulator als Referenzpunkt zu nutzen kann f r eigene Untersuchungen nicht in Betracht gezogen werden da sowohl Soft ware als auch Hardware Emulatoren gepr ft werden sollen Die Darstellung der Ergebnisse als H ufigkeitsverteilung mit Referenzpunkten gestatten einen schnellen Blick auf die Pr zision der Emulation A4 3 Verwandte Arbeiten 3 3 Vergleichsstudien In diesem Abschnitt werden die Vergleichsstudien NR09 Sha 10 und Min 11 bez glich ihrer Messmethodik und Ergebnisse analysiert Die beiden letztgenannten Studien stammen von den gleichen Autoren Minhas et al und wurden in den aufeinanderfolgenden Jahren 2010 2011 mit unterschiedlichen Schwerpunkten ver ffentlicht W hrend in Sha 10 die Stabilit t der Paketverz gerung untersucht wird steht in Min 11 die Pr zision bei der Begrenzung der Datenrate im Vordergrund In der ersten Studie NR09 von Nussbaum et al werden beide Gr en im Zusammenhang mit dem vom Emulator verwendeten Zeitgeber betrachtet 3 3 1 Nussbaum L und Richard O 2009 Nussbaum et al untersuchen in NR09 die drei Emulatoren NISTNET NETEM sowie DUMMY NET bzgl ihrer Funktionsweise und Genauigkeit bei der Emulation von Verz gerungen sowie Datenraten F r das eigene Messkonzept sind
66. Ha era 70 2 2 2 Messungen sre e Sa Se Ee RR EP ROE Se BAe we eo 71 5 2 3 Auswertung sos s e a ea ae a a d a e oaaae a aa a a oa a 74 5 3 Zusammenfassung A oa SR PERAK CP EE E e ren 83 6 Umsetzung snra 2 3 sa ac aaa Wr a ra a EE EE Geek BR A 85 6 1 Vers chs ufbau sss s ea 22 002 KR HR nern NEE A 85 6 1 1 Hardwaretechnischer Aufbau 85 6 1 2 Softwaretechnischer Aufbau 2 onen 86 6 2 Vorgehensweise 2 22 Cm ee 89 6 2 1 Vorfelduntersuchungen A AN EEN EEN NEE ee E E 91 6 2 2 IMeSSUNGeN E ease Se Gd Ba A ok Ge tee ade he hd oe Gace 5 92 6 3 Zusammenfassung 4 u odd aaa ae 93 7 Validation 2 2 ee 95 7 1 Versuehsaufbau u aha aa DS ERE REYES OO PERE RO 95 7 2 Paketgenerierung und erlassung 2 6 665 666 us eae eee eee es 95 7 3 Fehlererkernung oces 4 boo 44 ea GS as ara ESE ORS 97 7 4 Zusammenfassung zwar aan a AEE ER AGERE See eo 99 Inhaltsverzeichnis iii 8 Durchf hrung 101 8 1 Vorfelduntersuchungen ees Grace a3 E e Si ea Dr Ee ae as 101 8 1 1 Grundverz gerungen euren 101 8 1 2 maximale verlustfreie Paketrate 4 235 280 4 near 102 E de CEET ENEE 103 8 2 Messungen EEN NEE a ENEE nee 104 8 2 1 Datenrate s s Soa addam 0 a a won a a a NA A 105 8 2 2 VETZ BELUNG Iy ie EA soe bo ne E e bee ea 107 8 2 3 Paketeffekte lt 2 22282 5 00 4 0 re Soe ai en ees 110 9 Zusammenfassung und Ausbleck 115 Anhang 44 42 04 Es oe ana bb eee sa ea en 119 A 1 Nachweis Versuchsaufbau Ping ant
67. Hz 667 MHz DDR2 Intel Pro PT 1000 E2 Tabelle 6 1 Hardwarekonfiguration der Versuchsrechner vgl Abb 5 3 86 6 Umsetzung gig vom PCI Bus oder anderen PCle Geraten und leitet die Daten ohne Multiplex Verfahren beispielsweise zur CPU oder zum Arbeitsspeicher weiter Die Hauptplatine des Emulator Rechners unterst tzt den PCle Standard 1 1 und die Intel Pro PT 1000 wird wiederum ber den PCIe x1 Steckplatz angeschlossen Insgesamt ist da her exklusiv eine Daten bertragung vom maximal 4 GBit s in beide Richtungen m glich Der Messrechner unterst tzt den Standard 2 0 was bedeutet dass die verwendete Netzwerkkarte exklusiv eine Transferrate von 8 GBit s nutzen kann In beiden F llen ist eine Nutzung von zwei PCle Karten ist nicht m glich da jeweils nur ein Steckplatz auf der Hauptplatine verf gbar ist D h die Grafikkarte des jeweiligen Rechners blockiert den anderen PCle Steckplatz Die beschriebene Aufteilung der Netzwerkkarten auf verschiedene Busse ist somit eine weitere Ma nahme Engstellen und damit ungewollte Paketeffekte sowie Verz gerungen zu vermeiden Die Verbindung zwischen beiden Rechner ist ein weiterer Ansatzpunkt zur Vorbeuge von Engp ssen Beide Rechner werden direkt ohne Zwischenverteiler wie einem Switch oder Hub miteinander verbunden Die verwendeten Netzwerkkabel erf llen den Cat 6 Standard sind dop pelt geschirmt und haben eine L nge von 50 cm Dadurch gew hrleisten diese Kabel Dat
68. Oe a 8 25 3 2 2 DUMMY NOL ou 4 is donee eed oh ae we ra ek E L gee eas od 26 3 2 3 KauNei 2235 oe ee ee Hee ae neuen 30 3 2 4 ModelNet 2 Coon onen 33 3 2 9 NetEm os u 4 0000 BEG en EES et a ie 36 3 26 NEEN ERR 2 4 eea ods i a foe a the Tent Bick ah ate ne ee iagi i Gi Gl x BE A ee foe 38 ii Inhaltsverzeichnis 3 2 7 Jones eos 3 42 Sk Gop We a a BR ESS Gee Bd goad ae 39 3 28 NetPath ce e aua a at oa EK aia a ae eee 41 3 3 Vergl ichsst dien es sari ne a OR EE e A ere OS 44 3 3 1 Nussbaum L und Richard O 2009 a 44 3 3 2 Shaikh J und Minhas T et al Goin 46 3 3 3 Minhas T und Shaikh J et al Got 48 3 4 Zusammenfassung 2 2 22mm nn 49 4 Anforderungsanalyse 2 2 CC onen 53 4 1 Funktionale Anforderungen 35 00 00 0 0 wa usa nase 53 41 1 Verfahren ne ae ee ee a See ws et 53 4 1 2 Genauigkeits und Leistungsmessungen 55 4 1 3 Implementation A ENEE Ee eds ENEE E cava bee es 56 E RE TEEN 56 4 2 Qualitative Anforderungen 2 d 244 54 as aa nr ia A Ce 56 4 3 Abgrenzungskriterien u 44 4 28644 EE RE D4 HG aa 58 4 4 EREM nen ee oe BYES ERS A Bo wre Se eS 58 5 Konzeption ee ee ee a ee ee sinne iii 61 5 1 Versuchsaufbau i oea e cressa tesa AN Seien as SE AA 61 5 1 1 Hardwaretechnischer Aufbau 61 5 1 2 Softwaretechnischer Aufbau aaa ee ee ee ee eee 63 5 2 Vorgehensweise ua au ovo gee ea EEE SRS GRE eR GRO eae 69 5 2 1 Vorlelduntersuchungen 5 20 0 5 444 ws e324
69. Pkt s bei einem hop abh v hops Tabelle 3 5 Produktangaben zur Granularit t und Leistung von MODELNET zus tzlich der Cross Core Traffic und die daraus resultierende Ende zu Ende Paketrate ermittelt Die Werte zur Leistung in Tabelle 3 5 zeigen die Ergebnisse der Messung mit nur einem Core Router F r Genauigkeitsuntersuchungen bei Ende zu Ende Verbindungen k nnen die erw hnten Vereinfachungen als Erwartungswerte benutzt werden 3 2 5 NetEm Die bisher vorgestellten Emulatoren basieren auf DuMMYNET und wurden daher haupts chlich f r den Einsatz unter FREEBSD entwickelt Abseits von DUMMYNET wird in Hem 05 eine eigenst ndige L sung namens NETEM f r den Einsatz unter Linux ab Kernelversion 2 6 pr sen tiert Dieser Emulator basiert ebenfalls auf dem Einsatz von Warteschlangen welche unter Linux qdisc 13y queueing discipline genannt werden In der Paketverarbeitung von Linux steht jedem Ein und Ausgang einer Netzwerkschnittstelle eine Haupt qdisc vor Mit Hilfe des Linux traffic control tools kurz tc k nnen nach einer Haupt qdisc weitere qdisc Warteschlangen baumartig hinzugef gt werden Ein Schema dieser Struktur ist in Abbildung 3 11 zu sehen Die Baumknoten werden classful qdisc genannt und unterst tzen Paketfilter Die Bl tter dagegen hei en classless qdisc und versenden lediglich eingehende Pakete weiter an das zugeordnete Netzwerkinterface Haupt gdisc classful qdisc 1 classful qdisc 2 classful qdisc 3
70. Puffer stellt u a f r die Leistungsbetrachung eines Emulators ein wichtiges Merkmal dar 3 4 Zusammenfassung Aus den Angaben in den vorgestellten Publikationen ergeben sich die in Tabelle 3 10 zusam mengefassten feststehenden Eigenschaften des jeweiligen Emulators Aufgrund der Bedeutung des Zeitgebers wurde dieser mit in die Tabelle aufgenommen Ebenso zeigten die Recherchen dass viele Emulatoren neben Benutzeroberfl chen auch Wahrscheinlichkeitsverteilungen f r Paketeffekte sowie Verz gerungen anbieten was f r die Generierung von Pfadangaben und einer gewissen Dynamik von Vorteil sein kann Daher werden auch diese Punkte mit in die Taxonomie aufgenommen Keiner der vorgestellten Emulatoren deckt alle Eigenschaften in der Taxonomie ab In Bezug auf die Mobilfunkeffekte bietet einzig WANEM Unterbrechungen an Ausbreitungsmodelle oder Handover wurden bei keinem Emulator gefunden Der von den Effekten her umfangreichste Emulator ist der Linktropy 7500 pro Dieser verf gt ber alle Paketeffekt und kann wie WANEM NETEM oder Imunss ber eine Benutzeroberfl che konfiguriert werden Letzterer hat eine indi rekte Pfadvorgabe und die Nutzung von virtuellen Betriebsmitteln als Alleinstellungsmerkmale Alle anderen setzen die Vorgaben explizit um und geh ren zur Gruppe der NLE Imungs kann durch eine Erweiterung auf einer dezentralen Architektur aufsetzen MODELNET dagegen beruht 50 3 Verwandte Arbeiten von vorn herein auf einer dezen
71. TECHNISCHE UNIVERSIT T DRESDEN FAKULT T INFORMATIK INSTITUT F R SYSTEMARCHITEKTUR Professur Rechnernetze Diplomarbeit zum Thema Entwicklung und Umsetzung einer Methode zur Genauigkeits und Leistungsanalyse von Netzwerkemulatoren von Peter B schel Forschungsgebiet Pervasive Computing and Collaboration Forschungsprojekt NESSEE Studiengang Informationssystemtechnik Jahrgang 2008 Matrikelnummer 347 1993 Semester WS 13 14 verantwortlicher Hochschullehrer Prof Dr rer nat habil Dr h c Alexander Schill Betreut durch Dipl Inf Robert L bke Eingereicht am 31 Januar 2014 in Dresden TECHNISCHE UNIVERSIT T DRESDEN Fakult t Informatik Institut f r Systemarchitektur Lehrstuhl Rechnernetze AUFGABENSTELLUNG F R DIE DIPLOMARBEIT Name Vorname B schel Peter Studiengang Informationssystemtechnik Matrikelnummer 3471993 Forschungsgebiet Pervasive Computing and Forschungsprojekt NESSEE Collaboration Betreuer Dipl Inf Robert Lubke Externe r Betreuer Verantwortlicher Hochschullehrer Prof Dr rer nat habil Dr h c Alexander Schill Beginn am 01 07 2013 Einzureichen am 31 12 2013 Thema Genauigkeits und Leistungsanalysen von Netzwerkemulatoren ZIELSTELLUNG Netzwerkemulation wird u a bei Experimenten mit Netzwerkanwendungen daf r eingesetzt die in realen Netzwerken anzutreffenden Bedingungen Parameter und Effekte nachzubilden Es ist eine gewisse Ge
72. Untersuchungen mit Hilfe der aufgef hrten Stromeigenschaften und je nach Gegenstand der jeweiligen Messung mit Hilfe einer bestimmten Vorgabe am Emulator Paketanzahl Anzahl an Probedurchl ufen etc Die eigentlichen Messungen werden wie in Abschnitt 5 2 2 konkrete Durchf hrung beschrieben unterschieden in die Ermittlung der Granularit t und des Wertebereiches Paketeffekte Granularit t Die Anzahl der zu sendenden Pakete beginnend bei 100 Paketen wird schrittweise um den Faktor 10 erh ht Gleichzeitig wird die Vorgabe des jeweiligen Paketeffektes beginnend bei 1 am Emulator entsprechend um den Faktor 10 verringert Die Anzahl der Probedurchl ufe wird pro Vorgabe Pfadl nge und Stromeigenschaft auf 100 festgelegt Die Erh hung der Paketanzahl bzw Verringerung des Vorgabewertes geschieht solange bis alle Paketzahlen gemessen wurden um so die Problematik mancher Pseudozufallsgeneratoren zu ber cksichtigen Die kleinste Effektrate wird anschlie end ermittelt und ist erreicht sobald die durchschnittliche relative Abweichung des jeweiligen gemessenen durchschnittlichen Paketeffektes von der Vorgabe gr er als 3 ist oder eine Paketstroml nge von hunderttausend Paketen erreicht wird Die Granularit t ist dann der Vorgabewert vor der berschreitung der relativen Abweichung bzw 0 001 bei der Paketstroml nge von hunderttausend Paketen F r die Untersuchung der Pfadl nge erh lt jeder Abschnitt die gleiche Vorgabe Dabei wir
73. abe j l 1 1 0 1 0 65 bzw 65 Alle Messungen haben jedoch die verwendeten Stromeigenschaften gemeinsam D h es wer den die Paketgr en a 64 512 1024 1500 gyte sowie die Paketabst nden b 20 120 1000 untersucht Dadurch ergeben sich pro Pfadl nge insgesamt 12 Datenraten und entsprechend eine 3x4 Ergebnismatrix mit 12 Einzelergebnissen f r jede Wertangabe und Statistik Tabelle 90 6 Umsetzung a al a2 a3 a4 b 64Byte 512Byte 1024Byte 1500Byte b1 20 us al b1 a2 b1 a3 b1 a4 b1 b2 120 us al b2 a2 b2 a3 b2 a4 b2 b3 1000 us al b3 a2 b3 a3 b3 a4 b3 Tabelle 6 2 Allgemeine Ergebnismatrix und gleichzeitig bersicht ber die verwendeten Paket gr en al a4 und abst nde b1 b3 vgl Abb 5 9 a al a2 a3 a4 b 64 Byte 512 Byte 1024Byte 1500 Byte PPS 1 50K 26MBit s 205MBit s 410 MBit s 480 MBit s PPS 2 8 3K 4 MBit s 34 MBit s 68 MBit s 100 MBit s PPS y3 1K 0 5 MBit s 4 MBit s 8 MBit s 12 MBit s Tabelle 6 3 bersicht ber die resultierenden Paket sowie Datenraten bei der Kombination aus den Werten f r al a4 und b1 b3 vgl Abb 5 9 6 2 veranschaulicht die verallgemeinerte Matrix Die Kennzeichnungen der einzelnen Paket stromeigenschaften orientiert sich dabei am Abschnitt 5 2 allgemeine Vorgehensweise Die Kombinationen aus Paketgr e und abstand ergeben wiederum die Tabelle 6 3 aufg
74. achen sind in Abbildung 8 6 zu sehen Alle Werte liegen ann hern bei 100 ms was dem erwarteten Resultat bei zehn hintereinander geschalteten Abschnitten entspricht Fazit Somit l sst sich zusammenfassen dass der Taktgeber ausschlaggebend f r die Genauigkeit Granularit t und den Wertebereich ist Wobei gleichzeitig die Puffergr e ausreichend gro gew hlt werden muss um bei mehreren Pfadabschnitten gen gend Pakete zwischenspeichern zu k nnen Die Taktgeber des Hardware Emulators und von NETEM arbeiten ausreichend schnell um auch Verz gerungen unterhalb 1 ms zu erlauben bzw um wesentlich stabilere Verz gerungswerte zu liefern Bei h heren Vorgabewerten liefern alle Emulatoren Verz gerungen innerhalb des Toleranzbereichs von 10 relative Abweichung Als einziger Emulator erlaubt Dummynet 8 2 Messungen 109 64 Paketl nge 512 102 in Byte 1500 1000 59 72 58 17 62 80 57 49 120 6 21 6 08 5 62 5 28 20 31 87 33 03 27 54 16 73 KauNet 1000 3 83 1 69 3 40 1 78 120 1 49 2 01 1 97 1 73 20 2 02 2 10 2 00 1 83 Paketabstand in jus 1000 Ik zu 120 5 92 9 55 NetEm 6 86 5 74 GE 20 35 25 30 24 23 97 5 29 14 94 Dummynet 1000 1 18 3 61 0 77 1 42 120 2 12 0 66 2 21 2 21 20 1 29 1 36 1 04 2 55 64 L
75. aketstr me werden mit Hilfe von Differentialgleichungen nachgebildet Die Ergebnisse dieser Gleichungen geben u a die mittlere Warteschlangenverz gerung an Daher arbeitet dieser Ansatz 4 2 Nachbildung von Netzwerkverhalten auf einer h heren Netzwerkebene So k nnen beispielsweise verschiedene Ausbreitungsmodelle f r kabellose Netzwerke getestet werden ohne den tats chlichen Aufbau von Antennen IHL07 Diese analytischen Methoden bringen schneller Ergebnisse hervor als der zweite Ansatz sind jedoch nicht so pr zise wie dieser Der zweite Ansatz ist Ereignisgetrieben SU03 und versucht Vorhersagen auf der Ebene von Datenpaket zu treffen Dieser gestattet dem Entwickler sich auf die kritischen Ereignisse zu konzentrieren und verschiedene Konzepte zu untersuchen Dadurch k nnen pr zisere Ergebnisse gefunden werden als beim analytischen Ansatz Ein Nachteil bei beiden Ans tzen ist jedoch dass die Ergebnisse stark von der G te des benutzten Modelles abh ngt Nicht alle Faktoren in einem Netzwerk sind modellierbar da sie oft dem echtem Zufall unterliegen Auch steigt mit zunehmender Komplexit t simulierter Netzwerke die Berechnungsdauer HK05 und es k nnen keine Experimente in Echtzeit durchgef hrt werden Ein simulierte Sekunde kann so eine reale Stunde dauern Ein anderer Nachteil ist dass die zu testende Anwendung erst an ein bestimmtes Modell angepasst werden muss und so zus tzliche Fehlerquellen entstehen Deshalb werden Simul
76. an des f r diese Paketgr e liegt F r b2 wird ein Wert gew hlt sodass die resultierende Datenrate f r a4 einen Wert von 100 MBit s annimmt Der letzte Abstand spiegelt eine Erkenntnis aus dem Kapitel 3 wieder Darin wird eine Untersuchung zum Emulator KAUNET vorgestellt bei der geringe Datenraten daf r Sorge tragen dass Systemeinfl sse minimiert werden und eventuelle Abweichungen nur durch den Emulator entstehen k nnen 6 2 1 Vorfelduntersuchungen In den Vorfelduntersuchungen werden zun chst die jeweiligen MLFFR f r die unterschiedlichen Paketgr en ermittelt Dazu wird nach und nach die Paketrate erh ht und auf ungewollte Paketverluste untersucht Sobald ein Verlust auftritt wird die Untersuchung gestoppt und die vorhergehende Rate als MLFFR gespeichert Aus diesen Ergebnissen l sst sich gleichzeitig der Abstand b4 berechnen Anschlie end werden die durchschnittlichen Grundverz gerungen f r alle vorgestellten Stro meigenschaften einschlie lich des zuvor ermittelten Wert f r b4 gemessen Wie in den an schlie enden Messungen zur OWD werden daf r jeweils 10000 Pakete versendet und analysiert F r die Ermittlung der Puffergr e wird wie im Beispiel in Abschnitt 5 2 1 vorgegangen D h am Emulator wird eine Datenrate von 1 MBit s eingestellt welche wiederum mit einer h heren Senderate untersucht wird 92 6 Umsetzung 6 2 2 Messungen Nach dem Abschluss der Voruntersuchungen beginnen die eigentlichen
77. arkeit anhand der genannten Vor und Nachteile Bedeutung positiver negativer o mittelm iger und kein Zusammenhang 22 23 3 Verwandte Arbeiten Im Hinblick auf die Anforderungsanalyse und die Schaffung eines eigenen Messkonzepts wer den in diesem Kapitel verwandte Arbeiten betrachtet Neben einigen wenigen neutralen Ver gleichsstudien sind es vor allem die Entwickler des jeweiligen Emulators die Betrachtungen zur Genauigkeit und Leistung anstellen Teilweise vergleichen diese ihr Produkt mit anderen Emulatoren um so einen besonderen G tegrad bestimmter Merkmale hervorzuheben Dadurch wiederum ergeben sich Hinweise f r ein eigenes Messkonzept Somit wird in diesem Kapitel zun chst die Auswahl der Emulatoren erl utert und anschlie end auf deren Publikationen eingegangen Abschlie end werden neutrale Vergleichsstudien vorgestellt 3 1 Auswahl der Emulatoren Die Auswahl der Emulatoren orientiert sich in erster Linie an deren Verf gbarkeit und Bekannt heitsgrad Dadurch ist es m glich eigene Untersuchungen durchzuf hren und es kann davon ausgegangen werden dass zu diesen Emulatoren bereits Vergleichsuntersuchungen existieren welche wiederum Anhaltspunkte f r ein eigenes Messkonzept liefern Weiterhin wird mit Blick auf die im Kapitel 2 vorgestellte Taxonomie versucht eine m glichst breitgef cherte Auswahl zu treffen Dem Institut steht ein Hardware Emulator Linktropy 7500 Pro
78. ationen oft zusammen mit Realumgebungen betrachtet Realumgebung werden in der Implementationsphase f r die Untersuchungen des Programm verhaltens unter realen Bedingungen benutzt Dazu wird reale Hardware sowie Software benutzt und zumeist die Zielplattform nachkonstruiert Im Netzwerkbereich k nnen solche Plattformen jedoch sehr kostenintensiv werden je komplexer die Zieltopologie ausf llt Teilweise ist es auch von vornherein nicht m glich ein reales Netzwerk f r eine beispielsweise neue bertragungs technik aufzubauen Im Satellitenbereich m ssten erst entsprechende Satelliten ins All geschickt werden Nachteilig wirkt sich auch die Tatsache aus dass bestimmte Netzwerkeffekte nur unregelm ig auftreten Eine kontrollierbare Testumgebung mit reproduzierbaren Ergebnissen ist daher mit Realumgebungen nicht gegeben Emulation kann als Verkn pfung von Realumgebung und Simulation angesehen werden Allgemein bildet eine Emulation die Funktionen und das Verhalten eines Systems nach ohne dessen Abh ngigkeit von bestimmten Ressourcen Die Netzwerkemulation erlaubt die Nachahmung von Effekten in realen Verbindungspfaden bis hin zur Nachbildung von Netzwerktopologien Gra 08 F r die Emulation einer Topologie wird eine weitere Abstraktionsebene zwischen realen Netzwerk und Emulator hinzugef gt In dieser Ebene es m glich virtuelle Netzwerkelemente zu erstellen welche in der Lage sind mit realen Elementen zu kommunizieren Dadurch kann nahez
79. aus einer neueren Ver ffentlichung PM06 zu IMUNES und veranschaulicht diese Art der Virtualisierung mit Hilfe eines Vergleichs zur traditionellen Art In dieser Publikation wird au erdem eine Erweiterung vorgestellt welche es A0 3 Verwandte Arbeiten VM 1 VM 2 VM 1 VM 2 Applications l Applications Operating System Applications Applications Onemig System i ei Private Resource network CPU Private Resources D rk CPU Virtual Machine b e mm zn me un vgl e n E a D O Operating System Virtual Machine J Virtual Machine Monitor Physical Machine Physical Machine a Traditional approach b Lightweight VM approach Abbildung 3 13 Leichtgewichtige Virtualisierung unter IMUNEs Quelle PM06 erm glicht IMUNEs dezentral zu betreiben Dazu werden mehrere Rechner ber ein peer to peer Netzwerk zusammengeschlossen Die Topologien werden mit Hilfe einer TcL Tx basierten GUI erstellt Wobei zwischen Kno ten engl nodes und Verkn pfungen engl links unterteilt wird Die Knoten werden weiter unterschieden in link layer nodes und in network layer nodes Erstere umfassen alle diejenigen Netzwerkbausteine die Pakete ohne bestimmte Kontrollen weiterleiten Switch Hub Letztere bilden die Endsysteme sowie Router nach und verf gen ber die komplette Funktionalit t eines FR
80. ausgew hlt wird Entsprechend ist der f nfte Mittelwert gleich dem f nften Messwert Der sechste Mittelwert wird anschlie end ber die Messwerte sechs bis neun gebildet Der siebente Durchschnitt dagegen wird aus dem siebenten bis neunten Messwert gebildet da ein hinzuf gen des zehnten Wertes eine Bereichs berschreitung bedeutet Weitere Mittelwerte sind nicht m glich da das Zeitintervall von 10 ms nicht mehr erreicht werden kann Aus diesem Grund entfallen ebenfalls alle Berechnungen nach dem f nften Mittelwert in den Mittelwertlisten Don D30 und Dun beide nicht in der Abbildung Die Elemente der brigen Listen Ds9 und Den werden nach dem gleichen Vorgehen berechnet AT 10 ms 20 ms 30 ms 40 ms 50 ms 60 ms X1 X2 X3 X4 X5 X6 X7 X8 X9 X10 2 3 _ 1 _ 1a Dao S KEE 3 af 3 Dis Xi 3 40 Bf 2 Z BO TG 2 2 3 1 1 6 1 6 1 7 19 D50 i KE GER Xi J Xi quia Xis GER Xi 3 2 2 3 40 1 5 2 2 3 1 9 110 Deo a Xiz Xi 9 ize Xi Abbildung 5 15 Berechnung der Durchschnittlichen AOWD fiir das jeweilige Zeitintervall AT auf der Empfangerseite Die konkreten Ergebnisse der Mittelwertbildungen sind in Tabelle 5 3 zu sehen Diese Werte bilden die Basis f r den zweiten Schritt bei dem der CODVwBMaA
81. bei eine Vielzahl von Netzwerkmetri ken Zudem ist es in der Lage die Messergebnisse eines Emulators mit denen von anderen in einen Zusammenhang zu bringen und mit verschiedenen Diagrammen grafisch darzustellen Da der Emulator dabei als Black Box angesehen wird kann die Testumgebung dar ber hinaus zur Messung von realen Verbindungen verwendet werden Neben den bereits durchgef hrten Untersuchungen k nnen zuk nftig noch weitere Netzwer kemulatoren analysiert werden um so zusammen mit dem entwickelten Klassifikationsschema einen einheitlichen und umfassenden berblick ber deren Eigenschaften zu gewinnen In Bezug auf die Weiterentwicklung des vorgestellten Messkonzepts k nnen durch dessen modularen Aufbau k nftig weitere Metriken z B aus dem Bereich des Mobilfunks hinzugef gt werden um das Spektrum der Emulatoren zu erweitern Au erdem gestattet dieser Aufbau einen Austausch von Komponenten wie beispielsweise dem Paketgenerator Dadurch ist eine stetige Verbesserung der Kernkomponenten m glich Eine weitere Verbesserungsm glichkeit bieten grafische Oberfl chen zur Konfiguration der Versuchsparameter Aktuell werden diese in Form von Textdateien an das System bergeben In der derzeitigen Version ist das Messsystem noch von bestimmten spezifischen Betriebssystemfunktionen abh ngig daher bietet es sich an entweder betriebssystemunabh ngige Funktionen zu nutzen oder mehrere Versionen f r unterschiedliche Plattformen zu erstellen
82. benfalls die RTD gemessen und als timun festgehalten Danach werden beide Endsysteme auf unterschiedlichen Rechnern virtualisiert die Umlaufverz gerung gemessen und als Ger Nach PPM08 ergibt sich die Verarbeitungszeit tproc mit Hilfe der folgenden Gleichung Uproc brot timun treal Der Durchsatz von TCP Paketen wird ebenfalls erst in einer realen Umgebung dann in einer zentralen und abschlie end in einer dezentralen Emulation mittels NETPERF gemessen Den h chsten Durchsatz bietet die zentrale Emulation gefolgt vom realen Aufbau und der dezentralen L sung Fazit Der Vergleich zwischen einem unmodifizierten System bzw einer realen Versuchsumge bung und einer f r die Emulation angepassten Umgebung gibt Aufschluss ber den Einfluss des Emulators Die gemessene Einflussnahme bezieht sich dabei auf den eingesetzten Aufbau und kann Tendenzen f r andere Versuchsumgebungen liefern Es zeigt sich f r die Untersuchungen zur Systemauslastung durch ImunEs dass vor allem der Arbeitsspeicherbedarf Hinweise zur Leistungsfahigkeit liefert Die Antwortzeit des Emulators ist besonders bei dezentralen L sungen eine m gliche Gr e zur Beurteilung Die vorgestellte Messung der Verarbeitungszeit und des Durchsatzes kann abgewandelt auch f r andere Emulatoren verwendet werden Eine direkte Verwendung dieser Messweise w rde voraussetzen dass ein Emulator sowohl zentral als auch dezentral verwendet werden kann 3 2 8 NetPath Die Entwic
83. bung steigt ebenfalls die ben tigte Rechenleistung Dezentral Die dezentrale bzw verteilte L sung ist dagegen nicht an die Rechenleistung eines einzelnen Rechners gebunden und kann so mehr Knotenpunkte sowie Endpunkte virtualisieren F r komplexere Testszenario besteht ein Emulator oft aus einem Verbund von Rechnern Der Nachteil hierbei ist jedoch die n tige Synchronisation zwischen der verteilten Hardware welche zus tzliche Verz gerungen verursacht L sungen die von einer Synchronisation absehen und sich dadurch aus unabh ngigen Rechnern zusammensetzen sind in ihrer Effektqualit t beschr nkt Andere Nachteile bei dieser Architektur sind die h heren Kosten und der gr ere Verwal tungsaufwand 2 3 2 Arbeitsbereich Dieser Bereich stellt die Betriebssystemebene dar in der ein Emulator Einfluss auf die Datenpakete aus bt Der Arbeitsbereich kann sich daher in der Kernel Ebene oder in der Nutzerebene befinden Wie pr zise die Vorgaben f r die Testumgebung umgesetzt werden h ngt berwiegend vom Manipulationsprozess und der Paketrate des Emulators ab Dieser Prozess sollte so wenig zus tz liche Verarbeitungskosten engl processing overhead verursachen und damit Einfluss auf die eigentliche Paketabarbeitung haben wie m glich Die Pakete werden idealerweise in Echtzeit manipuliert und weiterverarbeitet Kernel Arbeitet ein Emulator im Kernel Bereich so ist der processing overhead geringer als in der Nutzerebene da Datenpaket
84. cht alle Ergebnisse f r jeden Versuch vorgestellt werden da die Anzahl der Einzelmessung bei ber 92000 liegt Daher werden nur einige von diesen pr sentiert 4 4 Zusammenfassung Aus der Analyse der Aufgabenstellung und unter der Ber cksichtigung der gewonnenen Er kenntnisse aus Kapitel 3 ergeben sich die in Tabelle 4 1 aufgelisteten Teilziele Diese werden bis auf das letzte Teilziel nach funktionalen F und qualitativen Q Anforderungen gruppiert Das letzte Teilziel steht gesondert da es die praktische Anwendung betrifft und die Endergebnisse dieser Arbeit liefert Die konkreten funktionalen und qualitativen Anforderungen sind in den Tabellen 4 3 und 4 2 mit der verwendeten Aufteilung dargestellt Die Buchstabenkombination in der Spalte Bezeichnung deutet dabei das bergeordnete Teilziel an 4 4 Zusammenfassung funktionale Anforderung Bezeichnung funktionale Anforderung Bezeichnung Paketgenerator FT 1 Taktrate FV 1 v Paketerfassung FT 2 Puffergr e FV 2 i Analyse Berechnung FT 3 Grundverz gerung FV 3 Uhr hr t FT 4 a et GE rt e verf gbare Datenrate FM 7 1 ilt Gi a i Kai m E Massendurchsatzrate FM 7 2 t t B rS Q 5 Verlustrate FM 7 3 Reale Umgebung FT 7 2 an S Dopplungsrate FM 7 4 keine ungew Paketverluste FM 1 3 Neuordnungsrate FM 7 5 g E 5 Kontrolle des Paketgenerators FM 2 Verz gerung FM 7 6 amp 5 keine Beeintr des Emulators FM 3 Verz gerungsvarianz FM 7 7
85. d Datenraten rechts f r die jeweiligen Paketstromeigenschaften unter Verwendung von KAUNET mit einer Datenratenbeschr nkung von 1 MBit s 2 2 onen Tab 8 5 Berechnete Puffergr e des Emulators KAUNET f r die jeweilige Paketstro meigenschalt os 25 0 sat ea dans aa Bere da Tab 8 6 Puffergr e des jeweiligen Emulators 2 2 22 Tab 8 7 Abweichungen der mittleren emulierten Verz gerung bei verschiedenen Stromeigenschaften des jeweiligen Emulators von der Vorgabe Pfadl nge 1 102 103 1 Einf hrung Die Anzahl der Entwicklungen im Bereich der Netzwerkprotokolle und verteilten Anwendungen steigt kontinuierlich mit zunehmender Vernetzung des Alltags an Das Bundesamt f r Sicherheit BSI ver ffentlichte beispielsweise eine Trendstudie Bro03 die f r das Jahr 2013 eine durchgehend digitalisierte und automatisierte Wertsch pfungskette voraussagt Ein Szenario daraus beschreibt wie der Wecker eines Gesch ftsmannes mit dessen Online Terminkalender vernetzt ist und ein Taxi zur Videokonferenz bestellt in welcher die Teil nehmer aus verschieden L ndern gemeinsam Produktentw rfe diskutieren und deren Produktion ansto en Das Beispielszenario zeigt indirekt auch die Gefahren auf sobald eine Anwendung vom erwar teten Verhalten abweicht Diese Fehlverhalten k nnen zum Beispiel eine falsche Weckzeit oder aber auch die Weiterleitung eines bereits verworfenen Entwurfs an die Produktion beinhalten Dadurch entst
86. d Empf nger gestartet um so sicher zustellen dass auch die ersten Pakete aufgezeichnet werden Anschlie end entnimmt die Steuerung aus der Liste der Auftr ge einen einzelnen Auftrag und bergibt diesen an den Paketgenerator Nachdem dieser alle Probestr me mit der vorgegebenen Anzahl an Probedurchl ufen versendet hat beendet die Versuchssteuerung die Paketerfassung und startet die Auswertung des Auftrages Nach der Auswertung wird mit dem n chsten Auftrag in der Liste fortgefahren und der beschriebene Ablauf wiederholt Paketerfassung Die passive Paketerfassung erfolgt parallel f r alle aus sowie eingehenden Pakete und wird in separaten Prozessen gestartet Jedem Prozess wird eine der beiden Netz werkkarten zugeordnet Die ausgehenden Pakete sind f r die anschlie ende Berechnung der 5 1 Versuchsaufbau 67 Steuerung T m neuer Tx Rx Paket REN Auftrag Paketerfassung Paketerfassung generator 8 starte gt I I a BESSE Bt startet DEE _ gestartet 171 starte i ee GE Bo ee ee as nachster ee eee eee gestartet Auftrag senden l Auftrag IW aa i sende Probestr me LL Auftrag gesendet durchl ufe ie m I ___ beende __ beende beende beredne l Ke KE 1 ed w l 5 eee bee H eee a __ berechnet T analysiere l i l i i 1 Abbildung 5 6 Sequenzdiagramm der Vers
87. d darauf geachtet dass sich die Effektraten multiplizieren und sich somit die erwartete Rate erh hen Dennoch entspricht die kleinste Effektrate dem vorgegebenen Wert Paketeffekte Wertebereich Aus den Ergebnissen zur Granularit t lassen sich die unteren Grenzen f r die einzelnen Wertebe reiche angeben Um die oberen Grenzen zu erhalten werden neun Effektvorgaben gew hlt Die Vorgaben beginnen bei 1 und werden schrittweise um 10 erh ht Hierbei werden je Vorgabe und Stromeigenschaft 100 Probedurchl ufe mit einer Paketanzahl gemessen welche sich nach der m glichen Granularit t richtet jedoch mindestens 10000 Pakete betr gt Das Ergebnis sind die Statistiken FA 1 sowie FA 3 bis FA 7 und xo 5 zu jedem Paketeffekt jeder Vorgabe und Stromeigenschaft Verz gerungen Granularit t Zur Messung der erreichbaren Granularit t der emulierbaren Verz gerungswerte werden je Stro meigenschaft Vorgabe und Pfadl nge 1000 Pakete in einem einzelnen Probedurchlauf verwendet Da der Takt des Kernels ausschlaggebend f r die Aufl sung ist dient dieser Wert als Ausgangs punkt f r die Untersuchungen Da die Taktung bzw die resultierende Verarbeitungsfrequenz eine eher theoretische Angabe ist liegt der eigentliche Startwert um den Faktor 10 h her Ist die Taktrate jedoch ungewiss so wird mit einer Vorgabe von 10 ms begonnen Der Wert entstammt der Mindestangabe f r die OWD des Emulators WANEM vgl Tab 3 7 Die Vorgaben werden solange um
88. de ist in Abb 3 2 zu sehen Diese zeigt die H ufigkeit an mit der die erste wissenschaftliche Ver ffentlichung zum jeweiligen Emulator zitiert wurde 24 3 Verwandte Arbeiten o 100 r l k i NISTNet 4 Dummynet E 80 J E ModelNet 3 Y a emulab E 60 KauNet 8 NetEm 40 J ES Kar sf HT att ye 20 A 2 OP Gy o E F e RE PPP org 5 hoa 2005 2006 2007 2008 2009 2010 2011 2012 2013 Monate Jan 2004 bis Jan 2013 Abbildung 3 1 Analyse der Suchanfragen zwischen 2004 und 2013 fiir bekannte Emulatoren Quelle 13f DUMMYNET zeichnet sich dabei deutlich von den anderen Emulatoren ab was jedoch auch darauf zur ck zuf hren ist dass dieser bereits 1997 ver ffentlicht wurde F r die geplanten Analysen in dieser Arbeit bietet es sich daher an DuMMyYNET als Ausgangs und Bezugspunkt zu nutzen Die Trendanalyse in Abb 3 1 zeigt ebenfalls dass KAUNET inzwischen fter gesucht wird als DummYNET Dieser erweitert die Funktionalit ten von DUMMYNET und eignet sich daher f r den direkten Vergleich Ein weiterer Vorreiter in der Netzwerkemulation ist NISTNET 13s welcher jedoch nicht mehr weiterentwickelt wird Allerdings wurden Teile des Programmkodes von einem anderen Emulator namens NETEM 13q bernommen In der Trendanalyse nimmt NETEM die aktuelle Spitzenposition ein daher wird auch dieser Emulator weiter untersucht NETEM bildet wie DUMMYNET die Basis f r andere Emulatoren Da
89. den einzelnen Probedurchlauf zun chst als Datei auf der Festplatte gespeichert und zur anschlie enden Auswertung je Probedurchlauf geladen Dieses Vorgehen bietet den Vorteil der Kapselung von Messung sowie Auswertung und gestattet au erdem flexiblere Versuchsszenarien Versuchssteuerung F r den automatisierten Ablauf der Experimente wird eine Steuerung eingesetzt welche Konfigurationen bzgl Netzwerkeinstellungen und Versuchsparameter auf nimmt und anhand dieser Auftr ge f r den Paketgenerator erstellt Jeder Auftrag entspricht dabei einem Versuch Ein Versuch besteht aus Probestr men welche sich untereinander in bestimmten Stromeigenschaften wie z B Paketgr e unterscheiden Ein Probestrom kann mehrmals in einer vorgegebenen Anzahl an Probedurchl ufen versendet und analysiert werden Abbildung 5 5 veranschaulicht die Einteilung Versuchsparameter 1 Versuch Probedurchlufe 2 Versuch Versuch 3 Versuch Ge 1 Probestrom Probestrom 2 Probestrom 3 Probestrom Abbildung 5 5 Einteilung der Versuchsparameter in Probestr me und zugeh rige Probedurch l ufe Zudem koordiniert die Versuchssteuerung den Ablauf der Messungen und der Auswertungen Dazu geh rt die richtige Startreihenfolge von Paketerfassung sowie versendung und die anschlie ende Auswertung des Versuchs In Abbildung 5 6 ist ein entsprechendes Aktivit tsdiagramm zu sehen Zuerst werden die Prozesse der Paketerfassungen f r den Sender un
90. der Analysen zu einem Emulator stehen die in den Abschnitten 2 4 1 bis 2 4 3 erw hnten Datenraten Verz gerungen und Paketeffekte bei unterschiedlichen Voraussetzungen wie z B der Pfadl nge Die genaue Aufz hlung der geforderten Netzwerkeffekte befindet sich in Tabelle 4 3 Die weiteren Anforderungen betreffen die Verringerung m glicher Abweichungen und die Zielstellung der Messungen Abweichung W hrend der Analysen zur Datenrate und Verz gerung d rfen keine ungewoll ten Paketverluste auftreten FM 1 da sonst Messwerte verf lscht werden k nnten Zudem zeigte sich in den vorgestellten Publikationen dass gleichzeitig zur eigentlichen Messung die Datenrate des Paketgenerators FM 2 und die durch diesen verursachte Verz gerung mit betrachtet werden sollten um m gliche Abweichungen zu ber cksichtigen Bei Werterfassungen innerhalb des Emulatorsystems d rfen die Emulationsprozesse nicht beeintr chtigt werden FM 3 Eine weitere Erkenntnis aus dem vorangegangen Kapitel ist dass reale Testumgebungen gegen ber hybriden oder virtuellen die genauesten Ergebnisse liefern Daher sollen auch die eigenen Untersuchungen innerhalb einer realen Umgebung stattfinden FT 7 Zielstellung Die Endergebnisse der Messungen sollen den m glichen Arbeitsbereich sowie die Wertstabilit t des Emulators in Verbindung zu dessen Auslastung und bei einer vorgegebenen Toleranz bestimmen FI 8 Dazu sind die Effekte zun chst einzeln und anschlie end gemeinsam
91. der Paketgr e FI 5 Protokollart FI 6 und des zeitlichen Paketabstandes FI 7 anbieten Entsprechend zur Quelle miissen Messpunkte fiir die Erfassung der Pakete FT 2 vgl Tab 4 3 vorhanden sein Da der Versuchsaufbau m glichst unabh ngig von einer bestimmten Hardware sein soll werden die Pakete mittels Software erfasst D h anstelle von einer beispielsweise DAG3 5E Netzwerkkarte werden die Pakete direkt von der Empfangerapplikation oder mittels spezieller Treiber aufgezeichnet Zudem werden f r die Paketerfassung Filter FT 5 sowie eine Datenhaltung FT 6 ben tigt um anschlie ende Analysen und Berechnungen nach verschiedenen Gesichtspunkten zu erm glichen Speziell f r die Untersuchungen der OWD ist au erdem eine Zeitsynchronisation FT 4 zwischen den Messpunkten des Versuchsaufbaus von N ten F r die Ermittlung der emulierten Datenraten Verz gerungen und Paketeffekte wird ein Tool ben tigt welches diesbez gliche zeit und ereignisgesteuerte Analysen sowie Berechnungen mit den erfassten Paketen anstellen kann FT 3 Die genannten Forderungen werden im Schema 4 2 zusammengefasst und in Beziehung gebracht Uhren synchronisation Paket es Analyse generator Berechnung Paketstrom Filter Datenhaltung eigenschaften Software basiert Abbildung 4 2 Grundlegende Anforderungen an den Versuchsaufbau 4 1 Funktionale Anforderungen 55 4 1 2 Genauigkeits und Leistungsmessungen Im Mittelpunkt
92. der Skalierbarkeit eines Emulators welche aus der Sicht des Testers Auskunft ber die m gliche Anzahl an Endsystemen und Netzwerkknoten im geplanten Versuchsaufbau gibt Die Emulationseinheiten d rfen dabei jedoch nur so viele Ressourcen beanspruchen dass dadurch die eigentliche Anwendung nicht beeinflusst wird Abbildung 2 10 zeigt die Faktoren welche f r die Skalierbarkeit eines Emulators eine Rolle spielen Emulator Effizienz Transparenz nach au en Skalierbarkeit Netzknoten emulatoren NLE Komplexit ts niveau Virtuelle Maschine VM Emulatoren virtueller Netz werke VNE Virtuelle Betriebs mittel VB Abbildung 2 10 Kategorie Skalierbarkeit und deren Einflussfaktoren Aus Sicht der Testanwendung muss der Emulationsprozess transparent sein Somit beschrankt die Transparenz die Skalierbarkeit Um m glichst viele Emulationseinheiten f r eine begrenzte Anzahl an Betriebsmitteln gene rieren zu k nnen muss ein Emulator dazu m glichst effizient arbeiten Daher bestimmt der Grad der Effizienz den Grad der Skalierbarkeit In Folge dessen wurden verschiedenste Methode entwickelt um eine m glichst hohe Effizienz bei der Emulation zu erreichen und trotzdem die Transparenz zu wahren Deren Umsetzungen k nnen dabei in die bereits erw hnten Netzknotenemulatoren NLE und Virtuelle Netzwerke Emulatoren VNE eingeteilt werden Gleichzeitig ze
93. die RTD als Metrik und eine angepasste Version von PInG als Messwerkzeug gew hlt Die Datenrate dagegen wird mittels BTT und dem Werkzeug IPERF untersucht 3 3 Vergleichsstudien 45 Genauigkeitsanalyse Der dominierende Faktor f r eine pr zise Emulation von z B Verz ge rungen ist der zugrundeliegende Zeitgeber bzw dessen Taktung In NR09 wird dieser Einfluss pro Betriebssystem und Kernelversion f r drei verschiedene Taktungen gemessen F r Dum MYNET wird beispielsweise die FreeBSD Version 6 1 und 7 0 mit den Taktungen 100 Hz 1 KHz sowie 10 KHz verwendet Gemessen werden die RTD von ICMP Paketen f r alle drei Taktungen bei einer eingestellten Paketverz gerung von 10 ms Die Idee dazu beruht auf der Annahme dass bei einer hohen Anzahl von Paketen welche in kurzen Abst nden den Emulator passieren Variationen zwischen den einzelnen RTD zu messen sind sobald die Sendefrequenz h her als die Taktung des Zeitgebers ist Der Grund daf r ist dass der Emulator Pakete nur im Takt des Zeitgebers verarbeiten kann Abh ngig von der Implementierung werden die Pakete daher leicht verz gert oder verfr ht weitergeleitet Standardm ig verwendet PING einen Zeitgeber mit einer f r die Untersuchungen zu geringen Taktung Nussbaum et al wechselten daher dessen Zeitgeber sodass auch Pakete mit einer Frequenz von bis zu 20 KHz versendet werden k nnen Die Ergebnisse werden in Form von Diagrammen zum einen als gemessene RTD ber der betracht
94. dung 3 4 Funktionsprinzip von DummYNET nach Riz97 Die Abarbeitung kann dabei auch nach anderen Prinzipien erfolgen An dieser Stelle werden pseudozuf llige Paketneuordnung durchgef hrt Dabei wird allerdings kein Zufallsgenerator verwendet sondern eine feste Zahlenreihe bei der lediglich der Anfangspunkt variiert wird Anschlie end werden die Pakete an die pipes bergeben die jedoch an dieser Stelle festgelegt nach dem FIFO Prinzip arbeiten Die Pakete verweilen eine vorgegebene Zeitdauer in diesen pipes und werden danach an die n chste Protokollstufe weitergeleitet In den pipes werden die Pakete ebenfalls zufalls hnlich f r die ben tigte Verlustanzahl verworfen Zus tzlich werden in Riz97 einige Einschr nkungen wie z B die Abh ngigkeit von der Granularit t und Genauigkeit des Systemzeitgeber verdeutlicht Diese bestimmt in Interrupt gesteuerten Systemen die Verarbeitungsrate der pipes F r die Einhaltung von z B einer be stimmten Paketverz gerung tp muss f r die Granularit t des Zeitgebers Tz gelten Tz lt tp Die erste Version von DUMMYNET war auf die Verarbeitung von TCP Paketen unter FREEBSD beschr nkt Die Steuerung von DuMMYNET geschah ber das sysct 1 Kommando ber die Jahre hinweg fand DummYNET immer mehr Verbreitung und wurde entsprechend weiterentwickelt In der aktuellen Version 20130607 werden mittlerweile UDP Pakete und die Betriebssysteme WINDOWS sowie Linux Kernel 3 8 unterst tzt Unter FREEBSD ist Dum
95. e Seite 85 86 91 94 Peripheral Component Interconnect Express Bussystem welches Hardware Steckkarten mit dem Rechner verbin det siehe Seite 85 86 94 Probability Distribution Function dt Verteilungsfunktion siehe Seite 80 Packet Duplication Rate dt Dopplungsrate von Datenpa keten siehe Seite 15 16 27 38 39 42 101 Packet Loss Rate dt Verlustrate siehe Seite 15 27 30 34 36 38 39 58 101 Packets Per Second dt Pakete pro Sekunde oder Paketrate siehe Seite 29 30 50 77 78 99 105 112 Per packet Processing Time dt Verarbeitungszeit je Paket siehe Seite 29 30 50 Paket Reordering Rate dt Paketneuordnungsrate siehe Seite 16 27 30 34 36 38 39 101 Retransmission Rate dt Wiederholungsrate von Daten paketen siehe Seite 15 Round Trip Delay dt Umlaufverz gerung gleichbedeu tend mit der Round Trip Time RTT siehe Seite 14 41 44 45 63 Round Trip Time dt Umlaufzeit eines Netzwerkpaket vom Sender ber den Empf nger zur ck zum Sender siehe Seite vi Abk rzungsverzeichnis Vil TCP UDP VB VM VNE WAN Transmission Control Protocol dt Ubertragungssteue rungsprotokoll siehe Seite 13 26 27 37 39 41 43 45 50 User Datagram Protocol siehe Seite 27 29 virtuelle Betriebsmittel siehe Seite 19 virtual machine dt virtueller Rechner siehe Seite 19 20 23 33 61 virtual network emulator dt Emulator basierend auf vir
96. e 3 3 zusammengefasst Zu einigen Effekten wie z B der m glichen Datenrate wurden keine Werte gefunden 3 2 3 KauNet KAUNET GHBO08 erweitert DumMYNET um die M glichkeiten Bitfehler und nderungen der Paketverz gerung sowie maximalen Datenrate nachzubilden Au erdem gestattet KAUNET eine pr zise Auswahl derjenigen Pakete welche verworfen bzw neu geordnet werden sollen Dazu erfolgt die Selektion entweder zeitgesteuert pro Millisekunde oder datengetrieben je Paket 3 2 Produktpublikationen und dokumentationen 31 Ein besonderes Merkmal von KAUNET ist dabei dass die Selektion als Muster engl pattern an den Kernel bertragen wird um so reproduzierbare Ergebnisse zu erhalten Die Veranschauli chung in Abb 3 7 stammt aus einer neueren Dokumentation Hur 12 zu KAUNET und zeigt wie beispielsweise Pakete zeitgesteuert engl time driven oder datengetrieben engl data driven anhand des Musters 0101 ausgew hlt und verworfen werden Die einstellbare Granularit t f r Effekte findet wie in Tabelle 3 4 aufgelistet daher auch auf Paketebene statt IP Packet IP Packet m m IP Packet IP Packet KN h T 7 to t amp gt Time N t 2 3 oo a Time driven packet loss IP Packet 1 et IP Packet N et IP Packet x 4 ad gt Time t ri 2 0101 b Data driven packet loss Abbildung 3 7 a Zeit und b datengesteuerte Auswahl bestimmter Pakete durch KAUNET anhand des Musters 0101 Quelle H
97. e Vielzahl von Netzwerkeffekten und Einstellm glichkeiten zur Verf gung Dazu geh ren beispielsweise C und AOWD Dar ber hinaus lassen sich Wahrscheinlichkeiten f r die einzelnen Effekte vorgegeben Ein Software zur Analyse und Aufzeichnung von Verlusten sowie Verz gerungen in Realumgebungen ist ebenfalls beigelegt Die Aufzeichnungen lassen sich im Anschluss auf dem Emulator abspielen und man erh lt so die Netzwerkkonditionen einer bestimmten Realumgebung 26 3 Verwandte Arbeiten Packet Loss 0 1000 org Advanced Parameters hide Probability 0 0000 mn max Delay 00 ms DO ms 0 0000 18 Elhemet HOR FCS Abbildung 3 3 Weboberfl che des Linktropy 7500 pro Hardware Emulators Gesteuert wird der Linktropy ber eine Weboberfl che welche in Abbildung 3 3 zu sehen ist Aus dieser ist auch eine genaue Auflistung der m glichen Pfadmanipulationen ersichtlich F r jeden Effekt stehen Informationen bereit die durch ein Bet tigen des Informationssymbols neben dem Effektnamen aufgerufen werden k nnen Andere Quellen f r Genauigkeits und Leistungsangaben sind der Hardware Guide Tec11 und das Benutzerhandbuch Tec13 Produktangaben Der Hardware Emulator besticht im Vergleich zu allen anderen Software basierten Emulatoren durch seine Leistung Dieser kann bis zu drei Millionen Pakete pro Sekunde verarbeiten und arbeitet gleichzeitig mit Paketverz gerungen im Millisekundenbereich Alle Produktangabe
98. e werden dabei auch unterschiedliche Paketgr en verwendet Genauigkeitsanalyse Jedem Emulator werden vier verschiedene Verz gerungen fest vorge geben Anschlie end wird in 32 Versuchsdurchl ufen mit 10000 Paketen und unterschiedlichen Hardware Komponenten die Durchgangsverz gerung jedes dieser Paket erfasst Anhand dieser Werte werden die durchschnittliche minimale sowie maximale Verz gerung berechnet Zur Veranschaulichung werden zus tzlich die verschiedenen CoTV und die H ufigkeitsverteilung je Hardware Plattform visualisiert Abbildung 3 17 zeigt ein Beispiel f r diese Diagramme bei der Nutzung von KAUNET Zu sehen sind die H ufigkeitsverteilungen f r verschiedene Paketgr en und die Variationskoeffizienten CoTV f r die am Emulator ein sowie ausgehenden Pakete in den Mittlungsintervallen von 1 ms bis 1 s Aus den CoTV l sst sich ablesen wie stark die Paket verz gerungen nach dem Durchlaufen des Emulators je Mittlungsintervall variieren Je geringer dabei das Intervall ist desto dominanter treten Spitzenwerte bzw Ausrei er in Erscheinung Ist die Verz gerungsausgabe des Emulators instabil entstehen fter Spitzenwerte und somit verl uft die Kurve f r die ausgehenden Pakete steiler Gleichzeitig zeigt die Kurve der eingehenden Pakete die Grundvariationen des Versuchsaufbaus an Im Idealfall verursacht der Emulator keine zus tzlichen Variationen und die Kurven decken sich beide Insgesamt zeigt sich dass die Paketverz gerung
99. e zuerst vom Kernel verarbeitet und anschlie end erst an die Nutzerebene weitergeleitet werden Ein weiterer Vorteil ist die zeitnahe Vergabe von Zeitstempeln in diesem Bereich Nachteilig wirkt sich die zus tzliche Anpassung des Kernel aus So muss zumeist ein lterer Kernel gefunden installiert entsprechend angepasst und neu kompiliert werden Nutzer Eine Emulator im Nutzerbereich ist entsprechend einfacher zu installieren und kann dank eines aktuellen Kernels sogar auf die gleichen Zeitgeber zugreifen wie sonst bei lteren Systemen nur der Kernel Dennoch bleibt der zus tzliche processing overhead bestehen und die Paketrate f llt geringer aus als bei Emulatoren mit einem Arbeitsbereich im Kernel 2 3 3 Zeitgeber Die Leistung und Genauigkeit eines Emulators ist u a abh ngig vom Zeitgeber sowie dessen Taktrate In einem Rechnersystem stehen oft mehrere Zeitgeber zur Verf gung wobei einer von diesen als Systemzeitgeber des Kernels fungiert Mit jedem Takt werden je nach Rechnerar chitektur eine oder mehrere Instruktionen von der CPU durchgef hrt Eine Instruktion ist ein Befehl im Befehlsregister einer CPU und bildet zusammen mit weiteren Befehlen verschiedene Verarbeitungsprozesse im System Auf einem System existieren mehrere Prozesse welche f r eine gewisse Anzahl an Takten die CPU in Anspruch nehmen d rfen Prozesse k nnen jedoch auch durch eine Unterbrechung engl Interrupt den Anspruch kurzfristig verlieren und geben 2 3 Fun
100. ech SX 14 NISTNET DUMMYNET und MoDELNET Insgesamt werden drei Experimente durchgef hrt Die Paketgr e wird f r alle Durchg nge auf 66 Byte festgelegt Das erste Experiment testet die Emulatoren auf die Einhaltung einer vorgegebenen Paketver z gerung bei einer ansteigenden Paketrate Im zweiten Experiment werden die auftretenden Paketverluste als Funktion der Paketrate betrachtet Zu Beachten ist dass die MLFFR in beiden Experimenten au en vor gelassen wird Im letzten Experiment werden die Antwortzeiten von mehreren TCP Verbindungsanfragen bei einer eingestellten Umlaufverz gerung und mit steigender Paketrate gemessen Gleichzeitig werden auftretende Paketverluste registriert und mit in die anschlie ende Betrachtung einbe zogen Der Hardware Emulator dient in der Auswertung als Referenz Die Werte werden als H ufigkeitsverteilung relativ zur Referenz aufgetragen und zeigen z B dass NETPATH als einziges dicht an den Werten des Hardware Emulators liegen Fazit Die Evaluation in dieser Publikation enth lt den wichtigen Hinweis dass bei der Messung von Leistungsgrenzen immer der Paketverlust betrachtet werden sollte Eine Metrik wie die vorgestellte MLFFR sollte f r ein eigenes Konzept mit in Betracht gezogen werden Durch diese lassen sich beispielsweise Aussagen zur Skalierbarkeit eines Emulators erzeugen Die Untersuchung der Einhaltung einer festgelegten Vorgabe f r eine variierende Belastung erm glicht es eine Skala f r die
101. eden welche in der Lage sind virtuellen Netzwerke nachzubilden engl Virtual Network Emulator VNE vgl NR09 Diese feststehenden Eigen schaften sind jedoch nur ein Unterscheidungspunkt wenn es um die Auswahl des Emulators f r ein bestimmtes Testszenario geht Wichtig sind neben weiteren festen Merkmalen wie der Mindestanforderung auch die messbare Eigenschaften welche zum Beispiel Auskunft ber die Genauigkeit des Emulators geben Daher werden in diesem Kapitel weitere Unterscheidungsmerkmale betrachtet die beide Arten von Eigenschaften ber cksichtigen Gleichzeitig entsteht so eine Taxonomie f r Netzwerke mulatoren die sich zu einem Teil aus den Produkteigenschaften und zum anderen Teil aus Genauigkeits und Leistungsanalysen zusammensetzt Die Taxonomie wird anschlie end f r die Anforderungsanalyse in Kapitel 4 und in der darauffolgenden Konzeption ben tigt Darauf aufbauend l sst sich so ein Schema f r die Bewertung und Einsatzm glichkeiten des jeweiligen Emulators ableiten In dieser Arbeit werden daf r wie in Abb 2 2 dargestellt die Emulatoren aufgrund ihrer Funktionsweise Effektqualit t und Skalierbarkeit klassifiziert Die feststehenden Merkmale wer den dabei aus den Dokumentationen des jeweiligen Emulators entnommen Die messbaren 6 2 Nachbildung von Netzwerkverhalten Eigenschaften dagegen sind Gegenstand der Genauigkeits und Leistungsanalysen zu dieser Arbeit Emulator eee ee SEHE Funktionswei
102. ef hrten Paket und Datenraten Zus tzlich wird ein vierter Abstand b4 f r die Paketgr e a2 gew hlt welcher dem Paketab stand der MLFFR des Versuchsaufbaus f r diese Paketgr e entspricht Die genauen Wertvorgabe f r die minimalen Paketabst nde kann daher erst nach Abschluss der Vorfelduntersuchungen angegeben werden Der Grund f r dieses Vorgehen wird im Folgenden erl utert Der Wert f r al entspricht der kleinsten erlaubten Ethernet Paketgr e und begr ndet sich auf der Erkennung von Paketkollisionen bei maximaler Netzausdehnung IEEE 802 3 CSMA CD Ethernet Bei Gigabit Ethernet w rde die sich die maximale Ausdehnung im Vergleich zu Netzwerken mit 10 MBit s auf wenige Meter reduzieren Daher wurde f r Gigabit Ethernet die minimale Paketgr e auf a2 512 Byte heraufgesetzt Daher ergibt die Kombination des vierten Abstandes b4 mit der Paketgr e a3 die gr te Paketrate f r diesen Versuchsaufbau unter Beachtung der Kollisionserkennung Der Wert f r a4 entspricht dem blichen Standardwert f r die Maximum Transmission Unit MTU Die Paketgr e von 1024 Byte f r a3 ist willk rlich gew hlt Die Paketabst nde starten individuell f r jede Paketgr e mit dem kleinsten m glichen Wert f r den Versuchsaufbau und damit mit dessen MLFFR f r die jeweilige Paketgr e Die folgenden Abst nde dagegen werden f r alle Gr en gleich gesetzt um so Vergleichsm glichkeiten zu schaffen Als Ausgangspunkt d
103. ehen finanzielle Einbu e oder beispielsweise im Falle von Fehlproduktionen im Verkehrsbereich sogar Gefahren f r Menschenleben Eine der Ursachen f r solche Fehlverhalten sind Einfl sse auf die Datenpakete w hrend der bertragung welche zumeist nur in Ausnahmesituationen auftreten Anwendungen sollten im optimalen Fall darauf reagieren k nnen und entsprechende Ma nahmen ergreifen Damit die Entwickler einer solchen Anwendung Fehlerf lle berpr fen k nnen ist eine umfassende Validierung n tig welche jedoch stark von der Testumgebung bzw dem Testverfahren abh ngig ist Das Verhalten von Protokollen und Anwendungen l sst sich in Modellen simulieren oder kann in realen Netzwerkumgebungen experimentell untersucht werden Beide Vorgehen einzeln betrachtet bergen jedoch Nachteile in sich die im 2 Kapitel n her erl utert werden Ein weitere Methode ist das Nachstellen von Netzwerkeffekten auf die Daten einer ber tragung mittels Emulation Mit dieser ist es m glich die Wechselwirkungen zwischen einer Netzwerkanwendung und einem Verbindungspfad zu untersuchen dessen Eigenschaften durch eine gezielte Beeinflussung weitestgehend vorgegeben werden k nnen Durch die Emulation entstehen so kontrollierbare und reproduzierbare Testabl ufe Die Verwendung eines Emulators beeinflusst jedoch zus tzlich die Testumgebung und ver ursacht Approximationen in den Testergebnissen Um diese Umst nde bei den Beobachtungen ber cksichtigen zu k
104. eigenschaften in einen Zusammenhang gebracht welche diese Eigenschaften unterst tzen Tabelle 8 6 Puffergr e des jeweiligen Emulators LINKTROPY DUMMYNET KAUNET Puffergr e Anzahl Pakete 250 50 50 8 2 Messungen 105 8 2 1 Datenrate Der Hardware Emulator setzt die Datenratenbeschr nkungen von allen getesteten Emulatoren mit den geringsten Abweichungen um Das liegt zum einen am gr eren Puffer und zum anderen an dessen h herer Verarbeitungsgeschwindigkeit welche wiederum aus einer h heren Taktrate resultiert In Abbildung 8 3a werden als Beispiel die relativen Abweichungen der gemessenen Daten raten von den eingestellten Vorgaben am Emulator als Balkendiagramme dargestellt Die Rate der Probestr me entsprechen dabei der festgelegten MLFFR d h es werden Pakete mit einer Gr e von 512 Byte und einer Paketrate von 125 KPkt s zur Messung verwendet Zum Vergleich befinden sich auch die relativen Abweichungen der anderen beiden Emulatoren in der Abbildung DUMMYNET und KauNET beschr nken die Datenraten mit deutlich h heren Abweichungen wobei gilt dass die absoluten relativen Abweichungen mit zunehmendem Unterschied zwischen der anliegenden Proberate und der zu emulierenden Datenrate ann hernd gleich bleiben Eine Ausnahme bildet jedoch KAUNET So ist eine besonders starke Abweichung f r eine Beschr nkung von 160 MBit s zu erkennen Der Grund liegt f r diesen Fall am fehlerhaften Mustergenerator bzw am Date
105. eitige Beeinflussung zu verringern Gleichzeitig verf gt der Messrechner f r eine parallele Verarbeitung von gesendeten und empfangenen Paketen einen Mehrkern Prozessor Die beiden Messpunkte zur passive Paketaufzeichnung werden auf dem Messrechner positioniert und durch Software realisiert 5 1 2 Softwaretechnischer Aufbau Die Grundkomponenten aus softwaretechnischer Sicht sind in Abbildung 5 4 dargestellt und bestehen im Wesentlichen aus einer Versuchssteuerung einem Paketgenerator zwei Paketerfas sungen sowie einer Analyse bzw Berechnungseinheit Alle weiteren Objekte in der Abbildung dienen der Versuchskonfiguration Datengewinnung und haltung 64 5 Konzeption Emulator Netzwerkkarte Q O Messpunkt E1 E2 50cm I I Tx Rx Messrechner mit Sender und Empf nger Abbildung 5 3 Hardware technischer Versuchsaufbau mit zusammengelegtem Sender und Emp f nger Versuchskonfiguration Die Voruntersuchungen und die eigentlichen Messungen basieren auf mehreren unterschiedlichen Versuchsparametern Beispielsweise werden die Datenraten bei verschieden Paketgr en untersucht Somit bietet es sich an die Abfolge und die Parameter der verschiedenen Versuche als Konfigurationsdatei zu hinterlegen An dieser Stelle kann eine GUI zur einfacheren Eingabe der Vorgaben eingesetzt werden Weiterhin sind f r den Paketgenerator und die Paketerfassung Netzwerkeinstellungen wie
106. en auch eine Toleranz f r ungewollte Paketeffekte ber cksichtigt werden muss F r die Betrachtung der Granularit t gilt dieses ebenfalls Die Emulatoren beschr nken die anliegende Datenrate ann hernd auf die geforderte Rate jedoch treten ungewollte Paketeffekte auf In Anhang A 5 sind die Abweichungen f r die minimale gew hlte Datenrate mit einem Pfad der L nge eins dargestellt Die Abweichungen bleiben auch bei einer Pfadl nge von 10 n herungsweise gleich vgl Anhang A 5 Der Pfad besteht dabei aus neun Abschnitten ohne jedwede Beschr nkung und einem einzelnen mit Ratenbeschr nkung Fazit Somit l sst sich zusammenfassen dass die Gr e des Puffers ber die Anzahl an unge wollten Paketeffekten und die H he der Differenz aus anliegender und eingestellter Datenrate ber die H he der Abweichung entscheidet Aussagen zur Granularit t oder zum Wertebe reich sind nur unter der Ber cksichtigung von vordefinierten Toleranzen m glich Lediglich der 106 8 Durchf hrung x x P PPS 125 0 KPkt s 80 PPS 125 0 KPkt s o 0 8 Emulator Linktropy gt 60 Emulator KauNet 5 0 6 5 40 S 0 4 5 20 35 5 1 13 1 o T 008 08 08 g 0 SES Wi E ZZ 20 2 E ZS 2 06 A g 60 3 7200 0 54000 0 61000 0 160000 0 7200 0 54000 0 61000 0 160000 0 Vorgabewerte am Emulator in KBit s Vorgabewerte am Emulator in KBit s a Linktropy b KauNet PPS 125 0 KPkt s Emulator Dummynet 6 5 2 5 9
107. en zumeist auf Hardware L sungen Beispiele daf r sind der LANforge FIRE Traffic Generator 13b oder Ixia Anue 3500 13i Allerdings stehen solche Produkte nicht zur Verf gung Programme welche die bisherigen Anforderungen umsetzen und Quelloffen verteilt werden sind z B OsTINATO 13t und IpeErr 13h Dennoch fehlen auch bei diesen wichtige Einstel lungsm glichkeiten um alle geforderten Metriken aus Tabelle 4 3 ermitteln zu k nnen So kann bei IPERF die Paketrate und der zeitliche Sendeabstand nur indirekt ber die Bitrate angegeben werden Auch ben tigt jedes Paket eine Sequenznummer sowie die aktuelle Paketstrom und Probedurchlaufnummer um beispielsweise Analysen bez glich der Neuordnung und Dopplung zu erm glichen Diese Konfigurationsm glichkeit findet sich jedoch in keinem der erw hnten Generatoren Folglich muss entweder eine Anpassung am jeweiligen Programm vorgenommen oder ein eigener Paketgenerator entwickelt werden Erstere M glichkeit erfordert eine intensive Einarbeitung in den Quellcode F r die andere Option kann dagegen ein bereits vorhandener Paketgenerator modifiziert werden In einer vorangegangenen Arbeit B s13 wurde f r das Messtool Nora ein Generator entwi ckelt welcher alle notwendigen Einstellungsm glichkeiten umsetzt Jedoch liegt der minimal m gliche Paketabstand unter beispielsweise Windows 7 bei 16 us und damit bei einer maxima len Paketrate von 62 5 KPkt s Der Grund daf r lieg
108. en able sen Aus diesen geht hervor dass Vorgaben bzgl der Generierung und Erfassung von Paketen sowie der Verbindung und Zeit notwendig sind Dadurch soll es beispielsweise m glich sein eine definierte Paketrate ber vorgegebene Netzwerkschnittstellen bzw Netzwerkports zu versen den und nach bestimmten Zeitabst nden zu erh hen Die genaue Auflistung der geforderten Einstellungsm glichkeiten ist in Tabelle 4 3 FI 1 bis FI 8 zu sehen Wunschkriterien Mit Hilfe der Software k nnte eine vollautomatische Analyse des Emu lators durchgef hrt werden D h der Nutzer t tigt die Eingaben und alle Einstellungen am Emulator sowie die Messungen f r einen bestimmten Betrachtungsbereich werden automatisch durchgef hrt FI w1 Zur einfacheren Steuerung der Implementation k nnte eine GUI eingesetzt werden FI w2 Diese wiederum k nnte die Endergebnisse als Diagramme visualisieren FI w3 Wobei auch Ergebnisse verschiedener Emulatoren gleichzeitig betrachtet werden k nnten FI w4 4 1 4 Auswertung Um eine einfache Vergleichsm glichkeit zwischen den verschiedenen Emulatoren zu schaffen sollten die absoluten Messwertangaben mit statischen Hilfsmitteln aufbereitet werden In den Publikationen und Studien wurden zumeist H ufigkeitsverteilungen FA 1 verwendet um Interpretationen ber die Genauigkeit bei bestimmten Vorgaben wie z B einer Paketl nge zu erm glichen Daher sollte neben der den Angaben zum Minimal Maximal und Durchschnittsw
109. en als Box Diagramme f r die verschiedenen Paketl n gen und raten bei einem einzelnen Pfadabschnitt 115 9 Zusammenfassung und Ausblick Das Thema dieser Arbeit ist der Entwurf und die Umsetzung eines Messkonzeptes zur Analyse von verschiedenen Netzwerkemulatoren in Bezug auf ihre Genauigkeit und Leistungsf higkeit bei der Nachbildung von bestimmten Paketeffekten der Einhaltung von Verz gerungen sowie der Stabilit t bei der Beschr nkung von Datenraten Das Ergebnis sind Daten aus denen sich Informationen f r Vergleichszwecke von verschiedenen Netzwerkemulatoren ableiten lassen Um Einflussfaktoren auf die genannten Eigenschaften zu ermitteln werden zun chst die wesentlichen Prinzipien von Netzwerkemulatoren sowie die Netzwerkeinfl sse auf Datenpakete im Grundlagenkapitel 2 vorgestellt Gleichzeitig wird in diesem Kapitel der Begriff der Emulation definiert und von der Simulation sowie SEmulation abgegrenzt Aus diesen Grundlagen ergibt sich ein Klassifikationsmodell f r Emulatoren bestehend aus feststehenden und messbaren Eigenschaften Dieses Modell kann dazu genutzt werden anhand von Randbedingungen an eine m gliche Testumgebung den passenden Emulator auszuw hlen Gleichzeitig lassen sich so ebenfalls Gemeinsamkeiten wie z B die Unterst tzung eines bestimmten Paketeffektes finden Diese bereinstimmungen bieten die ersten Ansatzpunkte f r ein einheitliches Messkonzept mit dem sich mehrere Emulatoren untereinander vergleic
110. en auf der INTEL Plattform stabiler sind Au erdem scheinen die Verz gerungsmechanismen von NETEM am pr zisesten zu arbeiten Starke Schwankungen der emulierten Verz gerungen sind vor allem bei KAUNET zu sehen 48 3 Verwandte Arbeiten 648 256 B x Indest 5128 Outlet 1024 B 1 ou 14708 e 03 Ei b H 3 0 01 f g 025 5 t a 5 gt 3 amp 02 AS 2 S 0 001 a 3 Sos _ H 8 0 0001 3 E i H zm a i i D D 10 05 ti H J f D amp k 1 0 05 8 10 06 A 1 1 A 92 9 96 s8 100 102 104 106 108 110 d Delay ms 10 10 10 10 Fig 15 Fixed Delay KauNet Shaper Intel Platform Fig 16 CoTV for 64Byte PDUs via the KauNet Shaper on the AMD Platform nominal delay 100 ms Abbildung 3 17 Beispiel f r die Visualisierung der H ufigkeitsverteilung und der verschiedenen CoTV links H ufigkeitsverteilung Quelle Sha 10 Fazit Die Arbeit Sha 10 konzentriert sich auf die Untersuchungen der Wertstabilit t einer vorgegebenen Paketverz gerung Erstmals wurde hierbei auf die zugrundeliegende Hardware Umgebung eingegangen und es zeigten sich Abh ngigkeiten diesbez glich Interessant ist ebenfalls die Versuchsumgebung welche auf DPMI aufbaut und es erm glicht passive Messungen am Ein und Ausgang des Emulators durchzuf hren ohne Paketerfassungs werkzeuge auf diesem zu installieren Die Messungen am Ein und Ausgang gestatten es die tats chliche Verz gerung des E
111. endeten Implementationen zur Analyse entstammen dem Messwerkzeug Nora welches ebenfalls zu Teilen in PYTHON und C geschrieben wurde So wird wie bei NoRA beispielsweise jeder Probedurchlauf vor der Analyse von Verz gerungen oder Datenraten auf Interrupt Verschmelzungen hin untersucht und bei Bedarf entsprechend behandelt Neu dagegen ist die M glichkeit aufgrund der Trennung von Messung und Auswertung Berechnungen parallel durchzuf hren F r die Berechnungen wird ein Prozesspool mit der Gr e von acht Elementen angelegt welches der Summe der verf gbaren physischen und virtuellen Prozessoren entspricht Jedem Prozess innerhalb des Pools wird ein Probestrom zur Bearbeitung zugeordnet Wenn ein Prozess mit den Berechnungen fertig ist wird diesem der n chste unbearbeitete Probestrom zugeordnet Die Ergebnisse der Berechnungen werden in weiteren csv Dateien oder als Diagramme in pdf Dateien gespeichert 6 2 Vorgehensweise 89 Steuerungsprozess in Python eigentliche Paketerfassung in C controller py ae c_nsniff c startProcess tx_sniffer static PyObject sniffOnDevice PyObject self args device_id PyObject xargs filter_string timeout R tee if PyArg_ParseTuple args sser SEN sniffer py amp device_id import c_nsniff Erweiterungsmodul laden amp filter_string amp timeout amp callback_func tif kwargs finish_sender is_set _ return 2 en gt gt z A f Sr eae
112. ennt voneinander emuliert werden k nnen ist eine Unterscheidung zwischen Paketdopplungen und Paketneuordnungen f r die Genauigkeitsanalyse erforderlich Pakete die au erhalb einer definierten Reihenfolge beim Empf nger auftreffen gelten als ungeordnet und m ssen neu eingereiht werden Der englische Begriff daf r lautet reordering daher wird in dieser Arbeit die Bezeichnung Neuordnung verwendet Der Wert der Neuordnungsrate engl Paket Reordering Rate PRR gibt das Verh ltnis zwischen der Menge der gesendeten und der Menge empfangenen ungeordneten Pakete Nr innerhalb eines Paketstromes an Nex Mr Zumeist werden aufsteigende Sequenznummern f r Ermittlung der ungeordneten Pakete verwen det Dabei ist die Betrachtungsweise wichtig ab wann ein Paket als au erhalb der Reihenfolge gilt In dieser Arbeit gelten alle versp teten Pakete als ungeordnet d h diese Pakete treffen erst nach einem urspr nglichen Folge Paket ein Der letzte Paketeffekt der auf ver nderte Bits w hrend der bertragung beruht wird in der Praxis h ufig dem Paketverlust gleichgesetzt Im einfachsten Fall nimmt ein einzelnes Bit den gegenteiligen Wert an und wird vom Empf nger als fehlerhaft erkannt Mehrere Bitfehler innerhalb eines Datenpaketes k nnen durch entsprechende Kanalkodierungskodes bis zu einem gewissen Ma korrigiert werden Dar ber hinaus jedoch ist das Paket f r den Empf nger ohne Bedeutung und wird verworfen Die H ufigkeit mit der Bitfe
113. enraten von mehreren GBit s Eine Fotografie des endg ltigen Aufbaus aus Hardware technischer Sicht ist in Abbildung 6 1 zu sehen 6 1 2 Softwaretechnischer Aufbau Die Pakete m ssen f r die Untersuchungen vom Messrechner aus ber den Emulator zur ck zum Ausgangspunkt versendet werden Da auf dem Messrechner zwei Netzwerkkarten installiert sind bedarf es einigen Vorkehrungen bzgl der Netzwerkkonfigurationen welche verhindern dass der Emulator ausgelassen wird und stattdessen die Pakete direkt zwischen den beiden Netzwerkkarten ausgetauscht werden Dazu werden die Karten logisch zwei unterschiedlichen Subnetzen zugeordnet Dies geschieht mit Hilfe der Einstellung bzgl der Subnetzmaske Wichtig ist dass der Emulator ebenfalls in beiden Subnetzen vertreten ist Au erdem erh lt die Karte welche die Pakete versendet eine anderes Gateway als die Empf ngerkarte In diesem Fall ist die IP Adresse des jeweiligen Gateways die ber das Netzwerkkabel verbundene Netzwerkkarte des Emulators Die konkreten Adresseinstellungen und die verwendeten Subnetzmasken sind im Schema in Abbildung 6 2 aufgef hrt Zum softwaretechnischen Versuchsaufbau geh ren neben der Netzwerkkonfiguration auch die Erstellung der Software Komponenten zur Messung und Auswertung Die Prozessorarchitek tur des Messrechners erlaubt es die Software Komponenten des Versuchsaufbau in mehreren eigenst ndigen Prozessen zu gliedern Dadurch ist es erst m glich die Paketgenerierun
114. ergibt sich aus den bereits erw hnten feststehenden Eigenschaften NLE und VNE Aus diesem Grund werden dazu in Abschnitt 2 5 einige Grundprinzipien erl utert 2 3 Funktionsweisen Die Betrachtung der Funktionsweise eines Emulators hilft bei einer ersten Einsch tzung bzgl der Kosten notwendigen Hardware des Verwaltungsaufwands m glichen Pr zision etc und gibt damit Aufschluss ber dessen Eignung f r eine bestimmte Testumgebung Ist beispielsweise lediglich ein einzelner Rechner f r den Testaufbau vorhanden bleiben alle Emulatoren mit einem dezentralen Ansatz au en vor Die Funktionsweise eines Emulators wird in dieser Arbeit mit Hilfe der f nf Kategorien Architektur Arbeitsbereich Zeitgeber Bedarf und Pfadvorgabe beschrieben Abbildung 2 3 zeigt eine bersicht der verwendeten Aufteilung 2 3 Funktionsweisen 7 zentral np Architektur 1 dezentral Kernel H Arbeitsbereich Nutzer Taktmodifikation m feste Taktung Zeitgeberwechsel H Zeitgeber adaptive Taktung Funktionsweise H m Betriebssystem H Anpassungen H Bedarf H ss m CPU techn Mindest anforderung 4 RAM m statisch explizit H O dynamisch O Pfadvorgabe m konstant implizit H e variabel Abbildung 2 3 Kategorie Funktionsweise mit den f nf zugeh rigen Unter
115. erscheiden sich die Werte von A und C nicht da keine weitere Last u vorhanden ist Der Wert von A sinkt sobald eine zus tzliche Last auf das bertragungsmedium wirkt siehe 7 1b w hrend der Wert von C laut Definition unver ndert bleibt In Abbildung 7 1c wird der Unterschied zur BTT verdeutlicht Eine TCP Verbindung besteht wegen gegenseitiger Steuerinformationen aus zwei Richtungen wobei der Durchsatz w hrend einer Verbindung verschieden oft angepasst wird Beispielsweise wird durch eine langsame Start Senderate engl Slow Start aus All 09 S 4 anfangs nicht die verf gbare Datenrate genutzt Wird der maximale Durchsatz erreicht ist A gleich Null jedoch stimmt der Wert der BTT nicht mit dem Wert von A vor der TCP Verbindung berein 2 4 2 Verz gerung Die folgenden Metriken beziehen sich auf die Paketlaufzeiten aus Sicht der Anwendung Die zus tzlichen Latenzen die durch die Emulation entstehen werden beispielsweise in Abb 3 6 gezeigt und geh ren mit zur Analyse Die Verz gerung engl Delay ist zeitlich beschr nkt und ist die Differenz zwischen dem Sendezeitpunkt t und Empfangszeitpunkt t eines Paketes Je nach Betrachtungsweise befinden 14 2 Nachbildung von Netzwerkverhalten sich dabei Sender T und Empf nger R auf unterschiedlichen oder aber auf ein und derselben Maschine Im ersten Fall wird die Verz gerung in eine Richtung engl One Way Delay OWD aus AKZ99a der Verbindung gemessen Im anderen Fa
116. ersuchsaufbau und einige Programm details der Analyse Software vorgestellt Au erdem werden in diesem Kapitel die konkreten Wertangaben der Versuchsparameter erl utert Zu diesen Parametern geh ren beispielsweise die verwendeten Paketstromeigenschaften und die Vorgabewerte am Emulator Der Nachweis ber die korrekte Funktion der Implementationen wird im siebenten Kapitel erbracht Dazu werden zun chst der Versuchsaufbau und anschlie end der Paketgenerator sowie die Datenerfassung mit Hilfe der Messwerkzeuge WIRESHARK und PING getestet Dabei zeigt sich die hohe Pr zision mit der die Generierung und Erfassung arbeiten Im letzten Kapitel werden abschlie end mit dem entwickelten Messkonzept die vier Emulatoren DUMMYNET KAUNET NETEM und LINKTROPY bez glich ihrer Genauigkeit und Leistungsf hig keit bei der Nachbildung von Verz gerungen Datenraten Paketverlusten dopplungen sowie neuordnungen untersucht Der komplette Umfang der Messergebnisse kann dabei nicht dargestellt werden da deren Anzahl au erhalb des Rahmens dieser Arbeit liegt Vielmehr dienen die Durchf hrungen im letzten Kapitel als Beispiel f r die Leistungsf higkeit des entwickelten Messkonzepts Allein f r diese vier 117 Emulatoren wurden ber 92000 Einzelmessungen automatisiert durchgef hrt und anschlie end ausgewertet Das Messkonzept erlaubt es sich einen berblick ber die messbaren Eigenschaften eines Netzwerkemulators zu verschaffen und unterst tzt da
117. ert auch die Verteilung der Werte ausgegeben werden FA 3 bis FA 5 F r die Analyse der Abweichung bietet sich au erdem die Ausgabe der mittleren absoluten Abweichung engl mean absolute deviation MAD sowie die des relativen Fehlers an FA 6 und FA 7 Um die Stabilit t bzw die Variation einer emulierten Datenrate zu betrachtet sollte der vorgestellte CoTV verwendet werden FA 2 F r die Auswertung der Voruntersuchungen werden Algorithmen ben tigt welche aus den Messwerten die Taktrate und die Puffergr e ermitteln 4 2 Qualitative Anforderungen Die qualitativen Anforderungen fassen zum einen die erforderlichen Nachweise zur korrekten Funktion des Messverfahren bzw dessen Implementation zusammen und zum anderen beinhalten diese alle nicht funktionalen Anforderungen 4 2 Qualitative Anforderungen 57 Teilziel Bezeichnung Vorfeldanalyse FV Messkonzepte FM Auswertung FA Testaufbau FT Implementation FI nicht funktionale Anforderungen QF Evaluation Nachweis der Umsetzung QN Messungen M Tabelle 4 1 bersicht Teilziele Nachweise Zun chst muss der korrekte Routenverlauf der Probepaket nachgewiesen werden um zu zeigen dass alle Pakete direkt vom Sender ber den Emulator zum Empf nger gesendet werden ON 11 Dadurch soll sichergestellt werden dass nur der Emulator an den verschiedenen Netzwerkeinfl ssen beteiligt ist Als n chstes muss die richtige Funktion des Paketgenerators gezeigt werden QN
118. erundet werden um sicherzustellen dass der Emulator stets ausgelastet ist Gemessen wird die emulierte Datenrate Remulierr und die OWD am Empf nger f r 10000 Pakete pro Paketgr e F r jede Paketgr e wird nach den Messungen die durchschnittliche emulierte Rate 9999 pi R ae gt i 0 Remuliert emuliert 10000 5 2 Vorgehensweise 71 sowie die durchschnittliche Verz gerung 9999 i 289 OWD 10000 berechnet Diese Werte werden abschliefiend in die Gleichung 3 3 eingesetzt um so die Puffergr e P zu erhalten wobei L der aktuellen Paketgr e von 64 Byte entspricht PL D Remuliert L Grundverz gerung Jeder von den vorgestellten Emulatoren arbeitet mit einem anderen Betriebssystem zusammen Teilweise werden diese anstelle der blichen Installation auf der Festplatte per Live System gestartet Dadurch ergeben sich unterschiedliche Voraussetzungen welche sich u a besonders durch verschiedene Grundverz gerungen u ern Diese Verz gerungen werden allein durch den Versuchsaufbau daher ohne den gestarte ten Emulator verursacht Um eine weitestgehend vom Betriebssystem unabh ngige emulierte Verz gerung zu erhalten wird dieses Grundrauschen bei den eigentlichen Messungen ber ck sichtigt F r die Ermittlung der Grundverz gerung wird lediglich das jeweilige Betriebssystem auf dem Rechner des Emulators gestartet Die Emulation selbst bleibt f r diese Voruntersuchung deaktiviert Gemessen werden mehrere Paketstr
119. esamt das ben tigte Verh ltnis zwischen Verlusten und keinen Paketverlusten zu erhalten Die Ursache ist der jeweilige Pseudozufallsgenerator welcher beispielsweise die ersten zehn Pakete verwirft und erst nach 10000 Paketen einen weiteren Verlust entscheidet Werden dabei ein zu kleines Beobachtungsintervall und zu wenige Probedurchl ufe gew hlt entstehen starke Abweichungen vom erwarteten Wert DUMMYNET ist auch hierbei der einzige Emulator welcher zuverl ssig Pfadverkettungen er laubt In Abbildung 8 9 ist das Messergebnis dargestellt Die Werte befinden sich innerhalb des Erwartungsbereiches D h bei zehn Abschnitten mit der gleichen Verlustrate von 1 muss die resultierende Rate bei 9 6 liegen 112 8 Durchf hrung PPS 50 0 KPkt s l PPS 8 3 KPkt s_ PPS 1 0 KPkt s_ T H H I l t N i 1 F 4 5 gemessene Paketeffekte loss E ae U i i i I 64 512 1024 1500 64 512 1024 1500 64 512 1024 1500 Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte Abbildung 8 9 Erfasste Paketverluste als Box Diagramme f r die verschiedenen Paketl ngen sowie raten bei 10 Pfadabschnitten und mit Dummynet als Emulator Der Erwar tungswert liegt bei 9 6 Verlusten Ein anderer Emulator der dieses ebenfalls durchf hren so
120. esamtverbindung P lautet wobei u und A sich im gleichen Zeitintervall befinden vgl Pra 03 A a LOL ui 2 2 2 4 Effektqualit t Netzwerkmetriken 13 Tx t Ci C2 D Rx Abbildung 2 6 P mit H 3 und C C Quelle B s13 Ein Umstellen der Gleichung 2 2 nach u ergibt E 2 3 a u 1 Zu Beachten ist dass sich beide Gleichungen auf den gesamten Verbindungspfad beziehen Die Gesamtauslastung u ist daher gleich der maximalen Einzelauslastung u Um auch Aussagen ber die Genauigkeit der emulierten Datenrate bei der Verwendung von TCP Paketen treffen zu k nnen wird auch die Durchsatzrate betrachtet Anderes als die maximale und die verf gbare Datenrate bezieht sich diese Gr e auf die Nutzdatenrate und wird von den Protokoll spezifischen Mechanismen beeinflusst Der maximal erreichbare Durchsatz einer TCP Verbindung wird als Massendurchsatzrate engl Bulk TCP Throughput BTT bezeichnet Abbildung 2 7 verdeutlicht den unterschiedlichen Kontext der genannten Datenraten In 7 1a C A C gt A C BTT UIWNUIOIIOIITNIII TTT D Tx i SS Rx 5 vm E en RX Uj Uj a max Datenrate entspricht b zus tzliche Last verringert c Unterschied zwischen CA der verf gbaren Datenrate verf gbare Datenrate gegen ber BTT Abbildung 2 7 Definition der verschiedenen Raten Quelle B s13 unt
121. eschieht ohnehin da zun chst jeder Probedurchlauf analysiert wird Zudem ist die Teilung in einzelne Zwischenergebnisse gegen ber der Verkettung aller Einzelwerte aus den verschiedenen Probedurchl ufen f r die Berechnungsgeschwindigkeit des Gesamtwertes von Vorteil da die Teilberechnungen parallel betrieben werden k nnen Eine weiterer Durchschnittswert ist die MAD welche die mittlere absolute Abweichung von der Emulationsvorgabe angibt und wie folgt berechnet wird k 1 e MAD x K Wert D KE l 1 Zus tzlich zum Durchschnitt und zur MAD wird der Zentralwert auch Median zu 5 genannt ermittelt Bei einer geordneten Liste von Werten befindet sich der Median f r eine ungerade Anzahl an Werten in der Mitte der Liste Bei einer geraden Anzahl an Listenelementen entspricht xo 5 dem Mittelwert aus dem Endwert der ersten H lfte und dem Anfangswert der zweiten H lfte In Abbildung 5 13 ist ein Beispiel f r diesen Fall zu sehen Gleichzeitig demonstriert das Beispiel den Vorteil des Median gegen ber dem Durchschnitt Ausrei er wie in diesem Fall der Wert 300 haben keinen Einfluss auf den Median F r die Betrachtung der Verteilung der Werte ist daher der Median vorzuziehen Weiterhin ist die Berechnung und Darstellung der H ufigkeitsverteilung wichtig Mit dieser lassen sich neben dem Modalwert xp auch die Standardabweichung o und damit die Streuung der emulierten Werte feststellen Zusammen mit dem Durchschnitt und dem Median erm
122. eschrieben Die Ergebnisse dieser Berechnungen werden zum einen f r den einzelnen Probedurchlauf und zum anderen f r den Probestrom als Datei gespeichert Nach dem letzten Probestrom eines Versuchs erfolgt eine gesonderte Auswertung aller gesammelten Ergebnisse Der genaue Ablauf der Auswertung und die Berechnungen sind Teil des n chsten Abschnittes 5 2 Vorgehensweise Die Vorgehensweise gliedert sich in drei Phasen In der ersten Phase werden alle Vorfeldunter suchungen durchgef hrt um zum einen den Einfluss des Versuchsaufbaus auf die Messungen 70 5 Konzeption und zum anderen den Paketpuffer des Emulators zu bestimmen Die zweite Phase beinhaltet die eigentlichen Messungen welche die Werte f r die dritte Phase die Auswertung liefert 5 2 1 Vorfelduntersuchungen Im Vorfeld der eigenen Untersuchungen werden die Puffergr e die Grundverz gerung und die MLFFR des Versuchsaufbaus bestimmt Auf eine automatisierte Betrachtung der Taktrate durch z B eine modifiziertes PING vgl Abschnitt 3 3 1 wird verzichtet da die Informationen auch manuell abgerufen werden k nnen Die gewonnenen Werte sind wichtig da der Versuchsaufbau selbst Einfl sse und Beschr nkungen auf die Ergebnisse der eigentlichen Messungen verursacht Die Beschr nkungen bzw Obergrenzen m ssen bekannt sein da diese sonst f lschlicherweise dem Emulator zu geschrieben werden k nnten Puffergr e In Min 11 wurde die Auswirkung der Puffergr e auf die S
123. eten Zeit und zum anderen als H ufigkeitsverteilung ebenfalls ber der Messdauer pr sentiert Ein Beispiel dieser Diagramme ist in Abbildung 3 15 zu sehen group 1 group 1 35 T 1 FreeBSD 7 0 100 Hz 7 F 30 Linux 2 6 22 100 Hz Linux 2 6 22 250 Hz 08 P 4 10 ms H E 2 j bo 5 20 er 06 F s d i De Prie 04 2 E 10 nm be s 5 Ga 0 2 FreeBSD 7 0 100 Hz gt Linux 2 6 22 100 Hz Linux 2 6 22 250 Hz 0 e ou d A 10 15 20 25 Time ms 5 10 15 20 25 30 Emulated latency ms 35 40 Abbildung 3 15 Messergebnisse Einfluss der Taktrate auf die Genauigkeit bei der Emulation einer Paketverz gerung von 10 ms rechts H ufigkeitsverteilung Quelle NR09 Erstere zeigen f r eine geringe Taktung ein S gezahnmuster was darauf zur ckzuf hren ist dass eingehende Pakete beim Emulator zun chst zwischengespeichert und erst mit dem n chsten Takt weiterverarbeitet werden Die Darstellung der H ufigkeitsverteilung gestatten einen ber blick auf die Streuung und die Genauigkeit Je dichter die Werte einer Kurve an den vorgegebenen Wert von 10 ms heranreichen desto pr ziser sind die emulierten Paketverz gerungen Um die Pr zision zu verbessern setzen einige Emulatoren entweder eine erh hte Taktrate ein oder verwenden einen anderen Zeitgeber als den Standardzeitgeber DumMYNET geh rt zur ersten Gruppe und NISTNET sowie NETEM zur zweiten Leistungsanalyse Wie
124. g 5 8 Die verbesserte Paketgenerierung in dieser Arbeit Da kein bestimmtes Betriebssystem gefordert wird kann auf diese Windows Funktionen zur ckgegriffen werden Damit entsteht zwar eine Betriebssystemabh ngigkeit jedoch f llt der zeitliche Umfang f r die Modifizierung des eigenen vorhandenen Paketgenerators geringer aus als die Einarbeitung in fremden Quellcode F r sp tere Versionen des Paketgenerators kann auch diese Abh ngigkeit durch eine Implementierung der Unix eigenen Funktionen beseitigt werden Analyse Berechnungseinheit Die Auswertung geschieht im Anschluss an die Messungen eines einzelnen Versuches und baut auf mehreren Algorithmen auf um zun chst aus den Roh daten Einzelergebnisse und anschlie end die geforderten statistischen Werte FA 1 bis FA 7 zu ermitteln F r jeden Probedurchlauf wird im Laufe der Messungen eine Datei angelegt welche die Paketnummern und die zugeh rigen Zeitstempel enth lt Diese Rohdaten bilden die Grundlage f r alle nachfolgenden Analysen Berechnet werden die Werte der Metriken FM5 1 bis FM5 7 vgl Tab 4 3 unter Zuhilfenahme von Algorithmen aus der vorangegangenen Arbeit B s13 In dieser wurde ein Messwerkzeug f r Ende zu Ende Verbindungen entwickelt welches bis auf die OWD alle geforderten Metriken berechnen kann Daher muss neben einigen wenigen Anpassungen lediglich ein Algorithmus f r die OWD zugef gt werden Dieser wird im n chsten Abschnitt zur Vorgehensweise b
125. g und erfassung gleichzeitig durchzuf hren Der Hauptprozess ist dabei die Versuchssteuerung vgl Abb 5 4 Diese startet und beendet alle anderen Prozesse F r die Gewinnung der Messwerte sind dies der Paketgenerator und die sender sowie empf ngerseitige Paketerfassung F r die Auswertungen wird ein Prozesspool angelegt dessen Elemente parallel alle Messergebnisse der einzelnen Probestr me analysiert und die Werte der Metriken sowie Statistiken berechnet Versuchssteuerung Die Prozessgenerierung und steuerung als solches wird mittels der Spra che PYTHON umgesetzt Die Prozesse selbst bzw die Verarbeitungsroutinen sind je nach zeitlicher Anforderung ebenfalls in PYTHON oder bei zeitkritischen Abl ufen wie z B der Paketgenerierung 6 1 Versuchsaufbau 87 BW wm 3 GE Fee nn eg e LESSER Emulator EN Messrechner Wei Mie amp CE oa Es Abbildung 6 1 Fotografie des realen Versuchsaufbau Oben Vergr erte Aufnahme der unter schiedlichen Netzwerkkarten und erfassung als Erweiterungsmodul in der Sprache C implementiert Die Erweiterungsmo dule werden wiederum von PYTHON aus mit bestimmten Parametern aufgerufen und durch sogenannte Callback Funktionen innerhalb des C Programmes gesteuert Ein Beispiel dazu ist in Abbildung 6 3 aufgef hrt In diesem startet der Steuerungsprozess ber einen Funktions aufruf mit Argumenten bzgl der Netzwerkkartenidentit t Erfassungsfiltern Zeitschranken usw den Proze
126. gen der Rohleistungen im Mittelpunkt Beispielsweise wird die Verarbeitungsleistung von NETPATH f r verschiedene Paketgr en und raten immer im Zusammenhang mit einer Verlustfreien bertragung betrachtet Die Rate bis zu der eine solche bertragung m glich ist wird in IHL07 als die maximal erreichbare verlustfreie Paketverarbeitungsrate kurz MLFFR bezeichnet 3 2 Produktpublikationen und dokumentationen 43 Effektqualitat Angaben OWD AOWD Leistung Paketrate 300 KPkt s MLFFR Granularit t Verz gerungen Die minimale Aufl sung betr gt 1 ms Tabelle 3 9 Angaben zur Granularit t und Leistung von NETPATH nach Aga05 Des Weiteren werden im ersten Teil der Evaluation haupts chlich die Verbesserung der an gepassten Elemente gezeigt Die Pr zision der modifizierten Warteschlangen wird z B anhand einer eingestellten Paketverz gerung sowie mit Hilfe aufsteigender Paketraten und unter Beach tung der MLFFR nachgewiesen Dabei wird die Abweichung der gemessenen zur eingestellten Verz gerung je Paketrate ausgewertet F r den Nachweis der m glichen Skalierbarkeit wird die MLFFR f r eine aufsteigende Anzahl an emulierten Pfadabschnitten gemessen Die erreichte MLFFR ist in Tabelle 3 9 zu finden welche zus tzlich auch die m gliche Granularit t bei der Vorgabe der Paketverz gerung enth lt Der zweite Teil beinhaltet Vergleiche mit anderen Emulatoren Ausgew hlt werden daf r ein Hardware Emulator namens Adt
127. gerungen SINN 0 08 Sdd S d ER Sdd S d DL S i r org een g o oso 8 KE ae O o o c 2 g S S KE E S D 2 mn E E N Q 2 E Es o o i 2 F 10 Ed E Ki g A 2 D gt a ol 5 5 D S 3 Ka 2 7 Zi E gt Q o 0 ao m 5 P szo G S BS D ozo Q S S e MN oro 8 s00 Hayya ulayssiyeM Noyyd ulaydsiyeM Hoyyd ulayssiyeM Abbildung A 1 Grundverz gerungen als Verteilungsfunktion des jeweiligen Emulators f r die verschiedenen Paketl ngen und raten 124 A 5 Messung Datenrate A 5 Messung Datenrate Wo 30 2 30 1 Vorgabe 200 KBit s 25 PPS 50 0 KPkt s KauNet 2077 ok Dummynet iol PS Linktropy H E 3 5 3 4 3 0 3 0 x 0 30 225l PPS 8 3 KPkt s 3 20 N Zut ZS el 4 6 4 6 3 4 3 S o 5 8 0 7 E03 EE EE x 3 PPS 1 0 KPkUs 20K Is 8 W 3 8 3 8 sf N Agg GISELE 28 28 03 2 5 25 92 sl B 64 512 1024 1500 Paketlange in Byte Abbildung A 2 Gemessene Datenraten bei unterschiedlichen Stromeigenschaften und einem einzelnen Pfadabschnitt Vorgabe 200 KBit s 31 7 301 Vorgabe 200 KBit s 30F PPS 50 0 KPkt s KauNet 251 z ol N Dummynet 15 T AS x sE 4
128. h f r das Beispiel zusammenfassen dass die Werte beim Sender f r kleine Zeitbereich nur geringe Abweichungen vom Mittelwert aufweisen w hrend Empf ngerseitig starke Streuungen zu verzeichnen sind und die verantwortlichen Ausrei er erst ab einem Bereich von 50 ms an Gewichtung verlieren Empfangerseite e e Senderseite T TTTTMTT7 AT in ms Abbildung 5 16 Visualisierung der berechneten CoDVwBMA f r den Sender und Empf nger unter Ber cksichtigung der Zeitintervalle AT 10 ms 20 ms 60 ms 5 3 Zusammenfassung In Abbildung 5 17 sind die wesentlichen Bestandteile des hard und software technischen Aufbaus zusammengefasst Die Abw gungen im ersten Teil dieses Kapitels ergeben einen Versuchsaufbau bei dem ein einzelner Rechner mit dem Emulator verbunden wird und die Messungen durchf hrt Dazu ist lediglich eine zweite Netzwerkkarte notwendig welche die Probestr me empf ngt bzw 84 5 Konzeption sendet Der Hauptvorteil ist dabei der Wegfall einer Uhrensynchronsation zwischen dem Sender und Empf nger F r den Software technischen Aufbau k nnen viele Komponenten aus einer vorgehenden Arbeit B s13 in welcher ein Ende zu Ende Messwerkzeug namens Nora entwickelt wurde mit einigen Anpassungen bernommen werden Dazu z hlen haupts chlich Konzepte zur Pake terfassung und Messwertanalyse Fehlende Teile wie die Versuchssteuerung oder Datenhaltung werden durch Erweiterungen der u
129. he dass WIRESHARK und die eigene Erfassungen auf der gleichen Quelle W nPcAPr aufbauen 7 3 Fehlererkennung Durchf hrung Das Messsystem ist in der Lage vor dem Beginn einer Messung Fehler in der Konfiguration der Netzwerkeinstellung und bei der Eingabe der Messparameter zu erkennen Dadurch soll der Bereich von m glichen Messfehlern weiter eingeschr nkt werden Der Nachweis daf r wird durch absichtliche Fehlkonfigurationen erbracht D h zum einen werden absichtlich Angaben zur Netzwerk oder Versuchskonfiguration weggelassen und zum anderen werden fehlerhafte Angaben an das System bergeben Nachweis 1 fehlende Angaben F r das Messsystem ist u a die IP Adresse des Empf ngers wichtig Fehlt diese Angabe in der Konfigurationsdatei f r die Netzwerkeinstellungen erscheint eine Fehlermeldung mit dem Hinweis auf die fehlende Adresse Der Inhalt einer entsprechenden Datei ist in Anhang A 2 zu sehen Dort wurde in Zeile 20 die Angabe zur IP Adresse auskom mentiert Beim Start der Messungen erscheint daraufhin Error missing Argument s rx_ip_addr Das gleiche Verhalten zeigt sich bei fehlenden Eingaben bzgl der Messungsparameter Bei spielsweise fehlen in der Konfigurationsdatei der Messung siehe Anhang A 3 die Angaben zu den Paketabst nden f r die Messung 2 Zeile 26 entsprechend gibt das System die folgende Meldung aus ValueError Given config for measurement 2 has not the right number of values
130. hen lassen Weitere Ansatzpunkte ergeben sich durch die Auswertung von vergleichbaren Arbeiten Die Literaturrecherche ergab jedoch dass nur wenige hnliche Arbeiten mit Vergleichsstudien exis tieren Vielmehr bieten die Entwickler des jeweiligen Emulators in ihren Dokumentationen Vorgehensweisen zur Analyse von Emulatoren an Allerdings beschr nken sich diese auf be stimmte Merkmale ihres Emulator Im Kapitel 3 zur Analyse von verwandten Arbeiten werden daher neben den Vergleichsstudien auch Dokumentationen betrachtet Die Wahl der jeweiligen Dokumentation st tzt sich dabei u a auf eine Trendanalyse von Internet Suchanfragen bzgl dem Stichwort Netzwerkemulator und der Anzahl der Zitation Die Analysen ergeben dass im Blickfeld der Arbeiten haupts chlich die Emulatoren DuUMMYNET NETEM KAUNET WANEM NETPATH IMMUNES und MoDELNET liegen Insgesamt werden zw lf Arbeiten in Kapitel 3 vorgestellt deren Schwerpunkte auf einem oder mehreren der genannten Emulatoren liegen Aus diesen lassen sich viele Ans tze zur Messung von bestimmten Eigenschaften von Emulatoren f r das eigene Messkonzept gewinnen Dazu z hlen beispielsweise ein Versuchsaufbaus mit passiver Paketerfassung und Metriken wie dem CoTV Zusammen mit dem Klassifikationsmodell aus Kapitel 2 und den gewonnenen Erkenntnissen aus Kapitel 3 ergibt sich eine grobe Struktur des eigenen Konzeptes f r das im Kapitel 4 eine Anforderungsanalyse durchgef hrt wird Als Ergebnis dieser Ana
131. hler auftreten wird zumeist als Bitfehlerrate engl Bit Error Rate BER bezeichnet Emulatoren welche die Nachbildung von Bitfehlern gestatten nehmen diese Rate oft als Verh ltnis entgegen Beispielsweise besagt eine BER von 1073 dass jedes tausendste Bit fehlerhaft ist F r kabelgebundene Verbindung spielt die BER eine geringe Rolle Ganz anders verh lt es sich jedoch in kabellosen Netzwerken PRR 2 9 2 4 4 Mobilfunk F r die Nachbildung von Verbindungen im Mobilfunkbereich werden Emulatoren ben tigt welche funkspezifische Merkmale unterst tzen Dazu z hlen allgemein Ausbreitungsmodelle Bewegungen und speziell Handover Effekte sowie Unterbrechungen der Verbindungen Ausbreitungsmodell Funkbasierte Verbindungen werden durch ihre Empfangsqualit t cha rakterisiert Diese ist wiederum das Resultat aus komplexen Umgebungseigenschaften und der Diese Bezeichnung wurde dem Englisch entnommen Die korrekte deutsche Bez lautet Bitfehlerverh ltnis 2 4 Effektqualit t Netzwerkmetriken 17 eingesetzten Technik Zu ersteren z hlen z B Reflexionen und Absorptionen Bei der Funktechnik spielen u a die Antennen und die Sendeleistung eine Rolle Modelle welche die Empfangsqualit t anhand der Frequenz elektromagnetischer St reinfl sse rtliche Gegebenheiten Funktechnik und des Abstandes vom Sender f r einen begrenzten Bereich berechnen hei en Ausbreitungsmodelle Der Grad der Komplexit t der genannten Einfl
132. hlter feststehenden Ei genschaften der Klassen Funktionsweise und Skalierbarkeit anhand der genannten Vor und Nachteile Bedeutung positiver negativer o mittelm iger und ken Zusammenhang EE 21 Tab 3 1 Angaben zur einstellbaren Granularit t und Leistung des Linktropy 7500 pro 27 Tab 3 2 timing Grad der Beeintr chtigung durch die genannten Faktoren Quelle Le LEE RPE RH ERED EE 29 Tab 3 3 Produktangaben zur m glichen Granularit t und Leistung von DUMMYNET nach 13w 2 2 Co onen 30 Tab 3 4 Angaben zur Granularit t und Leistung von KAUNET 34 Tab 3 5 Produktangaben zur Granularit t und Leistung von MODELNET 36 Tab 3 6 Angaben zur Granularit t von NETEM nach 13q 38 Tab 3 7 Produktangaben zur Granularit t und Leistung von WANEM nach KN08 39 Tab 3 8 Produktangaben zur Granularit t von IMuNEs nach Unil2 42 Tab 3 9 Angaben zur Granularit t und Leistung von NETPATH nach Aga05 43 Tab 3 10 bersicht der feststehende Eigenschaften der ausgew hlten Emulatoren 51 Tab 4 1 bersicht Teilziele 425 yawns 2 Cha na a I OR a a We 57 Tab 4 2 bersicht qualitative Anforderungen 58 Tab 4 3 bersicht funktionale Anforderungen 59 Tab 5 1 Allgemeine Probestromeigenschaften je Emulationsvorgabe f r die einzelnen Bereiche bei der Untersuchung der Granularit t und des Wertebereiches Pro Vorgabe werden dabei mehrere Paketabs
133. https www grid5000 fr besucht am 26 11 2013 siehe S 61 iperf 2013 URL http iperf fr besucht am 02 12 2013 siehe S 68 Ixia Anue 3500 2013 URL http www ixiacom com products network_test load_modules anue_3500 besucht am 02 12 2013 siehe S 68 KAUNET DETERMINISTIC NETWORK EMULATION 2013 URL http www kau se en kaunet besucht am 07 09 2013 siehe S 23 Kernel Probes Kprobes 2013 URL https www kernel org doc Documentation kprobes txt besucht am 09 09 2013 siehe S 37 Libpcap 2013 URL http www tcpdump org besucht am 13 02 2013 siehe S 67 Modeling Topology of Large Internetworks 2013 URL http www cc gatech edu projects gtitm besucht am 07 09 2013 siehe S 34 ModelNet Systems and Networking 2013 URL http modelnet ucsd edu besucht am 07 09 2013 siehe S 23 Multi Generator MGEN 2013 URL http cs itd nrl navy mil work mgen besucht am 18 09 2012 siehe S 32 netem GUI 2013 URL http phpnetemgui sourceforge net be sucht am 07 09 2013 siehe S 36 B 10 Quellenverzeichnis 133 13q 13r 13s 13t 13u 13v 13w 13x 13y 13z 13aa AKZ99a Mic04 Pra 03 netem Network Emulation 2013 URL http www linuxfoundation org collaborate workgroups networking netem besucht am 07 09 2013
134. icher Abstand ber die vorhandene Grundverz gerung hinaus w chst Eine Betrachtung der empfangenen und gesendeten Paketrate bei einer voreingestellte Rate von 500 KPkt s zeigt dass die Senderate vom System auf 126 KPkt s reduziert wird Somit wird f r KAUNET eine MLFFR von 125 KPkt s angenommen und der minimale Paketabstand auf 8 us festgelegt Die Betriebssysteme FREEBSD 10 0 und Linux 3 2 auf denen jeweils DUMMYNET und NETEM basieren verhalten sich gleicherma en und puffern die Pakete Die Zahlenwerte f r die Dauer der Pufferung sind hnlich denen von FREEBSD 7 3 daher werden auch hierbei 8 1 Vorfelduntersuchungen 103 Paketgr e in Byte 64 512 1024 1500 LINKTROPY 34 55 77 96 Se FREEBSD 10 0 DUMMYNET 116 106 142 167 FREEBSD 7 3 KAUNET 91 103 133 161 z Linux 3 2 NETEM 52 75 110 177 LINKTROPY 50 63 85 100 amp FREEBSD 10 0 DUMMYNET 104 129 145 161 2 120 EREEBSD 7 3 KAUNET 111 119 146 172 E Linux 3 2 NETEM 61 83 102 127 LINKTROPY 51 100 111 138 nad FREEBSD 10 0 DUMMYNET 161 153 191 204 FREEBSD 7 3 KAUNET 148 157 185 208 LINUX 3 2 NETEM 88 94 114 148 Tabelle 8 3 Mittelwerte der erfassten Grundverz gerungen in us f r den jeweiligen Emulator unter Verwendung von verschiedenen Paketgr en und abst nden Paketgr e in Byte 64 1024 64 1024 Paketabstand 20 19 51ms 390 25 ms 1285408 Bit s 1029950 Bit s in us 120 19 75ms 385 31 ms 1280090 Bit s 1019509 Bit s Tabel
135. ie end wird f r jeden Probedurchlauf ein Paketgenerator mit bestimmten Paketstromeigenschaften konfiguriert und ebenfalls gestartet Die Messwerte werden w hrend der Untersuchungen in Dateien gespeichert und nach Beendigung eines Versuchsdurchlaufes ausgewertet sowie visualisiert Dabei kann auf L sungen aus einer vorangegangenen Arbeit zur ckgegriffen werden Diese L sungen umfassen die Paketgenerierung und erfassungen sowie einige Analysemethoden zur Wertermittlung von Netzwerkmetriken Wobei jedoch im Einzelnen Verbesserungen und Anpassungen vorgenommen werden Weiterhin werden in diesem Kapitel die Vorgehensweisen bei den einzelnen Messungen zu n chst allgemein und anschlie end detailliert beschrieben Die Genauigkeit eines Emulators misst sich anhand der Abweichung des gemessenen vom vorgegebenen Wert Die Leistungs f higkeit wird durch aufsteigende Paketstrom und Pfadeigenschaften wie z B der Paketrate oder Pfadl nge ermittelt Gleichzeitig wird eine neue Metrik zur Betrachtung der Wertstabilit t entwickelt Durch diese ist es m glich Aussagen ber Abweichungen f r verschiedene Zeitspan nen zu treffen und damit denjenigen Betrachtungszeitraum zu erhalten bei dem die geringsten Schwankungen auftreten Dabei gilt je kleiner dieser Zeitraum ist desto stabiler verhalten sich die Messwerte Das sechste Kapitel beinhaltet ausgew hlte Teile der Umsetzung und Implementation des Messkonzepts In diesem Zusammenhang werden der reale V
136. ie Anzahl und die Paketnummern der neu geordneten Pakete Verz gerungen Die n chsten notwendigen Metriken sind die OWD und AOWD F r Letz tere kann der Algorithmus komplett inklusive der Behandlung von Interrupt Verschmelzungen engl Interrupt Coalescence vom Messwerkzeug Nora tibernommen werden Eine direkte Implementation fiir die Ermittlung der OWD existiert jedoch nicht in Nora da das Werkzeug fiir Ende zu Ende Verbindungen ohne Zeitsynchronisation ausgelegt wurde bei denen Sender und Empfanger auf unterschiedlichen Rechnern installiert werden Allerdings kann der Algorithmus der AOWD soweit ver ndert werden dass auch die Einwegeverz gerung berechnet werden kann Anstelle des zeitlichen Abstandes zwischen zwei aufeinanderfolgenden Paketen wird der Abstand zwischen dem Sende und Empfangszeitpunkt berechnet Alle anderen Mechanismen wie z B die Ber cksichtigung von Paketverlusten und dopplungen werden aus der urspr ngli chen L sung bernommen Eine schematische Darstellung des angepassten Algorithmus f r die OWD Berechnung ist in Abbildung 5 12 mit Beispielwerten zu sehen Nach der Messung eines Probedurchlaufes existiert jeweils eine Liste mit den Rohdaten f r den Sender und Empf nger In einem ersten Schritt wird die Empf ngerliste aufsteigend sortiert wodurch alle Neuordnungen beseitigt werden Im Beispiel betrifft dieses das f nfte Paket Anhand der Paketnummern werden anschlie end alle Verluste sowie Dopplungen in der
137. ie CPU Auslastung und Paketrate Pakete je Sekunde bei zunehmender Pfadl nge H und Anzahl gleich zeitiger Verbindungen Aus Sicht des Emulators wird daher die L nge der pipe Verkettung und die Zahl der parallel betriebenen Ketten erh ht Es zeigt sich dass ab einer bestimmten Konstellation die CPU Auslastung 100 betr gt und ankommende Pakete verworfen werden In Yoc 02 wird daher der Begriff MopELNET Kapazitat verwendet Im zweiten Experiment wurde zudem der zus tzliche Paketaustausch zwischen den Core Router untersucht welcher aufgrund der verteilten pipes entsteht Dieser Austausch wird als Cross Core Traffic bezeichnet Die VNs kommunizieren ber eine Stern Topologie in einer Weise dass pro Versuchsdurchgang eine bestimmte Prozentzahl an Verbindungen zwei Core Router durchlaufen Gemessen wird die Paketrate in Bezug auf den prozentualen Anteil an Cross Core Traffic Genauigkeitsanalyse F r die Betrachtung der Genauigkeit wird zun chst festgehalten dass der Zeitgebertakt wesentlich ist Bei einer resultierenden Granularit t von 100 us und einer Verkettung von 10 pipes ergibt sich so eine Abweichung von 1 ms Speziell MODELNET versucht diese Abweichung mit in die Konfiguration der pipes einzubeziehen Anschlie end werden Untersuchungen bzgl der Distill Phase angestellt MODELNET kann Ende zu Ende Verbindungen vereinfachen indem es pro Verbindung lediglich eine einzelne pipe anlegt Daf r wird die minimale Kanalkapazit t der urspr
138. ie obere Grenze ermittelt Das Ziel bei diesem Vorgehen ist es Vergleichsm glichkeiten zwischen allen Emulatoren zu schaffen um beispielsweise Aussagen ber Schwankungen zu einer bestimmten emulierten Vorgabe bei gleichen Voraussetzungen treffen zu k nnen Ein vorzeitiger Abbruch wegen Toleranz ber schreitung w rde diese M glichkeit verhindern Die Vorgehensweise bei den Paketeffekten Verz gerungen und Datenraten in Bezug auf die Anzahl der Pakete und Probedurchl ufe sowie Zeitdauer gleicht dem Ablauf bei der Granularit t vgl Tabelle 5 1 5 2 3 Auswertung Die Rohdaten der einzelnen Probedurchl ufe eines Versuches werden w hrend der Messungen jeweils in einer Datei gespeichert und m ssen f r die abschlie ende Auswertung in der dritten Phase analysiert werden Die Analyse liefert die Einzelwerte zu den geforderten Metriken FM 7 1 bis FM 7 7 f r jeden einzelnen Probedurchlauf und die statistischen Werte FA 1 bis FA 7 f r ebenfalls alle einzelnen Probedurchl ufe eines Probestromes sowie f r den Probestrom selbst Die f r die Ermittlung der Einzelwerte ben tigten Algorithmen werden bis zu einem gewissen Grad aus der vorgehenden Arbeit B s13 zum Messtools Nora bernommen Dazu z hlen die Algorithmen f r die Ermittlung der Datenraten AOWD und Paketeffekte Wobei letztere Algorithmen um die M glichkeit erweitert werden m ssen konkrete Paketnummern auszugeben um zum einen die Genauigkeit bei musterbasierten Emulatoren wie K
139. ient dabei die maximal erreichbare Datenrate innerhalb des Versuchsaufbaus Somit wird sich bei der Wahl von b1 an der gr ten Paketl nge orientiert Probemessungen abseits der Vorfelduntersuchungen haben gezeigt dass f r den Versuchsauf bau und bei einer Paketgr e von 1500 Byte die verlustfreie Datenrate maximal 672 MBit s betr gt Da jedoch die Senderate f r diese Paketgr e 920 MBit s betr gt k nnte der Grund 6 2 Vorgehensweise 91 irql8 em2 uhci4 lt gemeinsamer Interrupt em2 entspricht E1 irq20 atapciO cpu0 timer irg257 eml lt E2 cpul timer Abbildung 6 4 Vereinfachte Ausgabe des Befehl vmstat i zur Analyse von gemeinsam ge nutzten Interrupts daf r zum einen bei der Hardware des Emulator Rechners und zum anderen bei der Weiterlei tungsstrategie des Betriebssystems zu finden sein So teilen sich beispielsweise auf dem Rechner des Emulators die Netzwerkkarte E1 siehe Abb 6 2 und der USB Controller den gleichen PCI Bus vgl Abschnitt 6 1 1 Das f hrt unweigerlich zu einer Beeinflussung und senkt damit die Datenrate Abbildung 6 4 veranschaulicht die Problematik und zeigt eine bersicht der Interrupt Aufteilung welche mittels des Befehls vmstat i FreeBSD erstellt wurde F r den Abstand ergibt sich bei einer maximalen Datenrate von 672 MBit s der Wert 1500 Byte 672 MBit s 18 us Der Wert von b1 wird daher so gew hlt dass dieser etwas oberhalb des minimalen Paketabst
140. ieses Verh ltnisses gleich eins so arbeitet der Emulator ideal Dagegen sind Werte mit Sk lt lt 1 ein Hinweis darauf dass entweder f r R lt Ri der Emulator berlastet ist oder f r R gt R keine Ratenbegrenzung notwendig ist Es zeigt sich dass die vorgegebene Datenrate f r gro e Paket eher umgesetzt wird als f r Pakete mit einer geringen Gr e Allerdings scheint NETEM dennoch weniger Probleme mit einer kleinen Paketgr e zu haben als KAUNET Zur genaueren Analyse sowie zur Visualisierung werden zus tzlich die relativen Abweichungen R R 1 als Diagramm dargestellt und neben der durchschnittlichen Paketrate P auch die Puffergr en Xc der Emulatoren wie folgt berechnet R P T 3 2 D R Xc S 3 3 Wobei D der Paketverz gerung und L der Paketgr e entsprechen Zu beachten ist dass D f r den berlastfall des Emulators gemessen wird Die Ergebnisse zeigen dass NETEM 100 und KAUNET 50 Pakete zwischenspeichern kann Weiterhin zeigt sich f r KAUNET das dieser unabh ngig von der zugrundeliegenden Hardware arbeitet Wogegen NETEM in der AMD basierten Umgebung Datenraten akkurater umsetzt Fazit Der Einsatz von DPMI als Versuchsumgebung gestattet auch in dieser Arbeit eine pr zise Untersuchung des ein und ausgehenden Verkehrs Interessant ist vor allem die M glichkeit indirekt ber die Messung der ausgehenden Datenrate und Paketverz gerung auf die Puffergr e des Emulators schlie en zu k nnen Dieser
141. igt diese Einteilung das m gliche Komplexit tsniveau und damit auch die Skalierbarkeit an Netzknotenemulationen NLE beschr nken sich auf die Nachahmung von einzelnen oder mehreren Knotenpunkten F r die Endsysteme werden zus tzliche Rechner in der Ver suchsumgebung ben tigt Mehrere Knotenpunkte lassen sich durch eine Aufteilung der Paketverarbeitung in einzelne Abarbeitungsstationen erreichen Ein eingehendes Paket durchl uft je nach Vorgabe eine bestimmte Anzahl dieser Stationen Eine Station entspricht 2 6 Zusammenfassung 19 dabei einem Pfadabschnitt mit definierten Eigenschaften wie z B einer Verz gerung Da durch lassen sich Verbindungspfade durch eine Netzwerktopologie erstellen Emulationen virtueller Netzwerke VNE k nnen dar ber hinaus Endsysteme nachbilden Ne ben der Partitionierung verwenden diese Emulatoren zus tzliche Methoden der Virtualisie rung und Simulation Letztere werden im Teilabschnitt zur SEmulation zusammengefasst Die Methoden zur Virtualisierung lassen sich weiter aufteilen in die Virtualisierung ganzer Rechner engl Virtual Machine VM oder einzelner Betriebsmittel VB wie dem Proto kollstapel Der Nachteil von VMs ist deren Redundanz So beinhaltet beispielsweise jede VM ein eigenes Betriebssystem dass zur Funktion einer Mindestanforderung an Betriebs mitteln bedarf welche jedoch ber den Anforderungen der eigentlichen Emulation liegen Die Skalierbarkeit ist entsprechend geringer als bei VB
142. il dass f r jede Paketnummer mindestens zwei Berechnungen ben tigt werden unabh ngig davon ob ein Paketeffekt aufgetreten ist Zuerst werden zwei aufeinanderfolgende Nummern voneinander abgezogen und dann wird das Ergebnis bzw der Abstand mit Eins verglichen Bei der zweiten M glichkeit wird eine Liste Lerw mit den erwarteten Paketnummern durch laufen und das Vorkommen der aktuellen Paketnummer in der gemessenen Paketliste Lgem gez hlt Die Paketnummern und deren Anzahl an Vorkommen werden anschlie end zusammen gespeichert Auch hier entstehen Nachteile f r die Performanz da f r jede Nummer aus Lerw die gemessene Paketliste durchlaufen wird Die dritte M glichkeit verkn pft die beiden erst genannten Ans tze und reduziert die Min destanzahl der Berechnungen pro Paketnummer auf einen einzelnen Vergleich F r das eigene Messkonzept eignet sich diese M glichkeit mit Blick auf die Performanz daher am besten Die folgenden Beschreibungen sollen den Algorithmus zusammen mit einem Beispielablauf verdeut lichen Wenn beide Listen Lew und Leen gleicherma en z B aufsteigend sortiert sind stimmt die erwartete Paketnummer mit der gemessenen solange berein bis entweder eine Dopplung oder ein Verlust aufgetreten ist Bei einer Dopplung ist die erwartete Nummer gr er als die Gemessene bei einem Verlust dagegen ist diese kleiner Stellt man sich beide Liste als Schieberegister vor so wird Lgem bei einer Dopplung solange um eine Paketnumme
143. in Abbildung 5 9 dargestell te Baum aufspannen Gleichzeitig l sst sich anhand des Baumes der Begriff der Genauigkeit und Leistung skizzieren Die Messungen welche auf den vertikal verkn pften Parametern beruhen liefern die Ergebnisse f r die Genauigkeitsbetrachtung einer Emulation W hrend die gemessene Umsetzung der Einstellungen in horizontaler Richtung die dabei erreichten Leistungen anzeigen Beispielsweise wird bei der Messung einer bestimmten Verz gerung in mehreren Probedurchl u fen die Datenrate erh ht Der Messwert der jeweiligen tats chlich emulierten Verz gerung gibt die Genauigkeit und die dabei ebenfalls gemessene Datenrate gibt die Leistung des Emulators an Die genauen Messparameter werden im Kapitel zur Umsetzung der Messung erl utert Konkrete Durchf hrung Die konkreten Messungen unterteilen sich in die Ermittlung der erreichbaren Granularit t der einstellbaren Paketeffekte Verz gerungen sowie Datenraten und in die Untersuchung des jeweiligen Wertebereiches unter der Ber cksichtigung von Abweichungen Wertstabilit ten sowie Skalierungen F r beide Unterteilungen werden die gleichen Paketstro meigenschaften verwendet da die Ergebnisse der Messungen zur Granularit t die Grundlage f r die Untersuchungen zum Wertebereich bilden Daher wird zun chst die kleinstm gliche Verz gerung Datenrate sowie Effektrate bei ausgew hlten Paketgr en Paketabst nden und Pfadl ngen ermittelt 5 2 Vorgehensweise 73 Mes
144. inktropy a Vorgabe 1 ms Paketl nge 512 102 in Byte 1500 1000 0 50 0 58 0 40 0 50 120 0 51 0 50 0 50 0 50 20 0 32 0 42 0 45 0 50 KauNet 1000 0 02 120 0 02 0 03 0 02 0 02 0 02 0 02 0 02 20 0 02 0 02 0 02 0 02 Paketabstand in us NetEm 1000 0 04 0 05 0 05 0 05 120 0 07 20 0 23 0 06 0 07 0 23 0 19 0 06 0 13 Dummynet 1000 0 04 120 0 02 0 01 0 02 0 02 0 01 0 02 0 02 20 0 01 0 01 0 01 0 01 Linktropy c Vorgabe 100 ms Paketabstand in us Paketabstand in jis 1000 120 20 1000 120 20 1000 120 20 1000 120 20 1000 120 20 1000 120 20 1000 120 20 1000 120 20 Paketlange in Byte 512 64 102 1500 4 77 7 10 4 28 4 89 100 4 82 4 66 5 76 4 68 90 3 83 5 75 4 77 2 73 KauNet 80 1 29 0 17 0 22 0 21 70 0 19 0 17 0 18 0 18 60 0 14 0 16 0 12 0 17 NetEm 50 0 46 0 60 4 72 0 40 140 0 44 0 45 2 80 0 54 30 2 52 2 38 1 66 1 44 Dummynet 20 0 39 0 13 0 15 0 28 10 0 35 0 20 0 07 0 21 0 0 08 0 11 0 16 0 17 Linktropy b Vorgabe 10 ms Paketl nge in Byte
145. intervall AT auf der Empf ngerseite oaa 82 Abb 5 16 Visualisierung der berechneten CoDVwBMA f r den Sender und Empf nger unter Ber cksichtigung der Zeitintervalle AT 10 ms 20 ms 60ms 83 Abb 5 17 berblick ber den Hard und Software technischen Versuchsaufbau inklu sive der Versuchskomponenten sowie parameter 22 22 84 Abb 6 1 Fotografie des realen Versuchsaufbau Oben Vergr erte Aufnahme der unterschiedlichen Netzwerkkarten 2 2 2 u onen 87 Abb 6 2 Netzwerkeinstellungen des Versuchsaufbaus 88 Abb 6 3 Beispiel f r die Prozessgenerierung der Paketerfassung sowie das Zusam menwirken von Python und einem C Erweiterungsmodul 89 Abb 6 4 Vereinfachte Ausgabe des Befehl vmstat i zur Analyse von gemeinsam genutzten Interrupts aie sigan avis Ans aaa aaa aa war 91 Abbildungsverzeichnis xiii Abb 7 1 Messergebnisse der erfassten Paketabst nde durch WIRESHARK und der eigenen Implementation auf der Senderseite a c sowie Empf ngerseite d e als Boxplot f r die verschiedenen vorgegebenen Paketabst nde und gr en 98 Abb 8 1 Box Diagramme f r die gemessenen Grundverz gerungen unter Verwen dung der verschiedenen Stromeigenschaften am Beispiel von FREEBSD 7 3 KAUNET 102 Abb 8 2 Gemessene Verz gerungswerte zur Ermittlung der MLFFR am Beispiel von FREEBSD 7 3 KAUNET 2 2222 oo Como Abb 8 3 Auszug aus den Messergebnissen zur Betrachtung de
146. inzelnen Pfadabschnitt Vorgabe 1 AS Erkl rung zum Urheberrecht 127 A 8 Erkl rung zum Urheberrecht Hiermit versichere ich die vorliegende Arbeit selbst ndig ohne fremde Hilfe und ohne Benutzung anderer als der von mir angegebenen Quellen angefertigt zu haben Alle aus fremden Quellen direkt oder indirekt bernommenen Gedanken sind als solche gekennzeichnet Dresden 30 Januar 2014 129 Bibliografie B 9 Literaturverzeichnis Aga05 AKZ99b All 09 AP12 Arl05 Bro03 Biis13 CR10 GHB08 Gra 08 Hal 12 Hem 05 AGARWAL Shilpi NetPath Manual Wisconsin Advanced Internet Laboratory 2005 siehe S 43 ALMES G et al RFC 2681 A round trip delay metric for IPPM Techn Ber RFC 2681 september 1999 siehe S 14 ALLMAN M et al RFC 5681 TCP congestion control Techn Ber 2009 siehe S 13 ALBERTO DAINOTTI Alessio Botta and et al A tool for the generation of realistic network workload for emerging networking scenarios In Computer Networks 56 2012 Nr 15 S 3531 3547 siehe S 37 ARLOS Patrik On the quality of computer network measurements 2005 siehe S 46 Broy M Kommunikations und Informationstechnik 2010 3 Neue Trends und Entwicklungen in Technologie Anwendungen und Sicherheit SecuMedia Verlag 2003 ISBN 9783922746485 siehe S 1 B scHeL P Nora Integrated Network Measurement Tool for End to End Connec
147. issen zur Betrachtung der Genauigkeit bei der Um setzung von 0 001 Paketverlust f r einen einzelnen Pfadabschnitt Die Box Diagramme von KAUNET erscheinen wegen der fehlenden Abweichung als ein zelne Striche mit einem Stern Durchschnittswert in der Mitte in der Verlustanzahl zwischen den einzelnen Probedurchl ufen zu sehen sind entsprechen 8 2 Messungen 111 die Messwerte bei KAUNET exakt der Vorgabe Bei keiner der verwendeten Paketl ngen oder gr en treten bei KAUNET Abweichungen auf In Abbildung 8 8 sind beispielsweise die erfassten Paketverluste f r die unterschiedlichen verwendeten Stromeigenschaften bei einer Vorgabe von 1 dargestellt Zudem werden in dieser Abbildung die Ergebnisse der anderen Emulatoren Vorgabe 1 00 PPS 50 0 KPkt s Anzahl gemessener Effekte O N Go A OT N OO A 0O NOAA 64 512 1024 1500 Paketl nge in Byte Abbildung 8 8 Erfasste Paketverluste als Box Diagramme f r die verschiedenen Paketl ngen und raten bei einem einzelnen Pfadabschnitt Auch hier erscheinen die Box Diagramme von KAUNET wegen der fehlenden Abweichung als einzelne Striche mit einem Stern in der Mitte gezeigt Bei diesen treten die Verluste unregelm iger und mit Abweichungen zum Vorgabewert auf In Bezug auf die Granularit t bleiben dennoch alle Emulatoren innerhalb der Toleranzgrenzen von 3 relative Abweichung Es sei jedoch angemerkt dass mehrere Probedurchl ufe erforder lich sind um insg
148. it WIRESHARK mit denen der implementierten Paketerfassung verglichen Ergebnisse Die Messergebnisse sind in Abbildung 7 1 als einfache Boxplots dargestellt Die Antennen stellen in diesem Fall den Minimal und Maximalwert der erfassten Paketabst nde dar In den Diagrammen der Senderseite l sst sich zum einen die Genauigkeit des Paketgenerators bei der Umsetzung der Vorgaben und gleichzeitig die Zuverl ssigkeit der Paketerfassung erkennen Als Referenz dienen die Ergebnisse welche zur gleichen Zeit mittels WIRESHARK gemessen wurden Die mittlere relative Abweichung der generierten Abst nde in Bezug auf die Vorgabe 7 3 Fehlererkennung 97 betr gt maximal 0 006 Au erdem arbeitet der Generator in nahezu allen F llen stabil Hierbei betr gt die relative Abweichung der einzelnen Extremwerte von der Vorgabe maximal 20 vgl Abb 7 1a Die implementierten Paketerfassungen am Sender und Empf nger liefern bis auf wenige Ausnahmen die gleichen Ergebnisse wie WIRESHARK Die Ausnahmen sind in Abbildung 7 1a und 7 1d zu finden Ein Grund daf r ist beispielsweise die angewendete Rundung der Werte bei WIRESHARK Gerade bei Zeitwerten im Mikrosekundenbereich f llt das Aufrunden besonders ins Gewicht Somit l sst sich zusammenfassen dass die Implementation des Paketgenerators stabil sowie zuverl ssig arbeitet und die Werte der eigenen Paketerfassungen nahezu exakt mit denen von WIRESHARK bereinstimmen Letzteres beruht auch auf der Tatsac
149. kategorien 2 3 1 Architektur Diese Kategorie bezieht sich auf die real existierende Hardware welche zur Emulation eingesetzt wird Ein Emulator kann dabei in einer eigens daf r konstruierten Hardware implementiert sein oder als Software vorliegen Allgemein bestehen die M glichkeiten den Emulator zentral auf einem einzelnen realen Netzwerkknoten Kr oder dezentral auf mehrere Rechnern verteilt zu installieren In beiden F llen kann durch eine weitere Virtualisierung eine komplexere Umgebung mit entsprechend virtuellen Knoten Kv aufgebaut werden als die zugrundeliegende Hardware urspr nglich erm glicht h tte So ist es beispielsweise denkbar eine Satellitenverbindung durch einen Emulator nachzuahmen obwohl kein Satellit zur Verf gung steht Zentral Bei einem zentralen System befinden sich alle Emulationskomponenten auf einem einzelnen Kr Es besteht die M glichkeit dass auch der Sender und oder der Empf nger Teil dieses Kr ist sind Im allgemeinen Fall jedoch befindet sich der Emulator getrennt von Beiden auf einem gesonderten Rechner Die Zentralisierung hat den Vorteil dass keine Uhrensynchronisation durchgef hrt werden muss da sich alle Emulatorelemente den gleichen Zeitgeber teilen Dadurch sind zentrale Systeme 8 2 Nachbildung von Netzwerkverhalten bei der Untersuchung von Paketverz gerungen am genauesten Nachteile diese Architektur zeigen sich in der eingeschr nkten Skalierbarkeit Mit steigender Komplexit t der Testumge
150. ket zum gt Netzwerk Paketverlust Warteschlange zur Verz gerung interface Abbildung 3 12 Schema der Paketverarbeitung durch NETEM Der Autor von Hem 05 beschreibt mit Hinblick auf die Genauigkeit von NETEM dass dieser durch die Granularit t des Zeitgebers durch den Pseudozufallsgenerator und die Puffergr e der Netzwerkkarte beeinflusst wird Daher ist wie bei DUMMYNET der Zeitgeber entscheidend f r den Grad der Genauigkeit In vorausgehenden Untersuchungen zur Genauigkeit von DUMMYNET zeigt sich dass dessen Zufallsgenerierung ebenfalls problematisch f r kurzzeitig Verbindungen ist und die Messwerte weit unter den geforderten Werten liegen Die Puffergr e muss f r die Analyse der Genauigkeit in Betracht gezogen werden wenn ein hohes kurzzeitiges Paketaufkommen engl Packet Burst erforderlich ist Genauigkeitsanalyse Die Evaluation von NETEM f llt in Hem 05 sehr kurz aus und beruht auf zwei 90 sek ndigen TCP Str me Auf eine Leistungsanalyse wurde komplett verzichtet Der Autor wei t darauf hin dass NETEM nicht das reale Internet nachbilden kann und es eher wichtig ist einzelne Verbindungen korrekt darzustellen Daher wurde zun chst eine reale TCP Verbindung ber einen 1 Mbps DSL Anschluss gemessen und anschlie end versucht diese mittels NETEM nachzubilden Genutzt wird in beiden Fallen ein Verfahren namens Kprobes 13k welches auf Kernelebene
151. kler des Emulators NETPATH beschreiben diesen in IHL07 als extrem leistungsf hig und pr zise In einer umfassenden zweiteiligen Evaluation zeigen sie dass die erreichbaren Werte weit ber denen anderer Software basierter Emulatoren liegen und nahe an die eines Hardware basierten Produktes heranreichen Der Umfang der emulierbaren Effekte hebt NETPATH 42 3 Verwandte Arbeiten Effektqualitat Angaben 2 Datenrate C 0 Bit s 1GBit s H bei 19 ze 3 BER 0 10 Verh ltnis Paketeffekt z E PDR 0 50 in 1 Schritten S Verz gerungen OWD 0 107 us Tabelle 3 8 Produktangaben zur Granularit t von ImuNEs nach Uni12 ebenfalls deutlich von anderen Emulatoren ab Bis auf die Erzeugung von CT deckt sich dessen Effekteumfang mit dem des LINKTROPY Des Weiteren werden in dieser Arbeit Begriffe wie Raw Performance dt Rohleistung und maximale verlustfreie Paketrate original engl Bez maximum loss free packet forwarding rate MLFFR gepragt Letzterer ist fiir das eigene Messkonzept interessant und wird im folgenden Ab schnitt zur Leistungsanalyse n her beschrieben Zun chst sollen jedoch die Funktionsprinzipien von NETPATH umrissen werden Um diese laut IHL07 hohe Pr zision zusammen mit einer extremen Leistungsf higkeit zu erreichen w hlen die Entwickler von NETPATH eine Plattform namens CLICK MODULAR ROU TER Koh 00 Mit dieser ist es m glich eine auf Polling basierte statt eine auf Interrupt ba
152. ktangaben eingegangen wird werden kurz die Prinzipien und die Umsetzung des Emulators beschrieben Dadurch ergeben sich die feststehende Merkmale f r die Einordnung in die vorgestellte Taxonomie Soweit Analysen vorhanden sind werden diese gesondert erl utert und im Fazit zur Betrachtung des jeweiligen Emulators zusammengefasst Daraus lassen sich u a die Vorgehensweise und die verwendeten Werkzeuge f r eine Anforderungsanalyse des eigenen Messkonzeptes ablesen Zus tzlich werden Produktangaben zum jeweiligen Emulator in den Tabellen 3 1 bis 3 9 aufgelistet Diese Angaben finden sich oft im jeweiligem Handbuch oder werden soweit vorhanden aus Messergebnissen der Evaluation abgelesen Der Umfang dieser Informationen variiert zwischen den Emulatoren und zeigt somit ebenfalls an welchen Stellen noch Analysen ben tigt werden Beim Hardware Emulator und WANEM sind keine Analysen auffindbar aus diesem Grund werden lediglich die Produktangaben f r sp tere Vergleiche in einer Tabelle aufgelistet DuMmMyYNET ist ebenso wie NETEM Grundlage f r andere Emulatoren Daher werden die Funktionsweisen von Beiden eingehender erl utert Die Entwickler von KAUNET haben diesen ausf hrlich evaluiert Weshalb dieser bzgl der Analysen umfassender betrachtet wird 3 2 1 Linktropy 7500 pro Dieser Hardware Emulator bildet ein WAN zwischen zwei Netzwerkbereichen nach und geh rt daher zur Klasse der NLE F r die Nachbildung stehen dem Versuchsdurchf hrenden ein
153. kte Verz gerungen Datenraten Paketanzahl steigend konstant konstant Probedauer _ _ erh ht Probedurchl ufe mehrere einzeln einzeln Tabelle 5 1 Allgemeine Probestromeigenschaften je Emulationsvorgabe f r die einzelnen Be reiche bei der Untersuchung der Granularit t und des Wertebereiches Pro Vorgabe werden dabei mehrere Paketabst nde und gr en untersucht Probestrom n tig vgl Tabelle 5 1 Um jedoch den Einfluss von stark abweichenden Werten zu verringern wird die Zeitdauer eines Probedurchlaufs wesentlich erh ht Die kleinste emulierbare Datenrate ist gefunden wenn alle nachfolgenden gemittelten Raten eine bestimmte Abweichung berschreiten Wertebereich F r die Ermittlung des Wertebereichs werden die Vorgaben f r die Paketef fekte Verz gerungen und Datenraten am Emulator Stufenweise erh ht Die Schrittweite bzw die Anzahl der Nachkommastellen pro Schritt richtet sich nach den Ergebnissen zur Granu larit t Die untere Grenze des Wertbereichs ist die kleinstm gliche emulierbare Wertvorgabe Zur Gewinnung der oberen Grenze werden zun chst alle Stufen durchlaufen und die zugeh rigen Messergebnisse gespeichert Die endg ltige Auswertung der Messwerte findet erst nach Abschluss der letzten Stufe statt Somit werden auch Vorgaben bzgl ihrer Abweichung und Stabilit t berpr ft welche bereits au erhalb des m glichen Wertebereichs liegen In der Phase der Auswertung wird anschlie end mit bestimmten Toleranzen d
154. ktionsweisen 9 diesen an den Unterbrechenden weiter Ein Interrupt kann nur zusammen mit einem Takt er folgen da erst die aktuelle Instruktion beendet wird Beispielsweise l sen ankommende bzw ausgehende Pakete einen Interrupt aus Die Rate der Interrupts bzw die Taktrate des Zeitgebers ist daher ausschlaggebend f r die Verarbeitungsgeschwindigkeit und die Granularit t bestimmter Effektqualit ten Ist die Ein bzw Ausgangsfrequenz der Pakete h her als die Taktrate werden diese zwischengespeichert und gesammelt weiterverarbeitet Bei einem zu geringen Zwischen speicher werden Pakete jedoch verworfen Um die Standardtaktrate des Systemzeitgebers zu erh hen fordern Emulatoren entweder eine Anpassung der Frequenz oder geben dem System einen anderen Zeitgeber vor dessen Taktrate h her ist Ersteres ist mit einer Anpassung des Systems verbunden und nicht ohne eine Kompilierung des Kernels umzusetzen Die andere M glichkeit ist von der Installation her einfacher und ohne Anpassungen durchf hrbar Jedoch sind nicht auf allen Systemen die gleichen Zeitgeber vorhanden Wodurch ein entsprechender Emulator abh ngig von einer bestimmten Hardware wird Eine zu hohe Taktrate birgt jedoch die Gefahr dass das System eher verlangsamt wird da der Wechsel zwischen den Prozessen ebenfalls mit einem Kontextwechsel verbunden ist Die Zwischenergebnisse sowie Daten des unterbrochenen Prozesses werden in den Cache Speicher gelegt und nach der Verarbeitung
155. l le zu verschaffen Dadurch wiederum lassen sich Bewertungen bzgl der Stabilit t emulierter Verz gerungen abgeben Shaikh et al beschreiben in MFA10 ausf hrlich die Vorz ge dieser Metrik Zun chst wird der Versuchsaufbau und anschlie end die Vorgehensweise bei der Wertermitt lung vorgestellt Versuchsaufbau Genutzt wird eine Versuchsumgebung namens Distributed Passive Measu rement Infrastructure DPMI Arl05 Diese besteht aus zwei Messpunkten und der blichen Verkettung zweier Endpunkte ber einen Router auf dem sich die Emulatoren befinden Die Endsysteme bestehen f r die Betrachtung der Abh ngigkeit vom Hardware System entsprechend entweder aus AMD oder INTEL basierten Komponenten 3 3 Vergleichsstudien 47 Ein Messpunkt ist f r genau eine Richtung der Verbindung zust ndig und ist auf eine Weise mit dem Aufbau verbunden dass dieser den Router berbr ckt Dadurch k nnen Pakete vor und nach dem Router erfasst werden Die Messpunkte verf gen ber DAG3 5E 13x Netzwerk karten welche spezielle f r die Paketerfassung konzipiert wurden Eine Veranschaulichung des Versuchsaufbaus befindet sich in Abb 3 16 pi ei Na Messpunkt 1 Endpunkt 1 Router Endpunkt 2 a gt 3 Messpunkt 2 Abbildung 3 16 Versuchsaufbau in Sha 10 angelehnt an die DPMI Gemessen werden das OWD bzw die Durchgangsverz gerung der einzelnen Pakete Neben der Hardwar
156. l throughput measurement device in ip output input demux device out local ip output gen device out iS B D E n o Detailed overhead measurements Abbildung 3 6 Oben die typische Messung der Paketrate durch die gesamte Paketverarbeitung des Betriebssystems Unten die verwendete Messmethode um die Paketklassifi kation und Emulation gesondert betrachten zu k nnen Quelle CR10 Effektqualit t Angaben PLR E Paketeffekte DER 0 100 Verz gerungen OWD Aufl sung 0 1 ms abh v Kernel Taktung Leistung Paketrate 300 KPkt s Tabelle 3 3 Produktangaben zur m glichen Granularit t und Leistung von DuMMYNET nach 13w mit einer bestimmten Verz gerung und abschlie end mit einer Beschr nkung der Datenrate durchgef hrt Die Ergebnisse der Messungen liegen f r beide Teilabschnitte bei wenigen Mikrosekunden Fazit Die vorgestellten Analysen bieten wichtige Anhaltspunkts f r ein eigenes Messkonzept So sollte neben der Wertbestimmung zu einem bestimmten Netzwerkeffekt auch der timing Aspekt untersucht werden Dadurch lassen sich bereits im Vorfeld der eigentlichen Versuchs durchf hrungen Angaben ber die H he der Abweichungen machen Des Weiteren spiegelt die PPT im Vergleich zur PPS eher die Leistung des Emulator wieder Wenngleich die direkte Bestimmung der PPT komplizierter ist und in mehreren Etappen durchlaufen werden muss Die Angaben zur Genauigkeit und Leistung von DumMYNET sind in Tabell
157. lator is the gateway A97B708B C2B7 48F2 949A 999829423225 tx_ip_addr 10 0 0 2 tx_mac_addr tx_port 2606 GATEWAY 00 O0e O0c c4 e4 e0 of Sender gw_ip_addr 10 0 0 1 gw_mac_addr RECIEV F rx_device_id rx_ip_addr 00 0e 0c c3 09 xd lt Nachweis 2 R A15744E6 3100 4817 8FB6 x lt Nachweis 2 10 0 0 6 lt Nachweis 1 rx_mac_addr rx_port 1308 68 05 ca 1d c f b7 VD CD A Ch Ui L P r DD L Gi L L L L L L bh b bd P ba b NNN N FRR k ka RR RP ka ka w CD A Ch Ui P ra Gi w DJ Ch iv L PM r Gi w D A Ch Gi G b ra OO 122 A 3 Konfigurationsdatei f r die Angabe von Messparametern A 3 Konfigurationsdatei f r die Angabe von Messparametern Config file Stream Strm configuration Protokoll Proto can be UDP A Strm consists of a number of Trains Trn_nr A Trn consists of a number of Packets Pckt_nr A Packet Pckt has a number of bytes Pckt_size Note given value cannot contain K Kilo or M Mega Each Strm has a sequence number Strm_seq_nr The inter departure time gap between Strm Trains Trn and Packets Pckt can be given explicitly Whereby Strm_gap are given in sec Trn_gap in msec and Pckt_gap in usec Also a minimum duration for Strm in sec or Trn also in sec can be configured Note the number
158. le 8 4 Durchschnittliche Verz gerungen links und Datenraten rechts f r die jeweiligen Paketstromeigenschaften unter Verwendung von KAUNET mit einer Datenratenbe schr nkung von 1 MBit s eine MLFFR von 125 KPkt s angenommen Die Ausnahme bildet der Hardware Emulator bei welchem auch bei einer Rate von 500 KPkt s kein Ansteigen der Verz gerungen bzw Paketverluste zu erkennen ist Der Messrechner kann keine Paketrate in der H he generieren bei welcher Verz gerungen oder Paketverluste am LINKTROPY auftreten Eine MLFFR ist daher nicht messbar 8 1 3 Puffergr e Am Emulator wird eine Einstellung von 1 MBit s als Datenratenbeschr nkung gew hlt Unter sucht werden dabei die Paketgr en a1 und a3 sowie die Paketabst nde b1 und b2 Daraus ergeben sich vier Vergleichswerte welche alle auf die gleiche Puffergr e zur ckzuf hren sind F r KAUNET sind die gemittelten Werte der OWD und die Datenraten des Versuches in der Ta belle 8 4 zu sehen Mit Hilfe von Gleichung 3 3 und diesen Werten ergeben sich die berechneten Puffergr en in Tabelle 8 5 Somit l sst sich insgesamt feststellen dass der Puffer von KAUNET standardm ig 50 Pakete zwischenspeichern kann Eine Gesamt bersicht der Puffergr en der verwendeter Emulatoren au er NETEM ist in Tabelle 8 6 aufgef hrt Es sei dabei angemerkt dass sich diese Gr en einstellen lassen und die gezeigten Werte den Standardwerten entsprechen Der Emulator NETEM besitzt nich
159. ll wird die Umlaufverz gerung engl Round Trip Delay RTD aus AKZ99b betrachtet Wichtig ist dass im ersten Fall eine Synchronisation der Zeitgeber auf beiden Seiten n tig ist Die Verz gerung eines Paketes setzt sich unter anderem aus den Einzelverz gerungen bei der bertragung De Ausbreitung D und in der Warteschlange D zusammen Die Darstellung in Bild 2 8 veranschaulicht die Zusammensetzung der Einzelverz gerung f r eine Richtung Formel 2 4 zeigt die Berechnung f r die jeweilige Verz gerung des j ten Paketes 2 4 pe 7 Dr D Do _ OWD Dy Dp Do Dy Dp Dy RTD Das Hochkomma bei den Einzelverz gerungen der RTD zeigt an dass die Einzelverz gerungen bei der Hin und R ckrichtung durchaus unterschiedliche Werte annehmen k nnen Einige Emulatoren sind in der Lage ein und ausgehende Pakete unterschiedlich zu behandeln um so asynchrone Verbindungen nachzubilden Tx Rx senden des 7 erste Bits Deis D D DE ein empfangen des 7 7 letzten Bits Zeit Abbildung 2 8 Schema der Verz gerungsphasen bei OWD Quelle B s13 Zuf llige Schwankungen der Paketlaufzeiten verursachen unterschiedliche Verz gerungen Speziell f r die OWD hat sich der Begriff Jitter trotz Mehrdeutigkeit f r die Variation der Verz gerungen zwischen aufeinanderfolgenden Paketen etabliert Eine Veranschaulichung dazu ist in Abbildung 2 9 zu sehen Als Gleichung wobei AOWD dem Jit
160. llt und gleichzeitig Evaluationen sowie Studien zu diesen erl utert Anhand dieser Prinzipien lassen sich die Emulatoren in die vorgestellte Taxonomie einordnen um z B einen Grundstock f r die Einsch tzungen zu erhalten Au erdem l sst sich so ein eigenes Mess konzept ableiten mit dessen Hilfe u a Werte gefunden werden k nnen welche die getroffenen Einsch tzungen entweder untermauern oder eine Berichtigung dieser erfordern 2 6 Zusammenfassung 21 Ki S a amp 5 is 5 S Ka 3 ol 1 Ss EAR e Slp lag amp Sla lla El F e Siss 3 2 s 2 s ee aa ae e Sial ATR a 2 silg 2 s 35 2 8 Q as 4 E Q Cl S ei E Oo 2 Q T gt amp Oo amp 21709 E a vu gt la DIE IG zentral Architektur dezentral 1o Modifikation o o feste Taktung Zeitgeber Wechsel H g adaptive Taktung o T S S Kernel o ct Arbeitsbereich KE User J J 3 FH statisch I 1Io explizit dynamisch o o o0 o Pfadvorgabe konstant o o FREE RE implizit variabel I EN Netzknotenemulation I 1Io o 5 VM H ene E o E Emulation virtueller Netzwerke VB o o o J Tabelle 2 1 Beispiel f r ein Bewertungsschema einiger ausgew hlter feststehenden Eigenschaf ten der Klassen Funktionsweise und Skalierb
161. llte ist KAUNET Jedoch treten bei diesem schwerwiegende Ausnahmefehler im Kernel von FREEBSD auf und verursachen Systemabst rze sobald mehrere Pfadabschnitte konfiguriert werden Daher werden auf weitere Untersuchungen mit KAUNET f r mehrere Pfadabschnitte verzichtet Neuordnung Auch hierbei hebt sich KAUNET von den anderen Emulatoren ab Ein direkter Vergleich kann beispielsweise mit Hilfe von Abbildung 8 10 durchgef hrt werden Ein weiteres Beispiel befindet sich ebenfalls in Anhang A 7 KAUNET setzt exakt die Vorgabe um Wogegen die Werte von z B NETEM deutliche Abweichungen aufgrund der Zufallsentscheidung aufweisen F r eine PPS von 50 KPkt s liegen die Werte deutlich oberhalb der Vorgabe und f r eine Rate von 1KPkt s finden gar keine Neuordnungen statt Daher ist zu vermuten dass die Zufallsent scheidungen nicht pro Paket sondern pro Zeiteinheit getroffen werden Was wiederum darauf hindeutet dass das Betrachtungsintervall zu klein und zu wenige Probedurchl ufe gew hlt wurde Einzig der Hardware Emulator weist hnliche Werte in Bezug auf die mittlere Neuordnungsrate auf Die Entscheidungszeitpunkte scheinen bei diesem Emulator mit einem geringeren Abstand zu erfolgen Dopplung NETEM besitzt als Einziger gegen ber den anderen Software Emulatoren die F hig keit Paketdopplungen zu emulieren Jedoch weichen auch bei der Paketdopplung die gemessenen Paketeffekte von den vorgegebenen ab So Schwanken beispielsweise bei einer Vorgabe vo
162. lt und zeigt neben den Messergebnissen auch die entsprechende Vorgehensweise bei der Genauigkeits und Leistungsanalyse Genutzt wird dazu ein einzelner Rechner dessen technische Merkmale f r die entworfene Taxonomie verwendet werden und in Tabelle 3 10 zu sehen sind Genauigkeitsanalyse Im ersten Teil der Analyse wird auf die Pr zision bzw auf deren Ein flussfaktoren eingegangen Zum einen bestimmt der Umfang des Netzwerkmodels und zum anderen die umsetzbare zeitliche Koordinierung engl timing den Grad der Pr zision Je detail lierter die Emulation stattfinden soll desto h her ist der Verarbeitungsaufwand Daher verzichtet DummYNET zum Beispiel auf die Nachbildung von Bitfehlern in Paketen Aus diesem Grund approximieren auch viele andere Emulatoren diese Effekte Laut CR10 wird der timing Aspekt im Wesentlichen durch den konkurrierenden Paketverkehr engl Cross Traffic CT bei mehreren emulierten Knotenpunkten die Interferenz durch andere Systemprozesse und die Granularit t des Zeitgebers beeinflusst Tabelle 3 2 zeigt den Grad der jeweiligen Beeinflussung Die Werte f r den CT beziehen sich in der Tabelle auf eine Paketl nge L von 1500 Byte mit einer Datenrate A von 1 Gbit s und 100 Mbit s Sobald mehrere Knotenpunkte N mit N gt 1 3 2 Produktpublikationen und dokumentationen 29 Beeintr chtigung Cross Traffic 120 1200us pro emulierten Knotenpunkt Interferenz gt 30s abh vom Betriebssytem Granularit t 25 1
163. lyse entstehen mehrere Teil ziele gruppiert nach funktionalen und qualitativen Anforderungen welche sich wiederum in weitere Teilschritte aufgliedern Zu diesen Teilzielen geh rt u a ein Hardware sowie Software technischer Versuchsaufbau der es erm glicht Pakete zu generieren uhrensynchron zu erfassen und bzgl bestimmter Metriken zu untersuchen 116 9 Zusammenfassung und Ausblick Im nachfolgenden Kapitel 5 werden entsprechend der gefassten Teilziele die einzelnen Kon zepte zu deren Umsetzung vorgestellt F r den Hardware technischen Versuchsaufbau werden die Testumgebungen aus den vorgestellten Vergleichsstudie sowie Dokumentationen betrachtet und gegen ber gestellt Als Resultat entsteht eine eigene L sung welche den Sender und Emp f nger der Probepakete auf einem einzelnen Messrechner vereint Dadurch entf llt die ben tige Uhrensynchronisation und es k nnen exakte Verz gerungswerte gemessen werden Ein weiterer Rechner dient als Versuchsrechner auf welchem die Emulatoren installiert werden M gliche Engstellen werden mit verschieden Mitteln vermieden Der Software technische Aufbau besteht aus mehrere Modulen die zusammen die jeweilige Untersuchung automatisiert starten steuern durchf hren beenden und auswerten Eine Versuchssteuerung nimmt die n tigen Konfigura tionen bzgl der Netzwerkeinstellungen und Versuchsparameter entgegen und startet zun chst jeweils eine Paketerfassung f r den Sender sowie Empf nger Anschl
164. m 10 0 0 5 bytes 100 time lt lms TTL 64 Reply from 10 0 0 5 bytes 100 time lt lms TTL 64 Reply from 10 0 0 5 bytes 100 time lt Ims TTL 64 Reply from 10 0 0 5 bytes 100 time lt lms TTL 64 Reply from 10 0 0 5 bytes 100 time lt lms TTL 64 Ping statistics for 10 0 0 5 Packets Sent 5 Received 5 Lost 0 0 loss Approximate round trip times in milli seconds Minimum Oms Maximum Oms Average Oms C gt ping S 10 0 0 2 n 5 1 100 i 2 10 0 0 6 Pinging 10 0 0 6 from 10 0 0 2 with 100 bytes of data Reply from 10 0 0 6 bytes 100 time lt lms TTL 127 Reply from 10 0 0 6 bytes 100 time lt lms TTL 127 Reply from 10 0 0 6 bytes 100 time lt lms TTL 127 Reply from 10 0 0 6 bytes 100 time lt lms TTL 127 Reply from 10 0 0 6 bytes 100 time lt lms TTL 127 Ping statistics for 10 0 0 6 Packets Sent 5 Received 5 Lost 0 0 loss Approximate round trip times in milli seconds Minimum Oms Maximum Oms Average Oms VD D A Ch On FWY r FA M ba ka ah ka rh ah Fa ba rh ka LA r GO w D JA Ch UT VS L P Ho A 2 Konfigurationsdatei f r die Netzwerkeinstellungen 121 A 2 Konfigurationsdatei f r die Netzwerkeinstellungen Configfile Network sender tx gt Emulator gt reciever rx Not SENDER tx_device_id this file can also be generated by commando Tx and Rx have to be placed on the same machine with different subnets Emu
165. m Emulator auf Die passive Aufzeichnung erm glicht es den tats chlichen Datenverkehr inklusive pr zisem Zeitstempel f r den Versende und Empfangszeitpunkt f r jedes einzelne Paket zu erhalten Dieser Aufbau stellt daher das Optimum bzgl der Werterfassung dar erfordert jedoch spezielle DAG Netzwerkkarten Eine prinzipielle Nachbildung dieser Struktur ist auch mit aktiven Netzwerkkomponenten m glich Beispielsweise k nnte ein Switch mit Port Mirroring eingesetzt werden wodurch anders als beim Hub die verf gbare Datenrate nicht verringert wird Allerdings werden je nach verwendeter Weiterleitungsmethode zus tzliche Latenzen im Mikrosekundenbereich hinzugef gt Damit der Switch nicht zum Flaschenhals wird muss dieser mindestens 1 GBit s pro Port unterst tzen Da jedoch ein solcher Gigabit Switch mit Port Mirroring nicht zur Verf gung steht muss eine andere M glichkeit der passiven Paketaufzeichnung gefunden werden In Hal 12 verwenden die Autoren bei der Untersuchung von KAUNET daf r das Werkzeug TcppuMmP an insgesamt vier Messpunkten Zwei von diesen befinden sich direkt auf dem Rechner des Emulators Die anderen beiden sind jeweils dem Sender und dem Empf nger vorgeschalten Der Vorteil dieser Aufteilung ist dass unerw nscht auftretende Paketeffekte jeweils zwischen dem Sender und Emulator sowie zwischen dem Empf nger und Emulator erkannt werden k nnen F r die Untersuchung in virtuellen oder hybriden Umgebungen i
166. mYNET Bestandteil des Kernels geworden 28 3 Verwandte Arbeiten Zus tzlich erschien 2010 eine weitere Publikation CR10 zu DumMMyYNET welche neben den An gaben zum damals aktuellen Stand des Emulators auch eine Genauigkeits und Leistungsanalyse enth lt Aus den Angaben geht hervor dass die aktuelleren Versionen von DUMMYNET in der Lage sind mehr als einen Pfadabschnitt nachzubilden Daf r wurde ein weitere Ebene zur Paketverarbeitung hinzugef gt welche ankommende und oder abgehende Pakete klassifiziert bestimmten pipes zuordnet und gegebenenfalls zur ck an den Ausgangspunkt der Verarbeitungskette sendet Diese Schleifenbildung wie in Abb 3 5 veranschaulicht bildet aus Sicht des Paketes eine Verkettung von mehreren pipes und damit die verschiedenen Pfadabschnitte mit den jeweiligen Eigenschaften Diese zus tzliche Ebene wird durch den Einsatz einer angepassten Version von ipfw einem Tool zur Konfiguration der FREEBSD Firewall erm glicht Die Pakete werden daher anhand von Firewall Regeln klassifiziert und an bestimmte pipes weitergeleitet Dadurch entstehen jedoch zus tzliche Verarbeitungskosten die im Analyseteil von CR10 weiter untersucht werden t REN Regel 1 Regel 0 DuMMYNET Regel N IPFW Abbildung 3 5 Funktionsprinzip von DUMMYNET mit der Erweiterung durch prw nach CR10 Protokollstapel Der Analyseteil ist zweigetei
167. mentation in Form einer Analyse Software begonnen werden kann muss erst dessen Rahmen mit Hilfe von funktionalen und qualitativen Anforderungen sowie Abgrenzungskriterien abgesteckt werden Diese lassen sich zum einen aus der Aufgabenstellung entnehmen und zum anderen aus den Erl uterungen zu den vorgestellten Analysen in Kapitel 3 gewinnen Letztere bieten eine Vielzahl an Hinweisen zum Versuchsaufbau zu Vorfeldbetrachtungen zur Versuchsdurchf hrung sowie zur Auswertung der Messwerte und zeigen dadurch viele Anforderungen an ein eigenes Messkonzept auf Die genaue Aufschl sselung der Anforderungen geschieht in den folgenden beiden Abschnitten und wird im letzten Abschnitt tabellarisch dargestellt 4 1 Funktionale Anforderungen Die Aufgabenstellung beinhaltet die grundlegenden Anforderungen an das Ergebnis dieser Arbeit Im wesentlichen umfassen diese die Forderung nach 1 einem Verfahren f r Genauigkeitsmessungen der in Abschnitt 2 4 erw hnten Metriken f r die Datenrate Verz gerung sowie die Paketeffekte bei gleichzeitigen Leistungsmessungen f r m glichst viele Hard und Software basierte Emulatoren und dessen Implementation in Form einer Software welche in der Lage ist Messergebnisse f r eine anschlie ende Auswertung zu liefern N Doe wW F r die Bestimmung der funktionalen Anforderungen an das Verfahren sowie dessen Umset zung werden diese verallgemeinert Forderungen anhand der gewonnen Erkenntnisse weiter
168. messenen von den vorgegebenen Werten Die Ergebnisse zur Paketverz gerung zeigen dass NETEM erst ab einer Verz gerung von 50 ms mit einer Genauigkeit von 99 arbeitet Eine Leistungsanalyse entf llt auch in dieser Arbeit Entsprechend werden in Tabelle 3 6 lediglich die Angaben zur m glichen Granularit t gelistet Fazit Die Nachbildung real existierender Verbindungen ist eine M glichkeit die Genauigkeit zu messen Dabei steht nicht nur eine einzelne Effektqualit t im Fokus der Untersuchung son dern es wird eine Kombination aus mehreren betrachtet Als Messwerkzeug kann KPROBES verwendet werden welches transparent gegen ber der Emulation arbeitet Eine andere M g lichkeit ist ein Ende zu Ende Messtool wie QosMET zu verwenden Auch in diesem Fall wird der Emulationsprozess nicht beeinflusst Ein Paketgenerator wie D ITG bietet viele variierende Paketstr me mit unterschiedlichen Paketabst nden und gr en Mit GPS ist man in der Lage eine Uhrensynchronisation durchzuf hren und so pr zisere Messwerte f r die OWD zu erhalten Um den Einfluss des Versuchsaufbaus auf die Emulation abzusch tzen sollte im Vorfeld eines Versuchsdurchlaufs eine Messung der geforderten Werte ohne Emulator durchgef hrt werden Der Messbereich der anschlie enden Untersuchungen sollte m glichst gro gew hlt werden um so den Arbeitsbereich des Emulators bestimmen zu k nnen 3 2 6 WANem Ein Emulator welcher eine besonders einfache Handhabung versprich
169. mit beide Netzwerkkarten ber dieses Bussystem betrieben werden k nnen Auch softwaretechnisch werden die Mehrprozessorarchitekturen dazu benutzt zum einen parallel Messungen und zum anderen parallel Auswertungen durchzuf hren Die verwendeten Algorithmen sowie deren Implementationen werden teilweise dem Messtool NORA entnommen angepasst und sogar verbessert So ist beispielsweise der Paketgenerator in der Lage stabilere und h here Paketraten zu versenden Fehlende Implementationen wie z B die Auswertung von Variationskoeffizienten oder die Visualisierung der Ergebnisse in Form von Diagrammen werden als Erweiterung zugef gt Im zweiten Teil dieses Kapitels werden die Abfolge und die genauen Zahlenwerte der Vorgaben am Emulator sowie der verwendeten Paketgr en abst nde anzahl und Probedauer f r die jeweiligen Untersuchung der Granularit t bzw des Wertebereiches erl utert Eine Zusammen fassung dazu ist in Tabelle 6 4 zu finden Bevor jedoch mit den Messungen begonnen werden kann m ssen zun chst Funktionsnach weise f r Teile der vorgestellten Umsetzung erbracht werden Dazu z hlt beispielsweise der richtige Routenverlauf der Probepakete Die Validierung des vorgestellten Messkonzeptes ist das Thema des n chsten Kapitels 95 7 Validation Die vorgestellten Konzepte bzw Umsetzungen zur Genauigkeits und Leistungsanalyse m ssen vor dem Einsatz auf deren korrekte Funktionsweise gepr ft werden Im Kapitel zur Anforde
170. mulators getrennt von der Grundverz gerung des Versuchsauf baus zu betrachten Eine Uhrensynchronisation entf llt ebenfalls Eine weitere Neuerung im Vergleich zu den anderen vorgestellten Ver ffentlichungen ist die Verwendung der CoTV Metrik um so einen berblick ber die H he der Variation f r verschiedene Mittlungsintervalle zu erhalten 3 3 3 Minhas T und Shaikh J et al 2011 Auch diese Studie stammt von den Autoren Minhas et al und untersucht den Einfluss verschie dener Hardware Umgebungen und Paketgr en auf das Emulationsverhalten Jedoch steht in Min 11 die Untersuchung der Genauigkeit bei der Datenratenbegrenzung durch NETEM und KAUNET im Vordergrund Zus tzlich werden mit Hilfe der gewonnenen Messwerte R ckschl sse auf die Hauptfaktoren bei der Datenratengestaltung des jeweiligen Emulators gezogen Diese Hauptfaktoren sind zum einen die Puffergr e und zum anderen die Paketrate Versuchsaufbau In Min 11 wird der gleiche Aufbau verwendet wie in der zuvor vorgestell ten Arbeit Sha 10 siehe Abb 3 16 In diesem Fall wird die ein sowie ausgehende Datenrate am Emulator ebenfalls f r verschie dene Paketgr en und Hardware Komponenten gemessen Die Emulatoren beschr nken je nach Versuchsdurchgang die Datenrate auf 512 KBit s oder 4000 KBit s 3 4 Zusammenfassung 49 Genauigkeitsanalyse Berechnet werden das Verh ltnis Sp aus der ausgehenden Datenrate Ro und der vorgegebenen Datenrate R Ist der Wert d
171. n berpr ft werden sollen und somit f r jede Variante ein neues Experiment gestartet werden muss Variabel Eine ver nderliche Topologie dagegen kann die verschiedenen Varianten und dar ber hinaus bestimmte Ereignisse nachbilden Dazu z hlen zum Beispiel Verbindungsabbr che 2 4 Effektqualit t Netzwerkmetriken 11 oder das im Mobilfunk relevante Handover beim Wechseln der Funkzelle Dadurch gestattet diese Art der Pfadvorgabe die beste Nachbildung von realen Netzwerken Implizite Pfadvorgaben entsprechen am ehesten realen Umgebungen k nnen jedoch kontrolliert Ausnahmesituationen ausl sen Im Vergleich zu expliziten Vorgaben sind diese abstrakt gehal ten und erlauben so eine einfachere Umsetzung von komplexen Netzwerkstrukturen Bei den expliziten Vorgaben werden dagegen im Vorfeld Annahmen ber das Pfadverhalten getroffen bzw es wird auf eine realit tsnahe Testumgebung verzichtet und nur bestimmte Effekte stehen im Fokus der Untersuchung 2 4 Effektqualit t Netzwerkmetriken In einer vorangegangenen Arbeit B s13 wurde ein Messtool zur Analyse von Ende zu Ende Ver bindungen entwickelt Die folgenden Erl uterungen und Abbildungen zu den Netzwerkmetriken stammen in abgewandelter Form aus dieser Arbeit Die Werte von Netzwerkmetriken geben Auskunft ber die Eigenschaft eines Verbindungspfa des und repr sentieren die Einfl sse auf die betrachteten Datenpakete Ein Verbindungspfad P besteht dabei aus i 1 bis H Teilabschnitten
172. n 0 01 die Anzahlen der Paketeffekte zwischen 0 und 0 08 vgl Abb 8 11 Die Mittelwerte liegen dabei bei 0 02 und somit innerhalb des vorher definierten Toleranzbereichs 8 2 Messungen 113 Vorgabe 31 00 PPS 50 0 KPkt s Anzahl gemessener Effekte 64 512 1024 1500 Paketlange in Byte Abbildung 8 10 Erfasste Paketneuordnungen als Box Diagramme fiir die verschiedenen Paket langen und raten bei einem einzelnen Pfadabschnitt Fazit Aus den Ergebnissen l sst sich zusammenfassen dass deterministische Vorgaben den Vorteil haben nicht von bestimmten Betrachtungszeitr umen und Probeanzahlen abh ngig zu sein So stimmen die emulierten Paketverluste und neuordnungen bei KAUNET zu 100 mit den Vorgaben berein F r geringe Vorgabewerte liegen auch die anderen Emulatoren bei allen drei Paketeffekten innerhalb des Toleranzbereichs Dies ndert sich jedoch f r steigende Vorgaben bei der Paketneuordnung da die Zufallsgeneratoren diesen Effekte zeitgetrieben steuern Ein zu hohe Rate sorgt f r zu viele Neuordnungen wohingegen eine zu niedrige f r zu wenige Paketeffekte sorgt Abh ngigkeiten von der Paketgr e konnten nicht festgestellt werden 114 8 Durchf hrung Abbildung 8 11 Vorgabe 0 01 PPS 50 0 KPkt s ker voy vi H Linktropy Anzahl gemessener Effekte o D OLUIIDNOO DDOPOIIDNOO DWDPOIDNKDO Paketl nge in Byte Erfasste Paketdopplung
173. n Eigenschaften e jcc cd ee ea dead BE Ped eo yon Abb 2 3 Kategorie Funktionsweise mit den f nf zugeh rigen Unterkategorien Abb 2 4 Pfad P mit den Teilabschnitten von i 1 bis i H Quelle B s13 Abb 2 5 Kategorie Effektqualitat mit den verwendeten Metriken Abb 2 6 P mit H 3 und C C Quelle Biis13 2222 Abb 2 7 Definition der verschiedenen Raten Quelle Biis13 Abb 2 8 Schema der Verz gerungsphasen bei OWD Quelle B s13 Abb 2 9 Verzogerungsvariationen Quelle Biis13 Abb 2 10 Kategorie Skalierbarkeit und deren Einflussfaktoren Abb 3 1 Analyse der Suchanfragen zwischen 2004 und 2013 f r bekannte Emulatoren Quelles EI 246 2 na dtawe dw Era Abb 3 2 Anzahl der Zitationen f r ausgew hlter Emulatoren Quelle 13e Abb 3 3 Weboberflache des Linktropy 7500 pro Hardware Emulators Abb 3 4 Funktionsprinzip von DuMMyNET nach Riz97 Abb 3 5 Funktionsprinzip von DUMMYNET mit der Erweiterung durch prw nach RIO eet oe oe ee d ok eee en bee a ee e Abb 3 6 Oben die typische Messung der Paketrate durch die gesamte Paketver arbeitung des Betriebssystems Unten die verwendete Messmethode um die Paketklassifikation und Emulation gesondert betrachten zu k nnen Quelle ERI bw au Ged A e ai ah oid ee gue A A aad Abb 3 7 a Zeit und b datengesteuerte Auswahl bestimmter Pakete durch
174. n oder die Vorgabe den Wert 200 kBit s annimmt Grundlage f r die jeweilige Messung sind einzelne Probedurchl ufe mit der Dauer von 10s Im Gesamtpfad erh lt immer nur ein Abschnitt die aktuelle Vorgabe alle anderen haben keine Beschr nkung bzw einen Wert der gr er als die MLFFR des Versuchsaufbaus ist Dadurch wird ber cksichtigt dass der Pfadabschnitt mit dem minimalen Vorgabewert die Gesamtrate bestimmt vgl Abschnitt 2 4 1 Die Positionierung dieses Abschnittes erfolgt vom Sender aus gesehen am Anfang der hinteren H lfte des Pfades Datenraten Wertebereich Der Untersuchungsbereich wird durch die MLFFR des Versuchsaufbaus beschr nkt D h auch wenn der Emulator h here Datenraten unterst tzt kann dies nicht durch diesen Aufbau gemes sen werden Vielmehr werden Abweichungen und die Wertstabilit t von einzelnen emulierten Datenratenbeschr nkungen mit Hilfe der vorgestellten Stromeigenschaften untersucht Die Vorgabewerte orientieren sich an der maximalen Datenrate von den bekannten Netzwerkzu gangstechnologien HSDPA WLAN 802 11g ADSL ANSI T1 413 und Kabel DOCSIS 3 0 daher 7 2 MBit s 54 MBit s 61 MBit s und 160 MBit s Das Ergebnis dieser Untersuchungen sind die Werte alle Statistiken FA 1 bis FA 7 f r jede Vorgabe und Stromeigenschaft wobei ungewollte Paketeffekte ber cksichtigt werden 6 3 Zusammenfassung Der hier vorgestellte Versuchsaufbau enth lt Hardware Komponenten welche das gleichzeiti ge Ver
175. n sind in Tabelle 3 1 zusammengefasst 3 2 2 DummyNet Die erste wissenschaftliche Publikation zu DUMMYNET stammt aus dem Jahr 1997 Riz97 Rizzo L beschreibt darin wie mit weniger als 300 Zeilen Quellkode der Kernel von FREEBSD dahingehend angepasst werden kann dass Pakete zwischen der IP und der TCP Verarbeitungsschicht verz gert verworfen oder neu geordnet werden k nnen Dazu werden im Protokollstapel zwischen den betreffenden Schichten zus tzliche Warteschlangen mit speziellen Abarbeitungsstrategien in Riz97 als routers bezeichnet und Kommunikationsschnittstellen als pipes bezeichnet mit einer definierten Verz gerung sowie Datenrate engl Bits Per Second BPS implementiert In Abbildung 3 4 ist dieser Aufbau dargestellt Die Pakete gelangen zun chst in die routers welche eine begrenzte Anzahl an Paketen aufneh men k nnen und die Abarbeitungsstrategien standardm ig First In First Out FIFO anwenden 3 2 Produktpublikationen und dokumentationen 27 Effektqualitat Angaben ee C 300 Bit s 1GBit s je Richtung CT 0 100 in 0 1 Schritten PLR ka Pakete 9 0 100 in 0 0001 Schritten S PRR amp BER Verz gerungen nn 0 ms 10 sin 0 1 ms Schritten Leistung Paketrate 3MPkt s Tabelle 3 1 Angaben zur einstellbaren Granularit t und Leistung des Linktropy 7500 pro TCP routerl pipel pP pipe2 router2 Protokollstapel DUMMYNET Abbil
176. nauigkeit der eingestellten Parameter z B Paketverz gerung und verlust erforderlich um eine Reproduzierbarkeit dieser Experimente zu gew hrleisten Sollen gro e Szenarien nachgebildet werden spielt auch die Leistung des Emulators eine wichtige Rolle Das Ziel dieser Arbeit ist es existierende und momentan in Forschung und Industrie eingesetzte Netzwerkemulatoren hinsichtlich dieser beiden Eigenschaften Genauigkeit und Performance eingehend zu untersuchen Dazu sollen die an die Genauigkeits und Leistungsmessungen gestellten Anforderungen ermittelt werden Weiterhin soll ein entsprechendes Messkonzept entworfen implementiert und evaluiert werden Daraufhin sollen die Genauigkeits und Leistungsmessungen mithilfe des entwickelten Messkonzepts f r m glichst viele der existierenden Netzwerkemulatoren durchgef hrt werden Dabei sollen neben Software basierten Netzwerkemulatoren f r verschiedene Betriebssysteme Windows Unix FreeBSD auch Hardware basierte L sungen analysiert werden Letztlich sollen die Ergebnisse der Messungen entsprechend ausgewertet werden SCHWERPUNKTE Grundlagen der Netzwerkemulation Einsatz Funktionsweise Verwandte Arbeiten berblick existierender Software und Hardware basierter L sungen Analyse der Anforderungen an Genauigkeits und Leistungsmessungen Entwurf Implementierung und Evaluierung eines Messkonzeptes Durchf hrung der Genauigkeits und Leistungsmessungen mit m glichst vielen
177. nd berechnet sich die BPS mit Hilfe der folgenden Gleichung p Sr by BPS ZI 5 2 tend tstart Wobei L der gemessenen Paketgr e des Paketes j in Byte entspricht statistische Werte Die Berechnungen der Statistiken erfolgt nach jedem Probedurchlauf auf Grundlage der Metrikwerte welche mit Hilfe der zuvor genannten Verfahren ermittelt wurden 5 2 Vorgehensweise 79 Die einzelnen Ergebnisse eines Durchlaufs bilden wiederum die Berechnungsgrundlage f r die statistischen Werte des Probestromes Die Minima und Maxima aus einer Menge von Metrikwerten beispielsweise werden zu n chst f r alle Probedurchl ufe ermittelt und in einer Liste gespeichert Anschlie end werden aus dieser Liste der Gesamt Maximalwert der Maxima bzw Gesamt Minimalwert der Minima des Probestromes gewonnen Metrik _ PR Probestrom Durchlauf 1X1 xi sf el i E f max bzw min Wobei N der Anzahl der Probedurchl ufe und i bzw k der Anzahl der ermittelten Werte einer bestimmten Metrik entsprechen Auf diese Weise ist es m glich den Wertebereich f r einzelne Metriken bzw die gr tm gliche absolute Abweichung von einer Vorgabe zu bestimmen Der Gesamt Durchschnitt eines bestimmten Wertes in Bezug auf einen Probestrom ist dage gen das arithmetische Mittel ber alle Einzel Durchschnitte der Probedurchl ufe Als Gleichung N k De zu K Dipvrehlauf j mit Dat K Wert j l I 1 Diese Aufspaltung in einzelne Durchschnitte g
178. nden daf r neben physischen auch in virtuellen und hybriden Versuchsumgebungen statt Unter anderem werden in drei Experimenten Analysen zur erreichbaren Durchgangsrate und zur Genauigkeit der Paketverz gerung bei unterschiedlichen Auslastungen durchgef hrt Bevor im Einzelnen auf die Analysen eingegangen wird soll kurz die Messmethode erl utert werden Messmethode Die Werte f r die Analysen werden wie in Abbildung 3 9 dargestellt an vier verschiedenen Stellen gemessen Speziell f r die Durchgangswerte werden die Datenpakete direkt am Eingang II und Ausgang III des Emulators erfasst VM L Messpunkte et in KauNer mp iv Re T o T 7 Virtuelle Umgebun g physische Umgebung virtuelle Umgebung hybride Umgebung Abbildung 3 9 Die drei Versuchsumgebungen fiir die Analysen von KAUNET F r die Erfassung der Werte wird das Werkzeug TCpDUMP 12 verwendet Ein anderes Tool namens MGEN 130 dient in den Experimenten als Paketgenerator Um die Einfl sse durch das Werkzeug zu verringern verwenden Hall et al virtuelle Datentr ger sogenannte Ramdrives zur Speicherung der erfassten Paketdaten F r die virtuelle Umgebung werden zwei verschiedene Testsysteme benutzt Zum einen wird ein Arbeitsplatzrechner und zum anderen ein Serversystem mit wesentlich mehr Leistung verwendet Leistungsanalyse F r den Nachweis der Leistungsf higkeit von KAUNET werden in Hal 12
179. ndover von einer Funkzelle in die andere statt Je nach Implementation kann es dabei zu einem kurzzeitigen Verbindungsabbruch Hard Handover oder einer Parallelverbindung Soft Handover kommen Bei letzteren verbindet sich das Mobilfunkger t zuerst mit der neue Zelle und bricht dann die Verbindung zur alten Zelle ab Beim Hard Handover dagegen beendet das Ger t zuerst die Verbindung zur alten Zelle und verbindet sich danach mit der Neuen Unterbrechungen Einige Emulatoren gestatten eine kontrollierte Unterbrechung einer Ver bindung um das Verhalten von Protokollen und verteilten Anwendungen bei Verbindungsabbr chen untersuchen zu k nnen So kann z B das zuvor beschriebene Hard Handover nachgebildet werden Nach NK11 k nnen Unterbrechungen weiter unterschieden werden in e Abbruch nach einer bestimmten Leerlaufzeit engl Idle timer disconnection e Zuf lliger Abbruch Zuf lliger Auf und Abbau der Verbindung 18 2 Nachbildung von Netzwerkverhalten 2 5 Skalierbarkeit Testumgebungen ben tigen oft die Emulation einer hohen Anzahl an Endsystemen und Netz werkknoten Emulatoren nutzen dazu allgemein die Tatsache aus dass die zu untersuchenden Protokolle oder Anwendungen zumeist nur einen geringen Anteil der Betriebsmittel eines Rechners ben tigen Es verschafft diesen die M glichkeit die vorhandenen Mittel aufzuteilen und auf einem einzelnen Kr mehrere Emulationseinheiten zu starten Dieser Umstand f hrt zum Begriff
180. nitten Vorgabe 10 ms dabei sogar Pfadverkettungen Der untersuchte Maximalwert von 1000 ms wurde ebenfalls bei allen Emulatoren mit positiven Ergebnis gemessen 8 2 3 Paketeffekte Verlust KAUNET emuliert aufgrund seiner deterministischen Paketauswahl die stabilsten Werte und die exakte Anzahl an Paketverlusten bzw neuordnungen Zur Gegen berstellung sind in Abbildung 8 7 die Messergebnisse des Hardware Emulators und von KAUNET bei einer Vorgabe von 0 001 Verlust zu sehen W hrend beim Hardware Emulator noch deutliche Abweichungen 40 PPS 50 0 KPkt s PPS 8 3 KPkt s PPS 1 0 KPkt s 1 06 PPS 50 0 KPkt s PPS 8 3 KPkt s PPS 1 0 KPkt s d T T T H i i i ED d i i 104 A i i A 8 3 0 ee aa kr i 8 2 i i i i i g 1 02 B25 a ae aaa i 2 i i i i i i d E 220 nt ee hm 100 te De en be bet a i i i i i i a Suel 1 a ger i 4 DIRK i DI 8 0 98 8 i i i T H i g 1 0 i i i i E 3 TE E go 5 i i i 0 96 0 5 Loi J i i i i i i i i i i 7 t i t 0 0 i i 1 H fi 1 li 1 0 94 i i i i i i 64 512 1024 1500 64 512 1024 1500 64 512 1024 1500 64 512 1024 1500 64 512 1024 1500 64 512 1024 1500 Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte a Linktropy b KauNet Abbildung 8 7 Auszug aus den Messergebn
181. nnen sollten bereits im Vorfeld der Testabl ufe Genauigkeits und Leis tungsanalysen der verwendeten Netzwerkemulatoren durchgef hrt werden Die Entwickler der einzelnen Emulatoren bieten zumeist solche Analysen f r ihr Produkt an jedoch unterscheiden sich diese Messverfahren untereinander und deren Ergebnisse werden nur auf bestimmte Nachweise ausgerichtet Vergleiche mit anderen Emulatoren werden selten beschrieben oder komplett weggelassen 2 1 Einf hrung 1 1 Motivation Die Motivation zu dieser Arbeit ergibt sich daraus ein einheitliches Messverfahren zu schaf fen welches die M glichkeit bietet Genauigkeits sowie Leistungsanalysen automatisiert f r m glichst viele Emulatoren durchzuf hren Dadurch ergeben sich Vergleichsm glichkeiten zwi schen den verschieden Netzwerkemulatoren und die Eignung des jeweiligen Emulators kann f r vordefinierte Testszenarien festgestellt werden Die Genauigkeitsanalyse bezieht sich auf die eingestellten Netzwerkparameter welche im Abschnitt 2 4 kurz umrissen werden Die Messverfahren dazu bauen auf einer vorhergehen den Arbeit B s13 auf in welcher ein integriertes Netzwerkanalysewerkzeug namens NORA entwickelt wurde Die Leistungsanalyse betrachtet zum einen den Funktionsumfang und zum anderen die m gli che Belastbarkeit sowie Skalierbarkeit des jeweiligen Emulators Die genaue Aufschl sslung der Teilbereiche ist in Kapitel 4 zur Anforderungsanalyse zu finden 1 2 Aufgabenstellung
182. nsatz des eigenen Versuchsaufbaus 62 Abb 5 2 Angepasster Ansatz des eigenen Versuchsaufbaus mit zwei Messpunkten 63 Abb 5 3 Hardware technischer Versuchsaufbau mit zusammengelegtem Sender und Empfangen oce reres ea Dees das owe OSE VEE ew ee 64 Abb 5 4 Softwaretechnischer Versuchsaufbau 0 65 Abb 5 5 Einteilung der Versuchsparameter in Probestr me und zugeh rige Probe E EE Oe TERE RGAE OEE RE RS EES RD ER G 66 Abb 5 6 Sequenzdiagramm der Versuchssteuerung bzgl der Startreihenfolge der verschiedenen Grundkomponenten 000008 67 Abb 5 7 Die Paketgenerierung in der vorangegangenen Arbeit B s13 68 Abb 5 8 Die verbesserte Paketgenerierung in dieser Arbeit 2 2 2 69 Abb 5 9 Allgemeines Schema der Parameterverkn pfungen f r die Messungen 73 Abb 5 10 Beispiel f r die Analyse von Paketverlusten und dopplungen 76 Abb 5 11 Pseudocode Bestimmung der Anzahl und Paketnummern von neu geordne ten Paketen sto hee enw MRSS ea aka 77 Abb 5 12 Beispiel f r das Vorgehen und die Berechnung der einzelnen OWD Werte 78 Abb 5 13 Beispiel f r die Ermittlung des Median einer Liste mit gerader Anzahl an EE EE EE ra Re aaa ak La 80 Abb 5 14 Schematischer Verlauf von links rechtsschiefen sowie symmetrischen Ver teilungen Oben PDF Unten CDF 2s 444 254 EEN 4504 4 444 043 80 Abb 5 15 Berechnung der Durchschnittlichen AOWD f r das jeweilige Zeit
183. nstellungsm glichkeiten bzgl der Verteilungsart bzw Wahrscheinlichkeit von z B Paketeffekten oder Verz gerungen F r eine Gegen berstellung der Gemessenen und der vorgegebenen Verteilung k nnen daher die drei sta tistischen Lageparameter xp xo 5 und der Durchschnitt verwendet werden Die Zusammenh nge sind in Abbildung 5 14 in den Graphen der jeweiligen PDF zu sehen Sind alle Lageparameter ann hernd gleich gro so besteht die M glichkeit dass die gemessenen Werte einer Normal verteilung unterliegen Der Graph der CDF eignet sich erg nzend zur PDF besonders um den Grad der Streuung bzw Abweichung abzulesen Je steiler der Graph ist desto konzentrierter liegen Werte vor 5 2 Vorgehensweise 81 AOWDJ Liste in ms Senderseite 2 3 2 2 3 3 2 2 2 2 Empfangerseite 3 2 2 3 40 1 5 2 2 3 Tabelle 5 2 Beispielwerte f r die Betrachtung der Wertstabilit t mit Hilfe von CoDVwBMA Der Variationskoeffizient engl Coefficient of Variation CoV stellt eine Vergleichsm glich keit zwischen Versuchen mit unterschiedlichen Vorgaben wie der Verz gerungsdauer dar Aber auch innerhalb eines Probedurchlaufes k nnen mit Hilfe des CoV verschieden gro e Betrach tungsintervalle miteinander verglichen werden um so z B die Wertstabilit t oder Streuung innerhalb verschiedener Zeitspannen betrachten zu k nnen Der Variationskoeffizient ist das Verh ltnis aus dem Durchschnitt und der Standardabweichung Cave 2
184. ntyp der Variable welche den Wert der Beschr nkung aufnimmt Bei der Eingabe von Datenraten gr er als 65535 KBit s findet ein berlauf statt und die Ein schr nkungen beginnen wieder bei 1 KBit s Somit liegt der obere Wertebereich f r KAUNET bereits bei 65535 KBit s Gleichzeitig werden die Auswirkungen einer geringeren Puffergr e deutlich F r die einzelnen Vorgabewerte reicht die Vorhaltekapazit t bei beiden Software Emulatoren nicht aus und es werden Pakete verworfen Der Hardware Emulator dagegen speichert alle ankommenden Pakete und vergr ert deren zeitlichen Abstand Offenbar gibt es f r die Ratenbeschr nkung zwei Ans tze Entweder wird die Rate durch Paketverluste oder aber durch Verz gerungen erwirkt Die Genauigkeit der Umsetzung zur Ratenbeschr nkung sinkt mit steigender Proberate und damit Last am Emulator In Abbildung 8 4 werden die Ergebnisse f r sinkende PPS und verschie dene Paketgr en dargestellt Bereits ab einer PPS von 50 KPkt s fallen die Abweichungen bis auf wenige Prozent Lediglich bei einer Paketgr e von 64 Byte sind noch starke Abweichungen zu erkennen Der Grund liegt in der n tigen Verarbeitungsgeschwindigkeit pro Paket Viele kleine Pakete bedeuten mehr Verwaltungs bzw Behandlungsroutinen als wenige gro e Dennoch treten auch f r diesen Raten bei den Software Emulatoren ungewollte Paketverluste auf F r den m glichen Wertebereich bedeutet dies dass neben einem Toleranzwert f r die Abweichung
185. of Trn and Pckt will increase until duration is reached If the duration of Strm_dur is 0 then it will be ignored and the given trn_nr or pkt_nr is used A Measurement can be one of the following type Type Static S Strm_seq_nr Strm_gap Strm_dur Trn_nr Trn_gap Trn_dur Pckt_nr Pckt_gap has to be given explicitly PPS or bps will ignored Static Extended E Pckt_gap and Pckt_size can be given as a list Packetrate per Train P Strm_gap Strm_dur Trn_nr Trn_gap Trn_dur min_PPS max_PPS step_PPS has to be given explicitly Rest will be ignored Bitrate per Train B Strm_gap Strm_dur Trn_nr Trn_gap Trn_dur min_bps max_bps step_bps has to be given explicitly Rest will be ignored Meas Type Ten dur Pckt_nr Pckt_gap Pckt_size min_PPS max_PPS E 5 5 WEE KS Beete OR e 10 64 r HE euss 2 EA Ee bake se 10 5 j y 64H 3125 1500 po NEE 22 Eir Ppt p00 e D K x T2031201 Les 3127 15001 a ksta ER Pea in BOOUO e pii y 1512 e 200 8 e TOC Re 2 kas 5 B 1000 ro aes 512 ro ro e or in a shorter notation Note columns with will not needed The type gives the hint if the Measure number is duplicated the last configuration row will be used 3 S UDP 3 5 300 10 10 1 100 5 1500 4 P UDP 4 1 10 200 1 150 100 150 K 50 k 5 B UDP 5 0 10 200 1 1000 1 M 2M IM A 4 Vorfelduntersuchungen Grundverz gerungen 123 A 4 Vorfelduntersuchungen Grundverz
186. ommunications and Mobile Computing Conference ACM 2010 S 336 340 siehe S 46 81 Mitts DL RFC 1305 Network time protocol In Specification Implementation and Analysis 1992 siehe S 63 Minuas Tahir Nawaz et al Evaluation of throughput performance of traffic shapers In Wireless Communications and Mobile Computing Conference IWCMC 2011 7th International IEEE 2011 S 1596 1600 siehe S 44 48 70 NAPOLI University of Flyer2 D ITG Distributed Internet Traffic Generator In 2008 siehe S 68 NAMBIAR Manoj et al Design of a new algorithm for WAN disconnection emulation and implementing it in WANem In Proceedings of the International Conference amp Workshop on Emerging Trends in Technology ACM 2011 S 376 381 siehe S 17 39 B 10 Quellenverzeichnis 131 NRO09 PM06 PPMos Riz97 Sha 10 SU03 Tec11 Tec13 Uni12 Yoc 02 ZM04 NUSSBAUM Lucas et al A comparative study of network link emulators In Procee dings of the 2009 Spring Simulation Multiconference Society for Computer Simulation International 2009 S 85 siehe S 5 44 46 50 61 Puzj z Zrinka et al IMUNES based distributed network emulator In Software in Telecommunications and Computer Networks 2006 SoftCOM 2006 International Conference on IEEE 2006 S 198 203 siehe S 39 40 Puzj z Zrinka et al Performance analysis of a decentralized network simulator based on IMUNES In
187. on Der fertigen Implementation muss eine Dokumentation beliegen welche die Handhabung des Programmes und dessen Ausgaben erkl rt 58 4 Anforderungsanalyse qualitative Anforderung Bezeichnung g Routenverlauf Sender Emulator Empfanger QN 1 genaue und stabile Paketgenerierung QN 2 E korrekte Paketerfassung QN 3 S Behandlung v Fehlkonfigurationen QN 4 einfache Installation freie Bibliotheken QF 1 Hardwareunabh ngig QF 2 3 gleichbleibender Testaufbau QF 3 E Dokumentation QF 4 Integration vorhandener Tools QF 5 Tabelle 4 2 bersicht qualitative Anforderungen 4 3 Abgrenzungskriterien Einige der in Abschnitt 2 4 erw hnten Effektqualit ten werden von der Umsetzung nicht abge deckt Dazu geh ren die Mobilfunkeffekte und die Bitfehlerrate Nicht korrigierbare Bitfehler u ern sich auf Paketebene als Verlust Daher sind diese Fehler nur indirekt ber die PLR zu ermitteln Von den untersuchten Emulatoren beherrscht lediglich WANEm Mobilfunkeffekte Die von WANEM unterst tzten Effekte beschr nken sich zudem auf Unterbrechungen Daher wird auf die Untersuchung der Mobilfunkeffekte verzichtet Weiterhin k nnen im Rahmen dieser Arbeit nicht alle vorgestellten Emulatoren analysiert werden Dazu z hlen die Emulatoren MopELNET und NETPATH Beide setzten Betriebssysteme voraus welche bereits mehrere Jahre alt sind und entsprechend alte Hardware fordern die wiederum nicht zur Verf gung stehen Ebenso k nnen ni
188. ply seq 127 32512 15 10 0 0 2 10 0 0 5 Echo ping request seq 128 32768 16 10 0 0 5 10 0 0 2 Echo ping reply seq 128 32768 17 10 0 0 2 10 0 0 5 Echo ping request seq 129 33024 18 10 0 0 5 10 0 0 2 Echo ping reply seq 129 33024 19 10 0 0 2 10 0 0 5 Echo ping request seq 130 33280 20 10008 10 0 0 2 Echo ping reply seq 130 33280 21 10 0 0 2 10 0 0 6 Echo ping request seq 131 33536 22 10 0 0 6 10 0 0 2 Echo ping reply seq 131 33536 23 10002 10 0 0 6 Echo ping request seq 132 33792 24 10 0 0 6 10 0 0 2 Echo ping reply seq 132 33792 25 10 0 0 2 10 0 0 6 Echo ping request seq 133 34048 26 10 0 0 6 10 0 0 2 Echo ping reply seq 133 34048 27 10002 10 0 0 6 Echo ping request seq 134 34304 28 10 0 0 6 10 0 0 2 Echo ping reply seq 134 34304 29 10 0 0 2 10 0 0 6 Echo ping request seq 135 34560 20 10006 10 0 0 2 Echo ping reply seq 135 34560 Tabelle 7 1 Ausgabe von Wireshark f r den Nachweis der Funktionalit t des Versuchsaufbaus wird dabei auf 10000 festgelegt Ein abschlie ender Test mit aufsteigenden Datenraten soll die Belastungsgrenze des Paketgenerators f r jede Stromeigenschaft aufzeigen Gleichzeit zum Funktionstest der Paketgenerierung wird die Erfassung der ausgehenden und eingehenden Pakete gepr ft Dazu wird das Netzwerktool WIRESHARK eingesetzt Gemessen werden mit diesem die Paketgr e und die einzelnen Paketabst nde der aus sowie eingehenden Pakete Abschlie end werden die Ergebnisse aus den Messungen m
189. r Genauigkeit bei der Umsetzung von verschiedenen vorgegebenen Datenraten f r einen einzelnen Pfadabschnitt Die Paketgr e betr gt bei allen Darstellungen 512 Byte Abb 8 4 Relative Abweichungen der gemessenen Datenraten bei unterschiedlichen Stromeigenschaften und einem einzelnen Pfadabschnitt Die vermeidlich fehlen den Balken in der Abbildung kommen dadurch zustande dass mit der jeweiligen Kombination von Paketgr e sowie abstand nicht die geforderte Datenrate er reicht wird Vorgabe 7200 KBit s 2 2 ss 220 su a Abb 8 5 Auszug aus den berechneten CoDVwBMA Werten zur Ermittlung der Wert stabilit t des jeweiligen Emulators w hrend der Messung der Verz gerungen Vorgabe TMS ps neaga Be ew ek ai Gls PERSE BEE ar DAR A Abb 8 6 Gemessene Verz gerungen mit dem Emulator Dummyner als Box Diagramm f r die verschiedenen Paketl ngen und raten bei 10 Pfadabschnitten Vorgabe TOMS rn era ar ra Va ren Be ne ns Abb 8 7 Auszug aus den Messergebnissen zur Betrachtung der Genauigkeit bei der Umsetzung von 0 001 Paketverlust f r einen einzelnen Pfadabschnitt Die Box Diagramme von KAUNET erscheinen wegen der fehlenden Abweichung als einzelne Striche mit einem Stern Durchschnittswert in der Mitte Abb 8 8 Erfasste Paketverluste als Box Diagramme f r die verschiedenen Paket l ngen und raten bei einem einzelnen Pfadabschnitt Auch hier erscheinen die Box Diagramme von KAUNET wegen der fehlenden Abweichung als einzelne S
190. r verschoben bis der erwartete Wert mit dem Gemessenen bereinstimmt w hrend Lerw festgehalten wird Gleichzeitig wird gez hlt wie oft Lgem verschoben wird Bei einem Paketverlust wird L m festgehalten und stattdessen wird Lerw verschoben Dieses Mal werden die erwarteten Paketnummer gespeichert um welche Lerw f r die bereinstimmung verschoben werden muss In Abbildung 5 10 ist ein Beispiel dazu gegeben bei dem zun chst ein einfacher Paketverlust dann zwei Dopplungen und anschlie end ein weiterer Verlust erkannt werden Im Beispiel werden die Paketnummern Lerw 1 2 3 4 6 erwartet Zu Beachten ist dass Lery das f nfte Paket nicht enth lt Das kann passieren wenn beispielsweise Lerw der gesendeten Paketliste entspricht und das f nfte Paket beim Sender verworfen wurde Gemessen werden die Paketnummern Lgem 2 2 2 3 4 Daher fehlen die Pakete 1 6 und das zweite Paket wurde zweimal verdoppelt Entsprechend wird im ersten Schritt 76 5 Konzeption akt Position Ber 1 2 314 6 1 213 4 6 1 2 3 4 6 1 2 3 14 6 Lgem 2 212 3l4 22 2 34 212121314 42 21213 4 Vergleich 1 lt 2 3 gt 2 3 gt 2 Verluste 1 1 vee u Anzahl 1 Paketnummer D Dopplungen a2 1 2 2 Lerw EIER
191. rachtenden Emulatoren asymmetrische Topologien nachbilden Daher sollte der eigene Versuchsaufbau eine Synchronisation der Zeitgeber ber cksichtigen Dies kann beispielsweise durch einen zus tzli chen Network Time Protocol NTP Server entweder eigenst ndig oder als Dienst auf einem der Versuchsrechner bewerkstelligt werden Um nicht den Probeverkehr zu unterbrechen k nnte eine zus tzliche Direktverbindung zwischen dem Sender und Empf nger ber zwei weitere Netzwerkkarten erstellt werden Dennoch entstehen auch in diesem Aufbau Abweichungen zwischen den beiden Stationen da jede NTP Aktualisierung einem Verarbeitungs Offset und einem Anfrage Antwort Umlauf unterliegen Letzterer kann zwar durch die direkte Verbindung vernachl ssigt werden der Offset jedoch sorgt f r variierende Abweichungen im Mikro bis Millisekundenbereich Im RFC Mil92 S 100 sind entsprechende Formeln und Erkl rungen zu finden Die L sung f r dieses Problem ist die Zusammenlegung von Sender und Empf nger auf einem einzelnen Rechner Dadurch teilen sich beide Rollen den selben Zeitgeber und arbeiten somit synchron Der bisherige Versuchsaufbau in Abb 5 2 wird endg ltig angepasst und ist schematisch in Abb 5 3 zu sehen Der Sender und der Empf nger erhalten dabei jeweils eine eigene Netzwerkkarte um zum einen die beiden Verbindungskabel des Emulators aufzunehmen und so auf Hardwareebene zwei eigenst ndige Subnetze erstellen zu k nnen und zum anderen eine gegens
192. rate sind zumeist auf den Paketgenerator MGEN zu r ckzuf hren da dieser teilweise nicht die geforderte Rate liefert Daher werden diesbez gliche Auswertungen als Verh ltnis zwischen empfangener und der tats chlich gesendeten Datenrate angegeben F r die Betrachtungen mit zunehmender Belastung wird die Verlustrate ber der geforderten Datenrate ausgewertet So zeigt sich die berlast von KAUNET ab einer bestimmten Datenrate und Anzahl an pipes Genauigkeitsanalyse Die Genauigkeitsbetrachtungen konzentrieren sich auf die Untersu chung der Paketverz gerung bei unterschiedlichen Belastungsstufen Die pipes werden so konfi guriert dass die Datenrate unbeschr nkt bleibt und nur bestimmte Verz gerungen auftreten Dabei wird die Durchgangsverz gerung in einem ersten Experiment f r ansteigende Datenra ten mit einer festgelegten Verz gerung gemessen Das erste Experiment besteht aus mehreren Durchl ufen die auf unterschiedlich festgelegten Verz gerungen basieren In einem weiteren Versuch steigt dagegen die Verz gerung und die generierte Datenrate wird mit kleinen Paketen sowie einer geringen Paketrate konstant gehalten Dadurch sollen alle Einflussfaktoren bis auf die geforderte Verz gerung minimiert werden Auch in den Analysen zur Genauigkeit zeigt sich dass die Messergebnisse innerhalb der virtuelle Umgebungen hinter den erwarteten Werten liegen So ist die Streuung der unterschied lichen Verz gerungen deutlich gr er als bei den
193. rden Sendefunktionen innerhalb des Betriebssystemkerns genutzt und auf Sockets innerhalb der Anwendungsebene verzichtet Der Nachteil dabei ist der h here Aufwand bei der Paketgeneration da die Pakete im Rohformat als Byte Sequenz bergeben werden m ssen Dem Gegen ber werden dadurch Verarbeitungsschritte eingespart vgl Abschnitt 5 4 Paketgenerator und es wird eine h here Paketrate erreicht Die Pakete werden zun chst mit einer Sequenznummer der Nummer des Probedurchlaufes sowie des Probe stroms versehen und mit zuf lligen Symbolen bis zur vorgegebenen Paketgr e aufgef llt Jedes generierte Paket wird zusammen mit einem Sendezeitpunkt ebenfalls mit Hilfe der WinPcap Bibliothek in einem Puffer gespeichert welcher vor dem Sendevorgang in den Kernelbereich geladen wird W hrend des Sendevorgangs werden die Sendezeitpunkte mittels aktivem War ten engl Busy Wait durchgesetzt Dieses sorgt f r eine erh hte Prozessorlast welche jedoch insgesamt wegen der Leistungsf higkeit des Messrechners nicht ins Gewicht f llt Analyse Berechnung Die Messergebnisse werden nach jedem Probedurchlauf in einer neuen Datei im csv Format gespeichert Diese umfassen die Paketnummern und Zeitstempel der erfassten Pakete Nach der Messung aller Probestr me eines Versuches beginnt die Analyse und Berechnung der Metrikwerte auf Grundlage dieser Messergebnisse Die Werte der Metriken wiederum bilden die Basis f r die Statistiken Viele der verw
194. rgebnissen bekannt gemacht 5 2 2 Messungen Nach den Voruntersuchungen beginnt die zweite Phase die eigentliche Messung Diese liefert die gesuchten Werte bez glich der Genauigkeit und Leistungsf higkeit 72 5 Konzeption Allgemeine Durchf hrung Die allgemeine Vorgehensweise ist dabei den Emulator mit bestimmten Vorgaben aus den Bereichen 1 Paketeffekte 2 Verz gerungen 3 Datenraten zu konfigurieren und Probestr me mit unterschiedlichen Eigenschaften bez glich a der Paketgr e b des Paketabstandes c der Paketanzahl vom Sender ber den Emulator an den Empf nger zu versenden Gemessen werden die Paketnum mer und der Zeitstempel jedes gesendeten sowie empfangenen Paketes Aus den Messwerten sollen in der anschlie enden Auswertung Wertebereiche Aufl sungen Abweichungen und Wertstabilit ten ermittelt werden Besitzt der Emulator au erdem die M glichkeit mehrere Emu lationseinheiten bzw Pfadabschnitte nachzubilden so werden die Vorgaben 1 bis 3 mittels verschiedener Stromeigenschaften a bis c bei ansteigender i serieller Pfadverkettung ii paralleler Pfadverkettung gemessen um zus tzlich Aussagen ber die Skalierbarkeit zu erhalten Die Parameter einer Messung ergeben sich aus der Kaskadierung einer zu emulierenden Vor gabe aus den Bereichen 1 bis 3 mit jeweils bestimmten Stromeigenschaften a bis c sowie f r jeweils aufsteigende i bzw ii Zur Veranschaulichung l sst sich der
195. rspr nglichen Software hinzugef gt Zus tzlich bringen Verbesserungen am Paketgenerator stabilere Probestr me mit h heren Paketraten zustande Die Eigenschaften der Probestr me und die Vorgaben am Emulator bilden die Versuchspara meter Ist der Emulator au erdem in der Lage Verteilungen oder Pfade nachzubilden so erweitert sich die Parametermenge Allgemein wird in einem Versuch ein bestimmter Vorgabewert einer Metrik am Emulator ein gestellt und mit bestimmten Paketstr men des Messsystems untersucht Die Messwerte werden gespeichert und in der anschlie enden Auswertung werden daraus die tats chlich emulierten Werte berechnet Mit statistischen Mitteln werden zudem die H he der Abweichungen und die je weilige Stabilit t einer Emulation analysiert Dadurch lassen sich Aussagen ber die Genauigkeit und die Leistungsf higkeit des Emulators treffen Die konkreten Messungen unterteilen sich in Ermittlung der erreichbaren Wertgranularit t und in die Untersuchung des m glichen Wertebereiches in Abh ngigkeit von bestimmten Toleranzen F r jede Vorgabe werden gleicherma en mehrere Paketraten mit unterschiedlichen Paketgr en verwendet In Bezug auf die Anzahl der Pakete und Probedurchl ufe unterscheiden sich jedoch die einzelnen Vorgaben je nachdem ob Paketeffekte Verz gerungen oder Datenraten untersucht werden Die genauen Wertangaben der Versuchsparameter werden im n chsten Kapitel zur Umsetzung der beschriebenen Konzepte diskutiert
196. rte f r die kritische Paketgr e 64 Byte mit einer Rate von 50 KPkt s in Abbildung 8 5 betrachtet Die Variationen der Verz gerungen fallen beim Hardware Emulator und bei NETEM deutlich geringer aus als bei DUMMYNET und KAUNET Noch ber den Betrachtungszeitraum von einer Millisekunde hinaus variieren die Verz gerungen mit einem Betrag von f nf Prozent um den Erwartungswert herum Erst bei einem Betrachtungszeitraum von 100 ms bleiben die Werte nach au en hin stabil Diese Schwankungen werden ebenfalls durch die Betrachtung der CDF in Anhang A 6 sichtbar Zus tzlich befinden sich in diesem Anhang die Verteilungsfunktionen der anderen Stromeigen schaften Auch bei diesen sind diese Schwankungen zu erkennen Der Grund daf r ist beim Taktgeber zu finden Bei KAUNET und DumMYNET bzw deren Betriebssystemen ist standardm ig eine Taktrate von 1000 Hz eingestellt Dadurch liegen die minimalen Paketverz gerungen von beiden Emulatoren bei etwas ber 1 ms pro Paket Bei h heren Vorgabewerten f llt dieser Punkt nicht mehr so stark ins Gewicht 108 8 Durchf hrung 4o Vorgabe 1 0 ms PPS 50 0 KPkt s Paketl nge 64 Byte KauNet NetEm Dummynet Linktropy CoDVwBMA 10 AT inms Abbildung 8 5 Auszug aus den berechneten CoD VwBMA Werten zur Ermittlung der Wertstabili t t des jeweiligen Emulators w hrend der Messung der Verz gerungen Vorgabe Ims In Anhang A 6 ist gleichzeitig die Genauigkeit ablesbar So
197. s Grundlage eine eigene Statistik namens Variationskoeffizient der Verz gerungen mit blockierenden gleitenden Mittelwerten engl Coefficient of Delay Variation with Blocking Moving Average CoDVwBMA eingef hrt wird 5 1 Versuchsaufbau Der richtige Versuchsaufbau ist Grundvoraussetzung f r die Messungen Dessen Eigenschaften entscheiden ber die m glichen Untersuchungen und deren Messgenauigkeit Daher werden in diesem Abschnitt die in Kapitel 3 vorgestellten Testaufbauten diskutiert und einer eigenen Variante gegen ber gestellt Weiterhin geh ren die in der Anforderungsanalyse vgl Abb 4 2 genannten softwareseitigen Komponenten und Messwerkzeuge mit zur Versuchsumgebung Auch f r diese werden bereits vorhandene L sungen abgew gt und eine eigene Konzeption vorgestellt 5 1 1 Hardwaretechnischer Aufbau Im Kapitel 3 wurden u a von Nussbaum et al Shaikh et al und Hall et al unterschiedliche Versuchsumgebungen vorgestellt die zusammen die Basis f r einen eigenen Ansatz bilden Die Hauptbestandteile sind dabei ein Paketsender sowie empf nger der Emulator und Messpunkte Die Vernetzung der Bestandteile und die Platzierung der Messpunkte sind die Unterscheidungs merkmale zwischen den drei Aufbauten Der Aufbau welcher von Nussbaum et al verwendet wird siehe Abb 3 14 ist Teil des franz si schen Grip 5000 Projektes 13g und besteht im wesentlichen aus einer Sterntopologie mit einem Router als Knotenpunkt Der Sender
198. sammen mit der Anzahl der doppelten Pakete beinhaltet Paketneuordnungen werden ebenfalls mit einer angepassten Version des diesbez glichen Algorithmus aus der vorangegangen Arbeit ermittelt Der Pseudocode mit der Anpassung ist in Abbildung 5 11 zu sehen Dem urspr nglichen Algorithmus wird im Alternativzweig der Abfrage eine Routine zur Speicherung der Paketnummer siehe Zeile 9 zugef gt Andere Anpassungen sind nicht n tig Um an die neu geordneten Paketnummern zu gelangen wird in der gemessenen und unsortierten Paketnummernliste jedes Paket mit einem wandernden Maximalwert verglichen Ist die aktuelle Paketnummer gr er als der bestehende Maximalwert so wird diese Nummer der neue Maximalwert Ist jedoch der Maximalwert gr er als die aktuelle Paketnummer so ist eine Neuordnung aufgetreten Die betreffende Nummer wird gespeichert und die n chste VD D A Ch On KWH rh jan 5 2 Vorgehensweise 77 lokal_max 0 Speichert lokales Maximum z hler 0 Z hlt die Pakete au erhalb der Reihenfolg nummern_liste Speichert die Paketnummern der Neuordnungen for i 0 bis l nge paketnummernliste if lokal_max lt paketnummernliste i lokal_max paketnummernliste i else nummern_liste einftigen paketnummernliste i lt Anpassung zahler 1 Abbildung 5 11 Pseudocode Bestimmung der Anzahl und Paketnummern von neu geordneten Paketen Paketnummer wird gepr ft Als Ergebnis erh lt man d
199. se Effektqualitat Skalierbarkeit fEig mEig Abbildung 2 2 Hauptkategorien der entworfenen Taxonomie mit Angaben zu feststehen bzw messbaren Eigenschaften Die Funktionsweise besteht allgemein aus feststehenden Eigenschaften und unterteilt sich in vier weitere Klassifikationsmerkmale welche in Abschnitt 2 3 n her beschrieben werden Zur Effektqualit t z hlen die unterst tzen Netzwerkeffekte sowie die Genauigkeit bei deren Umsetzung Daher enth lt dieses Klassifizierungsmerkmal neben den feststehenden auch messbare Eigenschaften Die Angaben zur Effektqualit t lassen sich zumeist aus den Ver ffentlichungen zum jeweiligen Emulator entnehmen Dennoch sind eigene Analysen bzgl der Genauigkeit vorzuziehen da die Betrachtungen in solchen Ver ffentlichungen oft unter Idealbedingungen durchgef hrt werden Um den Grad der Genauigkeit zu einem bestimmten Netzwerkeffekt messen zu k nnen werden Metriken ben tigt In Abschnitt 2 4 werden daher Netzwerkmetriken h ufig unterst tzter Effekte vorgestellt Die Skalierbarkeit umfasst ebenfalls feste sowie messbare Merkmale Letztere beschreiben die m gliche Leistung und die daf r ben tigten Ressourcen Ein Beispiel daf r ist die CPU Auslastung im Zusammenhang mit der maximal m glichen Paketrate bei der Emulation von verschieden vielen Knotenpunkten Das m gliche Potenzial zur Skalierbarkeit
200. senden und Erfassen von Probepaketen auf einem einzelnen Messrechner erm glichen Dadurch kann auf eine Uhrensynchronisation verzichtet werden Der Rechner des Emulators 94 6 Umsetzung Stromeigenschaften Vorgaben am Emulator Paketanzahl Probe Probe Abbruch bei durchl ufe dauer 1 kein Abbruch Paketeffekte 100 1000 100000 100 1 0 1 0 0001 2 rel Abw 3 3 0 0001 emuliert E 1 rel Abw 10 S Verz gerungen 1000 1 10 9 9 0 1 ms 2 ungew Paketeffekte O 3 0 1 ms emuliert 1 rel Abw 10 Datenraten 10000 1 10s 1 0 9 0 1 MBit s 2 ungew Paketeffekte 3 0 1 MBit s emuliert s e E Paketeffekte 10000 o Granularit t 100 1 11 21 91 H vo 3 Verz gerungen 1000 1 15 50 100 1000 ms z Datenraten 10000 1 10s 7 2 54 61 160 MBit s Tabelle 6 4 bersicht der verwendeten Messparameter zur Ermittlung der Granularit t und des Wertebereiches wiederum verf gt ber Leistungsmerkmale die zumeist ber den geforderten Merkmalen liegen Zur Optimierung der m glichen Datenrate werden jeweils eine PCI und eine PCIe Netzwerkkarte verwendet Dadurch agieren die Karten auf unterschiedlichen Bussen und beeinflussen einander nicht Dennoch k nnten weitere Vorkehrungen getroffen werden um die m gliche Datenrate noch weiter zu steigern Dazu z hlt beispielsweise die Verwendung von Hauptplatinen welche noch einen weiteren PCle Anschluss haben da
201. sierte Paketabfrage an der Netzwerkkarte durchzuf hren Dadurch wird schneller auf ein ankom mendes Paket reagiert Au erdem ist CLICK modular aufgebaut und erm glicht es durch das Zusammensetzen verschiedener Basismodule ein Element mit den geforderten Eigenschaften zu kreieren Die Konfiguration der Module bzw Elemente wird mit einer deklarativen Sprache durchgef hrt die zudem Abstraktionsm glichkeiten f r zusammengesetzte Elemente bietet Solche Elemente bilden beispielsweise sogenannte PollDevices welche die Netzwerkkarte im merw hrend auf eingehende Pakete abfragt und bei positiver Antwort diese Pakete sofort mit Zeitstempeln versieht Andere Elemente erm glichen NETPATH als Multi Link Emulator zu fungieren Eingehende Pakete werden daher nach bestimmten Merkmalen klassifiziert und so an verschiedene nachfol gende Elemente verteilt Die Entwickler sehen jedoch bei manchen Elementen weitere Verbesserungsm glichkeiten und passen u a Warteschlangenelemente an So entstehen neue Elemente mit verbesserten Leistungswerten welche im ersten Teil der Evaluierung aufgezeigt werden Leistungsanalyse Die Evaluation geschieht in zwei Teilen Im ersten Teil werden die Rohleis tungscharakteristiken von NETPATH gemessen Diese umfassen den Durchsatz die Skalierbarkeit und Pr zision Da Emulatoren ab einer bestimmten Datenrate anfangen Pakete zu verwerfen und so Leistungsdaten verf lscht werden stehen in IHLO7 vor allem verlustfreie Messun
202. soll den Grad der Zuverl ssigkeit des Versuchsaufbaus steigern indem es bereits vor einer Messung m gliche Falschmessungen verhindert 100 101 8 Durchf hrung Im Rahmen dieser Arbeit werden mit Hilfe des vorgestellten Messkonzepts die Nachbildungen der Netzwerkmetriken C OWD PLR PRR und PDR durch die vier Emulatoren DUMMYNET KAUNET NETEM und LinxTropy analysiert Jeder dieser Netzwerkemulatoren decken mehrere oder sogar alle der zu untersuchenden Metriken ab Tabelle 8 1 bietet dazu einen bersicht an vgl auch Tab 3 10 Dar ber hinaus sind DummYnET und KAUNET in der Lage mehrere Pfadabschnitte zu emulieren Weiterhin k nnen nur ausgew hlte Ergebnisse pr sentiert werden da die Gesamtanzahl an Messergebnisse au erhalb des Rahmens dieser Arbeit liegt Die restlichen Auswertungen und auch die einzelnen Messdaten befinden sich auf beigelegten Datentr gern 8 1 Vorfelduntersuchungen Am Beispiel von KAUNET wird die allgemeine Durchf hrung zur Ermittlung der Grundverz ge rung MLFFR sowie Puffergr e erl utert Die Vorfelduntersuchungen der brigen Emulatoren verlaufen analog Daher werden deren Ergebnisse abschlie end zusammengefasst aufgef hrt 8 1 1 Grundverz gerungen Die Messung der Verz gerung des Versuchsaufbaus wird ohne jedwede Emulationsregel durch gef hrt Speziell f r KAUNET bzw FREEBSD 7 3 ergeben sich die in Tabelle 8 2 aufgef hrten Mittelwerte in Bezug auf die jeweilige Stromeigenschaft Zur
203. ss der Paketerfassung Der dazugeh rige Quelltext zeigt neben der Einbindung und dem Aufruf des Erweiterungsmoduls die Callback Funktion welche beispielsweise den Wert 2 zur ckgibt wenn der Sender alle Pakete versendet hat Das Erweiterungsmodul ist in C geschrieben Die darin enthaltenen Funktionen k nnen wie im Beispiel dargestellt direkt in Python aufgerufen werden Diese Vermischung der Sprachen verbindet die Geschwindigkeit der maschinennahen Sprache C mit der einfachen Prozesssteuerung durch PYTHON Paketerfassung In Abbildung 6 3 ist au erdem ein Hinweis grau hinterlegt auf das genutzte Verfahren zur Paketerfassung zu erkennen Die Pakete werden passiv mittels pcap Treiber und der zugeh rigen W nPcAr Bibliothek 13aa erfasst und auch versendet Die Erfassung der Pakete geschieht dadurch bereits nach deren Behandlung durch den Netzwerkkartentreiber D h 88 6 Umsetzung IP 10 0 0 6 30 Gateway 10 0 0 5 IP 10 0 0 5 30 Rx E2 logische t e ei Trennung Messrechner Tx E1 F et Emulator IP 10 0 0 2 30 IP 10 0 0 1 30 Gateway 10 0 0 1 Abbildung 6 2 Netzwerkeinstellungen des Versuchsaufbaus die Zeitstempel werden unabhangig von der Verarbeitungsgeschwindigkeit einer Anwendung m glichst nahe am Ubertragungsmedium vergeben Paketgenerator Die WinPcap Bibliothek bietet neben der Paketerfassung auch die M glich keit Pakete zu versenden Dabei we
204. sse bestimmt den Grad der Genauigkeit des Models Die Werte dieser Einfl sse beruhen auf empirischen semiempirischen und deterministischen Daten bzw Berechnungen Entsprechend lassen sich Ausbreitungsmodelle klassifizieren Wobei der Grad der Genauigkeit e empirischer Modelle auf hnlichen Messungen sowie Erfahrungswerten beruht und daher gering ist Beispiel OKUMURA HATA MODELL e semiempirischer Modelle auf Berechnungen mit Vereinfachungen und N herungen beruht und somit mittelm ig ist Beispiel COST 231 LOS MODELL e deterministischer Modelle auf exakten Berechnungen beruht und dementsprechend hoch ist Beispiel IKEGAMI MODELL Bewegungen Mit Hilfe der Ausbreitungsmodelle ist es m glich innerhalb eines begrenzten Bereiches einem Ort eine bestimmte Empfangsqualit t zuzuordnen ndert sich der Ort ndert sich zumeist die Empfangsqualit t Emulatoren die Bewegungen unterst tzen arbeiten oft mit Simulatoren zusammen Mit diesen werden im Vorfeld einer Emulation die Bewegungen simu liert und mit Hilfe eines Ausbreitungsmodells die zugeh rigen Empfangsqualit ten berechnet Anschlie end werden die Ergebnisse vom Emulator zeitlich versetzt mittels Verz gerungen Datenraten und weiteren Paketeffekten umgesetzt Handover Bewegungen rufen weitere Effekten hervor Speziell f r die Emulation zellular aufgebauter Funknetze ist die Nachbildung von Zellwechseln naheliegend Aus Sicht eines Mobilfunkger tes findet eine bergabe engl Ha
205. st diese Vorgehensweise durchaus sinnvoll Der eigene Aufbau wird jedoch mit realen Verbindungen in Form von kurz en Netzwerkkabeln 50 cm L nge konzipiert Die Einfl sse der Kabelverbindungen auf die Probepakete k nnen vernachl ssigt werden da die Wahrscheinlichkeiten f r ungewollte Pa ketverluste dopplungen oder neuordnungen u erst gering sind und sich Verz gerungen bei solchen Kabell ngen im Nanosekundenbereich befinden Dadurch wiederum kann auf die zwei Messpunkte des Emulators verzichtet werden Dieser Verzicht hat auch den Vorteil dass dem Emulator ohne diese Messpunkte mehr Ressourcen zur Verf gung stehen und keine zus tzlichen Beeinflussungen entstehen Der angepasste Ansatz ist in Abbildung 5 2 dargestellt Ein weiterer Punkt welcher von keiner der bisher vorgestellten Versuchsumgebungen be r cksichtigt wird ist die Uhrensynchronisation bei der Messung von OWDs Trotz eines sym 5 1 Versuchsaufbau 63 Sender Emulator Empf nger Netzwerkkarte ei O Messpunkt Tx e1 E2 Rx I w 50cm 50cm Abbildung 5 2 Angepasster Ansatz des eigenen Versuchsaufbaus mit zwei Messpunkten metrischen Aufbaus ist die alternative Halbierung der RTD nur bedingt anwendbar Bei den geplanten Untersuchungen soll der Emulator an dessen Leistungsgrenzen gef hrt und nicht durch eine zus tzliche R ckrichtung beeinflusst werden Auch k nnen einige der zu bet
206. sucht werden Allein bei der letzten Paketrate ergeben sich f r die 5 1 Versuchsaufbau 65 Versuchs einstellungen werden geladen parameter startet Versuchs steuerung Ergebnisse Paket generator Berechungs einheit startet speichert Rohdaten speichert Paketstr me Rx Paket Paket erfassung Rohdaten Paket erfassung eee Tx Netzwerkkarte Rx Netzwerkkarte DH D D Di Zeenen AB aant filtert und er fasst Rohdaten Y zum Emulator vom Emulator Abbildung 5 4 Softwaretechnischer Versuchsaufbau Rohdaten insgesamt Paketnummern und Zeitstempel werden als Integer Werte mit jeweils 4 Byte angenommen Paketanzahl Paketnr Sekundenanteil Mikrosekundenanteil Laufzeit KPkt Byte 200 12 S Pkt F r den gesamten Versuch ergeben sich insgesamt 100 s 229 MByte 20 Byte KPkt KPkt Teri 10 EH 2GByte 100s 12 g Pkt s x 2 66 5 Konzeption Diese Gr e kann von aktuellen Systemen noch im Arbeitsspeicher verarbeitet werden ndern sich jedoch die Vorgaben und es wird beispielsweise eine geringere Schrittweite von 1 KPkt s gefordert so erh ht sich der Speicherbedarf auf 22 GByte Eine Datenhaltung im Arbeitsspeicher ist daher nur bei Systemen mit mehr als 22 GByte RAM m glich Der zur Messung vorgesehene Rechner besitzt 8 GByte daher werden die Rohdaten f r je
207. sungen 1 Paketeffekt 2 Verz gerung 3 Datenraten Wertvorgabe SC Vorgabe 1 Vorgabe M N a1 Paketl nge _ ax Paketl nge Stromeigenschaften 7 b Paketabstand _ br Paketabstand Genauigkeit 7 c Paketanzahl _ _ co Paketanzahl i serielle Verkettung ii parallele Verkettung Pfadverkettungen a ya ii Pfad iy Pfade ii Pfad iin Pfade Leistung bei aufsteigenden Wertvorgaben Stromeigenschaften und Pfadverkettungen Abbildung 5 9 Allgemeines Schema der Parameterverkn pfungen f r die Messungen Granularit t Die kleinstm gliche Effektrate wird durch eine schrittweise Verringerung der Wertvorgabe mit entsprechender Erh hung der Paketanzahl je Probestrom ermittelt vgl Ta belle 5 1 Denn es gilt beispielsweise bei einer Vorgabe von 1 Paketverlust verdopplung oder neuordnung muss ein Paket von 100 gesendeten Paketen in einem Paketstrom von der Manipulation des Emulators betroffen sein Bei 0 1 muss ein Paket von 1000 Paketen bei 0 01 eines von 10000 Paketen usw manipuliert werden Bei der Messung muss jedoch die Eigenheit des Pseudozufallsgenerators bei einigen Emulatoren nur f r lange Paketfolgen die richtige Prozentzahl an Paketen zu beeinflussen ber cksichtigt werden Daher werden alle Mes sungen ohne vorzeitigen Abbruch durchgef hrt und erst hinterher die Abweichung kontrolliert Um Abweichungen und Ausrei ern entgegen zu wirken werden
208. t ist WANEM KN11 Dieser ist als NLE konzipiert und stellt sich die Aufgabe ein WAN zwischen zwei Testsystemen nachzubilden Der Emulator wird als Live CD sowie als MWare Image zum Download angeboten und bedarf daher keiner Installation bzw Anpassung eines existierenden Betriebssystems WANEM kann da dieser auf NETEM aufbaut ber tc und oder einer angepassten Version der NETEM GUI konfiguriert werden Allerdings gestattet WANEM mehr Konfigurationsm glichkeiten und kann zus tzlich zu den Effektqualit ten von NETEM auch Unterbrechungen vgl Abschnitt 2 4 4 nachbilden 3 2 Produktpublikationen und dokumentationen 39 Effektqualitat Angaben Datenrate C 120 KBit s 50MBit s PLR PDR 0 100 E KE PRR 555 0 0000000232 Schrittweite a BER 7 OWD Verz gerungen AOWD Die minimale Aufl sung betr gt 10 ms Unterbrechungen Idle Zuf llig Die minimale Aufl sung betr gt 1 s Leistung Paketrate 10000 Pkt s 100 MBit Netzwerkkarte Tabelle 3 7 Produktangaben zur Granularit t und Leistung von WANEM nach KN08 Die Implementation der Unterbrechungen wird in einer zus tzlichen Arbeit NK11 beschrieben und beruht im Wesentlichen auf dem Einsatz von iptables und einem Kernel Modul zur berwachung von TCP Verbindungen namens connt rack Produktangabe F r den Vergleich mit eigenen Messergebnissen werden an dieser Stelle die Angaben zur Genauigkeit und Leistungsf higkeit aus der Dokumentation KN
209. t nde und gr en untersucht 74 Tab 5 2 Beispielwerte f r die Betrachtung der Wertstabilitat mit Hilfe von CoDVwBMA 81 Tab 5 3 Ergebnisse der Mittelwertberechnungen f r die Betrachtung der Wertstabi lit t mit Hilfe von CoDVwBMA aoaaa aaa eee ee ee 83 Tab 6 1 Hardwarekonfiguration der Versuchsrechner vgl Abb 5 3 85 Tab 6 2 Allgemeine Ergebnismatrix und gleichzeitig bersicht ber die verwendeten Paketgr en a1 a4 und abst nde b1 b3 vgl Abb 5 9 90 Tab 6 3 bersicht ber die resultierenden Paket sowie Datenraten bei der Kombi nation aus den Werten f r al a4 und b1 b3 vgl Abb 5 9 90 Tab 6 4 bersicht der verwendeten Messparameter zur Ermittlung der Granularit t und des Wertebereiches aia a4 bbb han san EES ee hae AA A 94 Xvi Tabellenverzeichnis Tab 7 1 Ausgabe von Wireshark f r den Nachweis der Funktionalit t des Versuchsauf Tab 8 1 bersicht ber die Funktionsm glichkeiten der ausgew hlten Emulatoren in Bezug auf die zu untersuchenden Netzwerkmetriken Tab 8 2 Durchschnittliche Grundverz gerungen in us des Versuchsaufbau f r die jeweilige Paketstromeigenschaft unter FREEBSD 7 3 KAUNET Tab 8 3 Mittelwerte der erfassten Grundverz gerungen in jus f r den jeweiligen Emulator unter Verwendung von verschiedenen Paketgr en und abst nden Tab 84 Durchschnittliche Verz gerungen links un
210. t der Paketverz gerung von KAUNET vgl Abschnitt 3 2 3 werden hier bewusst sehr hohe Paketraten gew hlt Dadurch kann die Implementation des Zeitgebers mit betrachtet werden und es lassen sich gleichzeitig zur Genauigkeit auch Aussagen zur Verarbeitungsleistung treffen Die Einhaltung der eingestellten Datenrate ist der Schwerpunkt der anderen Betrachtungen Je nach Implementation kann im Vorfeld bereits mit einer zu hohen oder zu niedrigen Datenrate gerechnet werden Beispielsweise sorgen die von NETEM eingesetzten Token Bucket Algorithmen f r eine zeitweise zu hohe Datenrate 3 3 2 Shaikh J und Minhas T et al 2010 Die Autoren Shaikh et al untersuchen in Sha 10 die drei Emulatoren NISTNET NETEM und KAuNET in Bezug auf ihre Verz gerungsformung engl delay shaping Dabei werden zudem die Abh ngigkeiten von der zugrundeliegenden Hardware betrachtet D h die Experimente finden mit ann hernd gleichen technischen Voraussetzungen zum einen auf der Hardware des Herstellers AMD Advance Micro Devices und zum anderen in einer INTEL basierten Umgebung statt Es zeigt sich dass die Wahl der Hardware tats chlich Auswirkung auf die Verz gerungen hat Ein weitere Sonderstellung dieser Studie ist der Einsatz des Coefficient of Throughput Variati on CoTV Mit diesen Variationskoeffizienten gelingt es sich einen einfachen berblick ber die Variation der Datenrate und damit auch der Verz gerung f r verschiedene Zeitinterva
211. t die 104 8 Durchf hrung P 1 0170 0 9425 0 8681 0 7936 no E 0 7192 ES o 0 6447 0 5702 2 0 4958 o n S 0 4213 5 0 3468 D 0 2724 0 1979 0 1235 0 0490 Abbildung 8 2 Gemessene Verz gerungswerte Paketl nge in Byte Paketl nge in Byte Paketl nge in Byte FREEBSD 7 3 KAUNET Paketlange in Byte PS 500 0 KPkt s PPS 200 0 KPkt s PPS 125 0 KPkt s PPS 100 0 KPkt s i T rs je i i SES S i 512 512 512 512 zur Ermittlung der MLFFR am Beispiel von Paketgr e in Byte 64 1024 Paketabstand 20 48 98 49 06 in us 120 49 37 47 95 Tabelle 8 5 Berechnete Puffergr e des Emulators KAUNET f r die jeweilige Paketstromeigen schaft M glichkeit Datenraten zu beschr nken vielmehr werden daf r andere qdiscs vgl Abschnitt 3 2 5 wie z B HTB Hierarchical Token Bucket oder TBF Token Bucket Filter genutzt Bei der Ratenbeschr nkung durch diese beiden Methoden wird u a die Puffergr e als Eingabeparameter verlangt 8 2 Messungen Die Ergebnisse werden in Abschnitte aufgeteilt welche sich jeweils auf eine bestimmte Metrik beziehen Je nach unterst tzter Metrik werden dabei zun chst einzelne ausgew hlte Ergebnisse der Emulatoren beispielhaft pr sentiert und erl utert Anschlie end werden diejenigen Emulato ren f r ausgew hlte Strom und Pfad
212. t in der Art der Generierung der Pakete Jedes Paket eines Probedurchlaufs wird vor dem Versenden zun chst in der Anwendungsebene mit den n tigen Informationen versehen und anschlie end ber einen Socket an den Kernel bergeben Abbildung 5 7 veranschaulicht den Ablauf Dadurch entsteht zum einen eine Abh n gigkeit von der Interrupt Rate des Nutzerbereichs und zum anderen entstehen Verz gerungen durch die periodische Speicherallokation sowie durch die bergabe an den Kernel Paket auff llen Paketnummern Paket Socket Nutzer m Layer 4 TCP UDP Kernel y Layer 3 IP E E Layer 2 MAC Abbildung 5 7 Die Paketgenerierung in der vorangegangenen Arbeit B s13 5 2 Vorgehensweise 69 Die L sung ist alle Pakete eines Probedurchlaufes vor dem Versenden zu generieren und im Kernelbereich zu puffern vgl Abbildung 5 8 Anstelle der Sockets in der Anwendungsebe ne werden beispielsweise unter Unix artigen Systemen direkt die Paket Sockets in der Ebene des Netzwerkkartentreibers Layer 2 verwendet Auch in Windows basierten Systemen ist dieser Ansatz m glich und es existieren bereits entsprechende Funktionen daf r wodurch der Zeitabstand auf 1 us reduziert werden kann Dieses Vorgehen wird z B von der bekannten WinPcap Bibliothek verwendet Paket auff llen Nutzer Kernel E Paket Puffer Paket Paket2 Paket3 gt Layer 2 MAC Abbildun
213. tabilit t der Pake traten gezeigt KAUNET als Beispiel hatte im Vergleich zu NETEM einen halb so gro en Puffer und zeigte dementsprechend eine gr ere Streuung in den Ergebnissen F r die eigenen Untersuchun gen ist die Puffergr e daher ebenfalls interessant Dazu wird eine Datenratenbeschr nkungen am Emulator eingestellt und ein Paketstrom mit konstantem Paketabstand verwendet Der Pa ketstrom muss den Emulator dabei komplett auslasten oder sogar berlasten D h das Verh ltnis aus eingestellter Rate und tats chlich emulierter Rate muss gr er gleich Eins betragen Ge messen werden neben der durchschnittlichen emulierten Datenrate auch die durchschnittliche Verz gerung um so die Puffergr e nach Gleichung 3 3 zu erhalten Das folgende Beispiel soll das Vorgehen verdeutlichen Am Emulator wird eine Datenratenbeschrankung von z B Reefordert 1 MBit s eingestellt Um den Emulator auszulasten bzw zu berlasten m ssen die generier ten Paketstr me ebenfalls mit einer Rate von mindestens Reingehend 1 MBit s versendet werden Als Indikator f r die Auslastung wird das Verh ltnis zwischen der tats chlichen emulierten Rate Remuliert und Rgeforderr beobachtet F r dieses muss gelten Rgefordert gt 1 Remuliert u Um eine solche Datenrate beispielsweise f r die kleinst m gliche Paketgr e von 64 Byte zu erreichen wird ein Paketabstand von 4 Byt Ay 64 Byte Me Lee 1 MBit s ben tigt Dieser kann auf 500415 abg
214. ter des j ten Paket entspricht AOWD OWD OWD DL DE DL DE Dy D5 2 5 Geht man davon aus dass die Pakete mit der selben Gr e ber den gleichen Pfad versendet werden so vereinfacht sich Gleichung 2 5 zu AOWD D DL 2 6 Je nach Anwendung k nnen diese Verz gerungen noch weiter aufgeteilt werden 2 4 Effektqualit t Netzwerkmetriken 15 Tx Rx T T T Ta T Ts Zeit Abbildung 2 9 Verz gerungsvariationen Quelle B s13 Die Ausbreitungs und Transferverz gerungen verhalten sich unter dieser Annahme gleichblei bend Somit ist Do die ausschlaggebende Gr e f r Jitter F r die Genauigkeitsanalyse ist die erreichbare Pr zision bzw die umsetzbare Granularit t f r die AOWD ein ausschlaggebender Punkt 2 4 3 Paketeffekte Die Effekte Paketverlust dopplung sowie neuordnung treten ebenso wie Bitfehler in realen Testumgebung selten und unkontrolliert auf Ein Hauptgrund f r den Einsatz von Emulatoren ist Verbindungspfade dahingehend gezielt manipulieren zu k nnen um so das Programmverhalten auch in Ausnahmesituationen untersuchen zu k nnen Auch hier bestehen die M glichkeiten eine einzelne Richtung oder den Hin und R ckweg zu betrachten Jedoch unterscheiden sich die Berechnungen f r die beiden M glichkeiten nicht voneinander Daher werden die folgenden Raten allgemein betrachtet Ein Vergleich zwischen der Menge der empfangenen Pakete Mp und der Menge der
215. tralen Architektur Alle brigen werden zentral betrieben Der Arbeitsbereich im Kernel ist wiederum allen gemein Weiterhin hat sich herausgestellt dass die Produktangaben zu den meisten Emulatoren deutli che L cken aufweisen So ist der Umfang dieser Angaben z B bei den Emulatoren DuMMYNET Tab 3 3 und MopELNET Tab 3 5 im Vergleich zu den Produktangaben zum Hardware Emulator in Tabelle 3 1 sehr gering Zumeist fehlen die Arbeitsbereiche und die m gliche Granularit t f r die verschiedenen Effektqualit ten Daher werden an dieser Stelle keine Vergleiche zwischen den Emulatoren angestellt Auff llig ist ebenso dass in den ver ffentlichten Analysen haupts chlich die Genauigkeit der emulierten Paketverz gerung und Datenrate betrachtet wird Untersuchung zu den brigen Effektqualit ten wurden vermutlich aus Gr nden des Umfanges nicht ver ffentlicht An den genannten Stellen setzen daher eigene Untersuchungen an um so die fehlenden Angaben zu ermitteln Dennoch lassen sich viele Hinweise f r eigene Untersuchungen herausfiltern Dazu geh ren Erkenntnisse ber den Versuchsaufbau Metriken und Visualisierungsm glichkeiten sowie Be trachtungen welche bereits im Vorfeld einer Messung auf Abweichungen hindeuten In den Arbeiten zu DUMMYNET werden die Einflussfaktoren CT Prozessinterferenzen und die Taktrate untersucht Au erdem wird die Metrik PPT als Alternative zur PPS vorgestellt Wobei jedoch die direkte Implementierung zur Mess
216. triche mit einem Stern in der Mitte 2 4 dices ne 4 0252 020000 Abb 8 9 Erfasste Paketverluste als Box Diagramme f r die verschiedenen Paketl n gen sowie raten bei 10 Pfadabschnitten und mit Dummynet als Emulator Der Erwartungswert liegt bei 9 6 Verlusten 2 2 2 u onen Abb 8 10 Erfasste Paketneuordnungen als Box Diagramme f r die verschiedenen Paketl ngen und raten bei einem einzelnen Pfadabschnitt Abb 8 11 Erfasste Paketdopplungen als Box Diagramme f r die verschiedenen Paket l ngen und raten bei einem einzelnen Pfadabschnitt Abb A 1 Grundverz gerungen als Verteilungsfunktion des jeweiligen Emulators f r die verschiedenen Paketl ngen und raten 2 2 2 2 22m Abb A 2 Gemessene Datenraten bei unterschiedlichen Stromeigenschaften und einem einzelnen Pfadabschnitt Vorgabe 200 KBit s 2 22222 Abb A 3 Gemessene Datenraten bei unterschiedlichen Stromeigenschaften und 10 Pfadabschnitten Vorgabe 200 KBit s 2 22 nn 106 xiv Abbildungsverzeichnis Abb A 4 Verz gerungen als Verteilungsfunktion des jeweiligen Emulators f r die ver schiedenen Paketl ngen und raten bei einem einzelnen Pfadabschnitt Vorgabe REENEN 125 Abb A 5 Erfasste Neuordnungen f r die verschiedenen Paketl ngen und raten bei einem einzelnen Pfadabschnitt Vorgabe 1 2 2 2 n nennen 126 XV Tabellenverzeichnis Tab 2 1 Beispiel f r ein Bewertungsschema einiger ausgew
217. u einzelnen feststehen den Merkmalen k nnen f r bestimmte Aspekte in einen Zusammenhang gebracht werden um so ein Bewertungsschema f r Emulatoren zu erstellen Ein Beispiel daf r ist in Tabelle 2 1 zu sehen Diese Tabelle fasst einige der genannten Vorz ge und Einschr nkungen vieler festste henden Eigenschaften zusammen um dadurch z B Aussagen ber die Verarbeitungsrate den Installationsaufwand die Effektgranularit t etc treffen zu k nnen So ist beispielsweise der Installationsaufwand bei Emulatoren mit einer zentralen Architektur welche anstatt einer Kernel Anpassung einfach einen anderen Zeitgeber verwenden und statische Pfadvorgaben ohne die Notwendigkeit einer Topologievorgabe unterst tzen im positiven Sinne gering F r den Aspekt der Realit tsn he sind Emulatoren mit impliziter Pfadvorgabe und der M glichkeit virtuelle Netz werke zu erstellen besonders geeignet Allerdings leidet die Skalierbarkeit und Verarbeitungsrate 20 2 Nachbildung von Netzwerkverhalten unter dem Einsatz von VMs und implizierten variablen Pfaden da in beiden F llen Redundanzen entstehen Das vorgestellte Beispiel eines Bewertungsschemas ist diskussionsw rdig und bein haltet einige verallgemeinerte Einsch tzungen welche im Einzelnen vom jeweiligen Emulatoren abh ngen und mit Leistungs und Genauigkeitsanalysen gepr ft werden m ssen Im folgenden Kapitel werden die Funktionsprinzipien einer breit gef cherten Auswahl von Emulatoren vorgeste
218. u in Echtzeit das Gesamtverhalten einer Anwendung in einer vorgegebenen Topologie mit gezielten Pfadmanipulationen untersucht werden Metriken wie Speicherverbrauch Prozessorauslastung oder die Latenz bei der Behandlung von Datenpaketen k nnen nicht durch eine Simulation gemessen werden Um verschiedene Bandbrei ten testen zu k nnen m ssten bei Realumgebungen mehrere Verbindungswege zur Verf gung stehen Die Emulation dagegen gestattet einen berblick ber die verwendeten Ressourcen und erlaubt eine einfache Einstellungsm glichkeit der gew nschten Netzwerkeigenschaft Daher eignen sich Emulatoren besonders f r die Test und Debuggingphase 2 2 Taxonomiekonzept 5 SEmulation ist die Kombination aus Simulation und Emulation Wobei zwei m gliche Varian ten zur Kombination existieren In der erste Variante wird zun chst eine Simulation bestimmter Ereignisse durchgef hrt um daraus die Eigenschaften der Zielplattform zu berechnen Die Ergeb nisse dienen im n chsten Schritt einem Emulator als Grundlage f r dessen Versuchsdurchf hrung Beispielsweise kann so die Empfangsqualit t eines Satellitensignals f r verschiedene Gebiete simuliert und die berechneten Werte anschlie end in einer Testumgebung emuliert werden Bei der anderen Variante agieren simulierte Netzwerkkomponenten in Echtzeit mit realen Netzelementen die wiederum emulierte Eigenschaften besitzen Die simulierten Komponenten k nnen dabei komplexe Bereiche eines Netzwerkes
219. uchssteuerung bzgl der Startreihenfolge der verschie denen Grundkomponenten OWD sowie AOWD wichtig Zus tzlich kann so die tats chliche Senderate ermittelt werden da durchaus Abweichungen von der geforderten Rate entstehen welche sonst f lschlicher Weise dem Emulator zugeschrieben werden Um die Verarbeitungsgeschwindigkeit bei der Erfassung zu erh hen reagieren beide Netz werkkarten anders als im sonst f r passive Datenerfassung blichen promiscuous mode nur auf Pakete welche wirklich nur f r diese bestimmt sind Au erdem werden nur die ersten Bytes mit den ben tigten Informationen und der Header eines jeden Paketes erfasst der Rest wird verworfen Filter sorgen w hrend der Erfassung daf r dass versuchsfremde Pakete nicht mit in die Rohdaten gelangen Genutzt wird daf r eine eigene Implementation mit Hilfe von angepassten L BPcAP Bibliotheken 131 da f r die Auswertung nur bestimmte Paketdaten ben tigt werden und sich die eigentliche Datengewinnung leichter in die Paketerfassung integrieren l sst Programme wie TCPDUMP bietet mehr Funktionen als ben tigt und speichern dagegen die Nutzdaten sowie die Header wodurch eine zus tzliche Extraktion der eigentlichen Daten notwendig wird Eine weitere Einschr nkung wird durch deren Portabilit t verursacht So stehen beispielsweise unter W npows basierten Systemen Funktionen zur effizienteren Paketerfassung zu Verf gung welche jedoch nicht von Un Ix artigen Umgebungen
220. und festgeschrieben Paketeffekte Datenraten D Software Komponeten Min LA Hardware Komponenten i Pfad Versuchsparameter D Emulator NIC 1 NIC 2 _ lt Paketanzahl gt Probe Probestr me lt en Anzahl D durchl ufe Tag NIC 3 NIC 4 a TA N Mess System Versuchssteuerung Senden Erfassen Erweiterungen NORA Datenhaltung 7 Berechnungen Auswertung S Abbildung 5 17 berblick ber den Hard und Software technischen Versuchsaufbau inklusive der Versuchskomponenten sowie parameter 85 6 Umsetzung In diesem Kapitel werden die Umsetzungen der vorgestellten Konzepte beschrieben wobei die Schwerpunkte dabei auf dem Versuchsaufbau und der konkreten Vorgehensweise bei den einzelnen Messungen liegen Der Aufbau orientiert sich an dem des vorhergehenden Kapitels und beginnt mit der Versuchsanordnung 6 1 Versuchsaufbau 6 1 1 Hardwaretechnischer Aufbau F r die Messungen werden zwei handels bliche Personal Computer mit jeweils zwei Netzwerkkar ten verwendet Die technischen Spezifikationen sind in Tabelle 6 1 aufgelistet Der Messrechner enth lt f r die Erfassung der Messwerte die leistungsst rkeren Komponenten So wird sicher gestellt dass der Messrechner eine h here Paketrate verarbeiten kann als der Emulator und somit unerw nschte Verz gerungen oder Paketeffekte nicht bei diesem Rechner zu finden sind
221. ung der PPT au en vor gelassen wird Die Publikationen zu KAUNET beschreiben einen Versuchsaufbau bei dem mit passiven Messmethoden direkt am Ein und Ausgang des Emulators sowie an den Endpunkten Pakete erfasst werden Dadurch k nnen die Durchgangswerte des Emulators von den Grundwerten des Versuchsaufbaus getrennt werden F r die Genauigkeit der emulierten Verz gerung werden anders als bei der Studie von Nussbaum et al kleine Pakete mit einer geringen Paketrate verwendet um so Systemeinfl sse zu minimieren Nussbaum et al dagegen verwenden hohe Paketfrequenzen um die Auswirkungen des Zeitgebertaktes auf die Zuverl ssigkeit der emulierten Werte zu untersuchen Bei MODELNET wird der Begriff der Kapazit t eines Emulators eingef hrt Diese zeigt den Punkt im Emulations prozess an bei der die CPU Last 100 betr gt und unerw nschte Paketverluste auftreten In der Arbeit zu NETPATH wird diese Kapazit t auf die Paketrate bezogen und als MLFFR bezeichnet F r die Evaluierung von NETEM wird ein in einer Realumgebung zuvor aufgezeichneter TCP Strom nachgebildet F r die dezentralen L sungen IMUNEs und MoDELNET werden die Paketraten f r steigende Verbundteilnehmer und Netzwerkelemente untersucht Die Betrachtung der Verz gerung wird in allen Publikationen sowie Studien mit Hilfe von variierenden Paketgr en und raten durchgef hrt F r eine bersichtliche Visualisierung der Messergebnisse werden zumeist H ufigkeitsverteilungen und speziell
222. unterst tzt werden Daher werden stattdessen die auf beiden Systemen verf gbaren Standardfunktionen verwendet Paketgenerator Die Pr zision und die Leistungsf higkeit des Generators legen den m glichen Betrachtungsbereich bei den Messungen fest So m ssen die zeitlichen Abst nde zwischen zwei aufeinanderfolgenden Paketen mit einer Aufl sung im Mikrosekundenbereich exakt eingehalten werden um eine konstante Paket bzw Datenrate von mehr als 1 KPkt s bzw 1MBit s bei L 1500 Byte zu gew hrleisten Zudem m ssen die in Tabelle 4 3 aufgelisteten Anforderungen FL4 bis FL6 erf llt werden D h der Paketgenerator muss Einstellungen bzgl der Paketgr e und der Sende sowie Empfangsports unterst tzen 68 5 Konzeption Es existieren bereits viele Hardware und Software basierte Generatoren die im Bereich bis 100 MBit s akkurat arbeiten und diese Einstellungen unterst tzen Eine bersicht ist auf den Internetseiten 13u und 13v zu finden Bei Datenraten jenseits der 100 MBit s geraten viele Software L sungen jedoch an ihre Grenzen So erreicht beispielsweise der bekannte und viel genutzte D ITG maximal eine Datenrate von 612 MBit s Quelle Nap08 F r Paketraten welche in den Bereichen liegen bei denen Emulatoren anfangen Pakete zu verwerfen m ssen Paketabst nde von 5 us bis 2 us erreicht werden was den Raten von 200 KPkt s bis 500 KPkt s entspricht Kommerzielle Paketgeneratoren bieten diese hohe Leistungsf higkeit und basier
223. ur 12 Anders als bei DummYNET werden Netzwerkeffekte in KAUNET deterministisch nachgebildet Die daf r ben tigten Muster werden im Vorfeld einer Emulation durch das beigef gte Tool namens PATT GEN generiert und abgespeichert Anschlie end werden diese Muster durch eine angepasste Version des bereits f r DUMMYNET genutzten Kommandos ip fw in den Kernelbereich bertragen Damit diese Vorgaben Wirkung zeigen erweitert KAUNET die pipes von DUMMYNET und f gt beispielsweise innerhalb der pipes eine zus tzliche Warteschlange f r die Paketneuordnung hinzu Abbildung 3 8 veranschaulicht Vorgehensweise und die Erweiterung durch KAUNET SES ZE Or a B Pipe DUMANE J zustzl Warteschlangen IP 01010011101011 010100 Muster patt gen KAUNET Abbildung 3 8 Funktionsprinzip von KAUNET mit dem Mustergenerator patt gen Um die Dynamik des Versuchsaufbaus weiter zu erh hen ist es m glich vor einer Emulation mehrere Muster zu verketten und so eine Wechsel der Vorgaben w hrend der Versuchsdurch 32 3 Verwandte Arbeiten f hrung zu erm glichen Zus tzlich kann ein Muster auf mehrere pipes verteilt werden Ein Hinzuf gen weiterer Muster w hrend der Emulation ist jedoch nicht m glich F r KAuNET wird in Hal 12 durch Hall et al eine umfassende Analyse bzgl der Leistung und Genauigkeit vorgestellt Die Untersuchungen fi
224. ur Granularit t und Leistung von KAUNET einen Teil der Netzwerkeffekte verzichtet Es werden Techniken angewendet die die vorgege bene Topologie automatisiert vereinfachen mehrere Endsysteme auf einem einzelnen Rechner virtualisieren und synthetischen Hintergrundverkehr erzeugen Emulation Realer Rechner Core Router Core Router VN1 VN2 ee 1 pipe VN3 V ch f Core Cluster Abbildung 3 10 Schematischer Aufbau von MopDELNET am Beispiel mit drei virtual edge nodes VN auf zwei Realen Rechner und einem Core Router Cluster mit drei Rechnern VN 1 und VN 2 verbinden sich parallel ber teilweise unterschiedliche Pipes mit VN 3 Der Aufbau von MoDELNET ist in Abbildung 3 10 schematisch dargestellt Dieser unterteilt sich in virtuelle Endsysteme als virtual edge node VN bez und in Server welche die eigentliche Emulation durchf hren und als Core Routers bezeichnet werden Letztere basieren auf DuUMMYNET und arbeiten mit modifizierten FREEBSD Kerneln Die Virtualisierung der Endsysteme basiert auf der Zuweisung von mehreren IP Adressen zu einer einzelnen Netzwerkkarte IP Aliasing Routing Tabellen und einem Verfahren um Systemkommandos mit eigenen Kommandos zu verkn pfen Library Interposition Der Begriff virtuell
225. worten 2 2 2222 120 A 2 Konfigurationsdatei f r die Netzwerkeinstellungen 2 121 A 3 Konfigurationsdatei f r die Angabe von Messparametern 122 A 4 Vorfelduntersuchungen Grundverz gerungen 123 A5 Messung Datenrate a eke a ds So ie ee ee e a 124 A 6 Messung Verz6gerungen 2 0 a 125 A 7 Messung Neuordnung 126 AS Erkl rung zum Urheberrecht u 24 840 6 040 220 OS EE SS 127 ET E ONE 129 B9 Liter t rv zeichnis o hie HSS ee SRS DOS REE SSE AY BS 129 B 10 Quellenverzeichnis 131 iv Abk rzungsverzeichnis BER BPS BTT CDF CoDVwBMA CoTV CoV CT FIFO GPS GUI ICMP IP LEm Bit Error Rate dt Bitfehlerrate siehe Seite 16 27 34 38 40 42 Bits Per Second dt Bits pro Sekunde oder Datenrate siehe Seite 26 77 78 Bulk TCP Throughput dt Massendurchsatzrate maxima le Durchsatz bei TCP Verbindungen siehe Seite 13 40 44 Cumulative Distribution Function dt kumulierte Vertei lungsfunktion siehe Seite 80 107 Coefficient of Delay Variation with Blocking Moving Ave rage dt Variationskoeffizient der Verz gerungen mit blo ckierendem gleitendem Mittelwert siehe Seite 61 81 82 107 Coefficient of Throughput Variation dt Variationskoeffi zient des Datendurchsatzes siehe Seite 46 48 50 56 61 81 115 Coefficient of Variation dt Variationskoeffizient siehe Seite 81 108 Cross Traffic
226. ww tcpdump org besucht am 23 12 2012 siehe S 32 132 B 10 Quellenverzeichnis 13a 13b 13c 13d 13e 13f 13g 13h 13i 13j 13k 131 13m 13n 130 13p Apposite s Linktropy and Netropy WAN emulators simulate bandwidth delay loss and other network impairments 2013 URL http www apposite tech com index html besucht am 13 05 2013 siehe S 23 CT503 MIX High Speed LANforge FIRE Traffic Generator 2013 URL http www candelatech com ct503 MIX_product php besucht am 02 12 2013 siehe S 68 Emulab Network Emulation Testbed Home 2013 URL http www emulab net besucht am 07 09 2013 siehe S 23 FreeBSD Jails 2013 URL http www freebsd org doc de_DE IS08859 1 books handbook jails html besucht am 06 09 2013 siehe S 19 39 Google Scholar 2013 URL http scholar google de besucht am 07 09 2013 siehe S 23 24 Google Trendanalyse bzgl Dummynet Netem Modelnet NetPath Emulab 2013 URL http www google de trends explore q Dummynet q Dummynet 20Netem 20Modelnet 20NetPath 20Emulab amp cmpt q besucht am 07 09 2013 siehe S 24 Grid 5000 a scientific instrument designed to support experiment driven research in all areas of computer science related to parallel large scale or distributed computing and networking 2013 URL
227. zeigt sich wie bei den Untersu chungen zur Grundverz gerung dass die Genauigkeit abh ngig von der Paketgr e ist Je gr er ein Paket ist desto deutlicher weichen die Werte von der Vorgabe ab Konkrete Wertangaben bzgl dem CoV befinden sich in den Tabellen 8 7 welche als Heatmap dargestellt sind Je dunkler eine Zelle in der Tabelle ist desto gr er ist der Wert des Variationskoeffizienten und damit die Abweichung vom Erwartungswert bzw der Vorgabe F r einen Vergleich werden in der selben bersicht die CoV Werte der Verz gerungen f r die Vorgaben 10 ms 100 ms und 1000 ms gezeigt Hierbei sind die Abweichungen f r die Software Emulatoren deutlich zur ckgegangen was zum einen auf die geringere Gewichtung der Werte in Bezug auf den hohen Erwartungswert und zum anderen auf die steigende Unabh ngigkeit von der Taktrate zur ckzuf hren ist In Bezug auf die Pfadverkettungen ist auch hierbei eine Abh ngigkeit von der Puffergr e zu erkennen Liegt der Paketstand um ein Vielfaches niedriger als die Verz gerung so steigt die Gefahr dass die Puffer nicht mehr ausreichen da zun chst alle auftreffenden Pakete in den Pipes zwischengespeichert werden m ssen Speziell bei KAUNET treten hohe Paketverluste auf wodurch eine Betrachtung und ein Vergleich der Messwerte hinf llig wird Anders verh lt es sich dagegen bei DUMMyYNET Die Werte f r die Untersuchungen mit zehn Pfadabschnitten welche jeweils eine Verz gerung von 10 ms verurs
228. zu z hlt z B WANEM 13z welcher ebenfalls in die Auswahl aufgenommen wird F r diesen Emulator lassen sich genauso wie beim Linktropy 7500 Pro keine direkten Analysen zur Genauigkeit oder Leistung finden jedoch zeichnet sich WANEM durch eine umfangreiche Dokumentation mit Leistungswerten aus 984 1000 T g 800 J R N 600 522 J a 8 400 J S 262 lt 200 J 49 0 6 22 8 NISTNet Dummynet ModelNet KauNet NetEm WanEm Netpath Imunes Abbildung 3 2 Anzahl der Zitationen f r ausgew hlter Emulatoren Quelle 13e Abseits der Trendanalyse wird ein weiterer Emulator namens NETPATH ausgew hlt Dessen Entwickler betonen dass NETPATH andere Emulationssysteme deutlich bertrifft 13r S 11 3 2 Produktpublikationen und dokumentationen 25 Die bisher gew hlten Emulatoren geh ren zur Klasse der NLE vgl Abschnitt 2 5 Um eben falls Emulatoren aus dem Bereich der VNE analysieren zu k nnen werden das frei verf gbare MOoDELNET und Imunes mit in die Auswahl aufgenommen Letzterer wurde in neueren Arbeiten oft zitiert und verspricht eine sehr einfache Konfiguration von Netzwerktopologien Zusammengefasst ergeben sich f r die Untersuchungen die folgenden Emulatoren Linktropy 7500 Pro ohne Analysen DUMMYNET KAUNET MODELNET NETEM WANEM ohne Analysen NETPATH IMUNES 3 2 Produktpublikationen und dokumentationen Bevor im Einzelnen auf die jeweiligen Analysen bzw Produ

und Leistungsanalysen von Netzwerkemulatoren

Contents

Download Pdf Manuals

Related Search

Related Contents