Peer-to-Peer Computing für mobile Ad Hoc Netze
Werbung
Gliederung Peer-to-Peer Computing für mobile Ad Hoc Netze Christoph Lindemann Universität Dortmund Informatik IV -Rechnersysteme und LeistungsbewertungAugust-Schmidt-Str. 12 44227 Dortmund http://www4.cs.uni-dortmund.de/~Lindemann/ Dieser Vortrag basiert auf gemeinsamen Arbeiten mit A. Klemm und O. Waldhorst ! Peer-to-Peer Computing und Ad Hoc Netze – P2P Systeme im Internet – P2P Systeme und mobile Ad Hoc Netze – Motivation der Forschungsarbeiten ! Das MANET Routing Protokoll und das Suchverfahren – Schwächen statischer Overlay Verbindungen – Schlüsselideen für den Entwurf des ORION Systems – Leistungskurven ! Das MANET Transfer Protokoll zum Runterladen von Dateien – Veranschaulichung der Funktionsweise – Leistungskurven ! Weitere Arbeiten Rechnersysteme und Leistungsbewertung Universität Dortmund 2 Veranschaulichung: P2P im Internet ! ! physikalische Kommunikation auf der IP Schicht logische Kommunikation auf der Applikationsschicht Peer-to-Peer Computing und Ad Hoc Netze ! ! Gnutella (AOL 2000), Chord (Kaashoek 01), PAST (Druschel 01), CAN (Ratnasamy 01) Herausforderung: Skalierbarkeit, Streaming Apps Rechnersysteme und Leistungsbewertung Universität Dortmund 4 Peer-to-Peer Systeme und Ad Hoc Netze ! MANET Anwendungsfelder (1) Mobile Ad Hoc Netze (MANET) ! – Multi-Hop Kommunikation – Jeder mobile Knoten kann als Relay für andere Knoten dienen ! Drahtlose Ad Hoc Netze haben viele Gemeinsamkeiten mit Peer-to-Peer (P2P) Systemen – Keine Infrastruktur – Kein a-priori Wissen über globalen Zustand – Ständig viele neu ankommende und abgehende Teilnehmer ! drahtloses LAN IEEE 802.11 – Mit Internet Zugang Internet – Mit Ad Hoc Erweiterungen IP Router Ethernet IEEE 802.11 Access Point IEEE 802.11 Access Point MANET Routing Protokolle – Proaktiv DSDV (Perkins 1994), reaktiv: DSR (Johnson et al. 2002), hybrid: AODV (Perkins et al. 2002) ! MANET Erweiterung für mobiles Internet – 7DS (Schulzrinne et al. 2001) Rechnersysteme und Leistungsbewertung Universität Dortmund 5 MANET Anwendungsfelder (2) ! Rechnersysteme und Leistungsbewertung Universität Dortmund 6 mobiles Ad Hoc Netz für Car-to-Car App. Mobil, drahtlos und vollständig autonomes LAN/MAN P2P Applikationen ! – IEEE 802.11 oder zukünftige Funktechnologie – Super Knoten mit UMTS Zugang zum Internet Internet Internet Informationsaustausch über Verkehrsereignisse (Stau, Unfall, Glatteis, etc.) ! Download Audio, Video, Streckenplanning von Infostation ! Drahtloser Parkautomat Herausforderungen: ! Ausnützen der Bewegung für Resource Discovery ! Funktechnologien für große Reichweite und schnelle Bewegung Rechnersysteme und Leistungsbewertung Universität Dortmund 7 Rechnersysteme und Leistungsbewertung Universität Dortmund 8 mobiles Ad Hoc Netz für Infotainment App. Aktuelle Forschungsthemen ! P2P Applikationen – Optimierung des Routing für vorgegebene Applikationen ! Internet Content-basierte Routing Protokolle für MANET File Sharing für mobiles elearning (z.B. “Notebook University”) ! Tausch von Musikclips, Klingeltönen, Bildern etc. von Handy zu Handy ! Resource Discovery durch Ausnützen von Bewegung – Passives verteiltes Indexieren ! Arbeitslastcharakterisierung und –modellierung für P2P-Systeme – Messmethodik, Verkehrsmodell, Parameterschätzverfahren Herausforderungen: ! ! Routing Protokolle für unregelmässige Bewegung ! QoS Unterstützung für Streaming Applikationen ! Effektives Management niedriger Speicher- und Batteriekapazität – Regelung durch Online Analyse einer Markov Modells ! ! ! Rechnersysteme und Leistungsbewertung Universität Dortmund 9 QoS/Revenue Management für B3G mobile Netze Erweiterungen für TCP über drahtlose Verbindungen Geschäfts- und Anreizmodelle für Relay Nutzung … Rechnersysteme und Leistungsbewertung Universität Dortmund 10 State-of-the-Art P2P Systeme P2P im IP Festnetz ! Gnutella, Chord, Past, etc. verwenden statische Verbindungen auf Applikationsschicht Das MANET Routing Protokoll und das Suchverfahren – Da Topologie des Netzes statisch ist, kein hoher Overhead – Bei hinreichend hoher Bandbreite kein Engpass Probleme für P2P in MANET ! häufig wechselnde Topologie und geringe Netzbandbreite ! Overlay Netz stimmt sehr schlecht mit zugrundeliegender Netztopologie überein – Lebenszeit einer Route auf Applikationsschicht (Verweilzeit eines Knotens im Bereich Min. bis Std.) – Lebenszeit einer Route auf Netzwerkschicht (Mobilität eines Knotens im Bereich Sek. bis Min.) Rechnersysteme und Leistungsbewertung Universität Dortmund 12 Schwächen statischer Overlay Verbindungen (1) ! Hoher Overhead für Routing Schwächen statischer Overlay Verbindungen (1) ! – Bewegung von Knoten erfordert häufiges Abgleichen und Erneuern gebrochener Routen Hoher Overhead für Routing – Bewegung von Knoten erfordert häufiges Abgleichen und Erneuern gebrochener Routen C C B F D A B F D A E G Rechnersysteme und Leistungsbewertung G Universität Dortmund 13 Schwächen statischer Overlay Verbindungen (1) ! Hoher Overhead für Routing Rechnersysteme und Leistungsbewertung Hoher Overhead für Routing – Bewegung von Knoten erfordert häufiges Abgleichen und Erneuern gebrochener Routen C C B D A Rechnersysteme und Leistungsbewertung B F Universität Dortmund D A E G 13 Schwächen statischer Overlay Verbindungen (1) ! – Bewegung von Knoten erfordert häufiges Abgleichen und Erneuern gebrochener Routen Universität Dortmund E G 13 Rechnersysteme und Leistungsbewertung F Universität Dortmund 13 Schwächen statischer Overlay Verbindungen (1) ! Hoher Overhead für Routing Schwächen statischer Overlay Verbindungen (1) ! – Bewegung von Knoten erfordert häufiges Abgleichen und Erneuern gebrochener Routen Hoher Overhead für Routing – Bewegung von Knoten erfordert häufiges Abgleichen und Erneuern gebrochener Routen C C B F D A B E G Rechnersysteme und Leistungsbewertung Universität Dortmund E G 13 Schwächen statischer Overlay Verbindungen (2) ! F D A Häufiges Abbrechen der Verbindungen auf Applikationsschicht Rechnersysteme und Leistungsbewertung Häufiges Abbrechen der Verbindungen auf Applikationsschicht – Die Verbindung auf Applikationschicht kann aufgrund von Bewegung abbrechen – Erfordert Aufruf eines Bootstrap Mechanismus C C B D Rechnersysteme und Leistungsbewertung B F Universität Dortmund D A E G 13 Schwächen statischer Overlay Verbindungen (2) ! – Die Verbindung auf Applikationschicht kann aufgrund von Bewegung abbrechen – Erfordert Aufruf eines Bootstrap Mechanismus Universität Dortmund E G 14 Rechnersysteme und Leistungsbewertung F Universität Dortmund 14 Schwächen statischer Overlay Verbindungen (2) ! Häufiges Abbrechen der Verbindungen auf Applikationsschicht Schwächen statischer Overlay Verbindungen (3) ! – Die Verbindung auf Applikationschicht kann aufgrund von Bewegung abbrechen – Erfordert Aufruf eines Bootstrap Mechanismus Schlechte Auslastung der Konnektivität auf Verbindungsschicht – Physikalische Verbindungen werden unnötigerweise mehrmals durchlaufen – Gilt für IP Festnetz wie für MANET C A C B X B F D X E G Rechnersysteme und Leistungsbewertung Universität Dortmund E G 14 Schwächen statischer Overlay Verbindungen (3) ! F D A Schlechte Auslastung der Konnektivität auf Verbindungsschicht Rechnersysteme und Leistungsbewertung Schlechte Auslastung der Konnektivität auf Verbindungsschicht – Physikalische Verbindungen werden unnötigerweise mehrmals durchlaufen – Gilt für IP Festnetz wie für MANET C C B D A Rechnersysteme und Leistungsbewertung B F Universität Dortmund D A E G 15 Schwächen statischer Overlay Verbindungen (3) ! – Physikalische Verbindungen werden unnötigerweise mehrmals durchlaufen – Gilt für IP Festnetz wie für MANET Universität Dortmund E G 15 Rechnersysteme und Leistungsbewertung F Universität Dortmund 15 Schwächen statischer Overlay Verbindungen (3) ! Schlechte Auslastung der Konnektivität auf Verbindungsschicht Schwächen statischer Overlay Verbindungen (3) ! – Physikalische Verbindungen werden unnötigerweise mehrmals durchlaufen – Gilt für IP Festnetz wie für MANET Schlechte Auslastung der Konnektivität auf Verbindungsschicht – Physikalische Verbindungen werden unnötigerweise mehrmals durchlaufen – Gilt für IP Festnetz wie für MANET C C B F D A B E G Rechnersysteme und Leistungsbewertung Universität Dortmund E G 15 Schwächen statischer Overlay Verbindungen (3) ! F D A Schlechte Auslastung der Konnektivität auf Verbindungsschicht Rechnersysteme und Leistungsbewertung Schlechte Auslastung der Konnektivität auf Verbindungsschicht – Physikalische Verbindungen werden unnötigerweise mehrmals durchlaufen – Gilt für IP Festnetz wie für MANET C C B D A Rechnersysteme und Leistungsbewertung B F Universität Dortmund D A E G 15 Schwächen statischer Overlay Verbindungen (3) ! – Physikalische Verbindungen werden unnötigerweise mehrmals durchlaufen – Gilt für IP Festnetz wie für MANET Universität Dortmund E G 15 Rechnersysteme und Leistungsbewertung F Universität Dortmund 15 Schlüsselideen des ORION Systems ! Veranschaulichung des Suchverfahrens Verbesserung A: kein Aufrechterhalten fester Verbindungen auf Applikationsschicht ! Response Routing Table – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen – Idee: Ersetzen von Application-layer Forwarding durch Linklayer Flooding (wie Multicast Mechanismus in DSR) ! File Routing Table – Routen zur Übertragung gefundener Dateien ! Verbesserung B: Reduktion des Kontroll-Overhead für die Auslieferung von Antworten C Local 1, 2, 3 – Idee: Zusammenstellen von Return Routen während des Flutens einer Anfrage (wie Routen-Entdeckung in AODV) A ! Verbesserung C: Reduktion der Response-Nachrichten Local – Idee: Aggregation identischer Suchergebnisse Rechnersysteme und Leistungsbewertung 1, 2 Universität Dortmund 16 Veranschaulichung des Suchverfahrens ! Rechnersysteme und Leistungsbewertung D Local 2, 3, 4 Universität Dortmund 17 Veranschaulichung des Suchverfahrens Response Routing Table ! – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen ! B Response Routing Table – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen File Routing Table ! – Routen zur Übertragung gefundener Dateien File Routing Table – Routen zur Übertragung gefundener Dateien C Local C Q 1, 2, 3 Local 1, 2, 3 Q A B A Local 1, 2 Rechnersysteme und Leistungsbewertung Universität Dortmund B Q Local D 1, 2 Local 2, 3, 4 17 Rechnersysteme und Leistungsbewertung Universität Dortmund D Local 2, 3, 4 17 Veranschaulichung des Suchverfahrens ! Veranschaulichung des Suchverfahrens Response Routing Table ! – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen ! – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen File Routing Table ! – Routen zur Übertragung gefundener Dateien Local C 1, 2, 3 B 1 2 Rechnersysteme und Leistungsbewertung A Remote Local 1, 2 1: B 1, 2 D Local 2: B 2, 3, 4 Universität Dortmund 17 Rechnersysteme und Leistungsbewertung Response Routing Table ! ! – Routen zur Übertragung gefundener Dateien Remote 1: B 2, 3, 4 Universität Dortmund 17 Response Routing Table File Routing Table Local C 1, 2, 3 1 2 3 A Remote Local 1, 2 1: B 1, 2 D Local 2: B 2, 3, 4 Local 1, 2, 3 B Local 2: B Local – Routen zur Übertragung gefundener Dateien C B D – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen File Routing Table A 1, 2, 3 Veranschaulichung des Suchverfahrens – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen ! Local B Local Veranschaulichung des Suchverfahrens ! File Routing Table – Routen zur Übertragung gefundener Dateien C A Response Routing Table Remote D Local 2, 3, 4 3: C Rechnersysteme und Leistungsbewertung Universität Dortmund 17 Rechnersysteme und Leistungsbewertung Universität Dortmund 17 Veranschaulichung des Suchverfahrens ! Veranschaulichung des Suchverfahrens Response Routing Table ! – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen ! – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen File Routing Table ! – Routen zur Übertragung gefundener Dateien Remote Local C 1, 2, 3 B 3 1: B File Routing Table – Routen zur Übertragung gefundener Dateien C A Response Routing Table A Remote Local 1, 2 1: B 1, 2 D Remote Local 2: B 2, 3, 4 3: B 3: C Rechnersysteme und Leistungsbewertung Universität Dortmund 17 Rechnersysteme und Leistungsbewertung Response Routing Table ! ! – Routen zur Übertragung gefundener Dateien 1: B C 1, 2, 3 Remote Local 1, 2 1: B 1, 2 Remote Universität Dortmund D Local 2: B 2, 3, 4 3: B Local 1, 2, 3 B Local 3: C Rechnersysteme und Leistungsbewertung File Routing Table A 2 3 4 17 Response Routing Table Local B 2: B 3: B Universität Dortmund – Routen zur Übertragung gefundener Dateien C Remote 2, 3, 4 – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen File Routing Table A Remote Local Veranschaulichung des Suchverfahrens – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen ! D 3: C Veranschaulichung des Suchverfahrens ! 1, 2, 3 B Local 2: B Local Remote D Local 2, 3, 4 3: C 4: D 17 Rechnersysteme und Leistungsbewertung Universität Dortmund 17 Veranschaulichung des Suchverfahrens ! Veranschaulichung des Suchverfahrens Response Routing Table ! – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen ! – Rückwärtsgerichtete Routen zur Übertragung von Suchergebnissen File Routing Table ! – Routen zur Übertragung gefundener Dateien – Routen zur Übertragung gefundener Dateien C 1, 2, 3 B A 4 Remote 1: B Remote Local 1, 2 1: B 1, 2 Local D Remote Remote 3: B 3: C 17 Leistungsstudie: Suchgenauigkeit Rechnersysteme und Leistungsbewertung ORION Message Volume (MB) Fraction of Responses 300 0,6 0,5 0,4 0,3 0,2 0,1 Universität Dortmund 643.1 250 ! 20 40 60 80 200 150 100 50 27.5 0 100 Off-the-Shelf Number Of Nodes Ansteigende Anzahl von Knoten Mehr als 90% Datenvolumen des off-the-shelf Systems für periodisches Aufrechterhaltung von Routen und Verbindungen ! Reduzierung des Overhead um mehr als zwei Größenordnung ! Mehr 70% des Datenvolumens bei ORION besteht aus Payload Bei off-the-shelf Ansatz werden Anfragen bei steigender Knotenanzahl nicht von jedem Knoten empfangen Rechnersysteme und Leistungsbewertung Universität Dortmund ORION ! – Ansteigende Netzlast – Ansteigende Anzahl von verlorener Nachrichten (Drops) ! 17 MAC & other Connection Control Payload 0 0 2, 3, 4 Zusammensetzung des Datenvolumens 0,8 Off-the-Shelf Local 4: D Universität Dortmund 0,7 1, 2, 3 3: C 4: B 4: D Rechnersysteme und Leistungsbewertung D 2: B 2, 3, 4 Local B Local 2: B 3: B File Routing Table Local C A Response Routing Table 18 Rechnersysteme und Leistungsbewertung Universität Dortmund 19 Veranschaulichung des Transferprotokolls ! Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt Das MANET Transferprotokoll zum Runterladen von Dateien C A B D 1 2 3 4 5 6 Rechnersysteme und Leistungsbewertung Universität Dortmund 21 Veranschaulichung des Transferprotokolls Veranschaulichung des Transferprotokolls ! ! Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt 1? C 1? A Steuerung des Datei-Transfers beim Empfänger B A B D D 1 2 3 4 5 6 Rechnersysteme und Leistungsbewertung C 1 2 3 4 5 6 Universität Dortmund 21 Rechnersysteme und Leistungsbewertung Universität Dortmund 21 Veranschaulichung des Transferprotokolls Veranschaulichung des Transferprotokolls ! ! Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt C A B C 1 A B 1 D D 1 2 3 4 5 6 Rechnersysteme und Leistungsbewertung 1 2 3 4 5 6 Universität Dortmund 21 Rechnersysteme und Leistungsbewertung Universität Dortmund 21 Veranschaulichung des Transferprotokolls Veranschaulichung des Transferprotokolls ! ! Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt C C 2? A B A B D D 1 2 3 4 5 6 Rechnersysteme und Leistungsbewertung 1 2 3 4 5 6 Universität Dortmund 21 Rechnersysteme und Leistungsbewertung Universität Dortmund 21 Veranschaulichung des Transferprotokolls Veranschaulichung des Transferprotokolls ! ! Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt 2? A Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt C C B A B 2 D D 1 2 3 4 5 6 Rechnersysteme und Leistungsbewertung 1 2 3 4 5 6 Universität Dortmund 21 Rechnersysteme und Leistungsbewertung Universität Dortmund 21 Veranschaulichung des Transferprotokolls Veranschaulichung des Transferprotokolls ! ! Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt Steuerung des Datei-Transfers beim Empfänger – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt C A C B A B 2 D D 1 2 3 4 5 6 Rechnersysteme und Leistungsbewertung 1 2 3 4 5 6 Universität Dortmund 21 Rechnersysteme und Leistungsbewertung Universität Dortmund 21 Veranschaulichung des Transferprotokolls Steuerung des Datei-Transfers beim Empfänger Successful Transfers (%) ! Leistungsstudie: Erfolgreiche Transfers – Sender kann während des Runterladens wechseln – Anfragen werden nicht an einem bestimmten Knoten adressiert, sondern für ein bestimmtes Fragement gestellt ! Verfahren zum Aufrechterhalten einer Route ! Packet Scheduling und Loss Recovery C A 90 80 70 60 50 40 30 20 10 0 Off-the-Shelf ORION 0 B 20 40 60 80 100 Number of Nodes ! Ansteigende Anzahl von Knoten – Ansteigende Konnektivität ! D 1 2 3 4 5 6 Rechnersysteme und Leistungsbewertung Leistungsverbesserung von ORION aufgrund des Re-query Mechanismus – Auffrischen von Routing Information und des Standorts einer Datei Universität Dortmund 21 Zusammenfassung Rechnersysteme und Leistungsbewertung Universität Dortmund Arbeitsgebiet Beobachtung ! Performance Evaluation P2P Systeme besitzen sehr schlechtes Leistungsverhalten für MANET aufgrund Verwendung statischer Verbindungen auf Applikationsschicht (Overlays) Online Analyseverfahren Forschungsergebnis ! 22 P2P System speziell zugeschnitten für MANET – Overlay Topologie spiegelt Netztopologie sehr gut wieder – Aggregation identischer Suchergebnisse zur Reduktion der Response-Nachrichten – Bereitstellung von Routing Information für effiziente Übertragung gefundener Dateien ohne zusätzlichen Aufwand Mobile Computing Systems QoS/Revenue Management Charakterisierung von Suchanfragen Peer-to-Peer Computing ! Reduzierungung des Overhead um mehr als zwei Größenordnungen ! Verbesserung der Suchgenauigkeit um eine Größenordnung Rechnersysteme und Leistungsbewertung Universität Dortmund Content-based Routing Protokolle 23 Rechnersysteme und Leistungsbewertung Universität Dortmund 24
