Master Thesis. im Studiengang. Master of Science in Computer Science. von. Marco Spina. Erstbetreuer: Prof. Dr. Martin Leischner, FH Bonn

Transkript

1 Fachbereich Informatik Department of Computer Science Master Thesis im Studiengang Master of Science in Computer Science Analyse von passiven Methoden zum kundenorientierten Round-Trip-Time Monitoring für den Einsatz bei einem Internet-Service-Provider von Marco Spina Erstbetreuer: Prof. Dr. Martin Leischner, FH Bonn Zweitbetreuer: Prof. Dr. Kerstin Uhde, FH Bonn Externer Betreuer: Dr. Jörg Hagemann, T-Mobile Eingereicht am: 31. August 2006

2 Inhaltsverzeichnis Zusammenfassung... 8 Abstract Einleitung Motivation Zielsetzung Vorgehensweise der Arbeit Verwandte Arbeiten Grundlagen und Vergleich der Konzepte der passiven Methoden Mit passiven Methoden von der Verkehrs- zur heutigen Leistungsmessung Verkehrsmessung Leistungsmessung Grundlagen Definition der RTT nach RFC Erfasster IP-Verkehrsanteil und erfasste Anwendungen Funktionsweise des Transportschicht-Protokolls TCP TCP/IP und Netzwerk bewirkte Probleme der passiven RTT-Messung Vergleich der Konzepte passiver Methoden zur RTT-Bestimmung Intern oder extern Ort bzw. Orte der zeitsynchronisierten Messgeräte Uni- oder bidirektionaler Verkehrspunkt Granularität Zusammenfassung der Probleme passiver RTT-Bestimmung Theoretische -, praktische Analyse und Bewertung der Implementierungen passiver RTT-Messmethoden des direkten Messkonzepts im Netzwerkbereich Theoretische Analyse Ausschluss der TCP-Stack Methode Vergleichskriterien der theoretischen Analyse Caller->Callee unidirektionale einmalige RTT-Messmethode nach Jiang u.a Callee->Caller unidirektionale einmalige RTT-Messmethode nach Jiang u.a Bidirektionale kontinuierliche RTT-Messmethode nach Veal u.a Unidirektionale kontinuierliche RTT-Messmethode nach Veal u.a Bidirektionale kontinuierliche RTT-Messmethode nach Jaiswal u.a Sonderfälle der fünf passiven RTT-Messmethoden Zusammenfassung Praktische Analyse Marco Spina 2

3 3.2.1 Vergleich mittels Untersuchung im Labor Wahl und Beschreibung des Messaufbaus Wahl der Messparameter Kalibrierung Wahl der Verkehrslast Messschritte und Messsystemsteuerung Messbereich einschränkende Aufrufparameter Messergebnisse Zusammenfassung Bewertung Bewertungskriterien Bewertungsmatrix ISP-Szenarien des passiven kundenorientierten RTT-Monitorings Ausgangsszenario Private und öffentliche Standortvernetzung des ISPs Private Vernetzung Standortverbindung über öffentliche Netze mittels VPN Einfache und redundante Anbindungsknoten Messung im Ausgangsszenario einer einfacher Anbindung Redundante Anbindungen Ressourcenbedarf des Monitors im Online Fall Skalierbarkeit Aggregation der Ergebnisse Einsatz mehrerer Monitore Einbindung ins NMS Multi-ISP Szenario Zusammenfassung und Empfehlung Fazit und Ausblick A Anhang A.1 Liste der eingesetzten SW für den Messaufbau A.2 Weitere Messergebnisse der 512 Bytes Rahmengröße Marco Spina 3

4 Abbildungsverzeichnis Abbildung 1 Übertragungszeit über Einwegverzögerung bzw. RTT und Bandbreite Abbildung 2 Szenario eines ISP, welcher mehrere Firmenstandorte vernetzt, im Zusammenhang des kundenorientierten Monitoring der RTT und des SLA Abbildung 3 Definition der RTT als Leitungs-RTT und die messbare Rechner-RTT Abbildung 4 Typischer Verbindungsablauf bei TCP Abbildung 5 Phasen der Überlastkontrolle von TCP, aus [Leischner 2004] Abbildung 6 IP- und TCP-Header-Felder zur Zuordnung von RTTs und Verbindungen Abbildung 7 Monitorkomponenten MS1 u. MS2 aus Netzwerkbetriebsmitteln Abbildung 8 Monitorkomponenten MS1 u. MS2 ohne Netzwerkbetriebsmittel Abbildung 9 Konzepte der RTT im Netzwerkpfad Abbildung 10 Arbeitsbereich der passiven Methoden SA, SS, ts3w, tssc, Cwnd Abbildung 11 Funktionsprinzip der SA RTT-Messmethode Abbildung 12 HTTP-request sanity check der SA Methode Abbildung 13 Funktionsprinzip der SS RTT-Messmethode Abbildung 14 SYNACK-ACK sanity check der SS Methode Abbildung 15 Funktionsprinzip der ts3w RTT-Messmethode Abbildung 16 Self-clocking Muster, welches die tssc Methode nutzt Abbildung 17 Autokorrelationsmaxima im Abstand von RTT für einen Zeitabschnitt Abbildung 18 Funktionsprinzip der Cwnd RTT-Messmethode Abbildung 19 Verlustfall bei der SA Methode Abbildung 20 Verlustbeispiele bei der SS Methode Abbildung 21 Verlustbeispiel bei der ts3w Methode Abbildung 22 Beispiele für die verzögerte Bestätigung Drei-Wege-Handschlag Abbildung 23 Aufbau für die Messung im Labor Abbildung 24 Kalibrierungskurve von NISTNet bei einer Verbindung Abbildung 25 NISTNet Kalibrierungskurve für bis zu zehn gleichzeitigen Verbindungen Abbildung 26 Mittelwerte der Implementierungen bei 1500 Bytes und 2% Verlust Abbildung 27 Minimum der RTTs der Implementierungen bei 1500 Bytes u. 2% Verlust Abbildung 28 Standardabweichung der Implementierungen bei 1,5 KBytes u. 2% Verlust Abbildung 29 Anzahl Einzelwerte der Implementierungen bei 1,5 KBytes u. 2% Verlust Abbildung 30 StdAbw.-Verhältnis der Implementierungen bei 1,5 KBytes u. 2%Verlust Abbildung 31 Relativer Fehler des Mittelwertes bei 1,5 KBytes u. 2% Verlust Abbildung 32 Variationskoeffizient der Implementierungen bei 1,5 KBytes u. 2% Verlust Abbildung 33 Relativer Fehler für 94 % aller Werte bei 1,5 KBytes u. 2% Verlust Abbildung 34 Mittelwerte der Implementierungen bei 512 Bytes und 2% Verlust Abbildung 35 Mittlere Zeit der Implementierungen zur Offline-Bestimmung einer RTT Marco Spina 4

5 Abbildung 36 Mittlere Anzahl an Paketen/s, welche die Implementierungen verarbeiten Abbildung 37 Szenario zweier Niederlassungen mit Firmenzentrale vernetzt mittels ISP Abbildung 38 Durch ISP verwaltetes VPN (blau) Abbildung 39 Monitorplatzierung im Ausgangsszenario bei einfacher Anbindung Abbildung 40 Standardabweichung der Implementierungen bei 512 Bytes u. 2% Verlust Abbildung 41 Minimum der RTTs der Implementierungen bei 512 Bytes u. 2% Verlust Abbildung 42 Anzahl Einzelwerte der Implementierungen bei 512 Bytes u. 2% Verlust Abbildung 43 StdAbw.-Verhältnis der Implementierungen bei 512 Bytes u. 2%Verlust Abbildung 44 Relativer Fehler des Mittelwertes bei 512 Bytes u. 2% Verlust Abbildung 45 Variationskoeffizient der Implementierungen bei 512 Bytes u. 2% Verlust Abbildung 46 Relativer Fehler für 94 % aller Werte bei 512 Bytes u. 2% Verlust Tabellenverzeichnis Tabelle 1 Vor-/Nachteile, des Zeitaspekts u. Monitorplatzes, der Konzepte passiver Methoden Tabelle 2 Tabelle mit der Verteilung der Granularität der timestamps Tabelle 3 Anwendbarkeitsergebnisse und Vorgehensweise durch die Autoren Tabelle 4 Bewertungsmatrix aus theo. u. prak. Methoden- bzw. Implementierungs-Analyse Gleichungsverzeichnis Gleichung 1 Gleichung der Uhrzeit einer realen Uhr Gleichung 2 RTT-Messgenauigkeit aus zwei Einwegmessungen mit synchronen Uhren Gleichung 3 RTT-Messungsgenauigkeit bei der direkten Messung mit einer Uhr Gleichung 4 Pseudocode der SA RTT-Messmethode Gleichung 5 Pseudocode der SS RTT-Messmethode Gleichung 6 Pseudocode der ts3w RTT-Messmethode Gleichung 7 Pseudocode der tssc RTT-Messmethode Gleichung 8 Pseudocode der Cwnd RTT-Messmethode Gleichung 9 Gleichung zur tcpdump Kalibrierung Marco Spina 5

6 Abkürzungen und technische Begriffe accounting Abrechnung accuracy Genauigkeit, Abweichung der Uhr zur Coordinated Universal Time (UTC) ACK Bestätigungssegment Ajax Asynchronous JavaScript and XML AS Autonomes System ASP Application Service Provider backbone Kernnetz callee Server bzw. Aufgerufener caller Client bzw. Aufrufer CW Cable and Wireless cwnd Congestion window bzw. Überlastfenster delayed verzögerte duplicate wiederholte EASLA end-to-end SLA between an end user and an ASP flow Verkehrsfluss, Datenstrom Frontend-Server Eingangs-Server, z.b. Webserver bei nachgelagertem Datenbankserver GLBP Gateway Load Balancing Protocol GPS Global Positioning System header Nachrichtenkopf HW Hardware ICMP Internet Control Message Protocol icwnd initiale Überlastfenster IETF Internet Engineering Task Force immediate sofortige IP Internet Protokoll IPPM IP Performance Metrics ISP Internet Service Provider link Verknüpfung MEZ Mitteleuropäische Zeit MIB Management Information Base monitoring Überwachung MSS Maximum Segment Size N Nachteile NAT Network Address Translation NLANR National Laboratory for Applied Network Research NMS Network Management System NNTP Network News Transfer Protocol NS Network Simulator NTP Network Time Protocol OSI Open Systems Interconnection payload Nutzlast performance Leistung piggy-back Huckepack request Anfrage Marco Spina 6

7 resolution ressourcen RMON rsh RTFM RTO RTT SA skew SLA SNMP SS SW synchronisation TCP TOS ts3w tssc V VoIP VPN workload Auflösung einer Uhr z.b. sec. oder ms Betriebsmittel Remote Monitoring remote shell Realtime Traffic Flow Measurement Retransmit Timeout Interval Round Trip Time SYN-ACK Drift, Veränderung der accuracy Service Level Agreement Simple Network Management Protocol Slow-Start Software Abweichung zwischen zwei Uhren Transport Control Protocol Type of Service timestamp-3-way timestamp-self-clocking Vorteile Voice over IP Virtuelles Privates Netzwerk Verkehrslast Marco Spina 7

8 Zusammenfassung Diese Arbeit ist in fünf Kapiteln unterteilt. Das erste Kapitel zeigt die Problemstellung der kundenorientierten Überwachung der RTT im Szenario eines ISPs und den Lösungsansatz mit passiven Methoden auf. Es folgen die Abschnitte zur Zielsetzung der Arbeit, der Vorgehensweise und den verwandten Arbeiten. Im Abschnitt der verwandten Arbeiten werden Quellen vorgestellt, die sich mit den Methoden der RTT-Bestimmung bei ISPs beschäftigen. Das zweite Kapitel stellt die Grundlagen und die Bedeutung der RTT und dessen passives Monitoring dar. Darin wird die ursprüngliche Verwendung der passiven Methoden zur Charakterisierung des Verkehrs bzw. der Abrechnung (engl. accounting) aufgezeigt und die RTT definiert. Aus der Definition werden die TCP Anwendungen wie z.b. HTTP, FTP, SMTP sowie Ajax-HTTP aufgeführt, welche als IP Anwendungen erfasst werden können. Es werden die Probleme der RTT-Bestimmung erarbeitet und in die TCP/IP und Netzwerk bedingten Gruppen eingeteilt. Diese sind Neuübertragung bzw. Paketverlust, Datenbündelung, Bestätigungsstrategien der verschiedenen TCP-Implementierungen, interaktive Anwendungen und Umordnung der Reihenfolge der Segmente in den Bündeln. Eine weitere Gruppe der konzeptionell bedingten Probleme wird im Konzeptvergleich der passiven Methoden zur RTT-Bestimmung aufgedeckt. Mittels des Konzeptvergleichs wird weiterhin, aus der direkten und indirekten RTT-Messung, die direkte nachfolgend untersucht. Dies liegt daran, dass der direkten RTT-Messung eine Messuhr genügt und damit ein Synchronisationsversatz zweier Messuhren nicht in das Messergebnis einfließt. Im dritten Kapitel werden fünf Open-Source-Implementierungen, des direkten passiven RTT- Messkonzepts im Netzwerkbereich, theoretisch und praktisch analysiert. Im theoretischen Teil werden dazu die fünf Implementierungen beschrieben und miteinander verglichen. Dazu wird deren Umgang mit den Problemen der TCP/IP- und Netzwerk-Gruppe erörtert. In der praktischen Analyse werden erstmals die Implementierungen unter gleichen Voraussetzungen auf deren Verarbeitungsgeschwindigkeit und Messgenauigkeit untersucht. Die praktische Betrachtung der Messgenauigkeit wird, aufgrund der unterschiedlichen Verifikationsansätze als auch Messergebnisdarstellung der Autoren, erforderlich. Für die praktische Analyse wird ein Messsystem entwickelt und benutzt, welches einen einheitlichen und direkten Verifikationsansatz fürs Labor umsetzt. Dieser ermöglicht den Vergleich der Messwerte mit Referenzwerten. Im Unterschied zu den Labormessungen der Autoren werden hier Kalibrierungsdaten berücksichtigt, welche eine optimierte Bestimmung der Messgenauigkeit zulassen. Die Leistungskennzahlen der Implementierungen der Methoden werden erstmals ermittelt, da es von den Autoren dazu keine Aussagen gibt. Eine abschließende Bewertung umfasst die Erkenntnisse beider Analysen. Darin wird die Bedeutung des Differenzierungsmerkmals des Mittelwerte und des Minimums der RTTs für die Methoden herausgestellt. Die Ergebnisse werden soweit vergleichbar den Ergebnissen der Autoren gegenübergestellt. Marco Spina 8

9 Das nächste Kapitel stellt Beispielszenarien eines ISPs vor. In diesen werden die Einsatzmöglichkeiten des Monitors aufgezeigt. Darüber hinaus werden die qualitativen und quantifizierten Bewertungsergebnisse der Analysen zur Empfehlung einer Implementierung einer passiven RTT-Messmethode für ein Firmenanbindungsszenario verwendet. Aufgrund der Leistungskennzahlen der Methoden mit heute üblicher PC-HW wird die Anbindungsbandbreite von 100 Mbit/s als Echtzeit bzw. Online verarbeitbar festgehalten. Dies entspricht einer Verarbeitungsgeschwindigkeit von ca Paketen/s bei Verbindungen/s und einer vollständigen Speicherzeit von 11,5 Tagen. Für Trendermittlung wird ein Jahresumfang bestätigt. Wird die Messgenauigkeit mitbetrachtet, bleibt die Slow Start Implementierung der passiven RTT-Messmethode von [Jiang u. a. 2002] für das ISP- Szenario zu empfehlen. Ihr relativer Fehler des Mittelwertes ist 2%, während der Variationskoeffizient 0,3% beträgt. Beide Kennzahlen gelten für 94% der Messwerte. Die Messgenauigkeit liegt somit im akzeptablen Bereich für die Beteiligten. Das fünfte und letzte Kapitel kommt zum Fazit, dass die passiven RTT-Messmethoden gegenüber den aktiven Methoden gleichberechtigt sind und darüber hinaus kundenorientiert arbeiten. Der Ausbau der passiven Methoden von der Verkehrs- zur Leistungsmessung bei den ISPs wird als konsequenter Folgeschritt festgehalten, welchen allen Beteiligten Vorteile bringt. Der Ausblick regt die Implementierung der Onlinefunktionalität an und sagt den passiven RTT-Messmethoden ein gutes Wirtschaftspotenzial voraus. Marco Spina 9

10 Abstract This work is divided into five chapters. The first chapter points the problem of the customeroriented monitoring of the RTT in the scenario of an ISP and the solution with passive methods. The next sections are the aim of the work, the proceeding and the related works. In the section of the related works sources are presented, which concern themselves with the methods of the RTT monitoring by ISPs. The second chapter represents the basics and the meaning of the RTT and its passive monitoring. Therein the original use of the passive methods is pointed out for the characterisation of traffic and/or the accounting and the RTT is defined. Due to the RTT definition, the TCP applications e.g. HTTP, ftp, smtp as well as Ajax HTTP are specified as the analysable IP applications. The problems of the passive RTT monitoring are devided in the TCP/IP and network caused groups. The problems are retransmission and/or packet loss, data bundling, confirmation strategies of the different TCP implementations, interactive applications and rearranging of the sequence of the segments in the bundles. A further group of the conceptionally caused problems is uncovered in the concept comparison of the passive methods of the RTT monitoring. By means of the concept comparison of the direct and indirect RTT measurement, the decision to examine the direct is followed. This is because of the fact that a clock meets the direct RTT measurement, so that a synchronisation disalignment of two clocks does not influence the result of measurement. In the third chapter five open-source implementations of the direct passive RTT measuring concept within the network, are analyzed theoretically and practically. In the theoretical part the five implementations are described and compared. In addition their handling of the problems of the TCP/IP- and of the network-group is discussed. In the practical analysis the implementations are examed for the first time under same conditions about their speed of operation and measuring accuracy. The practical analysis of the measuring accuracy is necessary, due to the different verification methods and result representations of the authors. For the practical analysis a measuring system is developed and used, which realises a uniform and direct verification method for the laboratory. This makes the comparison of the measured values with reference values possible. In contrast to the laboratory measurements of the authors calibration data are considered here, which permit an optimized determination of the measuring accuracy. Achievement of speed operation numbers of the implementations of the methods are determined for the first time, since there are no statements from the authors to it. A evaluation covers the results of both analyses. Therein the meaning of the average values and the minimum of the RTTs is outlined. The results are confronted, so far comparably, to the results of the authors. The next chapter presents example scenarios of a ISPs. In these the delopyment of the monitor are shown. Beyond that, the qualitative and quantified evaluation results of the analyses are used for the recommendation of an implementation of a passive RTT measuring method, for a firm binding scenario. Due to the speed operation numbers of the methods with today usual PC-HW the binding bandwith of 100 Mbit/s for real time analysis is calculated. This corresponds to a speed of operation of approx. 269,000 pakets/s with connections/s and a complete storage time of 11,5 days. For trends a yearly scale Marco Spina 10

11 is confirmed. If the measuring accuracy is regarded, the slow start implementation of the passive RTT measuring method of [Jiang et.al. 2002] remains to recommend for the ISP scenario. Its relative error of the average value is 2%, while the Variationskoeffizient amounts to 0.3%. Both characteristic numbers apply to 94% of the measured values. The measuring accuracy thus is within an easy acceptable range for the involved partners. The fifth and last chapter comes to the fact that the passive RTT measuring methods are equal to the active methods and beyond work customer-oriented. The development of the passive methods from traffic- to the power-measurement by the ISPs is held as consistent subsequent step, which brings advantages to all involved partners. The view energizes the implementation of the online functionality and forecasts the passive RTT measuring methods a good economical potential. Marco Spina 11

12 1 Einleitung 1.1 Motivation Internet Service Provider (ISP), welche die verschiedenen Standorte einer Firma anbinden, siehe Abbildung 2, schließen in einem Service Level Agreement (SLA) feste Dienstgüten für das Verbindungsnetz ab. Die vereinbarte Netz-Dienstgüte dient dem Betrieb von Anwendungen. Der Betrieb der Anwendungen soll damit im Rahmen der Erwartungen der Firma liegen. Die Firma tritt dabei dem ISP als Kunde gegenüber. Die Verletzung der vereinbarten Netz-Dienstgüte führt zu einer Vertragsstrafe, daher muss die Netz-Dienstgüte durch Monitoring (Überwachung) sichergestellt werden. Die Überwachung dient sowohl dem Kunden als auch dem ISP. Dem Kunden werden durch die Überwachung Berichte zur Verfügung gestellt. Dem ISP hingegen dient die Überwachung dem Betrieb, der Planung und der Entwicklung der Infrastruktur. Die Netz-Dienstgüte wird beispielsweise mit netzwerkcharakteristischen Parametern wie der Round Trip Time (RTT) bzw. der Einwegverzögerung, dem Paketverlust und der Bandbreite festgelegt. Die RTT entspricht dabei der Zeit, die ein Paket vom Client zum Server (Einwegverzögerung) und zurück braucht. Vergleicht man die Parameter, sprechen mehrere Argumente dafür, dass die RTT ein besonders wichtiger Parameter ist. So sind vom Paketverlust im Normalfall nur einzelne Pakete betroffen, während von der RTT alle betroffen sind. Die Bandbreiten sind in den letzten Jahren kontinuierlich gestiegen und steigen weiter. Im ISP Bereich liegt die Bandbreite bei mehreren Gbit/s. Firmen werden bereits mit Bandbreiten von 100 Mbit/s und mehr angebunden. Bei diesen Netzwerken wird, die für den Kunden relevante Übertragungszeit jedoch von der Einwegverzögerung und nicht von der Bandbreite bestimmt. Da die RTT der Einwegverzögerung für Hin- und Rückpfad entspricht, gilt das Gleiche für RTT und Bandbreite. Veranschaulicht wird dies in Abbildung 1 aus [Tanenbaum A.S. 2003] S Im Diagramm wird die Übertragungszeit einer 1 Mbit-Datei abhängig von der Bandbreite dargestellt. Übertragungszeit [ms] Einwegverzögerungsanteil Bandbreite [Bit/s] Abbildung 1 Übertragungszeit über Einwegverzögerung bzw. RTT und Bandbreite Marco Spina 12

13 Auch die Bestrebung das Netz vom Best-Effort Prinzip wegzuführen, hebt die Bedeutung der RTT an. Die RTT beeinflusst ein breites Spektrum an Anwendungen. Es reicht von der Echtzeitanwendung bis zur unkritischen HTTP Anwendung. Aufgrund der besonderen Rolle der RTT, ist deren Überwachung immer notwendig. Die RTT wird in den Endrechnern berechnet, welche an einer Verbindung beteiligt sind. Auf diese RTT-Werte kann jedoch nicht zugegriffen werden. Um ohne Änderung der Endrechner auszukommen, ergibt sich der Bedarf die RTT gesondert zu ermitteln. Die Methoden, welche die RTT bestimmen, lassen sich in aktive und passive Methoden einteilen. Die aktiven Methoden generieren Testverkehr. Durch den generierten Testverkehr wird der Startzeitpunkt der RTT-Messung vorgegeben und dessen Stoppzeitpunkt einfach ableitbar. Eine aktive Methode ist beispielsweise ping, welches auf der IP Schicht (S3) arbeitet. Die aktive Methode hat zwei Nachteile. Der zusätzlich generierte Testverkehr beeinflusst das zu messende System und er weicht vom Kundenzugriffmuster ab. Die passiven Methoden eliminieren diese Nachteile, indem sie den tatsächlichen Nutzerverkehr und damit genau das Kundenzugriffmuster messen. Dazu beobachten die passiven Methoden den Nutzerverkehr hauptsächlich auf der TCP Schicht (S4). Außerdem bieten sie den wichtigen Vorteil der flexiblen Platzierung des Monitors. Der Monitor kann sich nämlich bei manchen passiven Methoden, an einer beliebigen Stelle auf dem Weg zwischen den Endrechnern Client und Server des Kunden befinden. Bei den passiven Methoden ist es allerdings notwendig den Datenschutz sicherzustellen. Durch die Berücksichtigung der zwei Aspekte, nämlich des Kundenzugriffsmusters und der Gesamtstrecke zwischen den Kundenendrechnern (siehe Abbildung 2 E2E-Strecke), erhält der Kunde einen echten Mehrwert vom ISP als Netzwerkdienstleister. Damit bekommt das SLA für den Kunden aussagekräftigere Vereinbarungen, denn es erfasst die zwei zuvor genannten Aspekte, welche die Kundensicht widerspiegeln. Außerdem wird die Überwachung dadurch kundenorientiert und nicht rein netzwerkorientiert betrieben. In Abbildung 2 wird die Problemstellung der kundenorientierten Überwachung der RTT aufgezeigt. Es wird rot der bisher überwachte Bereich und grün der erweiterte Bereich durch die Verwendung des passiven Ansatzes dargestellt. Bei Client/Server Anwendungen mit einer drei- oder Mehrschichtenarchitektur, endet der überwachte Bereich am Frontend-Server (Eingangs-Server). Marco Spina 13

14 SLM: SLA NMS: Ende-zu-Ende Monitoring Bisheriges RTT Monitoring. Neuer Ansatz: Kundenorientiertes E2E RTT Monitoring. MS3 S5 - S7 S4: TCP S3: IP RTT E2E RTT ISP Statistik{RTT E2E, t } Folge{RTT E2E, t } S4: S4: TCP TCP L3: S3: IP IP MS2 MS1 S5 - S7 S4: TCP S3: IP S2 L2 S2 S2 Schicht 1 (S1) S1 L1 Schicht 1 (S1) Client Monitor Frontend-Server/ Server Kundennetz werk A Monitor Schicht 1 (MS1) : MS2: MS3: Internet - Service - Provider (ISP) Kundennetzwerk A Einzelmesswerterfassung. Aggregation zu Statistiken. Zentralisieren der Daten, Visualisierung und Management der Monitore, welche sich alle beim ISP befinden. Abbildung 2 Szenario eines ISP, welcher mehrere Firmenstandorte vernetzt, im Zusammenhang des kundenorientierten Monitoring der RTT und des SLA Von den passiven Methoden sind nun einige Varianten als Open-Source-Implementierungen verfügbar. Diese wurden allerdings noch nicht einer vergleichenden Analyse und Bewertung für das Szenario eines ISPs unterzogen. 1.2 Zielsetzung Im vorherigen Kapitel wurde die Problemstellung der kundenorientierten Überwachung der RTT im Szenario eines ISPs und der Lösungsansatz mit passiven Methoden aufgezeigt. Ziel der Arbeit ist es, für ein Firmenanbindungs-Szenario eines ISPs, eine passive Methode zum kundenorientierten Monitoring der RTT zu empfehlen. Die Empfehlung soll sowohl mit qualitativen als auch mit quantifizierten Vergleichsergebnissen belegt werden. 1.3 Vorgehensweise der Arbeit Die Vorgehensweise teilt sich in folgender Abfolge: 1) Problem- und Lösungsansatz-Darstellung. 2) Erarbeitung der Grundlagen und Bedeutung der RTT und dessen passives Monitoring. 3) Vergleich der Konzepte. Marco Spina 14

15 4) Erfassung der Probleme der passiven RTT-Messmethoden. 5) Theoretische und praktische Analyse der passiven RTT-Messmethoden unter Aufstellung und Begründung eines einheitlichen Verifikationsansatzes. 6) Darstellung von Firmenanbindungsszenarien durch einen ISPs. 7) Verwendung der qualitativen und quantifizierten Bewertungsergebnisse der Analysen zur Empfehlung einer Implementierung einer passiven RTT-Messmethode für ein Firmenanbindungsszenario. 8) Fazit und Ausblick. 1.4 Verwandte Arbeiten In diesem Kapitel werden Arbeiten vorgestellt, die sich mit den Methoden der RTT- Bestimmung bei ISPs beschäftigen. Es handelt sich um folgende Arbeiten bzw. Quellen [Cáceres u. a. 2000], [Cable and Wireless], [Cheng u. a. 2004] und [Chen u. a. 2002]. Die Quellen unterscheiden sich in dem Bereich, welcher durch die RTT erfasst wird und in den verwendeten Werkzeugen. In [Cáceres u. a. 2000] wird der Prototyp einer Infrastruktur zur Überwachung des kommerziellen IP-Netzwerks von AT&T vorgestellt. Die Infrastruktur überwacht die Verkehrsauslastung und die Leistung (engl. performance) des IP-Netzwerks. Es folgt ein Beispiel wie mittels der Analyse und Korrelation der zentralisierten Messdaten die Tarifstruktur angepasst wird, so dass eine gerechtere Nutzung des Netzes durch die Kunden möglich ist. In der Quelle wird damit die Bedeutung der Netzwerküberwachung für den Betrieb, die Planung und die Entwicklung hervorgehoben. In der Infrastruktur wird die RTT mit aktiven Methoden zwischen den Grenzroutern des AT&T Netzwerkes ermittelt [...] provides an infrastructure for measuring edge-to-edge performance of the IP backbone using a suite of active measurements. The system currently measures and reports round-trip packet delay [...] [Cáceres u. a. 2000] S. 148 Kapitel Active Measurements. Diese Arbeit wird im Vergleich zu [Cáceres u. a. 2000] einerseits den abgedeckten Bereich der RTT erweitern und andererseits das Kundenzugriffsmuster verwenden, wodurch eine höhere Kundenorientierung und Differenzierungsmöglichkeit bei SLAs entsteht. Eine weitere Quelle ist [Cable and Wireless]. Die Kunden und registrierten Benutzer bei Cable and Wireless (CW) können eine https-webseite einsehen, in welcher RTT- Leistungswerte aus zwei Bereichen stehen. Zum einen handelt es sich um die RTT innerhalb des CW-IP-Backbones (deutsch: Kernnetz) und zum anderen um die RTT über das CW-IP- Backbone zu bestimmten Webseiten. Diese Webseiten gehören nicht zum CW-Netzwerk, sondern sind eine Auswahl der beliebtesten Webseiten aus zehn Branchen. Die Liste wird von dem unabhängigen Institut Nielsen Net Ratings erstellt. CW überwacht, berichtet und garantiert die Leistungswerte gegenüber seinen Kunden. CW bietet ihnen eine Rückzahlung an, wenn die Leistungsdaten die SLAs verletzen. Mit der Erfassung der Leistungsdaten zu den Marco Spina 15

16 Branchenwebseiten wird über den netzwerkbezogenen Dienst hinaus, ein kundenbezogener Verbindungsdienst, erbracht. Zur Messung kommen die Werkzeuge ping und traceroute zum Einsatz. Diese gehören zu den aktiven Methoden. Die Unterschiede zwischen dieser Arbeit und [Cable and Wireless] sind die selben, welche bei [Cáceres u. a. 2000] genannt sind. Die Arbeit [Cheng u. a. 2004] stellt fest, dass beim Einsatz und Management von SLAs, Metriken und Bewertungsmethoden der Netzwerk- und Anwendungs-Qualität nötig sind. Es definiert die RTT und die Bedienrate einer Webanwendung. Beide Größen sind dabei kundenorientiert definiert. In den beschriebenen SLAs, wird die RTT über die gesamte Strecke zwischen dem Client und dem Server erfasst. Man findet diese Verträge beispielsweise zwischen Kunden und Application Service Provider (ASP) [ ] especially in SLA for network services, there still exist many issues without common understandings, such as the definition of end-to-end performance metrics for end-to-end SLA between an end user and an ASP (called as EASLA). [Cheng u. a. 2004] S. 409 Kapitel Introduction. Des Weiteren wird die RTT hier passiv, während des 3 Wege-Handschlags 1 im TCP Verbindungsaufbau, auf der Clientseite ermittelt. Im Vergleich zu [Cheng u. a. 2004] werden in dieser Arbeit Implementierungen von passiven Methoden zur RTT-Bestimmung betrachtet, die an einer beliebigen Stelle auf dem Weg zwischen Client und Server platzierbar sind. Damit wird es auch für einen ISP möglich den kundenorientierten Dienst anzubieten. Die nächste Arbeit [Chen u. a. 2002] stellt eine Übersicht über die verschiedenen Möglichkeiten des Monitorings in IP-Netzen im Internet dar. Aufgrund der steigenden Vielfalt an Diensten im Internet wird über eine erhöhte Forschungstätigkeit im Bereich der Verkehrsmessung und Internetleistungsmessung berichtet. Es werden Projekte und Werkzeuge zur Leistungsmessung behandelt. Die behandelten Messungen reichen von einer lokalen bis zu einer globalen Abdeckung. Der Zweck stattdessen reicht von der lokalen verbreiteten, passiven, Router-basierten, Verkehrsfluss-Messung bis zur globalen aktiven Leistungsmessung. Die Werkzeuge und deren Methoden werden anhand der Schicht des OSI- Referenzmodells erörtert, auf der ihre Analyse basiert. Dabei werden Stärken und Schwächen der Methoden aufgezeigt. Die RTT wird aktiv bestimmt. Hierbei werden Methoden verwendet, welche auf der dritten und vierten Schicht basieren. Werkzeuge der dritten Schicht sind ping und seine Varianten. Aus der vierten Schicht gibt es Client/Server-basierte Test- Software wie NetPerf oder nur clientseitige Software wie NetIQ/Qcheck. Bei den aktiven Methoden wird das Problem der Last gesehen. Bei den passiven Methoden wird hingegen der hohe Rechenaufwand bemängelt. In [Chen u. a. 2002] wird erklärt, dass The measurement can be made [...] passively by marking DATA packets with a unique identification that can be recognized by the measurement points. [...] However, the practical problem of uniquely marking packets to enable measurements is constrained by existing protocols that have not allocated a packet 1 3 Wege Handschlag ist erklärt in Kapitel Marco Spina 16

17 header field for this purpose. [...] Hence, passive performance measurements are not used in practice. [Chen u. a. 2002] S. 5 Kapitel Router-Based Passive Measurements. Diese Arbeit behandelt die Implementierung einer passiven RTT-Messmethode, welche die Einschränkung eines Feldes zur Assoziation zwischen Paket und zugehörigem Antwortpaket löst. Der nächste Einwand zum Rechenaufwand der passiven Methoden bezieht sich auf die Verkehrslastanalyse. Die Notwendigkeit hingegen die benötigten Betriebsmittel (engl. ressourcen) zu bestimmen, ist ein berechtigter Punkt des Autors und wird daher in dieser Arbeit im Kapitel 4.4 berücksichtigt. Marco Spina 17

18 2 Grundlagen und Vergleich der Konzepte der passiven Methoden Dieses Kapitel stellt die Grundlagen und ein Vergleich der Konzepte der passiven Methoden dar. Darin wird die ursprüngliche Verwendung der passiven Methoden zur Verkehrmessung bzw. der Abrechnung (engl. accounting) und der Leistungsmessung aufgezeigt und die RTT definiert. Es werden die Probleme der RTT-Bestimmung erarbeitet und in die TCP/IP und Netzwerk bedingten Gruppen eingeteilt. Eine weitere Gruppe der konzeptionell bedingten Probleme wird im Konzeptvergleich der passiven Methoden zur RTT-Bestimmung aufgedeckt. Mittels des Konzeptvergleichs wird weiterhin, aus der direkten und indirekten RTT-Messung, die vorteilhaftere im Kapitel 3 untersucht. 2.1 Mit passiven Methoden von der Verkehrs- zur heutigen Leistungsmessung Die passiven Methoden sind ursprünglich als Methoden zur Verkehrsmessung entstanden. Die Verkehrsmessung teilt sich in die Messung der Verkehrslast (engl. workload) und des Verkehrsflusses (engl. flow) auf. Der Zweck dieser Teilung liegt in der Messung des Verkehrs aus Netzwerksicht und zur Abrechnung, wobei die Messung des Verkehrs aus Netzwerksicht mit der Verkehrslastmessung abgedeckt wird, während die Abrechnung mit der Verkehrsflussmessung erfolgt. Zu diesen Einsatzfeldern aus der Vergangenheit, werden die passiven Methoden heute auch in der Messung der Leistung (engl. performance) des Netzes eingesetzt Verkehrsmessung Die Messung der Verkehrslast und des Verkehrsflusses unterscheidet sich in der Granularität und in den verwendeten Statistiken. Ferner bezieht sich die Verkehrslast auf den Verkehr an der physikalischen Netzwerkschnittstelle, der Verkehrsfluss hingegen auf den Verkehr einer logischen Verbindung. Als Standard gibt es das Remote Monitoring (RMON) [Waldbusser 2000] und den Quasi- Standard NetFlow [Leinen 2004]. Die RMON Software ist ein erweiterter Simple Network Management Protocol (SNMP) Agent. Die ermittelten Werte des RMON werden in speziellen RMON MIBs abgelegt. Eine MIB ist dabei eine Art Tabelle oder Datenbank. RMON ermittelt zum Beispiel folgende Daten der physikalischen Netzwerkschnittstelle: die Protokollverteilung, die Paketgrößenverteilung, die Anzahl verworfener Pakete und die Schnittstellenauslastung. Marco Spina 18

19 Netflow hingegen verwendet logische Verbindungen, welche z.b. durch Quell- und Ziel-IP- Adresse, Quell- und Ziel-IP-Port und TOS 1 -Information beschreibbar sind. Beispiele für ermittelte Daten sind: Verbindungs-Dauer, -Beginn, -Ende sowie Anzahl von Bytes und AS 2 - Nummern der Quell- und Ziel-IP-Adressen Leistungsmessung Die passiven Methoden werden heute auch in der Leistungsmessung des Netzes eingesetzt. Netzwerkcharakteristische Leistungsparameter sind sowohl Verzögerungen, wie z.b. die RTT oder die Einwegverzögerung, als auch der Anteil an verlorenen Paketen. Im Rahmen dieser Arbeit soll dieses neue Einsatzfeld am Beispielszenario eines ISP untersucht werden. 1 Type of Service (TOS) 2 Autonomes System (AS): Dies ist im Internet ein IP-Netz, welches als Einheit verwaltet wird. Marco Spina 19

20 2.2 Grundlagen In den Grundlagen wird die Definition der RTT vorgestellt. Des Weiteren werden die Aspekte und Probleme von TCP/IP und des Netzwerks erläutert, welche für die passive Ermittlung der RTT relevant sind Definition der RTT nach RFC 2681 Die RTT ist im RFC 2681 [Almes u.a. 1999] von der IPPM standardisiert und wird darin folgendermaßen definiert: >>Die Type-P-Round-Trip-Time von der Quelle zum Ziel zum Zeitpunkt T ist dt<< entspricht der Zeit, die ein Typ-P Paket von der Quelle zum Ziel und zurück benötigt. Dabei speist die Quelle das 1. Bit eines Pakets zum Zeitpunkt T auf die Leitung in Richtung Ziel ein. Das Ziel empfängt das Paket und antwortet dann unmittelbar mit einem Typ-P Paket Richtung Quelle. An der Quelle wird das letzte Bit des Antwortpakets zum Zeitpunkt T+dT von der Leitung empfangen. (Siehe Leitungs-RTT in der Abbildung 3). Ein Typ-P Paket wird durch die OSI-Schicht definiert, d.h. die Zeitmessungen des Hin- und Rückpakets müssen auf der selben OSI-Schicht durchgeführt werden. Darüber hinaus muss die Länge des Pakets angegeben werden. Als Beispiel kann hierfür ein Ethernet Rahmen auf der Sicherungsschicht mit der Länge von 1514 Bytes genannt werden. Rechner-RTT Verarbeitung Q Verarbeitung Z Verarbeitung Q Tx Q Hintransport Rx Z Tx Z Rücktransport Rx Q Zeit T Leitungs-RTT Tx[ Q Z]: Zeit um ein Paket der Länge L, an der Quelle (Q) bzw. Ziel (Z), in die Leitung zu senden. Rx[ Q Z]: Zeit um ein Paket der Länge L, an der Quelle (Q) bzw. Ziel (Z), von der Leitung zu empfangen. T+dT Abbildung 3 Definition der RTT als Leitungs-RTT und die messbare Rechner-RTT Marco Spina 20