Network Security and Monitoring Project

Transkript

1 Network Security and Monitoring Project Für die Vorlesung Computernetzwerk & Sicherheit von Prof. C. Tschudin Von Anita Lerch Ben Rhouma Thomas Mangold 30. Mai 2005

2 Network Security and Monitoring Project Anita Lerch & Thomas Mangold Zusammenfassung Die Überwachung einer ungeschützten Verbindung zum Internet mittels je eines Linux- und Windowsrechners soll das Gefahrenpotential für ungesicherte PC s zeigen. Gleichzeitig sollen Unterschiede und Gemeinsamkeiten zwischen den beiden heute hauptsächlich verbreiteten Systemen protokolliert werden. Da keine Infektion stattfand, kann auf Grund dieses notwendigerweise begrenzten Versuches auch kein eindeutiger Verlierer unter den beiden eingesetzten Systemen ermittelt werden. Sieger sind hingegen sicher die Vertreiber von Schutzsoftware, welche gerne an der bestehen Unsicherheit verdienen. Einleitung Sind ungeschützte Rechner am Internet zu verantworten oder nicht und woher droht Gefahr? Wie weit spielt das Betriebssystem eine Rolle und wie gut geschützt werden heutige Rechner ausgeliefert? In den Medien und der Kioskliteratur wird wöchentlich über den gefährlichen Internetsumpf mediengerecht und auflagefördernd berichtet. Die Hersteller von Sicherheitsprodukten wie Virenscannern und Firewalls unterstützen diese absatzfördernde Berichterstattung mit eigenen Studien bezüglich des Gefahrenpotentials im Internet. Im Sinne einer eigenen Meinungsbildung wollten wir selbst erfahren, wie gross die Gefahr aus dem Netz wirklich ist. Dabei ist uns bewusst, dass wir nur eine Momentaufnahme machen konnten. Ausserdem ist das Infizierungsrisiko in hohem Grad von der Benutzung, der installierten Software und dem beim Surfen hinterlassenen Spurenmuster im Internet abhängig: Viele Attacken zielen auf Schwachpunkte einzelner Softwarepakete wie Microsoft Office oder SQL-Server ab. Rechner ohne diese Software sind demnach immun gegen solche Attacken. Die Rechner besuchen nur periodisch immer wieder die gleichen Server wie Updateseiten der Softwarelieferanten und allenfalls P2P-Server. Damit können wenigstens Spuren im Netz hinterlassen werden, auch wenn sie nichts mit den Spuren eines menschlichen Surfers gemeinsam haben. Ein Programm, welches zufällige Webseiten besucht und die Webseiten semantisch interpretiert, um in die aufgestellten Social-Engineering Fallen zu treten, würde diesem Dilemma abhelfen, aber auch den zeitlichen Rahmen des Projektes sprengen. Das in der Vorlesung Webtechnologie erstellte Java Programm fragt nur eine zufällige Seite aus einer endlichen Anzahl ab und gleicht somit auch keinem menschlichen Benutzer. Die heutigen Systeme sind aus der Schachtel (out of the box) schon recht sicher vorkonfiguriert. Dies geht soweit, dass sie auch auf Ping Anfragen nicht reagieren. Werden die vorinstallierten Schutzprogramme und die Firewall ausgeschaltet, versuchen die Updates immer wieder einen sicheren Zustand zu erreichen. Ein Abstellen dieser Updates ist zwar möglich, aber dann verhalten sich die Rechner so ruhig, dass sie im Netz gar nicht gefunden werden. Um den Vergleich zwischen Windows und Linux so fair wie möglich zu gestalten, wurde bei Linux die Security Enhanced Option und die Firewall ausgeschaltet. Bei Windows wurde der vorinstallierte Virenschutz deinstalliert und ebenfalls die Firewall ausgeschaltet. Allerdings verzichteten wir bei Windows auf die zusätzliche Datei- und Druckerfreigabe, da diese per default inaktiv ist und der Benutzer beim Aktivieren ausdrücklich davor gewarnt wird. Dokumentation_V1.3.doc

3 Network Security and Monitoring Project Anita Lerch & Thomas Mangold Problemstellung Mit der Verbreitung der Microsoft-Monokultur entstanden, wie die Evolutionstheorie voraussagt, Schädlinge. Da diese in erster Linie die Wirte der grössten Population befallen, bestand unsere Aufgabe darin, je einen Linux und einen Windows PC als Vertreter der beiden meist verbreiteten Systemarchitekturen ungeschützt ans Netz zu hängen und zu beobachten, ob sie infiziert werden. Im Falle einer Infektion geht es darum, den Schädling zu bestimmen und das Schadenpotential aufzuzeigen, sowie den Infektionsweg zu protokollieren. Zusätzlich geht es darum, eine Aussage zu machen über die Art, Häufigkeit und das Gefahrenpotential der erfolglosen Attacken aus dem Netz. Diese müssen dazu über einige Tage protokolliert werden. Lösungsansatz Auf dem Linux Client wurde Fedora Core 3 mit den Standard Einstellungen installiert, jedoch ohne SE-Linux. Der Windows Client wurde im Lieferstandard (Windows XP Home mit Service Pack 2) belassen, jedoch musste die McAfee Software deinstalliert werden, da sie automatisch alle Sicherheitseinstellungen inklusive Firewall reaktiviert. Die Firewall wurde auf beiden Rechnern ausgeschaltet. Anschliessend wurden beide Rechner über das Netz auf den neusten Stand gebracht, um Verkehr zu erzeugen. Die Updates wurden jedoch nicht installiert. Der Laptop wurde minimal als Linux Webserver aufgesetzt (nach der Anleitung von Snort Install Manual für CentOS, RHEL4 und FC3 ). Dabei wurde wieder Fedora Core 3 als Distribution verwendet. Installiert wurde unter anderem der Apache Server mit MySQL und PHP, sowie Snort und Base (Basic Analysis and Security Engine). Snort ist eine Intrusion Detection Software, die den Netzverkehr überwacht und bei Attacken eine Alarmmeldung ausgeben kann. Da bei richtiger Konfiguration von Snort eine direkte Analyse der Daten und eine Ausgabe in eine MySQL Datenbank möglich ist, kann mit der Web Applikation Base eine schöne graphische Darstellung der Daten erreicht werden (siehe login base, passwort snort). Während dem sieben Tage dauernden Monitoring liefen drei verschiedene Dämonen von Snort, um sicher zu stellen, dass keine Daten verloren gehen. Dokumentation_V1.3.doc

4 Network Security and Monitoring Project Anita Lerch & Thomas Mangold Der erste Dämon (snort -l /home/project1/log/binary -i eth0 -g snort -b -D) speicherte den ganzen Netzverkehr binär in eine Datei. Er diente als Backup, da mit dem Argument -r und dem Namen der binären Datei die Daten nachträglich noch einmal abgespielt werden können. Der zweite Dämon (snort -l /home/project1/log/snort -i eth0 -g snort -D) wurde aus Verlegenheit verwendet, da die gewünschte Direkteintragung in die Datenbank nicht von Anfang an funktionierte. Damit wurde der Netzverkehr ohne Analyse einfach in eine Log-Datei geschrieben. Beim dritten Dämon (snort -c /etc/snort/snort.conf -i eth0 -g snort -D) handelt es sich um den von Beginn weg vorgesehen Dämon, der sich im ersten Anlauf nicht zur Zusammenarbeit mit der Datenbank konfigurieren liess. Er benutzt die Konfigurationsdatei, in der die Analyse mit einem Regelwerk definiert ist und schreibt die Ergebnisse in die MySQL Datenbank. Um zu verhindern, dass unsere Computer selbst Würmer ins Internet verteilen, wurde fast jeden Tag ein Scan mit der AntiVir Software durchgeführt. Es wurde AntiVir gewählt, da sie für Windows wie auch für Linux bei privater Nutzung kostenlos zur Verfügung steht. Am 20. Mai um Uhr wurde zusätzlich die P2P Software EMule auf dem Windows Client installiert, um die IP Adresse im Netz weiter bekannt zu machen. Resultate Nachdem die Computer vom Netz genommen worden waren, erfolgte ein abschliessender Scan mit der aktuellsten Version von Antivir. Beide Computer wurden in den sieben Tagen Monitoring nicht infiziert. Dokumentation_V1.3.doc

5 Network Security and Monitoring Project Anita Lerch & Thomas Mangold Der auf beiden Computern ein- und ausgegangene Netzverkehr ist in der untenstehenden Tabelle ersichtlich. Eingang: WinXP Linux Signature Snort ID Kategorie 0 2 (portscan) TCP Portscan (portscan) TCP Portsweep ICMP Destination Unreachable Communication Administratively Prohibited ICMP PING CyberKit 2.2 Windows ICMP PING NMAP ICMP superscan echo MS-SQL version overflow attempt 2050 A MS-SQL Worm propagation attempt 2003 A MS-SQL Worm propagation attempt OUTBOUND 2004 A 5 0 NETBIOS DCERPC IActivation little endian bind attempt 3276 N 7 0 NETBIOS DCERPC ISystemActivator path overflow attempt little endian unicode 2351 N 5 0 NETBIOS DCERPC Remote Activation bind attempt 2251 N 4 0 NETBIOS SMB-DS DCERPC LSASS DsRolerUpgradeDownlevelServer exploit attempt 2514 N 4 NETBIOS SMB-DS IPC$ unicode share access 2466 N 0 2 RPC portmap listing TCP RPC portmap status request UDP RPC STATD UDP stat mon_name format string exploit attempt Tagged Packet 1 A = Attacke; N = Normale Netzkommunikation Ausgang: WinXP Linux Signature Snort ID Kategorie 4 0 (http_inspect) BARE BYTE UNICODE ENCODING (portscan) Open Port (portscan) TCP Portscan 5 0 (portscan) TCP Portsweep (portscan) UDP Portsweep SCAN UPnP service discover attempt Tagged Packet WEB-CGI redirect access WEB-IIS.htr access WEB-MISC http directory traversal 1113 WEB-MISC weblogic/tomcat.jsp view source 9 9 attempt 1054 Dokumentation_V1.3.doc

6 Network Security and Monitoring Project Anita Lerch & Thomas Mangold Schlussfolgerungen Die sofortige Infizierung des Windows PC, wie in der Kioskliteratur und auf den Webseiten der Schutzsoftwarehersteller suggeriert, fand nicht statt. Hingegen waren beide beobachteten Rechner samt dem Beobachtungsrechner einem ständigen Gewitter von Portscans und versuchten Bufferoverflow-Attacken ausgesetzt. Wir können nicht sagen, ob der Einsatz eines MS-SQL-Servers eine Infizierung nach sich gezogen hätte, waren doch mit Abstand die meisten Angriffe gegen dieses Softwarepaket gerichtet. Erstaunlicherweise wurde vor allem versucht, auf den Linux-Rechnern den MS-SQL-Server zu attackieren, obwohl dieser dort gar nicht läuft. Das kann zwei Gründe haben: Entweder ist der Windows-Rechner so mitteilsam, dass er einem Angreifer gleich mitteilt, dass hier kein SQL-Server aktiv sei, oder aber Microsoft hat wirklich einen Teil seines Sicherheitsversprechens eingelöst und mit dem Servicepack 2 zu Windows XP die Scheunentore geschlossen. Die zweite Aussage stimmt auch mit den neuen Sicherheitsrichtlinien von Microsoft überein: Seit Servicepack 2 antwortet ein Rechner nur noch auf qualifizierte Anfragen und bei Portscans bleibt er weitgehend stumm. Dieses Verhalten kann nur durch die Drucker- und Dateifreigabe umgangen werden. Trotzdem ist die Anzahl protokollierter Antworten des Windowsrechners deutlich höher als von Linux, welches sich. konzipiert als Netzwerkbetriebssystem, leisten kann, kommunikativer zu sein im Vertrauen darauf, die stärkere Verteidigung gegen Angriffe eingebaut zu haben. Referenzen Snort Users Manuel Snort Install Manuel für CentOS, RHEL4 und FC3 Honeypots Dokumentation_V1.3.doc

7 Schlussbericht Projekt VoIP Messung der Bandbreite/Qualität Vorlesung Netzwerke und Sicherheit SS2005, Universität Basel 27. Mai 2005 Roman Kreuzer, Frank Preiswerk, Zusammenfassung In unserem Projekt geht es darum zu zeigen, dass Voice over IP-Telefonie im Gegensatz zur herkömmlichen Telefonie stark von äusseren Einflüssen (Bandbreite, Packet Loss) abhängig ist. Wir haben untersucht, wie sich die Verbindungsqualität in Abhängigkeit der verfügbaren Bandbreite sowie unter Auftreten von Packet Loss verhält. Einleitung, Hintergrund Voice over Internet Protokoll, kurz VoIP, gehört die Zukunft. Zumindest wenn man Marktanalysten und Medien Glauben schenken will. Die Technologie ist in den letzten Monaten richtiggehend gehyped worden, ist in Wirklichkeit aber nichts neues und vielen Usern unter dem Namen NetMeeting seit Windows 95 ein Begriff. Erst mit der Verbreitung von Breitbandanschlüssen jedoch wurde der VoIP-Technik entsprechende Beachtung geschenkt. Doch noch immer ist die Verbindungsqualität in der Praxis oft der konventionellen Telefonie unterlegen. Wir haben untersucht, wie sich die Verbindungsqualität in Abhängigkeit der verfügbaren Bandbreite sowie unter Auftreten von Packet Loss verhält. VoIP Verbindungen unterliegen der Belastung in einem Netzwerk. Im Gegensatz zu einem typischerweise TCP-basierten Dienst, der digitale Daten von A nach B sendet und bei Packet Loss erneut die letzten x Datenpakete übertragen kann, besteht bei VoIP, welches auf UDP basiert, ein kontinuierlicher Datenfluss, der einerseits erneute Übertragungen nicht zulassen darf, andererseits aber grosszügiger mit verlorenen Paketen zurecht kommt. Problemstellung Ein erstes Problem stellte sich bereits bei der Definition einer guten Verbindung. Die Empfindung von Qualität ist generell subjektiv. In unserem Fall, so hat sich es sich herausgestellt, ist das Problem weniger signifikant als angenommen, da die Grenze zwischen guter Qualität und absoluter Unverständlichkeit in Bezug auf die Bandbreite sehr eng ist. Für die genaue Kontrolle der Bandbreite ist es nötig, in einem nach aussen abgetrennten Netzwerk zu arbeiten, um den Traffic im Netz auf einem überblickbaren

8 Minimum zu halten. Diese Bedingung schränkte die Wahl der Software stark ein. Bekannte Lösungen wie Skype konnten daher zu unseren Zwecken nicht in Betracht gezogen werden. FreeBSD 5.4 Host Subnet x Subnet x Routing ipfw/dummynet Bandbreitenregulation/ Packet Loss Simulation Ethernet Interface 1 = Gateway für VoIP Host Ethernet Interface 2 = Gateway für VoIP Host Windows XP Host 1 NetMeeting Windows XP Host 2 NetMeeting Figur 1: Verwendete Netztopologie und Verbindungspfade für die VoIP-Qualitätsmessungen Lösungsansatz Um die Tests durchzuführen, haben wir ein Netzwerk aufgebaut bestehend aus: 1 FreeBSD 5.4/Dummynet Host mit 2 Netzwerk-Interfaces 2 Windows XP/VoIP Hosts (Peer to Peer) Zur Drosselung der Bandbreite wurde das Tool Dummynet ausgewählt, welches die FreeBSD-Firewall IPFirewall als Interface benötigt. Sämtliche Befehle an Dummynet werden über die IPFirewall mit dem Command ipfw eingegeben (siehe unten). Dazu wurde uns vom Departement ein Dell Host zur Verfügung gestellt, welchen wir um zwei baugleiche Netzwerkkarten erweiterten. Die für das Projekt vorgesehene FreeBSD Live-CD bereitete uns Schwierigkeiten, denn die Ethernet-Devices vr0 und vr1 waren mit ifconfig nicht anzusprechen. Darauf haben wir uns kurzerhand dazu entschlossen, eine echte FreeBSD 5.4

9 Installation vorzunehmen. In der neu eingerichteten Umgebung waren die Karten nun ansprechbar, es zeigten sich jedoch andere Probleme: FreeBSD war standardmässig ohne die Option IPFirewall konfiguriert, wir mussten diese Funktion (und weitere) in den Kernel kompilieren. Anschliessend wollten wir uns von der Wirkung von Dummynet überzeugen und installierten zu diesem Zweck einen FTP-Server (War FTP) auf einem VoIP-Host und überwachten die Übertragungsgeschwindigkeit. Tatsächlich reagierte die Rate sofort auf Drosselung der Bandbreite. Wir haben Dummynet mit folgenden Optionen verwendet: $ ipfw add pipe 1 icmp from any to any zum Erstellen einer Pipe und $ ipfw pipe 1 config bw xkbit/s plr y zu deren Konfiguration, wobei x die Bandbreite und y ein Wert zwischen 0 und 1 für die (prozentuale) Häufigkeit von Packet Loss ist. Erste Tests mit der eingerichteten Umgebung lieferten enttäuschende Resultate: Die Gecko Phone-Verbindung war stets begleitet von starkem Rauschen und Knistern. Dies trat auch bei beliebig hohen Durchsatzraten auf. Ausserdem war der Time Lag auffallend lang. Dazu kam, dass das Programm sensibel auf Bandbreitenänderungen über Dummynet reagierte, die Verbindung wurde jeweils gestört und musste neu aufgebaut werden. Wir entschlossen uns, eine vergleichbare Software zu testen. Wir wollten weiterhin mit Windows arbeiten, da wir dort ohne grossen Aufwand die Gespräche mit einem Voice Recorder als.wav-files aufnehmen konnten. Gnome Meeting war also keine Alternative. Microsoft NetMeeting schien uns zunächst als veraltete Software mit ineffizientem Codec. Doch die Tests haben ein anderes Bild gezeigt: NetMeeting liefert deutlich besserer Gesprächsqualität ohne Störgeräusche Es reagiert wie gewünscht auf Bandbreitenänderungen on the fly. Die Time Lags sind kürzer Weiter unten stehen technische Details zur gemessenen Qualität von Gecko Phone. Schliesslich war der Entscheid naheliegend, die Tests mit NetMeeting durchzuführen. In NetMeeting wurden sämtliche erweiterten Funktionen wie Chat, Zeichenbrett und Webcam deaktiviert um die Resultate nicht zu verfälschen. In Gecko Phone sowie NetMeeting haben wir viel Zeit damit verbracht, verschiedene Bandbreiten und Packet Loss-Raten zu kombinieren, um deren Auswirkungen zu untersuchen. Wir haben versucht, Schlüsselwerte zu finden um die Anzahl aufgenommener, dieser Dokumentation mitgelieferten Samples, auf ein Minimum zu reduzieren, ohne auf eine umfassende Repräsentation der Effekte verzichten zu müssen.

10 Resultate Unsere Messungen haben gezeigt, dass VoIP-Verbindungen grundsätzlich auch bei geringen Bandbreiten und einigen Prozent Packet Loss akzeptable Qualität bieten. Das File sample.wav ist die das Original unseres Test Samples. Messungen mit gedrosselter Bandbreite, ohne Packet Loss Folgende Messungen haben wir zu Dokumentationszwecken aufgenommen: 600 Kbit/s, 0% Packet Loss sample_600kbs_0%loss.wav 40 Kbit/s, 0% Packet Loss sample_40kbs_0%loss.wav 34 Kbit/s, 0% Packet Loss sample_34kbs_0%loss.wav 30 Kbit/s, 0% Packet Loss sample_30kbs_0%loss.wav 26 Kbit/s, 0% Packet Loss sample_26kbs_0%loss.wav 22 Kbit/s, 0% Packet Loss sample_22kbs_0%loss.wav 10 Kbit/s, 0% Packet Loss sample_10kbs_0%loss.wav Bei den Messungen ohne Packet Loss ist kein Qualitätsunterschied festzustellen zwischen 600 Kbit/s, 40Kbit/s und 34 Kbit/s wobei letztere die Grenze darstellt zu eintretender Congestion, was Packet Loss und somit Qualitätsabfall zur Folge hat. Trotz der Spezifikation des G Codecs mit 6.4Kbit/s, reflektiert die 34Kbit/s Durchsatzrate den tatsächlich verwendeten Traffic inklusive Overhead von NetMeeting und dem sonst auftretenden Netzwerkverkehr. Messungen mit Packet Loss, volle Bandbreite Erneut haben wir die wichtigsten Messungen aufgenommen: 34 Kbit/s, 2% Packet Loss sample_34kbs_2%loss.wav 34 Kbit/s, 5% Packet Loss sample_34kbs_5%loss.wav 34 Kbit/s, 15% Packe Loss sample_34kbs_15%loss.wav 34 Kbit/s, 50% Packet Loss sample_34kbs_50%loss.wav Nach unserem Empfinden sind 2% Packet Loss noch immer vergleichbar mit einer mittelstarken GSM-Verbindung. Bei 5% liegt die Qualität bereits deutlich unter Festnetz- wie auch Mobilnetzqualität. Bei ca 15% fanden wir den Punkt, an dem theoretisch ein Austausch noch möglich ist, es jedoch längst nicht mehr zumutbar wäre, sich konzentriert und flüssig zu unterhalten. Zum Schluss haben wir als Vergleich das Test Sample bei 34Kbit/s in Geckophone aufgenommen. Die Qualität ist nicht vergleichbar mit NetMeeting und das Sample mehrheitlich unverständlich. Filename: sample_gecko_34kbs_0%loss.wav Die Geckophone Website schreibt: In compressed mode Gecko Phone uses an incredibly low 10KBaud bandwidth as opposed to the 28kBaud found in most other VOIP solutions. This makes Gecko Phone ideal for game pairings and maintaining a fast game server connection. Wir können diese Aussage unter Berücksichtigung unserer Erfahrungen nicht bestätigen.

11 Schlussfolgerungen und Ausblick Es bleibt festzuhalten, dass trotz sorgfältiger Auswahl der Software sowie ausfindig machen der relevanten Sprünge der Qualität als Funktion der Bandbreite, in unseren Resultaten keine vollständig objektiven Aussagen gemacht werden können. Die Test-Samples sollen helfen, dass sich der Leser selbst ein Bild der Resultate machen und unsere Feststellungen seinem eigenen Empfinden gegenüberstellen kann. Voice over IP befindet sich momentan in einer Boomphase. Wir sind der Meinung, dass der Erfolg dieser Technologie stark von den folgenden Faktoren abhängt: Komfort Qualität der Verbindung Jeweils im Vergleich zur herkömmlichen Telefonie. Der Komfort wird in nächster Zukunft durch die Entwicklung von VoIP-fähigen Telefonapparaten massiv gesteigert werden. Die Bedienung eines VoIP-Telefons wird sich nicht mehr von der Bedienung eines konventionellen Telefons unterscheiden. Es wird mit Sicherheit nicht mehr notwendig sein, mit Mikrophon und Kopfhörer vor dem Computer zu sitzen. Die Qualität der Verbindung wird einerseits implizit durch die stetige Erhöhung der weltweiten Durchsatzrate und Redundanz des World Wide Web verbessert, könnte aber auch durch die Entwicklung optimierter Codecs gesteigert werden. Referenzen Umfassendes Portal zum Thema Voice over IP. Website des FreeBSD-Projekts Anleitung zur Kompilierung von FreeBSD mit IPFIREWALL-Optionen Website des Dummynet-Projekts Website von Gecko Phone Website von NetMeeting Freeware FTP-Server

12 LUNAR Mesh Felix Gorny, Michael Keller 27. Mai 2005 Zusammenfassung Im Rahmen dieses Projekts wurde zum ersten Mal ein Mesh-Netzwerk basierend auf dem LUNAR Routing Protokoll in einer realistischen Weise implementiert. Dazu wurden 5 Knoten in der Umgebung des Petersplatzes aufgestellt, wovon einer mit dem Internet verbunden war. Danach wurden Messungen mit iperf und wget durchgeführt, welche Aussgagen darüber machen sollten, wie brauchbar ein solches Netzwerk für den Endbenutzer ist. Die Resultate waren durchmischt: das Routing an sich funktionierte, während Ausfälle in der Ordnung von 10 Sekunden relativ häufig waren, insbesondere wenn mehrere Knoten gleichzeitig auf das Internet zuzugreifen versuchten. Wiederholte Messungen führten zu sehr unterschiedlichen Resultaten, wofür wir keine Erklärung haben. Die Umgebung rund um den Petersplatz eignet sich gut, um ein Mesh-Netzwerk aufzubauen. Die meisten Gebäude sind in Universitätshand, andere werden von Studenten bewohnt, womit wir ziemlich grosse Freiheit in der Auswahl der Gebäude hatten. Wir strebten eine möglichst kreisförmige Verteilung der Geräte an, mit einer Vielzahl von Alternativrouten bei Wegfall eines Knoten. Abbildung 1 zeigt die Positionen unserer 5 Knoten zum Zeitpunkt der Messungen. Abbildung 2 zeigt die beobachteten Routen. Unglücklicherweise konnten wir keinen Knoten im Kollegienhaus aufstellen, da dort ein öffentliches WLAN auf Kanal 6 zu dominant war. Ein Umschalten des Kanals auf dem bereits implementierten Netzwerk erwies sich als nicht trivial und wurde aufgegeben. 1 Aufgabenstellung Unsere Aufgabe bestand darin, ein Mesh-Netzwerk basierend auf dem LUNAR Routing Protokoll zwischen mehreren Gebäuden in der Umgebung des Petersplatzes aufzubauen, und anschliessend aus Benutzerperspektive Bandbreiten-Messungen durchzuführen. Das Netzwerk basiert auf Cisco-Linksys Geräten (WRT54G), welche mit einer Linux-Distribution (openwrt) betrieben werden. Darauf ist LUNAR installiert, eine von Prof. Chr. Tschudins Forschungsgruppe entwickelte Routing-Software. 2 Aufbau der Infrastruktur 2.1 Übersicht Abbildung 1: Aufstellung der Knoten Im folgenden Text sind die Standorte im einzelnen beschrieben. Die schmatischen Skizzen ( Minimaps ) zeigen den Standort in Bezug auf die nächsten Aussenwände, sowie die Verbindungsrichtungen zu den nächsten Knoten. Die Tabellen sind eine Zusammenfassung der Scanresultate des jeweiligen Knoten (wl scanresults). 1

13 LUNAR Mesh Gorny/Keller Abbildung 3: Standort LUNAR1 Abbildung 2: Beobachtete Routen 2.2 LUNAR1 Standort: Bernoullistr. 16, Departement für Informatik, 4. Stock, ca. 12 Meter über Boden. Sehr breite Glasfront. Dieser Knoten war über Ethernet am Internet angeschlossen und funktionierte somit als Internet-Gateway für das Netzwerk. Abbildung 4: Minimap LUNAR1 SSID RSSI noise Channel BaselMesh Laptop AP public AP LUNAR2 Standort: Gloriastr 30/32, Institut für medizinische Mikrobiologie, Dachstock, ca. 6 Meter über Boden. Dieses Gebäude ist ein altes Fachwerkhaus. Die Wände bestehen aus Stein und Mörtel, das Fenster ist jedoch ziemlich klein. Abbildung 5: Standort LUNAR2 SSID RSSI noise Channel BaselMesh public LUNAR3 Standort: Schönbeinstr. 18/20, Universitätsbibliothek, Boden 6, Würfel 5, ca. 10 Meter über Boden. Dicke Wände aus Sandsteingemisch. Anmerkung: Ein erster Standort im Parterre, auf Abbildung 6: Minimap LUNAR2 2

14 LUNAR Mesh Gorny/Keller der von der Bernoullistrasse wegliegenden Seite, war unbrauchbar (mit einer Signalstärke von ca. -95 dbm und nur sehr gelegentlicher Verbindung zu LUNAR1). SSID RSSI noise Channel BaselMesh Laptop public USR LUNAR4 Standort: Petersplatz 11, Studentenwohngemeinschaft, 3. Stock, ca. 8 Meter über Boden. Das Gerät ist von zwei Fenstern umgeben, eines in Richtung LUNAR2, das andere beinahe mit Sichtkontakt zu LUNAR1. Eigentlich eine optimale Position, leider führt das andere Netzwerk auf Channel 6 zu einer schlechten Signal/Noise-Ratio. Abbildung 7: Standort LUNAR3 SSID RSSI noise Channel BaselMesh public Home LUNAR6 Standort: Petersplatz 13, Dachstock, ca. 8 Meter über Boden. Zuerst versuchten wir im 1. Stock des Hauses einen guten Platz zu finden. Leider wies die Verbindung eine extreme Empfindlichkeit auf. Veränderungen des Standortes um nur wenige Zentimeter liessen einen Kontakt zu bzw. kappten diesen. Im Dachstock war diese Sensitivität nicht so stark zu spüren. Der beste Ort war eine runde, kleine Fensteröffnung in der dicken Aussenwand des Gebäudes. Von dort aus entstanden direkte Routen zu Lunar 1, 2 und 4. Abbildung 8: Minimap LUNAR3 SSID RSSI noise Channel BaselMesh Home Messungen Es wurden zwei Messreihen durchgeführt: 1. Durchsatz zwischen je zwei Knoten im Netzwerk, Abbildung 9: Standort LUNAR4 3

15 LUNAR Mesh Gorny/Keller 2. Durchsatz zwischen mehreren Knoten und dem Internet, bei z.t. gleichzeitigem Zugriff. Letztere Messreihe ist der High-Level Ansatz, der letztendlich für die Benutzertauglichkeit ausschlaggebend ist. Die erste Messreihe wurde durchgeführt, um eine Erklärungsgrundlage für letztere zu erhalten. Abbildung 10: Minimap LUNAR4 3.1 P2P-Verbindungen Um die P2P-Durchsätze zu messen, wurde iperf verwendet. Es wurde jeweils ein Knoten in Servermode gesetzt, und von jedem anderen Knoten als Client drei Messungen ausgeführt. Der Durchschnittswert dieser drei Messungen ging in die Grafiken ein. 3.2 Internetzugriff Die Messung des Internetzugriffs erfolgte über wget. Auf einem Server mit mehr als genügend upload-bandbreite wurde ein File von 4.7 MByte deponiert. Danach wurde das File in drei verschiedenen Szenarien von ein bis drei Knoten gleichzeitig nach /dev/null heruntergeladen. Die Szenarien waren folgende: M2,M4,M6 Jeweils exklusiver Download von LU- NAR2, LUNAR4 und LUNAR6, M42/M24 Download von LUNAR4, nach 50% zusätzlich Download von LUNAR2 (und umgekehrt), Abbildung 11: Standort LUNAR6 M246 Gleichzeitiger Download von LUNAR2, LUNAR4 und LUNAR6. Folgende Bemerkungen zur Messmethode: Da uns die Überlagerungen interessierten, das Wegstehlen der Bandbreite, wählten wir Knoten, die möglicherweise gemeinsame Routen hatten, insbesondere nicht LUNAR3, das immer eine Direktverbindung zu LUNAR1 vorzieht. Alle Messungen wurden zweimal ausgeführt. Abbildung 12: Minimap LUNAR6 wget lieferte uns jede Sekunde die heruntergeladene Datenmenge. Da die Differenzen zwischen jeweils zwei Samples erratisch sind und möglicherweise auf Paketgrössen und 4

16 LUNAR Mesh Gorny/Keller LUNAR1 6 5 Mbit/s LUNAR4 0 LUNAR2 LUNAR3 LUNAR4 LUNAR6 Mbit/s Abbildung 13: iperf Messung LUNAR LUNAR1 LUNAR2 LUNAR3 LUNAR6 2.5 LUNAR2 Abbildung 16: iperf Messung LUNAR4 2 Mbit/s LUNAR1 LUNAR3 LUNAR4 LUNAR6 Abbildung 14: iperf Messung LUNAR2 LUNAR LUNAR3 Mbit/s Mbits/s 3 0 LUNAR1 LUNAR2 LUNAR3 LUNAR LUNAR1 LUNAR2 LUNAR4 LUNAR6 Abbildung 17: iperf Messung LUNAR6 Abbildung 15: iperf Messung LUNAR3 5

17 LUNAR Mesh Gorny/Keller Unzulänglichkeiten von wget zurückzuführen sind, wurde ein Moving Average (10) der Differenzen geplottet. D.h. wenn s i die von wget gelieferten samples sind, sind unsere y i = 1 10 i i 9 (s i s i 1 ) = 1 10 (s i s i 10 ). Für die ersten 10 y-werte gilt y i = 1 i s i, und es sollte ihnen nicht zuviel Aussagekraft beigemessen werden. bytes/s LUNAR seconds LUNAR2 Minor ticks auf der x-achse sind immer 10 Sekunden (bei einzelnen Graphen sind die Labels nicht informativ). Abbildung 18: wget M2 1. Messung Die Abszissen-Werte sind immer bytes/s, auch wo es nicht angegeben ist. Die Darstellungen mit mehreren gleichzeitigen Downloads sind gestapelt. D.h. sei bei einem gewissen x ein gewisser roter Wert y = y r und darüber ein gewisser blauer Wert y = y b, dann war die rote Bandbreite y r, die blaue Bandbreite y b y r und die Gesamtbandbreite y b. bytes/s LUNAR seconds LUNAR2 4 Diskussion 4.1 Messungen Die P2P-Messungen sehen vernünftig aus und liegen innerhalb der erwarteten Werte (angesichts der Positionen und Noise/Signal Ratios). Insbesondere sind die Resultate symmetrisch bezüglich Client- Server Verhältnis. Die wget-messungen sind alles andere als einheitlich. Wir beleuchten drei Faktoren: Ausfälle: Trotz Glättung der Kurven sind bereits bei den Einzelmessungen recht ausgeprägte Ausfälle oder Einbrüche die Regel. Verschiedene Messungen haben massive Einbrüche in der Grössenordnung von 10 Sekunden. Aus Benutzersicht ist diese Unregelmässigkeit bei interaktiven Anwendungen (z.b. Browser) vermutlich eher unerfreulich. Reproduzierbarkeit: Bei den meisten Messungen (ausser M24) wurde bei der zweiten Messung eine um einen Faktor 3-10 höhere Bandbreite (und damit entsprechend kürzere Gesamtdauer) erreicht. Tatsache ist, dass diese Messungen nicht zum gleichen Zeitpunkt stattfanden: Alle 1. Messungen ausser M24 wurden zwei Stunden vor den 2. Messungen ausgeführt. Von unserer Seite war der einzi- Abbildung 19: wget M2 2. Messung bytes/s LUNAR LUNAR seconds Abbildung 20: wget M4 1. Messung bytes/s LUNAR LUNAR seconds Abbildung 21: wget M4 2. Messung 6

18 LUNAR Mesh Gorny/Keller LUNAR6 bytes/s LUNAR LUNAR4 LUNAR seconds Abbildung 22: wget M6 1. Messung Abbildung 26: wget M24 1. Messung LUNAR bytes/s LUNAR LUNAR4 LUNAR seconds Abbildung 23: wget M6 1. Messung Abbildung 27: wget M24 2. Messung LUNAR4 LUNAR LUNAR6 LUNAR4 LUNAR2 Abbildung 24: wget M42 1. Messung Abbildung 28: wget M Messung LUNAR4 LUNAR LUNAR6 LUNAR4 LUNAR Abbildung 25: wget M42 2. Messung Abbildung 29: wget M Messung 7

19 LUNAR Mesh Gorny/Keller ge Unterschied, dass während der 1. Messperiode ein zweiter Computer an LUNAR1 angeschlossen war, allerdings nur mit einer schweigenden ssh- Verbindung auf die lokale (non-lunar) Adresse Wir achteten immer darauf, keine anderweitigen Datentransfers während den Messungen auszuführen, dementsprechend ist es fraglich, ob dieser Umstand dafür verantwortlich war. Gegenseitige Beeinflussung: Bei den Messungen wollten wir sehen, ob sich Knoten gegenseitig die Bandbreite wegstehlen. Sowohl in den Messungen M42 als auch in den Messungen M24 wird die Bandbreite des bereits aktiven Downloads vermindert, wenn der zweite hinzustösst. Obwohl LUNAR4 normalerweise LUNAR2 routet, kann man nicht sagen, dass LUNAR4 immer als Gewinner aus dem Rennen geht: in der 2. Messung von M24 kommt der Download von LUNAR4 gar vorübergehend vollständig zum Erliegen, während LUNAR2 weiterfährt. In den Messungen M246 ist die Situation etwas chaotisch: in der 1. Messung hat LUNAR2 gar keine Chance. In der 2. Messung ist LUNAR2 sehr überzeugend, und deutlich besser als LUNAR4, LUNAR6 braucht fast dreimal so lange wie LU- NAR2. wo zumindest eine kritische Menge von Knoten tatsächlich auf Dächern installiert sind, idealerweise mit direkten Sichtverbindungen, wo nötig unterstützt durch bessere Antennen, mag die mittelfristig einzige gangbare Lösung sein. 4.2 Andere Beobachtungen Das Routing an und für sich funktioniert einwandfrei. Wenn ein Knoten unerreichbar wurde, war es meist nur eine Frage von Sekunden bis wir wieder eine Verbindung herstellen konnten. Unangenehm ist der Umstand, dass die Software z.z. unfähig ist, selber dem BaselMesh beizutreten. Es gab mindestens einen Fall, wo ein Knoten gar ohne Reset den BaselMesh spontan verliess und nicht mehr zurückkam. Die Frage des Channels ist sicher heikel: ein Mesh-Netzwerk sollte ganz allgemein in seinem Einzugsgebiet praktisch ein Monopol auf einen Channel haben. Das mag aber sehr unwahrscheinlich sein, insbesondere falls Netze wesentlich häufiger werden. Möglicherweise wäre ein adaptives Verfahren denkbar, wonach alle Knoten eines Mesh sozusagen demokratisch einen Kanalwechsel beschliessen und synchronisiert durchführen können. Die Positionierung der Geräte ist auf jeden Fall ein entscheidender Punkt, und möglicherweise heikler als angenommen. Die Vision eines Roofnet, 8

20 Project # 5: Performance of video-conferencing tools in wireless networks Lukas Meier Roman Šuma May 29, 2005 Abstract Build a WLAN with 2 users and 2 access points. Measure the behavior of data sent during a handover (change of access point) during videoconferencing. During the handover there will be a short period of time where the video transmission is stopped and resumes after the new access point was found.

21 Project # 5: Performance of video-conferencing tools in wireless networks Lukas Meier Roman Šuma Contents 1 Introduction 2 2 Problems and solutions 2 3 Measurements 3 4 Conclusion 4 5 Links 5 May 29,

22 Project # 5: Performance of video-conferencing tools in wireless networks Lukas Meier Roman Šuma 1 Introduction We plan to use 2 access points and switch from one to another by changing the essid from access point 1 to 2 of the WLAN card of the laptop user. We measure on both sides what packets are being sent/received. 2 Problems and solutions Situation at the beginning Hardware: Laptop, PC 2 Access points (linksys wireless - g, model WRT54G) 2 webcams enough network cables Software: Gnomemeeting Ethereal Fedora Core 3 In the first meeting we installed Fedora Core 3 and managed to setup the environment for the communication between the two end-users. We choose to use this architecture: Fix Machine GW: Access Point GW: Access Point 2 Mobile Machine Figure 1: Network scheme Schematic showing a cable connected PC communicating with a wireless connected laptop which changes from access point 1 to access point 2. (during measures we used as fixed, and as laptop) A different idea would have been to use a hub to connect the access points and the PC, but we had no hub and it worked great without. At this stage we had no camera or microphone used, we measured traffic caused by pinging and chatting in gnomemeeting. We switched the access point by changing the ESSID of the access point. ( : iwconfig eth1 essid AP1 : iwconfig eth1 essid AP2) AP1 now no longer knows where the user is and asks all surrounding machines to look for it. May 29,

23 Project # 5: Performance of video-conferencing tools in wireless networks Lukas Meier Roman Šuma This worked well. At our second meeting we tried to install the webcams, which caused a lot of problems. After looking in the internet for quite a long time we found no working logitech drivers for the logitech quickcam notebook pro, that s why we later changed the webcams. Our third meeting started with a conference with Prof. Tschudin. We thought that everything will go well with the new webcams and in fact had not a lot driver problems. After we left the the conference with Prof. Tschudin we tried to measure the performance in gnomemeeting, the cams displayed the local (own) video input correctly, but as soon as we had a video conference started the gnomemeeting process on both computers froze. A problem we were unable to solve that day. At the fourth meeting Christoph Jelger came and had a look at our problem, after a while he used the command dmesg, which listed an error and at the same time proposed using: qcset compat=dblbuf This solved the freezing problem and we were able to begin with our measures. 3 Measurements First we saved both ethereal-outputs in the files ethereal output desktop and ethereal output laptop. The script analyse.sh then produced our plots. The script reads as echo "transform desktop ethereal output" awk BEGIN{type="otr";ctr=0}/ * *UDP/{time=$2;type="Drcv"} / * *UDP/{time=$2;type="Dsnd"} /^Data/{size=substr($2,2)}/^0020/{ctr++;if(ctr>8&&ctr<7805) printf("%10.9f\t%s\t%i\n",(time )/ ,type,($7+$8+$12)*size); type="otr"}../data/ethereal_output_desktop > desktop.list echo "transform laptop ethereal output" awk BEGIN{type="otr";ctr=0}/ * *UDP/{time=$2;type="Lsnd"} / * *UDP/{time=$2;type="Lrcv"} /^Data/{size=substr($2,2)}/^0020/{ctr++;if(ctr>5&&ctr<7338 ) printf("%10.9f\t%s\t%i\n",(time )/ ,type,($7+$8+$12)*size); type="otr"}../data/ethereal_output_laptop > laptop.list echo "synchronize outputs" paste desktop.list laptop.list awk {if($6!="") printf("%10.9f\t%s\t%i\n%10.9f\t%s\t%i\n",$1,$2,$3,$4,$5,$6); else printf("%10.9f\t%s\t%i\n",$1,$2,$3);} sort > synchronized.list echo "prepare plot data" awk BEGIN{val=0}/Dsnd/{val++;printf("%10.9f\t%i\n",$1,val)} /Lrcv/{val--;printf("%10.9f\t%i\n",$1,val)} synchronized.list > D2L.data awk BEGIN{val=0}/Lsnd/{val++;printf("%10.9f\t%i\n",$1,val)} /Drcv/{val--;printf("%10.9f\t%i\n",$1,val)} synchronized.list > L2D.data echo "prepare plot commands" echo -e "plot D2L.data \nset terminal postscript\nset output \"D2L.ps\"\nreplot\nquit" > D2L.plot echo -e "plot L2D.data \nset terminal postscript\nset output \"L2D.ps\"\nreplot\nquit" > L2D.plot echo "generate plots" gnuplot D2L.plot gnuplot L2D.plot echo "" echo "finished! See the timeplots D2L.ps and L2D.ps!" echo "" May 29,

24 Project # 5: Performance of video-conferencing tools in wireless networks Lukas Meier Roman Šuma 350 L2D.data Figure 2: Laptop to Desktop (L2D) x-coords: time (1 is about a minute ±3s) y-coords: packet-overflow-depth t, each sent packet increases t, each received packet decreases t. Where is what situated? Between 0.2 and 0.3: AP1 AP2 Between 0.4 and 0.5: AP2 AP1 Between 0.6 and 0.8: AP1 non-existing Between 0.6 and 0.8: non-existing AP2 Between 0.9 and 0.1: AP2 AP1 As regular gnomemeeting user we saw that the video-transmission stopped during the handover. The time was about what we measured. Plots of our measures: we can see clearly 3 small gaps and a big one. The small gaps are caused by the change AP1 AP2. The big gap is the change of the essid to an non-existing essid and then back to AP2. These changes are being made on the laptop. 4 Conclusion There may be negative packet-overflow-depths, because the synchronization isn t perfect. That s caused by slightly different starting time and asynchronous clockworks of the computers. This should have few influence to the quality of our results. We see very clearly in these plots, that during the hand overs there is a big packet-overflow-depth. This means a lot of packets are being sent, but reach no target. Especially in the D2L Plot the change AP1 AP2 is a big gap because the Desktop is directly connected to AP1. During the big gap (change of essid to a non-existing id) we see that both, desktop and laptop are having a send break. The laptop realizes earlier that it s nonsense to send packets. May 29,

25 Project # 5: Performance of video-conferencing tools in wireless networks Lukas Meier Roman Šuma 800 D2L.data Figure 3: Desktop to Laptop (D2L) x-coords: time (1 is about a minute ±3s) y-coords: packet-overflow-depth t, each sent packet increases t, each received packet decreases t. 5 Links (ethereal for measuring) (fedora core 3 as OS) (gnomemeeting as videoconferencing tool) (drivers for logitech quickcams) May 29,

26 Computernetzwerke und Sicherheit Sommersemester 2005 Projekte Service Level Agreement Marcel Arheit und Simon Lutz Betreuung: Lidia Yamamoto 1

27 1. Abstract Im Rahmen der Vorlesung Computernetzwerke und Sicherheit fanden verschiedene Projekte statt wie auch unseres zum Thema Service Level Agreement, bei dem wir unsere Internetanbindung zu Hause einem mehrstufigem Test unterzogen haben. Dazu haben wir verschiedene Messungen durchgeführt, zusammengetragen und ausgewertet. Die Resultate sind nun hier dokumentiert. Es sei vorweggenommen, dass die Ergebnisse ein erfreuliches Bild abgeben und die Erwartungen eines Kunden an seinen Provider erfüllen. 2. Einleitung Die privaten Internetanschlüsse stossen in immer neue Geschwindigkeits Regionen vor und werden heutzutage flächendeckend angeboten. Die Produkte der verschiedenen Anbieter werden üblicherweise durch die Bandbreite charakterisiert. Den Vertrag zwischen dem Kunden und dem Provider nennt man 'Service Level Agreement' (nachfolgend kurz 'SLA' genannt). Doch halten die Provider wirklich was sie versprechen? Jedenfalls kann man zeitweise Performance Verluste wie zum Beispiel langsamer Zugriff oder gar Unterbrechung der Verbindung feststellen. Als Kunde ist man dem eigentlich ausgeliefert. Wir wollten diese Tatsache genauer untersuchen und bei unseren eigenen Providern die Einhaltung des SLA prüfen. Da wir über eine Anbindung per Kabel und eine über ADSL verfügen, lag es nahe, diese beiden verschiedenen Verbindungsarten zu vergleichen. 3. Problemstellung Die Geschwindigkeit einer Verbindung eines Internetanschlusses zu Hause hängt von vielen Faktoren ab. Unser Ziel war es, diese zu messen und zu verstehen. Die Frage, der wir nachgingen lautete: Wird unser SLA 2

28 gebrochen? Und wenn ja, inwiefern? Dazu mussten wir die gemessenen Daten analysieren, mögliche problematische Stellen finden und diese mit der Performance zu Hause in Verbindung bringen. Ausserdem hat uns interessiert, ob die technischen Unterschiede einer ADSL und Kabelverbindung auch zu Differenzen in der Performance führen bzw. führen könnten. 4. Aufbau und Ablauf Um verschiedene Aspekte anschauen zu können, haben wir die Messung in drei Teile gegliedert: Abb.1: Aufbau der Messung mit ihren drei Teilen 4.1 Interner Test: Hausanschluss Provider Um möglicherweise bereits hier Defizite aufzuzeigen, haben wir das interne Netz des Providers untersucht. Dazu verwendeten wir ping und traceroute (zum Nameserver). Da wir bei dem Kabel Anbieter ausserdem noch über einen FTP Zugang verfügen, konnten wir so die Bandbreite auf dem eigentlich kürzesten Weg testen. 3

29 4.2 Hausanschluss Hausanschluss Heutzutage gibt es viele peer to peer Anwendungen, bei denen auch die Geschwindigkeit der Verbindung eine wichtige Rolle spielt. Für die Messung haben wir neben ping und traceroute das Tool iperf verwendet, das im Client Server Mode einzelne und auch parallele TCP Streams ermöglicht und die Bandbreite ausgibt. Die Leistung wurde in beiden Richtungen ausgewertet. 4.3 Hausanschluss Server Zu diesem Zweck konnten wir an der Universität einen Server installieren und an eine offene Leitung hängen. Das heisst, wir waren direkt im Internet und nicht Teil des Uni Intranets. Wir haben FreeBSD 5.4 aufgesetzt und die nötigen Programme eingespielt. Zum einen den ssh deamon für die Remote Kontrolle und wiederum iperf als Messungs Tool, auch bidirektional. In diesem Teil kamen ebenfalls ping und traceroute zum Einsatz. 4.4 Ablauf Um eine repräsentative Aussage machen zu können, haben wir uns innerhalb von einer Woche auf gewisse Zeiten, die wir über die ganzen 24h verteilten, festgelegt und sind immer nach dem gleichen Prozedere vorgegangen. Dieses sah vor, die drei Tests in oben genannter Reihenfolge direkt nacheinander auszuführen (z.t. mit Hilfe von Scripts). In den einzelnen Schritten waren ping und traceroute jeweils die Gradmesser am Anfang, gefolgt von der Bandbreitenmessung mittels iperf bzw. per FTP. Die Messung mit iperf wurde nochmals in vier Unterteile zerlegt: dem Senden einer 1Mb Datei und einer 15Mb Datei und dies jeweils mit einem und fünf parallelen TCP Streams. 4

30 5. Resultate 5.1 ADSL Anschluss Produktangaben: Provider: Tele2 Down Stream: 600 Kbit/s 75 Kbytes/s Up Stream: 100 Kbit/s 12.5 Kbytes/s Da ich keinen Zugang zu einem FTP Server erstellen konnte, hat der interne Test wenig Aussagekraft. Deshalb musste ich mich auf Delay Messungen mittels ping beschränken. Auch hier traf ich erneut auf eine Schwierigkeit, der DNS (Domain Name Server) von Tele2 kann nicht durch ping erreicht werden. Ich wich aus diesem Grund auf die Domain, home.tele2.ch aus. Wie in 4.4. beschrieben begann jede Messung mit einem Ping. Die dadurch entstanden Werte ergeben einen Mittelwert von 52.9ms. Leider konnte wie von uns im Voraus befürchtet, die Verbindung mit dem Kabelanschluss nur in eine Richtung getestet werden. Die Ursache dessen liegt nicht wie vorerst angenommen im NAT (konnte durch dynamischer DNS umgangen werden), sondern bei der Firewall meines ADSL Modems. Diese lässt nur gezielte Port Anbindungen zu, welche in den Einstellungen durch den Benutzer freigegeben wurden. Es kann nicht ein ganzer Bereich von Ports geöffnet werden. Dies bedeutet, dass das Senden von Daten via "iperf" nicht möglich ist, nur das Empfangen. Beim Senden wird der Port durch "iperf" zufällig gewählt und somit kann dieser in nicht freigegebene Bereiche fallen. Deshalb können für diesen Teiltest nur Messungen für den Kabelanschluss betrachtet werden. Durch das oben beschriebene Problem waren meine Messungen auch beim Server Home Test auf den Download beschränkt. Die Geschwindigkeit der Downloads bewegte sich konstant um Kbits/s. Die Standardabweichung ist also mit sehr gering. Während meiner Messperiode sind nur vier Ausreisser zu nennen. Dadurch beträgt der kleinst gemessene Wert 230 Kbits/s. Die grösste Geschwindigkeit, die in diesen Tagen erreicht werden konnte war Kbits/s. Erstaunlicherweise liegt der erreichte Mittelwert Kbits/s über der vom ISP versprochenen Bandbreite. 5

31 Es zeichnen sich auch leichte Veränderungen in den Mittelwerte der Tageszeiten ab. Die Werte der Tages Messungen sind um rund 40 Kbits/s höher als die der am Abend gemessenen (siehe Abb.3). Die Werte der Nacht liegen in etwa in der Mitte. Der Vergleich der Werktage mit dem Wochenende weist auf, dass Sonn und Samstags auf minimale grössere Geschwindigkeiten zurückgegriffen werden können, wie an den Werktagen (siehe Abb.2). 5.2 Kabelanschluss Produktangaben: Provider: Teleport Down Stream: 1024 Kbit/s 128 Kbytes/s Up Stream: 256 Kbit/s 32 Kbytes/s Im internen Test mit dem Provider wurden die Soll Werte problemlos erreicht. Der Ping pendelte sich unabhängig des Tages und der Zeit auf einen Wert zwischen 10 und 15ms ein, mit Extrema bis 25ms. Mit Geschwinigkeiten von Kbytes/s für den Up und Kbytes/s für den Download war auch die FTP Verbindung auf einem konstant hohen Niveau, welches alle Erwartungen erfüllt. Die Zeiten der Pings mit dem Server an der Universität lagen trotz einzelnen Maxima bis über 200ms in der Regel zwischen 17 und 22ms, weshalb sich auch hier keine Schlüsse auf äussere Bedingungen ziehen lassen. Die Banbreiten Messung mit iperf lieferte ebenfalls ein erfreuliches Resultat. Die Geschwindigkeit für das Senden lag jeweils zwischen 260 und 332 kbits/sec und somit immer über dem eigentlichen Wert des Abonnementes. Der Schnitt lag bei 285kbits. Ob fünf parallele oder ein einzelner TCP Stream verwendet wurden, hatte keinen Einfluss. Die selben Aussagen gelten auch für das Empfangen der Daten. Die Resultate hatten nur sehr kleine Schwankungen und übertraffen die Provider Angaben mit einem Minimum von 1040Kbits/sec und einem Maximum von 1100Kbits/sec auch an jedem Tag und zu jeder Zeit. 6

32 5.3 Direkte Verbindung Da sich diese Messung nur in eine Richtung ausführen liess, sind die Resultate hier etwas spärlicher ausgefallen. Der Ping lag im Schnitt bei etwa 100ms und die Route hat mit acht Hops auch eine gewisse Länge. Die Werte waren unabhängig von äusseren Faktoren konstant. Die Messung mit iperf ergab für das Senden von Daten vom Kabel zum ADSL Anschluss Geschwindigkeiten von Kbits/sec. Der Schnitt lag bei ungefähr 250 Kbits/sec, was ziemlich genau den Soll Werten meiner Anbindung entspricht. 6. Schlussfolgerungen 6.1 Einhaltung des SLA Nach den Messungen über diese Zeitdauer von ungefähr einer Woche können wir sagen, dass unsere Provider sehr zuverlässig sind. Wir konnten keine Tage oder bestimmte Zeiten finden, zu denen die Performance bedeutend schlechter war als vom Anbieter versprochen. Diese Tatsache machte die Suche nach Flaschenhälsen und Ähnlichem leider unnötig, da sie scheinbar inexistent sind. Die Zeiten in denen sich der allabendliche Verkehrsstau jeweils auch im Internet und nicht nur auf der Strasse breitgemacht hat, sind also in unseren Fällen definitiv vorbei. 6.2 Unterschied Kabel ADSL? Wer nun auf eine allgemeingültige Antwort auf diese Frage gehofft hat, müssen wir enttäuschen. Die hervorragenden Messwerte auf beiden Seiten liessen uns keinen Sieger ermitteln. Auch die Konstanz der Bandbreite lässt keine Präferenz der beiden Übermittlungstechniken zu. Dies brachte uns auch dazu, darauf zu verzichten, aus technischen Unterschieden Folgen auf die Leistung abzuleiten. Bei der Wahl des Angebots sollten also andere Faktoren wie z.b. Preis, Geschwindigkeit und Datenmengenbegrenzungen aussschlaggebend sein. 7

33 7. Diagramme 7.1 ADSL Kb/s Download Werktage Wochenende Abb.2: Geschwindigkeitsvergleich Werktag - Wochenende Download Kb/s Tag (08:00-17:00) Abend (17:00-24:00) Nacht (0:00-8:00) Abb.3: Geschwindikeitsvergleich Tageszeiten Dowload Kb/s M 15M Abb.4: Geschwindikeitsvergleich Filegrösse 8

34 7.2 Kabel Kb/s Download Werktage Wochenende Abb.5: Geschwindigkeitsvergleich Werktag - Wochenende Kb/s Download Tag (08:00-17:00) Abend (17:00-24:00) Nacht (0:00-8:00) Abb.6: Geschwindikeitsvergleich Tageszeiten Kb/s Download 1M 15M Abb.7: Geschwindikeitsvergleich Filegrösse 9

35 Kb/s Upload Werktage Wochenende Abb.8: Geschwindigkeitsvergleich Werktag - Wochenende Kb/s Upload Tag (08:00-17:00) Abend (17:00-24:00) Nacht (0:00-8:00) Abb.9: Geschwindikeitsvergleich Tageszeiten Kb/s Upload 1M 15M Abb.10: Geschwindikeitsvergleich Filegrösse 10

36 8. Referenzen iperf: Teleport: Tele2: FreeBSD: 11

37 CS221 Computer Networks and Security Project #7 Fraglets and Sockets by Jasenko Zivanov Abstract: The following document has been written in the course of a students project concerning fraglets, a metabolistic approach to communications protocols, at the University of Basel. It describes the steps taken to integrate basic network functionality into an existing fraglet interpretation environment, some difficulties encountered while designing a reliable fraglet based communications protocol, the methods adopted to solve them and a description of said protocol. It includes data from some measurements of the performance of that protocol and proposals regarding the fraglets instruction set.

38 Introduction: Fraglets are a new programming model inspired by metabolic pathways in living organisms. They allow a simple construction of some unusual mechanisms, but the implementation of certain well-known structures (like data containers) can become quite tricky. In the course of this project, the first step was the implementation of a UDP interface that allows fraglets to be sent from one interpretation environment to another. Then, a fraglet-based protocol was created, which was by far the most interesting and difficult part of the assignment. In the end, some measurements we performed on the performance of that protocol under different conditions. While designing the protocol, certain ideas regarding the further development have emerged. Those are described in the last section, proposals. In order to simplify navigation of this document, the corresponding paragraphs have been colour-coded as follows: blue - interpreter pages 3 and 4 green - protocol pages 5-15 grey - performance pages 16 and 17 orange - proposals pages 18 and 19 Due to the highly modular nature of this assignment, the report has been kept in a similar structure. Besides of a certain number of cross references between the sections, they are thematically rather far apart. As the order of the sections is more or less the same as the order in which the individual tasks were performed, it still makes a lot of sense to read them in that order.

39 Part One: The Interpreter 1. Input Files Changing the interpreter program made it necessary to also make minimal alterations to the input syntax, though input files written using the old syntax will still be compatible. The only parameter changed is the node configuration parameter 'a'. The new syntax goes as follows: local context: a name input node: a name local port remote node: a name ip-address port Where the string 'local' means, the node will receive fraglets arriving at port port of the machine the interpreter runs on, and an ip-address (dot notation) means that the node is running elsewhere, and fraglets sent to that node are actually transmitted to that port at that address. No instructions are executed for fraglets stored at a node declared remote. The name used on a remote machine for the node a fraglet is sent to is furthermore irrelevant, fraglets are transported without any node specification and arrive at any node listening on that particular port at that address. In order to maintain a certain readability, it might be wise to still use the same names for a certain node on both sides. Let us look at an example configuration: Instance A: a beta udp local 1138 a gamma udp Instance B: a gamma udp local 1139 a beta udp Here, every fraglet on instance A sent to udp:gamma will arrive at node gamma of instance B, while every fraglet inside instance B sent to udp:beta will end up in node beta of the A instance.

40 Now, consider the following: Instance A: a alpha udp local 1138 a beta udp Instance B: a gamma udp local 1139 a delta udp In this case, each fraglet sent to udp:beta from instance A will arrive at node gamma of instance B, while each fraglet sent to udp:delta from instance B will arrive at node alpha of instance A. This behaviour allows for some additional flexibility, but, in order to conserve readability, its use should be limited to cases where the architecture of the remote instance really is unknown. 2. Program Parameters Two command line paramaters were added to the program: -lose N: -log N F: loses each unreliably sent packet with a probability of 1/N, unless N equals zero. logs each reaction happening at node N to a file F, using the same output syntax as the standard console output (at debug-level one). They were both necessary for the debugging of the new protocol. 3. Notes - All fraglets are transported in ASCII form. As the unsigned short vocabulary of the environment is created at runtime, that representation generally differs from instance to instance. - As the impact of interpretation-time on the round-trip-time by far outweighs the one of the time really needed to deliver a packet over loopback* and return the ACK, the wait instruction is still based on instruction count and not real-time. See section performance for more *) this would probably even apply if the packet was sent to Australia. No machines located in Australia were at my disposal at the time, so this is not confirmed.

41 Part Two: The Protocol Designing fraglet based programs may seem quite difficult in the beginning, but compared to many other things that get much easier as time goes by, it actually remains quite mind-boggling and nerve-challenging. Still, it is a very interesting programming paradigm, and in the following I would like to demonstrate certain difficulties encountered along the way, and the methods adopted to solve them just before I face the reader with the complexity of a diagram of the entire protocol. In order to grant at least some perspective before we begin, here is a rough outline of the new protocol: - Circular data store, allowing for continuous sending of data - Data is transmitted one symbol at a time - Each data element is transported along with one token from a ring as header - All tokens from the ring can be away at the same time (pipelining) - Receiver expects one particular token, only that one is acknowledged - Of each data element sent away, a backup is stored and a copy of the token is placed at the end of a list - If no ACKs arrive during a certain time interval, all backups are resent, but neither deleted nor their tokens removed from the list - Each incoming ACK returns the token, deletes the associated backup and removes the first entry in the list 1. Multiple Contexts Only after having altered the interpreter program, was it that the possibilities of multiple contexts became apparent. Until then, different nodes were mentally associated with different fraglet environments running on different machines, connected by a slow and possibly lossy connection. Introducing real remote nodes suggested using local nodes as local 'reaction chambers', similar to the different compartments in a living cell. For one, this allowed modularizing the fraglet code, so single reactions could take place entirely within one context, while fraglets with a certain header could be used as interfaces between contexts, thereby reducing design complexity and making keeping track of used identifiers much easier. For the other, multiple contexts also allowed storing multiple associations to one symbol. On the following pages there are two examples of the latter.

42 Example Counting The data to be sent was supposed to be ordered, so the reordering capabilities of the protocol could be tested. Now, if we were handling real data, it probably would have been wise to store all the data symbols in one singular fraglet with a specific header, and then always slice one symbol off for transportation. In this test however, it was decided to store the data in a circular order, thereby allowing for a measurement of performance over an indefinite amount of time. This is when multiple contexts came in handy for the first time: In one node, labeled 'producer', we have the following fraglets: N times producer[n(i):data(i)] (0 <= i < N), and once producer[next_data:n(i)] Note that symbols printed italic are placeholders for symbols of the form n0, n1, etc. (or data0, data1, etc. respectively). This way we know which of the N data elements is supposed to be accessed next, and can access it easily through the reaction: (Reaction R1): producer[get_next] + producer[next_data:n(i)] + producer[n(i):data(i)] producer [n(i):data(i)] + producer[next_data:n(i+1)] + emitter[next_data:data(i)] The details of the reaction are left out here, but they can be looked up in the fraglet code to this report. The important thing is, we can retrieve the symbol 'n(i)' because it carries the known header 'next_data' in one fraglet, and then access the fraglet carrying the header 'n(i)' to retrieve the corresponding data element and write something like 'send:udp:emitter:next_data' in front of it (although, in the real protocol, copies of the n(i) and data(i) symbols need to be created first). Now, the problem we are faced with is the following: After one data-element has been accessed, how do we know which n(i) is the next one (labeled 'n(i+1)' in our case)? The straightforward solution is to use fraglets containing all n(i)s as headers and the corresponding n(i+1)s as tails. Unfortunately, we already have fraglets carrying the headers n(i) in this context, so there is no way of knowing if we are attempting to access [n(i):data(i)] or [n(i):n(i+1)]. We could try and use a different set of number-identifiers m(i) and store the current-next relationships in this alphabet, that is, have fraglets of the form [m(i):m(i+1)] swimming around instead. But even in this case, in order to translate from n(i) to m(i), we would still need fraglets carrying n(i) as headers floating around - as well as other fraglets with m(i)s as headers, as those would be needed for the reverse-translation.

43 So the only way to solve the problem using this approach, is by putting the current-next relationships into a separate context - in our case it has been named 'counter'. Then, we can use the following simple reaction to get the next n(i) into our producer: Reaction R2: counter[next:n(i)] + counter[n(i):n(i+1)] producer[next_data:n(i+1)] + counter[n(i):n(i+1)] The producer only has to create a copy of n(i) at some point during Reaction R1, and send it into the counter with the tag 'next' attached to it. Combined with Reaction R1, we receive the following interface that will deliver the next data(i) to the node designated emitter each time it is used: Data Retrieval Interface: emitter[send:udp:producer:get_next] emitter[next_data:data(i)] Image 1.1: Data Retrieval Interface

44 Example Tokens Similar to the data elements in the data store, tokens, too, are aligned in a predefined circular order. Now that we have used the term 'interface' in conjunction with contexts, we can declare the expected behaviour of our token store in the form of an interface: Token Retrieval Interface: emitter[send:udp:token_order:get_token] emitter[token:t(i)], (as soon as the next token has been returned to the store, or instantly if it is there) In order for it to work, we will of course need a context named token_order. token_order works in a similar way as counter, except for the fact that it stores the next token itself, and that it does not send that next token to the emitter directly, but instead, it sends it to a context named tokens, with the header confirm attached to its head. Reaction R3: token_order[get_token] + token_order[next_token:t(i)] + token_order[t(i):t(i+1)] tokens[confirm:t(i)] + token_order[t(i):t(i+1)] + token_order[next_token:t(i+1)] Here, as well, most of the fraglets are responsible for copying the symbols from the association fraglet [t(i):t(i+1)], in order to restore it after the reaction, so all of them have been left out and can be looked up in the code. Besides of the fraglets needed for the reaction, tokens contains only single-symbol fraglets of the form [t(i)] (initially all of them). Upon arrival of a [confirm:t(i)], certain fraglets stored in tokens try to match the arriving t(i) with one already present in tokens, and forward it to the emitter. The according t(i) is thereby removed from tokens. This way, we can assure that no token can be delivered from token_order to the emitter, unless (or before) we have returned the same token to tokens (we do this upon an ACK). Reaction R4: tokens[confirm:t(i)] + tokens[t(i)] emitter[token:t(i)] To prevent confusion, a [get_token] is sent from the emitter to token_order only when another token has arrived (except for the first one of course, this is actually always the very first instruction that is executed). There is a diagram on the following page.

45 Image 1.2: Token Retrieval Interface end examples Those were two things that could only be accomplished using multiple contexts, because they require multiple associations to single symbols. In example 1.1, we had to associate numbers with data elements as well as the succeeding numbers, while in example 1.2 tokens had to be ordered in the same circular fashion as the numbers, and we needed a way to store the information if a token is available or not. Note that the use of multiple contexts violates the active networking paradigm, since it relies on an existing node architecture. This could be solved by introducing an instruction that spawns a new node with a certain name. This instruction could also be executed at constant time (by hanging the new node in at the head of the node-list), the removal of a certain node, however, can not. Allowing fraglets to create nodes would also introduce further complications considering namespace uniqueness, but most of them could be solved by allowing nodes to reside within other nodes and making them invisible from the outside (similarly to the way namespaces help to solve naming conflicts in C++ libraries). see section proposals

46 2. The Timer New to the instruction set is the wait instruction. However, storing a separate timeout for each data packet is quite clumsy (mostly because it is impossible to delete a packet having the symbol wait at its head - so all backups would have to be prevented from being resent rather than be explicitly resent). Instead, a timer context was created, that will send a NAK to the emitter each time its timeout runs out. Each time an ACK arrives, we can delay the timer, so it will send us a NAK only if no ACKs have arrived for a while (it still has to be calibrated). To build the timer, a fraglet containing a sequence of N times a singular symbol d and the symbol ALARM at the end has been used (timeout sequence := [d:d:d:..:d:alarm]). Furthermore, there is (almost) always a fraglet waiting around (it has a wait instruction at its head), to slice one d off from the head of the timeout sequence and then restore itself. If the symbol ALARM is detected as header in the context, the NAK is sent to the emitter and the timeout sequence is restored to its initial state. If a delay is triggered (ie. the fraglet [delay] sent to the timer), the d at the head of the timeout sequence is simply overwritten by multiple ds. As this is the simplest context of all, we can (for once) present all the fraglets right here: timer[wait:match:d:split:x:*] timer[matchp:x:wait:match:d:split:x:*] timer[matchp:alarm:split:send:udp:emitter:nak:*:d:d:d:d:alarm] timer[matchp:delay:match:d:d:d:d:d] timer[matchp:reset:match:d:split:d:d:d:d:alarm:*:nul] timer[d:d:d:d:alarm] # 'timeout sequence' 3. Lists Storing backups of data sent away, so they can be sent again if the timeout for an ACK runs out, has been handled the following way: Backups of all outbound symbols are stored in one context, backups, with the t(i)s, the tokens sent away along with those data symbols, as headers. Furthermore, all outbound tokens are stored in a list in a context called missing_tokens. When a token is sent away, a copy of it is appended to the end of the list and the associated backup is sent to backups. When an ACK arrives, the token at the beginning of the list is removed and the corresponding backup in backups is deleted. When a resend is triggered, a copy of the list has to be created and one of the two lists sent to the backups context, where it will trigger a resend of all backups associated with the tokens contained in the list.

47 Fulfilling the first two conditions is easy: To add an element to the list, we can simply write 'match:t:list' at the beginning of the list and have the fraglet [T:new_element] swim around. This way, new_element is attached to the end of the list and the list carries the header 'list' afterwards. add: [list:t(i):t(i+1):..:t(j-1)], [missing:t(j)] [match:t:list:t(i):t(i+1):..:t(j-1)], [T:t(j)] [list::t(i):t(i+1):..:t(j-1):t(j)] Removing an element is not difficult either, all we need to do is exchange the first element first with the symbol list and then with an asterisk, and then invoke split on the list. remove: [list:t(i):t(i+1):..:t(j)] + [returned:t(k)] [exch:r0:list:t(i):..:t(j-1)] [r0:t(i):list:t(i+1)..:t(j-1)] [exch:r1:*:t(i):list:t(i+1)..:t(j-1)] [r1:t(i):*:list:t(i+1)..:t(j-1)] [split:a:t(i):*:list:t(i+1)..:t(j-1)] [a:t(i)] + [list:t(i+1)..:t(j-1)] Note that t(k), the token returned with the ACK, is not necessarily the same as t(i), since although the receiver only sends an ACK for the next expected token, an ACK could be lost along the way - our protocol cannot cope with that. It would be however rather easy to fix this, if we had the equals instruction at our disposal. Note also that if some ACKs only arrived in the wrong order, no damage would occur. see section proposals Creating a copy of the list, however, proved to be quite complicated. A mechanism was conceived that could split off the first entry from the list and append two copies of it to the ends of two new lists, called list0 and list1. Unfortunately, there is no notification after the original list has been emptied - the former list fraglet just disappears instead. So, in order to have a reliable termination condition, another list (labeled size) has to be managed, one that has the single entry 'l' at all those positions, where the original token list has elements. From the size list, we remove the header, put a list_empty symbol at the end, and remove an l for each copied (token-)list-entry (we have to move all ls to another new fraglet called new_size, so we do not lose the size list in the process). This way, as soon as the list_empty symbol has been exposed, all elements have been copied and we can rename one copy of the list back to list, and send the other to backups (after certain additional modifications). Of course, this means that the size list has to be extended by an l each time we add an element and an l has to be removed each time we remove one. On the following page, I will try and explain the procedure again in the form of a simplified algorithm.

48 resend: [list:t(i):t(i+1):..:t(j)] + [resend_all] + [size:l:l:..:l] [copied_list:t(i):t(i+1)..:t(j)] + [list0] + [list1] + [list_size:l:..:l:end_list] + [l] + [new_size] on (match:l) { [copied_list:t(i):t(i+1)..:t(j)] + [list0] + [list1] + [list_size:l:..:l:end_list] + [l] + [new_size] [copied_list:t(i):t(i+1)..:t(j)] + [list0] + [list1] + [list_size:l:..:l:end_list] + [new_size:l] [copied_list:t(i+1)..:t(j)] + [list0:t(i)] + [list1:t(i)] + [list_size:..:l:end_list] + [l] + [new_size:l] } on (match:end_list) { [list0:t(i):t(i+1)..:t(j)] + [list1:t(i):t(i+1)..:t(j)] + [new_size:l:l:..:l] [list:t(i):t(i+1)..:t(j)] + [size:l:l:..:l] + [send:udp:backups:resend:t(i):t(i+1)..:t(j):end_list] } That was an attempt to describe the process of copying the list of missing tokens in a C-like syntax. Lots of steps have been left out. See the attached code, if you would like to know the details. 4. Controlling Parallelism Although, as we have seen in paragraph 3, fraglets are rather unpractical to build data containers (at least without the 'equals' instruction), they do make perfect semaphores. Due to the fact that all list operations from the previous paragraph are handled in multiple steps (since the addition of the size list), and because all three events triggering the individual operations (ACK, NAK and SEND) could occur at practically any time, some measures had to be taken to assure that only one of the operations can take place at a time. The solution was very simple. Each operation was altered so that it assimilates the [READY]-fraglet before it continues, ie. 'match:ready' has been inserted into the fraglet recognizing the interface-call header and after the last step of the operation has been completed, a new [READY]-fraglet is set free. This way, as long as there is exactly one [READY]-fraglet in the beginning, it acts as a 'natural semaphore'.

49 5. The Big Picture And now, the moment we've all been waiting for - a diagram of the entire protocol. To enhance readability, it was split up into three fractions, corresponding to the three basic operations, ACK, NAK and SEND: Image 5.1: reactions taking place when a fraglet is sent to the receptor.

50 Images 5.2 and 5.3: reactions taking place upon arrival of an ACK (above), and when the timer releases a NAK (below).

51 6. Receptor - The Central Flaw So far, we have only explained the emitter side of the protocol. There are two reasons for that. For one, except for its capability to expect a certain token and return an ack with that token when it arrives, it is rather simple. It does need two local nodes, but if we solved the far graver problem, this one would also disappear. The other reason is a that it does not work as it is supposed to. It only expects one token, but that does not prevent it from receiving fraglets carrying others, so it simply ignores those, and they remain dormant. As the token set is circular, at a certain point, the tokens of the dormant fraglets become the expected ones. At that point, there is no way of forcing the system to favor a newly arrived fraglet over an older one. In fact, as the current fraglet with the expected token might need some time to arrive, the dormant ones are actually being preferred. A very simple way out of this would be the introduction of the equals instruction. see section proposals Then, we could simply put a header specific to our protocol in front of every fraglet we send, match that header on the receiver side, and either pick the fraglet or delete it, according to the equality between the token it carries and the expected token. Using a specific header for incoming fraglets (ie. not a token), would then also remove the need for a second context (that is currently used to find the succeeding token to a specific token - see "multiple contexts, example 2").

52 Part Three: Performance Five tests have been performed. Each time, one instance of the fraglet environment was left to send data to another instance over loopback during a time interval of two minutes. The rate of packet loss was thereby altered between the tests (using parameter "-lose N"). The following table contains the results: probability of packet loss fraglets transmitted during two minutes Number of instructions executed on all emitter nodes together / / / / An interesting effect is the drop in transmission performance at low packet loss probabilities. This can be accounted for by the bad calibration of our timer. The timeoutdelay caused by an ACK is probably longer than the average time interval between two succeeding ACKs, so when only a small number of packets is lost, the timeout can grow indefinitely long. If a packet is lost under those conditions, the timeout we have to wait out until the packets are resent can grow very long very quickly. The main reason for this assumption is the dropping number of instructions executed during the two minutes, which implies that nodes were idle for a part of the time. Although we were only sending fraglets of the form [tnn:datan] (size = 11 Bytes) between the nodes, in order to calculate the average transmission rate, we could just as well have sent packets of the size of one kilobyte. A function (called test_send_times(..)) was introduced into the C-code to prove that the impact of packet size on the number of transmitted packets is insignificant to our measurements. The function first sends one million packets of the size of 3 Bytes and then one million packets of the size of 1024 Bytes and prints out the time needed for both procedures. The times the function returns are the following: 3 Byte: 18 secs, and 1024 Byte: 23 secs. The difference are only five seconds over one million packets, or, in the average, five microseconds over one packet.

53 The maximal number of transmitted packets in our test series is 34, so the time difference between sending 34 3-Byte-packets and 34 1-K-packets is about 170 microseconds, which is only slightly more than 1.4 E-4 % of the total time, and thus clearly negligible. So, if we now assume that we were in fact sending packets of the size of one kilobyte (1K would still fit nicely into an IPv4 packet), our highest result, the one with no packet loss involved, would correspond to a transmission rate of about K/sec. This is very low, but it can be greatly attributed to the low interpretation speed of our environment. In order to make a projection on how performance would look like on a theoretical fraglet-based architecture, another function has been introduced, get_instruction_count( ), that adds up all instruction counts of all nodes and sends the sum to the console. Our prime example, the measurement without packet loss, executes roughly 26K instructions on the emitter during the two minutes, and it is probably never idle (each ack arrives even before the next of the thirteen tokens is away). Now if we imagine an architecture that could execute only one million fraglet instructions per second, it would allow us to execute the 26K instructions within about 26 milliseconds. Assuming that each outbound fraglet still carries a payload of one kilobyte, that would correspond to a transmission rate limit set at 1.3 megabytes per second. Then, of course, other factors such as the currently neglected packet size and, most of all bandwidth, would play the crucial role.

54 Part Four: Proposals 1. the 'equals' instruction During the design process, one feature was missed the most. Fraglets rely entirely on a positive logic. If a fraglet with a certain header is present, a reaction can be initiated - if it is not, the reaction will still be initiated once it arrives. There is no way of reacting to the negative outcome of a condition. A great help in this matter would be an instruction with the following behaviour: [ equals : s : t : x : y : tail ] if (x == y) [ s : tail ] else [ t : tail ] With this, we could easily make the receptor in our protocol delete fraglets carrying unexpected tokens. All we would need would be a common header to all fraglets we send to the receptor, and the following two fraglets: Let the header be the symbol DDP, and the expected token t(i) [match:ddp:equals:expected:nul:t(i)] [matchp:expected: <do something with the right packet> ] Another use could be found in missing_tokens in the reaction that removes a token returning with an ACK from the list of missing tokens. Currently, the protocol cannot cope with a lost ACK, because there is no way to know if the token we remove from the list really is the one that has been returned. Using the equals instruction, we could simply keep removing tokens from the list until we get the right one (and return them all to the list, if none of them is the right one - that is what would happen if two ACKs happened to arrive in the wrong sequence).

55 2. the 'spawn' instruction Another instruction that could make a great difference would be one that can create a node either in the environment or the node where it is executed (the latter would require nodes to be able reside within other nodes). The heavy use of multiple contexts demonstrated in our protocol could only then be made compatible with the active networking paradigm. 3. a graphical high-level fraglet language Considering the very unorthodox nature of fraglets (compared to the widely popular programming languages), and the fact that 'copy-paste' commands are used much more frequently while writing fraglet programs, one could imagine a graphical environment that would allow the designer to compose large systems of fraglet-nodes in a very short amount of time. Elementary reactions such as the duplicating of symbols (accounting for a major part of the code to this project) could then be combined to larger reactions (the program would take care of identifier-uniqueness). Those larger reactions would be symbolized by singular 'reaction objects', which in turn could be placed inside nodes. The overall representation might look a little like the diagrams presented in this document. The main benefit to this would be a faster assimilation of the fraglet idea by the public, thanks to increased accessibility - and therefore a greater probability of the concept taking root and evolving - possibly in symbiosis with the hardware industry.

56 Conclusions: Even without the extensions to the instruction set proposed above, it is possible to create quite complex structures using fraglets. This has only been made possible by the use of multiple contexts, as they allow an isolated development of reactions in one singular node, so systems with a fairly large degree of complexity can be broken down into simpler pieces and worked out individually. Some reactions, however, cannot be split up, and in those cases the programmer is suddenly confronted with the full amount of confusion inherent to a programming language based on biochemistry (see lists). It is certainly in the interest of a programmer to work on such problems and waste as little time as possible on trivial tasks like duplications of symbols or the insertion of one specific symbol at one specific point in a fraglet, so I think the need for a higher level language is quite apparent - although lots of repetitive tasks can still be simplified by an extensive use of the 'copy-paste' functionality of any text editor. As diagrams similar to the ones presented in this report were also used in the construction of the protocol itself, the idea of basing a higher level language entirely on such diagrams somehow does not seem that far fetched at all - especially considering that the fraglets paradigm emerged from a world fascinated by the accomplishments made in modern biochemistry, a field that can and does profit greatly from modern visualization techniques (although this applies mostly to 3D visualization techniques). Of course, one could also easily imagine a purely text-based higher level language, but that would take away part of the popularity potential fraglets definitely exhibit so far. Besides of that, the performance of the interpreter is still a little problematic, but I suppose something will be worked out in time. References: C. Tschudin, Fraglets - a Metabolistic Execution Model for Communication Protocols, Proceeding of AINS 2003,

57 VideoConferencing Messung der Bandbreite/Qualität Projektreport Erik Baier Christian Horisberger Projektbeschreibung Ziel ist die Analyse der Übertragungsqualität bei einer Kommunikation über VideoConferencing. Welchen Einfluss haben dabei Faktoren wie 'Paketloss' und die zur Verfügung stehende Bandbreite? Erwartete Resultate Bandbreite minimal: 256 kbit/s (both directions) gute Audio/Video Qualität: 512 kbit/s (both directions) Paketloss Bis zu einer bestimmten Rate noch tolerierbare Qualität der Verbindung. Ist die Technologie für den Heimanwender schon einsetzbar? (~ADSL 600/100 kbit/s) Projektaufbau Zwei PCs werden via Ethernet Schnittstelle (100Mbit/s) miteinander verbunden. Dazwischen schalten wir einen weiteren PC, mit dem Betriebssystem FreeBSD, der zur Simulation von verschiedenen Bandbreiten und Paket Loss dient. Dazu verwenden wir 'dummynet' (ein Bestandteil von FreeBSD). Für die Videoaufzeichnung verwenden wir zwei Logitech Quickcam Webcams. Der Hauptteil des Projektes besteht darin, die Parameter in dummynet zu verändern und die Messresultate zu protokollieren und zu vergleichen (Audio- und Video-Qualität). Als VideoConferencingtool verwenden wir das in Windows XP bereits enthaltene NetMeeting. Vorgehensweise Nachdem wir die Software der Webcams installiert haben, verbinden wir die zwei Laptops direkt über ein Ethernetkabel, um einen ersten Eindruck einer idealen Verbindung zu erhalten. Dabei stellen wir fest, dass die zur Verfügung stehende Bandbreite bei weitem nicht ausgenützt wird. Die Videoqualität ist zudem auf beiden Seiten unterschiedlich und eher mässig. Während die Bildübertragung auf der einen Seite flüssig läuft, ruckelt das Bild auf der anderen Seite doch erheblich. Wir stellen fest, dass der eine akkubetriebene Laptop wegen einer Stromsparfunktion die CPU Leistung stark drosselt. Nachdem wir dieses Problem beheben konnten, gehen wir daran die Optionen von NetMeeting unter die Lupe zu nehmen.

58 NetMeeting Hier fällt uns als Erstes die mangelnde Vielfalt der Einstellungen negativ auf. Besonders bei den Videooptionen scheint das Programm eher veraltet zu sein. Ein Blick in die Applikationsinfos zeigt, dass die uns vorliegende Version 3.01 wohl im Jahre 2001 zum letzten Mal überarbeitet wurde. Die möglichen Einstellungen sind eher wage (Schieberegler für Bildqualität) oder zu ungenau (drei verschiedene Fenstergrössen ohne genaue Grössenangaben). Eine Auswahl von verschiedenen Videocodecs sowie Informationen zum verwendeten Standartcodec fehlen gänzlich. Auch eine Einstellungsmöglichkeit der Bildwiederholungsrate ist nicht vorhanden. (Abb. 1) Abbildung 1 - Videooptionen Dass die zur Verfügung stehende Bandbreite nicht ausgenützt wird, folgt wohl aus dieser beschränkten Optionsvielfalt. Ausserdem stehen inzwischen diverse Video- und Audiokompressionsverfahren zur Verfügung, die hier noch nicht unterstützt werden und bei gleicher Bandbreite bessere Qualität erzielen könnten. Ein wenig besser ist unser Eindruck von der Optionsvielfalt der Audioeinstellungen. Hier kann man zumindest zwischen verschiedenen Codecs wählen, wenn auch der qualitativ beste Codec lediglich 8kHz Mono mit 6400 Bit/s zur Verfügung stellt. Insgesamt hat man sich scheinbar eher für eine einfache Handhabung entschieden, was für Laien aber sicher von Vorteil ist. FreeBSD Bei der Verwendung der uns vorliegenden Version der LiveCD werden die installierten Netzwerkkarten leider nicht unterstützt, was uns zu einer Komplettinstallation von FreeBSD zwingt. Diese gestaltet sich etwas schwieriger als erwartet. Da das Programm ipfw, welches dringend benötigt wird, um dummynet ansprechen zu können, hier nicht vorhanden ist, muss erst der Kernel

59 neu kompiliert werden. Dank der Zusammenarbeit mit der Gruppe VoIP können wir jedoch auch dieses Hindernis schliesslich überwinden. Ein weiteres Problem stellt dann die Verbindung der Laptops mit dem dazwischengeschalteten Computer dar. Der etwas ältere Laptop muss zwingend per Crosscable verbunden werden, während der neuere automatisch umschaltet. Nachdem wir die Routingtabelle erstellt und IP-Adressen vergeben haben, können sich die zwei Laptops anpingen. Nun können wir endlich mit den Messungen beginnen. Messungen Zuerst überlegen wir uns, welche Parameter wir bei der Messung variieren wollen. Wir beschliessen dass folgende Bandbreiten und Paketlossraten realistisch sind: Bandbreiten 56kBit/s 128kBit/s 256kBit/s 512kBit/s 1024kBit/s Paketloss 0% 2.5% 5% 10% 25% Zu jeder Kombination testen wir zudem die drei möglichen Bildgrössen. Die Videoqualität belassen wir auf einem mittleren Wert. Diese Parameter ergeben zusammen noch eine überblickbare Anzahl von Kombinationsmöglichkeiten und sollten ausreichen um eine aussagekräftige Analyse zum Verhältnis Bandbreite/Qualität zu machen. In der nachfolgenden Tabelle haben wir die Resultate für jede Kombination festgehalten. Für die Bewertung der Bild/Audioqualität haben wir uns schlussendlich doch für eine subjektive Wertung von 1 bis 10 entschieden. Wichtige Punkte, die wir dabei berücksichtigt haben sind: Video Bildwiederholungsrate Verzögerung Verpixelung/Artefakte Detailvielfalt dynamische/statische Bilder Audio Verzögerung Klarheit Verständlichkeit Rauschen/Klirren

60 Messresultate zum Projekt Video Conferencing Image Size Bandwith Paket loss Video Sound Comment Small % Gute Qualität Medium % Gute Qualität Large % Gute Qualität Small % Gute Qualität Medium % Gute Qualität Large % 9 10 Gute Qualität Small % 7 10 Medium % 5 10 Ruckelig, Sound gut Large % 3 4 Streifen, Ruckeln, Sound abgehackt Small % 2 3 Stark verpixelt, Sound abgehackt Medium % 2 2 Ruckelig, verpixelt, Sound abgehackt Large % 1 2 Nicht brauchbar Small % 1 1 Nicht brauchbar Medium % 1 1 Nicht brauchbar Large % 1 1 Nicht brauchbar Small % 9 10 Gute Qualität Medium % 8 10 Leichte Streifenbildung Large % 8 8 Bild leicht verzögert Small % 8 10 Lange Wartezeit bis neues Zwischenbild kommt Medium % 7 9 Probleme nur bei schnellen Bewegungen Large % 7 8 Verzögerung, Lange verpixelt, gute Zwischenbilder Small % 7 10 Lange Delays, Refresh ok Medium % 6 10 Starke Artefaktbildung Large % 5 8 Verpixelt, Streifen Small % 8 10 Annehmbare Qualität Medium % 7 8 Streifen bei Bewegungen Large % 7 8 Streifen bei Bewegungen, leicht störend Small % 7 9 Pixel bleiben zu lange bestehen. Medium % 6 7 Verpixelt, refresh OK Large % 5 7 Bild bleibt verpixelt, leichtes Delay Small % 7 10 Schnelle Bewegungen verpixelt, gute Response Zeit Medium % 5 10 Verpixelt Sound OK Large % 3 4 Verpixelt Sound abgehackt Small % 7 10 Sound abgehackt stark vepixelt Medium % 6 8 Stark verpixelt, Bewegungen ruckelig Large % 6 6 Stark verpixelt, Bewegungen extrem schlecht Small % 5 7 Sehr ruckelig Medium % 5 4 Sehr ruckelig, verpixelt Large % 4 6 Ruckelig, Streifen bleiben lange bestehen Any Size % 1 1 Ruckelig, Pixelig, No Sound Any Size % 0 0 No Connection Any Size % 0 0 No Connection Any Size % 0 0 No Connection

61 Bildquelle Die Idee, den Videostream aufzuzeichnen und im Nachhinein direkt zu vergleichen, konnten wir leider nicht umsetzten, da entsprechende Optionen/Tools fehlten. Als Referenzbild verwendeten wir keine Testbilder, sondern echte Gesichter, da dies ja auch die Hauptverwendung der Software sein soll. Simple geometrische Formen/Flächen eigneten sich nicht als Testbilder, denn dabei wurde die Bildqualität nur wenig von der gewählten Bandbreite beeinflusst. Um eingehende und ausgehende Bilder zu vergleichen nahmen wir mit beiden Webcams das selbe Bild auf, um damit die Qualität mit oder ohne Kompression zu vergleichen. Dabei wurde das direkt aufgenommene Bild als kleines Bild-im-Bild dargestellt. (Abb. 2) Abbildung 2- Screenshot NetMeeting Fazit Aufgrund unserer Messungen kommen wir zu folgenden Erkenntnissen: NetMeeting ist veraltet, dafür gratis und auch für Laien einfach zu bedienen Eine automatische Anpassung der Audio/Videoqualität aufgrund von Bandbreite und Paketloss findet nicht statt. Dabei stört uns besonders, dass der Audiostream manchmal abgehackt übermittelt wird, und scheinbar keine Priorität gegenüber der Videoübertragung hat. Eine Paketlossrate, die 10% übersteigt, führt unweigerlich zu einer unbrauchbaren Übertragungsqualität ab 25% Paketloss schafft es die Software nicht einmal mehr, eine Verbindung herzustellen Das absolute Minimum der Bandbreite beträgt 256kbit/s. Diese muss für incoming und outgoing Streams gewährleistet sein. Daher ist die Anwendung mit einem gewöhnlichen ADSL Anschluss nicht zu empfehlen. Für eine brauchbare Qualität benötigt man ~512kBit/s mit möglichst wenig Paketloss Eine neue in Windows integrierte VideoConferencing Software, die die vorhandenen Ressourcen effizienter nutzt, wäre äusserst wünschenswert und könnte der zur Verbreitung der Technologie beitragen.

62 CS 221: Computernetzwerke und Sicherheit Sommersemester 2005 Projekt 10: Bittorrent Espen Jevidalo Patrick Mächler Projekt 10, Bittorrent Espen Jervidalo, Patrick Mächler 1/5

63 Abstract P2P Tauschbörsen, wie etwa Bittorrent, erleben einen enormen Zuwachs. Bittorrent soll dabei besonders faire User belohnen, welche zumindest soviel up wie downloaden. In dieser Arbeit zeigen wir, versuchen wir aufgrund von Messungen zu zeigen, dass dieses System funktioniert. Unsere Ergebnisse fielen dabei positiv aus. Einleitung P2P Netzwerke (Peer to peer) haben in den letzten Jahren massiv an Bedeutung gewonnen, durch die grosse Verbreitung von internetbasierten Kopierbörsen bei Durchschnittsanwendern. Diese sind bekannter unter dem eigentlich falschen, mediengeprägten Begriff Tauschbörsen (denn die Dateien verbleiben auf dem PC und werden nicht ausgetauscht) welche zwar auch existieren aber viel weniger Bedeutung haben [1] (wir werden im weiteren Text dennoch den Begriff Tauschbörsen benutzen). Durch die dezentralisierte Struktur von P2P Netzwerken ist Inhaltskontrolle nur schwer möglich und ermöglicht gleichzeitig eine grosse Verbreitung der Daten, da verschiedenste User die downgeloadeten Dateien in der Regel wieder uploaden und somit eine grössere Bandbreite und Verfügbarkeit für alle User möglich ist (d.h. der Aufwand wird auf alle aufgeteilt). Obschon ein Grossteil der Industrien (z.b. Film und Musik) diese P2P Tauschbörsen mit allen Mitteln bekämpfen, da viele urheberrechtliche geschützte Werke auf diese Art ohne Zahlung der Lizenzgebühren verbreitet werden, sehen einige Zweige der Softwareinsdustrie, insbesondere Linuxdistributoren diese Tauschbörsen auch als grosses Potential. Bittorrent ist eine dieser Tauschbörsen deren Funktionsprinzip wie folgt ist: Es existiert ein zentraler Server, genannt Tracker, der downloadbare Dateien, deren Hashdaten (zur Integritätsprüfung) und die Adressen der Clients welche diese Dateien besitzen verwaltet, jedoch keine eigentlichen Datentransfere [2]. Problemstellung Das Bittorrent Filesharingprotokoll behauptet von sich selbst fair zu sein, d.h. User die mehr uploaden werden besser behandelt als User die weniger uploaden, denn genau auf diesen Prinzipien beruhen die P2P Netzwerke [3]. Gegeben sei nun eine Netzwerktopologie mit verschiedenen Usern die Bittorrent verwenden. Einige User sind dabei fair (d.h. sie uploaden mehr oder genausoviel wie sie downloaden) andere unfair (d.h. sie uploaden wenig oder gar nichts, möchten aber viel downloaden). Werden die unfairen User durch die in Bittorrent eingebauten Machanismen wie geplant bestraft, bzw. die fairen User entsprechend belohnt? Lösungsansatz In diesem Abschnitt werden wir kurz unser Bittorrent Netzwerk vorstellen, sowie erklären wie die Messungen zustande kamen und mit welcher Software diese realisiert wurden. Als Tracker setzten wir eine FreeBSD Box [4] mit direkter Verbindung zum Internet auf, soll heissen keine Firewall und kein NAT, welche Portzugriffe erschwert hätten. BitTorrent Tracker Die Wahl der Tracker Software erwies sich als eine der grössten Hürden. Bei der anfänglich gestellten Fragestellung wäre hier nur ein Tracker mit anti leech Mechanismen in Frage gekommen. Leider mussten wir feststellen, dass es bis heute keine ernstzunehmende Implentierung gibt, welche dieses Feature benutzt. Der Hauptgrund dafür ist, dass man nicht ausschliessen kann, dass Daten vom Client manipuliert werden. Nach einigem hin und her fiel die Entscheidung auf den C++ Tracker BNBT [5]. Die Installation und Configuration verlief problemlos. BitTorrent Client Die Client Software musste 2 Anforderungen erfüllen. Der Client musste in erster Linie fähig sein Transfer Daten wie Projekt 10, Bittorrent Espen Jervidalo, Patrick Mächler 2/5

64 Upload und Download Raten bereitzustellen und zweitens musste sie auch auf einer remote shell bedienbar sein. Der offizielle BT Client von bittorrent.com erwies sich in Kombinaiton mit screen [6] als gute Wahl. Anmerkung: Für grafische Oberflächen eignet sich Azureus [7]. Ein weit verbreitetes Java Programm mit guter Bedienung und integrierter Tracker Funktion. Superseed BitTorrent benötigt neben dem Tracker einen Ur Seeder, welcher von Anfang an, die benötigten Dateien lokal zur Verfügung stellt. Hierbei handelt es sich lediglich um einen BitTorrent Client, welcher die Datei bereits gespeichert hat. Hier findet also kein Datentransfer in dem Sinne statt. Eine sinnvolle Lösung ist es diesen auf der selben Maschine wie den Tracker zu platzieren, jedoch nicht unbedingt notwendig. Daten Eine mittles /dev/random erzeugte Datei von 7936 KB Grösse wurde für die Datenübertragung verwendet. Um das entsprechende torrent File zu erstellen benutzten wir btmaketorrent.py aus der offiziellen Suite von bittorrent.com. Shell Aufruf: Output: btmaketorrent.py file file.torrent Der Befehl setzt sich zusammen aus der Tracker URL und einer Datei. Somit ist in dem erstellten file.torrent die URL verankert, welche beim Start eines neuen Transfers aufgerufen werden musss, um mit dem Tracker in Kontakt zu treten. Ip: BNBT Tracker Superseed Up-/Down-Raten: 100Mbit/s Ip : Seed Up-/Down-Raten: 384 / 1536 Kbit/s VPN Uni 1. Client Up-/Down-Raten: 11Mbit Ip: Client Up-/Down-Raten: 384 / 1536 Kbit/s Abbildung 1: Darstellung des benutzten BitTorrent Netzwerkes. Resultate Für die Demonstration unseres Netzwerkes wurden die 3 unten aufgeführten Messungen durchgefürt. Um die Verteilung der Last auf die vorhandenen Peers aufzuzeigen wurden die übertragenen Datenvolumen gemessen und dargestellt. 1. Datentransfer In diesem Versuch wollen wir den ersten tatsächlichen Datenaustausch demonstrieren. Nur der Superseed steht zur Verfügung mit den gewünschten Daten. Projekt 10, Bittorrent Espen Jervidalo, Patrick Mächler 3/5

65 Beobachtungen: Der Tracker lieferte dem Client nur den ursprünglichen Superseed als Peer. Dieser wurde daraufhin kontaktiert und der Transfer kam nach ungefähr 30 Sekunden zu Stande. Durchschnittliche Übertragungsrate lag bei ~20KB/s Superseed 1. Datentransfer 1. Seed Transferred Data (MB) Received Data (MB) Diagramm 1: 1. Datentransfer Demonstration des ersten tatsächlichen Datenaustausches 2. Datentransfer Der Client aus dem ersten Transfer bietet sich nun ebenfalls als Seed an, somit stehen dem neuen Client 2 Seeds zur Verfügung. Durchschnittliche Übertragungsrate liegt bei ~40KB/s. Beobachtungen: Der Transfer wurde 50 zu 50 aufgeteilt auf die 2 vorhandenen Seeds. Die Übertragungsrate veränderte sich praktisch simultan auf den beiden Seeds und resultierte in einer Downloadrate von 40KB/s für den client. Erstaunlich ist, dass der upload auf den Seeds wiedermal die 20KB/s Schranke nicht überschritt, obwohl viel mehr möglich gewesen wäre. Der Client befand sich im Uni Netzwerk über einen VPN Client (UB wlan). 2. Datentransfer Transferred Data (MB) Received Data (MB) Superseed 1. Seed Client Diagramm 2: 2. Datentransfer Datenautausch mit 2 Clients Projekt 10, Bittorrent Espen Jervidalo, Patrick Mächler 4/5

66 3. Datentransfer Bei dieser Messung wollen wir 2 Clients gleichzeitig starten. Es standen wiederum der Superseed und der 1. Seed zur Verfügung. Im Gegensatz zum 2. Client wurden dem 1. Client beide Seeds vom Tracker übergeben, somit war hier ein Transfer von 2 Seeds simultan möglich. Die resultierende Übertragungsrate peilte sich auf ~30KB/s ein. Der 2. Client musste sich mit lediglich 10KB/s zufrieden geben, ausgehend vom 1. Seed. Es fand keinen Datenaustausch zwischen den beiden Clients statt. Erst einige Zeit nachdem der 1. Client seinen Datentransfer beendet hatte, stiess der Superseed beim verbleibenden Transfer des 2. Clients hinzu und ermöglichte eine Übertragungsrate von 40KB/s Datentransfer Transferred Data (MB) Received Data (MB) Superseed 1. Seed Client 1 Client 2 Diagramm 3: 3. Datenaustausch 2 Clients, einer davon mit Seed Schlussfolgerungen und Ausblick Nebst einigen Beobachtungen die wir uns nicht erklären konnten (wieso werden gewisse Übertragungsraten nicht überschritten, obschon dies möglich wäre?), bestätigte sich mit der 3. Messung die Behauptung, dass Bittorrent faire User belohnt und unfaire User nicht. Da bereits einige Tracker wegen Rechtsstreitigkeiten vom Netz genommen werden mussten (bekanntestes Beispiel ist wohl suprnova.org [8]) werden derzeit starke Bemühungen unternommen Bittorrent auf eine komplett dezentralisierte Ebene, d.h. ohne zentrale Tracker, zu bringen. Entsprechende Implementierungen befinden sich aber noch grösstenteils in der Betaphase, weshalb wir zu diesem Zeitpunkt hier von Messungen absahen. Referenzen [1] [2] [3] [4] [5] [6] [7] [8] Projekt 10, Bittorrent Espen Jervidalo, Patrick Mächler 5/5

67 Projekt CS 221 Gigabit NIC Marcus Baechinger, Stephan Steiger Sommersemester 2005 Abstract Anhand von Geschwindigkeitstest konnten wir feststellen, dass sich der Umstieg auf Gigabitnetzwerke für allgemeine Anwendungen (Datentransfers) nur bedingt lohnt. Eine Abstimmung der Hardware und gute Informationssammlung sind nötig, damit man die optimale Leistung erreichen kann. Einleitung Im Moment werden überall bessere und schnellere Netzwerke angepriesen. Immer mehr Firmen stellen ihre Netzwerke auf Gigabit-Ethernet oder neue schnellere Methoden um. Doch lohnt es sich wirklich, die ganzen Switchtes, Netzwerkkarten und anderes zu ersetzen? Bekommt der Kunde wirklich die versprochene Geschwindigkeitssteigerung? Diese Fragen zu beantworten ist das Ziel unseres Projekts. Problemstellung Wir versuchten die folgenden Fragen zu beantworten: i) Wie hoch ist der maximale Durchsatz über 1) eine Crossover-Verbindung 2) über eine Verbindung mit Switch? 1

68 ii) Gibt es verschiedene Treiber für die Karten und wird je nach dem ein besserer Durchsatz erreicht? Lösungsansatz Die beiden PCs waren mit je einer D-Link GBNIC ausgerüstet. Für die Tests mit dem Switch haben wir einen Netgear Gigbit-Switch verwendet Vorgehen für Frage i): Der Druchsatz soll mit den Tools iperf und iptraf gemessen werden. Wir wollen Tests mit folgenden Methoden durchführen: a) Maximaler Output über /dev/zero. Messung mit iperf. b) Filetransfer ohne Protokoll. Messung mit iperf. c) Filetransfer mit dem smb-protokoll. Messung mit iptraf. Vorgehen für Frage ii): Suche auf dem Internet nach allfälligen Opensource-Treibern und anderen Hersteller- Treibern. Wir haben jedoch keine anderen Treiber als die des Herstellers gefunden. Resultate Die Installation der Karten verlief ohne Probleme. Die Karten wurden vom Betriebssystem (Linux: Fedora Core 3) erkannt und waren sofort einsatzbereit. Durch hinzufügen eines Moduls im Kernel wurde auch das Erhöhen der MTU ermöglicht. Die Infos dazu waren auf der CD des Netzwerkkartenherstellers zu finden. Messung des Durchsatzes Wir haben einen durchschnittlichen Durchsatz von maximal von 800MB/s erreicht, aber nur mit ganz bestimmten Konfigurationen. Das Maximum konnten wir nur durch folgenden Aufbau erreichen: Die PCs waren mit dem Crossover-Cable verbunden und die MTU war auf

69 gesetzt. Damit die Daten von der Festplatte unabhängig gesendet werden konnten, sendeten wir Daten aus /dev/zero via iperf an den anderen PC. Die anderen Konfiguration sahen wie folgt aus: Verbunden mit Crossover-Cable: MTU 1500/8000, Filetransfer via iperf; MTU 8000, Filetransfer via SMB. Wir mussten feststellen, dass alle Transfers mit einer MTU >1500 nicht durch den Switch gingen, darum konnten wir die Testserien nur mit einer kleinen MTU durchführen. Die Produktinfos zum Switch gaben zwar eine maximale MTU von 8010 an, was dann aber im Test nicht funktionierte. Verbunden über Switch: MTU 1500, Transfer von /dev/zero; Filetransfer via iperf; Filetransfer via SMB. Die Vergleiche sind in den folgenden Grafiken dargestellt. Abbildung 1: Maximaler Durchsatz Vergleich der maximalen Geschwindigkeitsraten über ein Gigabitnetzwerk 3

70 Abbildung 2: Maximaler Durchsatz mit Hinderniss Festplatte Vergleich des maximlen Durchsatzes bei Filetransfer (ohne Protokoll) Schlussfolgerung Ein Durchsatz von 1 Gigabit/s wurde nie erreicht, was wir auch nicht erwarteten. So waren wir mit einer Geschwindigkeit von 800 MBits/s zufrieden, wenn auch diese Geschwindigkeit nur in einer bestimmten Konfiguration erreicht wurde. Würde der Switch auch mit der höheren MTU (8000) funktionieren, hätte die Gigabit-Technologie den Test bestanden und das Aufrüsten von Netzwerken auf Gigabitübertragung würde sich lohnen. Die Frage bleibt, ob ein Umstieg sinnvoll ist, da das Netzwerk meist für Datenübertragung gebraucht wird, welche jedoch nicht schnell genug von der Festplatte gelesen werden. Eine vorherige Abstimmung der Hardware (NIC - Switch) hätte ev. das Problem mit der tiefen MTU des Switch gelöst. 4

71 Abbildung 3: Maximaler Durchsatz mit smb Vergleich des maximlen Durchsatzes bei Filetransfer (mit smb-protokoll) 5