Kalman Graffi - Efficiency and Information Management in Peer-to-Peer Systems
1. Efficiency and Information Management in Peer-to-Peer Systems QuaP2P Kolloquium, 9. April 2008 Efficiency and Information Management 7.31.10.25 peer - to - peer.info 12.5.7.31 95.7.6.10 86.8.10.18 planet - lab.org berkeley.edu 89.11.20.15
2.
3.
4.
5.
6. Efficiency Management in Peers Publikationen Systematic First Response Use Case Evaluation D. Bradler, J. Kangasharju, M. Mühlhäuser MODIES 2008 Evaluation of Peer-to-Peer Overlays for First Response D.Bradler, J. Kangasharju, M. Mühlhäuser, MP2P 2008 Taxonomy on Sched. and AQM Mechanisms in P2P Scenarios K. Graffi et al.Technical Report KOM-2007-1/2, 2007 Taxonomy of Scheduling and Active Queue Mechanisms on Overlay Flows Welche Strategien aus der Netzwerk-schicht sind auch im Overlay anwendbar? 01/2007 1. Message Scheduling Before: After : 2. Queue Management Before: After: Queue Limit Overlay Bandwidth Management – Scheduling and Active Queue Management of Overlay Flows Overlay Bandwidth Mana-gement: Sched. and AQM of Overlay Flows, K.Graffi et al., IEEE LCN ‘07 Wie kann man QoS für Overlay Flows erbring-en? Welche Verfahren sind geeignet? Sind lokale Lösungen aus-reichend? 10/2007 Wie kann man QoS (geringe Latenz, Loss) für P2P-basierte Notrufdienste erbringen? Anwendung der Erkenntnisse. ECHoP2P: Emergency Call Handling over P2P Overlays ECHoP2P: Emergency Call Handling over P2P Overlays K.Graffi, A.Kovacevic, et al. P2P-NVE ‘07 11/2007 Connect me to an emergency station! Emergency Call Handling QoS Provisioning 05/2007 P2P Forschung - Übersicht und Herausforderungen, K.Graffi, Quap2P, it-Informa-tion Technology, 2007 Peer-to-Peer Research – Overview and Challenges Was ist Peer-to-Peer? Gemeinschaftsarbeit von QuaP2P mit einem Überblick zu Peer-to-Peer und seinen Herausforder-ungen. Network Wrapper Overlay Layer User UDP TCP Online-time Model Behavior Package Loss Delay Model Bandwidth Kademlia Simulation Engine Application Layer Distribution Strategy Chord Replication Strategy
7. Efficiency Management in P2P Networks 05/2008 Load Balancing for Multimedia Streaming in Heterogeneous Peer-to-Peer Systems K.Graffi,…,A.Kovacevic, et al. ACM NOSSDAV ‘08 Load Balancing for Multimedia Streaming in Heterogeneous Peer-to-Peer Systems Wie kann die Ressourc- en und Aufgabenver-teilung in P2P Netzen fair gestaltet werden? Wie kann man Lasten-verteilung und Hetero-genität unterstützen? Eine allgemeines Over-Overlay für Attribute-based Peer Search. Wie gestaltet man skalierende Informationsarchitekturen? Information and Efficiency Management: Attribute-based Peer Search for Structure P2P Overlays Towards and Information and Efficiency Management Arch… K. Graffi et al. Technical Report KOM-2008-2, 2008 4/2008 7.31.10.25 peer - to - peer.info 12.5.7.31 95.7.6.10 86.8.10.18 graffi.org - lifesocial.org 130.83.139.139 KBR Layer Unified ID Space with Overlay specific IDs KBR using Unified ID Space Coordinator Support Peer Peer From Cells to Organisms: Long-Term Guarantees on Service Provisioning in P2P Networks K. Graffi, A.Kovacevic, et al. ACM SIGAPP NOTERE ’08 From Cells to Orga-nisms: Long-term Guarantees on Service Provisioning in Peer-to-Peer Networks Wie kann man die Optimierung der Res- sourcenverteilung im Overlay als Aufgabe des Overlays gestalten? 06/2008 Information and Efficiency Management in the case of FreePastry Information and Efficiency Management in the Case of FreePastry, K.Graffi et al., to be published ‘08 Ein Statistik-Modul (für Overlay Service Provider) und Attribute-based Peer Search. 3/2008 7.31.10.25 peer - to - peer.info 12.5.7.31 95.7.6.10 86.8.10.18 graffi.org - lifesocial.org 130.83.139.139
8. Towards QoS & Emergency Call Handling 2 Connect me to an emergency station! Emergency Call Handling QoS Provisioning
9.
10.
11.
12.
13.
14.
15.
16.
17.
18. Towards a Kind of „Efficiency Management” 4 Peers α β λ μ Parameters f( α , β )=…= x g( λ , μ )=…=y h( α , λ )=…=z Models Interpreted state Architecture Choose priorities Efficiency Management Architecture Analysis, Modeling and Interpretation Using Info. to Gain Efficiency
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31. Questions? Kalman Graffi Peer-to-Peer Research Group Dept. of Electrical Engineering and Information Technology Multimedia Communications Lab · KOM Merckstr. 25 · 64283 Darmstadt · Germany Phone (+49) 6151 – 16 49 59 Fax (+49) 6151 – 16 61 52 [email_address] Further information: http://www.KOM.tu-darmstadt.de/ Publications: http://www.KOM.tu-darmstadt.de/Research/Publications/publications.html
Notas do Editor
Roter Faden: Evtl. Unklare Details:
Roter Faden: Was ist P2P? Welche QoS Anforderungen bisher gestellt? Evtl. Unklare Details:
Roter Faden: Viele Qualitätsaspekte wichtig für P2P Systeme Evtl. Unklare Details:
Roter Faden: Zukünftige, “seriöse” P2P Applikationen bestehend aus effizienten Modulen die QoS bieten. Anwendungsbesipiel: Katastrophenszenario -> Überleitung zu Emergency Call Handling Evtl. Unklare Details: ??ja: rst?? FreePastry: Freie modulare Implementierung von Pastry, PAST: Storage+Replikationslogik modular aufbauen zu FreePastry, Scribe: Group Communication für FreePastry, POST: co-operative messageing, SplitStream: high-bandwidth content distribution Gegensatz zu früher: P2P Programme werden nicht mehr from the scratch entwickelt, sondern modular zusammengesteckt
| | November 19, 2007
| | November 19, 2007
Roter Faden: Zukünftige, “seriöse” P2P Applikationen bestehend aus effizienten Modulen die QoS bieten. Anwendungsbesipiel: Katastrophenszenario -> Überleitung zu Emergency Call Handling Evtl. Unklare Details: ??ja: rst?? FreePastry: Freie modulare Implementierung von Pastry, PAST: Storage+Replikationslogik modular aufbauen zu FreePastry, Scribe: Group Communication für FreePastry, POST: co-operative messageing, SplitStream: high-bandwidth content distribution Gegensatz zu früher: P2P Programme werden nicht mehr from the scratch entwickelt, sondern modular zusammengesteckt
Roter Faden: ECH: ungelöst, Anforderungen: Location-based search, QoS-mechanisms Evtl. Unklare Details: Grafiken rechts zeigen Bilder die für die Simualtion dann verwendet wurden: Populationsdichte, Notrufzuständigkeitsgebiete, Simulationssnapshot
Roter Faden: Globase.KOM löst das Problem der Location-based Search, Details Evtl. Unklare Details: Special Issue of the Proceedings of IEEE on Advances in Distributed Multimedia Communications
Roter Faden: Unsere Lösung: Eingeschobener Network Wrapper zum einbetten von QoS Mechanismen für Overlay Nachrichten. HiPNOS behandelt Nachrichten gemäß ihrer Delay und Loss Prioritäten. Results: Lösung funktioniert sehr gut. Evtl. Unklare Details: Sollen Referenzen zu den Lösungen hier eingefügt werden? Oder zu Globase?
Roter Faden: Unsere Lösung: Eingeschobener Network Wrapper zum einbetten von QoS Mechanismen für Overlay Nachrichten. HiPNOS behandelt Nachrichten gemäß ihrer Delay und Loss Prioritäten. Results: Lösung funktioniert sehr gut. Evtl. Unklare Details: Sollen Referenzen zu den Lösungen hier eingefügt werden? Oder zu Globase?
Roter Faden: Gute Lösung verschiebt den Fokus von den QoS Mechanismen zu der Frage: Wie kommen wir an die Informationen, die notwendig sind um gute QoS Entscheidungen zu treffen. Diese Folie soll das Thema Emergency Call Handling und HiPNOS / Overlay Bandwidth Management abschließen und zum zweiten Teil des Talks überleiten. Evtl. Unklare Details:
Roter Faden: Zeigen dass jetzige P2P Applications schon jeweils für sich Informationen zur Effizienzsteigerung einsammeln -> Lässt sich durch eine deddizierte Schicht besser erledigen. Evtl. Unklare Details:
Roter Faden: Zeigen dass jetzige P2P Applications schon jeweils für sich Informationen zur Effizienzsteigerung einsammeln -> Lässt sich durch eine deddizierte Schicht besser erledigen. Evtl. Unklare Details:
Roter Faden: Effizienz Management Lifecycle: Info einsammlen, aufbereiten/auswerten, Wissen wieder in das System (in Form von besseren Entscheidungen) einfließen lassen Evtl. Unklare Details:
Roter Faden: Nun Übergang zu unserer Lösung: Eine zusätzliche Schicht auf strukturierte P2P Overlays (die durch die Common API einheitlich angesprochen werden können). Die Query Form die unsere Architektur bietet, wird vorgestellt Evtl. Unklare Details: Common API, Paper von “F. Dabek and B. Zhao and P. Druschel and I. Stoica“ zum Vereinheitlichen der Services von DHTs, wichtig hier: Route(ID, Msg) – mittels der eine Nachricht (Msg) zu einem Peer geroutet werden kann der für eine ID (ID) zuständig ist.
Roter Faden: Nun Übergang zu unserer Lösung: Eine zusätzliche Schicht auf strukturierte P2P Overlays (die durch die Common API einheitlich angesprochen werden können). Die Query Form die unsere Architektur bietet, wird vorgestellt Evtl. Unklare Details: Common API, Paper von “F. Dabek and B. Zhao and P. Druschel and I. Stoica“ zum Vereinheitlichen der Services von DHTs, wichtig hier: Route(ID, Msg) – mittels der eine Nachricht (Msg) zu einem Peer geroutet werden kann der für eine ID (ID) zuständig ist.
Roter Faden: Nun Übergang zu unserer Lösung: Eine zusätzliche Schicht auf strukturierte P2P Overlays (die durch die Common API einheitlich angesprochen werden können). Die Query Form die unsere Architektur bietet, wird vorgestellt Evtl. Unklare Details: Common API, Paper von “F. Dabek and B. Zhao and P. Druschel and I. Stoica“ zum Vereinheitlichen der Services von DHTs, wichtig hier: Route(ID, Msg) – mittels der eine Nachricht (Msg) zu einem Peer geroutet werden kann der für eine ID (ID) zuständig ist.
Roter Faden: wo ist die EM Architektur (=Information Einsammel Service) einzuordnen: Über der common API (die über den Strukt. Overlays ist), Update-Flüsse: in einem virtuellen Baum hoch, Peers kennen ihre Vater-Knoten (woher: nächste Folie) Evtl. Unklare Details:
Roter Faden: Vater-Knoten ist der Peer zuständig für die mittlere ID in einer Domain (=ID Space Intervallabschnitt), Rekursive Domains Supporting peers zum Load Balancing (da sonst schwache Knoten an wichtigen Stellen sitzen könnten) Evtl. Unklare Details: Peer responsible for a specific ID (e.g. middle) is responsible for ID domain: Determinstische Zuweisfunktion, dadurch kann jeder Peer ermitteln, an welchen Peer er ein Update schicken muss (und zwar an den zuständigen für eine bestimmte ObjectID) Durch diese deterministische Funktion, spart man sich die Maintenance Kosten Storyline zur Animation: Zuerst sehen wir einen ID Space auf den die Overlay IDs abgebildet werden. Die Peers sind in diesem ID Space verteilt. Wir betrachten nun die Protokollschritte aus der Sicht eines einzelnen Peers (roter Pfeil), dieser bestimmt zuerst an wen er seine Updates schicken muss. Dazu halbiert er den ID Space jeweils soweit bis er seinen Coordinator identifiziert (die nächste Halbierung würde den Peer sich selbst als Coordinator zuweisen). An den Coordinator wird nun das Update geschickt. Auch der Coordinator hat einen Coordinator eine Ebene höher, an den die Updates weiter propagiert werden. Mit der Zeit baut sich der Baum von unten her auf und wächst zusammen. Die Coordinatoren können sich Supporting Peers zur Ünterstützung auswählen, diese werden anhand ihrer Kapazitäten ausgewählt.
Roter Faden: Soll zeigen dass Queries wirklich nützlich sind für eine komplexe Applikation, Query processing: bottom up, bis Anfrage voll beantwortet werden kann. Evtl. Unklare Details:
Roter Faden: Einige Qualitätsaspekte der Lösung und ein Bild zur Visualisierung des Baumes Evtl. Unklare Details:
Roter Faden: Anwendungsbeispiel, soll zeigen, dass ohne unsere Lösung die vielen Fragen schwer zu beantworten sind. Ein Effizienz Management System kann sie beantworten Evtl. Unklare Details: Text zu der Animation: Ein Objekt wird in der DHT gespeichert, der Peer fällt aus, Objekt ist weg -> Das ist unerwünscht, Replikation ist die Lösung um die Objekte im Netz zu halten. Abe es stellen sich Fragen (gerade bei vielen Objekten und Peers im Netz) …
Roter Faden: Visionäres Ende, keine Details mehr. Ausblick: Selbst-Analyze des P2P Systems, mit dem Ziel eines Selbst-Bewusstseins. Das System soll fehlende Ressourcen erkennen und sich mittels “Ressourcen-Handel” mit den Peers am Leben halten. Ein Service-Provider für die Peers. Evtl. Unklare Details: