Efficiency Management in Peer-to-Peer Systems First Research Talk, 2007-06-18
Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency?  </li></ul></ul><ul><ul><l...
Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency?  </li></ul></ul><ul><ul><l...
QuaP2P - Efficiency in P2P <ul><li>Research group QuaP2P </li></ul><ul><ul><li>My part: Efficiency </li></ul></ul><ul><ul>...
My First Approach for Efficiency Gain <ul><li>How to get better quality / less costs? </li></ul><ul><ul><li>Identify probl...
Scheduling and Active Queue Management  <ul><li>Learn from network layer </li></ul><ul><ul><li>Scheduling </li></ul></ul><...
Example: Emergency Call Handling (ECH) over P2P <ul><li>ECH is not supported in VoIP (  ) </li></ul><ul><ul><li>2009: mand...
Solution: Overlay Bandwidth Management <ul><li>Extending PeerfactSim.KOM </li></ul><ul><ul><li>Simple message-based  bandw...
Evaluation Results of Simple Solution <ul><li>HiPNOS.KOM: Highest Priority First, No Starvation [6] </li></ul><ul><ul><li>...
Efficiency Management System <ul><li>“ If each peer  knows  which QoS policy to follow,  </li></ul><ul><li>it is easy to a...
Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency?  </li></ul></ul><ul><ul><l...
P2P Efficiency Management System Focus Efficiency Management Architecture Analysis, Modeling and Interpretation Using EMS ...
External Interest Groups: OSP, ISP <ul><li>– P2P based Internet TV </li></ul><ul><li>Characteristics </li></ul><ul><ul><li...
Internal Interest Group: Replication Layer <ul><li>Content storage in P2P systems </li></ul><ul><ul><li>Churn is a problem...
EMS Architecture: Requirements <ul><li>Manages peer information </li></ul><ul><ul><li>Gathers, aggregates and provides inf...
EMS Architecture: Challenges <ul><li>EMS built on top of overlay </li></ul><ul><ul><li>Topology of EMS Architecture </li><...
<ul><li>Goal: Determine the state of the network </li></ul><ul><li>Need to know: </li></ul><ul><ul><li>Parameters of the P...
EMS Modeling: Challenges <ul><li>General  analysis and interpretation of measurements </li></ul><ul><li>Query driven model...
EMS Information Usage: Requirements <ul><li>Information accessible by </li></ul><ul><ul><li>Each layer in the system </li>...
EMS Information Usage: Challenges  <ul><li>Identify control layers: </li></ul><ul><ul><li>Which information is necessary o...
Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency?  </li></ul></ul><ul><ul><l...
<ul><li>EMS Usage: </li></ul><ul><li>A lot for each layer </li></ul><ul><li>EMS Architecture: </li></ul><ul><li>SOMO: Tree...
Future Work <ul><li>Investigate in all three directions </li></ul><ul><ul><li>Focus  on modeling and architecture </li></u...
Summary: P2P with EMS and Self-X <ul><li>Until now:  </li></ul><ul><ul><li>Static (local) optimization criteria  </li></ul...
Thank You for Your Attention. Questions?
Publications
Publications: accepted <ul><li>[1] Kalman Graffi, Aleksandra Kovacevic, Patrick Mukherjee, Michael Benz, Christof Leng, Di...
Publications: under review <ul><li>[4] Kalman Graffi ,  Parag Mogre, Matthias Hollick, and Ralf Steinmetz.  Detection of C...
Publications: Invention Reports <ul><li>K. Graffi, P. Mogre, M. Hollick, C. Schwingenschlögl.  “Name not public yet”,  Inv...
Publications: Not first author <ul><li>[7] Parag Mogre, Kalman Graffi, Matthias Hollick, and Ralf Steinmetz.  AntSec, Watc...
Other Slides
More Related Work Efficiency Management Architecture Analysis, Modeling and Interpretation Using EMS to Gain Efficiency Va...
Cooperation Partners using the EMS <ul><li>Several interested cooperation partners </li></ul><ul><li>- Dependability </li>...
Current Work <ul><li>Taxonomy on related work and deriving new solutions </li></ul><ul><li>Possible architectures for an E...
Upcoming SlideShare
Loading in...5
×

Efficiency Management in P2P Systems - 2007

179

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
179
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Hallo, ich heiße euch zu meinem ersten F-Vortrag mit dem Titel Efficiency Management in Peer-to-Peer Systems willkommen.
  • Zunächst möchte ich einen Überblick geben über die Themen die ich besprechen möchte. Ich beginne mit einer Einleitung zu Effizienz in P2P Systemen und wie die klassische Herangehensweise zur Effizienzsteigerung aussieht. Ich werde in diesem Abschnitt auch präsentieren, welche Tücken der klassische Ansatz hat. Daraus leite ich die Motivation für ein Efficiency Management System ab und beschreibe seine Komponenten und Anwendungsgebiete. Im nächsten Schritt will ich auf die einzelnen Komponenten näher eingehen und die wissenschaftlichen Herausforderungen und verwandten Arbeiten beschreiben. Ich schließe dann mit einem Ausblick über meine aktuelle und zukünftige Arbeit, sowie einer Zusammenfassung und der Liste der Publikationen.
  • Beginnen wir also mit dem Klassischen Ansatz zur Effizienzsteigerung. Zunächst kläre ich die Fragen, was ist Effizienz und im welchem Kontext steht meine Arbeit. Dann gehe ich auf den klassischen Ansatz zur Effizienzsteigerung ein, die auf Scheduling von Ressourcen im System setzt und zeigen an dem Beispiel von Emergency Calls in P2P Netzen, welche Probleme der Ansatz birgt.
  • Der Kontext meiner Arbeit ist definiert durch die QuaP2P Forschergruppe, die als Ziel hat Qualitätsaspekte in P2P Systemen allgemein zu untersuchen. Mein Bereich ist dabei die Effizienz, die den Tradeoff zwischen Leistung und dazu nötigen Kosten beschreibt. Wichtig ist dabei, die wechselseitigen Beziehungen zu den anderen Qualitätsaspekten zu berücksichtigen. Bei der Effizienzbetrachtung in P2P Systemen habe ich dabei 3 Gebiete, in denen eine Effizienzsteigerung möglich ist. Zum einen kann die Ressourcennutzung innerhalb der Peers optimiert werden, zum anderen ist das Overlay in die Betrachtung zu integrieren. Die Peers bieten unterschiedliche Dienste und Ressourcen an, so dass eine effiziente Ressourcenallokation dort auch notwendig ist. Schließlich wird die Sicht noch auch die Internet Service Provider erweitern und deren Einfluss auf P2P Systeme bzw. ungekehrt. Die Ziele meiner Arbeit sind dabei zum einen die Kosten für bestehende Dienste zu senken unter Beibehaltung der Funktionalität, aber auch neue Dienste/Services einzuführen, die keine Zusatzkosten erzeugen. Wichtig ist bei der Analyse der Systems und der Entwicklung von Lösungen, dass diese möglichst allgemein, sprich overlay- und applikationsunabhängig sein sollen.
  • Betrachten wir nun den klassischen Ansatz zu Effizienzsteigerung. Diese sieht vor, dass man zunächst Optimierungskriterien bestimmt, hinsichtlich derer das System verbessert werden soll. Dann bestimmt man die Ressourcen-Bottlenecks im System, die die Leistung von Dienstgüte behindern könnten. Weiter sind Einschränkungen an eine Lösung zu identifizieren und im Designprozess zu berücksichtigen. Schließlich entwickelt man eine faire Allokationsstrategie für die Bottleneck-Ressourcen, so dass die zuvor definierte Dienstgüte erfüllt werden kann. Scheduling von knappen Ressourcen ist der gängige Ansatz zur Effizienzsteigerung, so dass ich mich in die Materie stärker vertieft habe um einen guten Überblick über die möglichen Verfahren zu bekommen.
  • Betrachten wir also Scheduling und Active Queue Management Verfahren. Was Active Queue Management ist, werde ich gleich beschreiben. Allgemein geht es darum, dass das System Anfragen an eine Ressource erhält und entscheiden muss, welchem Anfrager wann die Ressource zur Verfügung gestellt wird. Dieses Prinzip ist auf verschiedene Ressourcen anwendbar, wie z.B. Rechenkraft, Bandbreite oder Speicherzugriffe. Wir gehen davon aus, dass die Anfragen in einer Queue zwischengespeichert werden, währen die Ressource in Benutzung ist. Scheduling nennt man nun das Verfahren, dass bestimmt, welches der Anfrager aus der Queue als nächstes Zugriff auf die Ressource erhält, sie bestimmt also die Reihenfolge der Anfrager in der Queue. Die Referenzlösung dafür ist First-In-First-Out. Nun kann es vorkommen, dass die Queue des Systems an ihre Grenzen stößt, da auch sie nur endliche Länge hat. Für diesen Fall gibt es Verfahren, die man unter dem Sammelbegriff Active Queue Management zusammenfasst. Sie entscheiden welche Anfragen aus der Queue entfernt werden, wenn eine Überlast vorliegt. Typisches Beispiel für ein Active Queue Management Verfahren ist Drop Tail, dass alle neu ankommenden Verfahren bei Überlast verwirft. Wir sehen, dass die Scheduling und Active Queue Management Verfahren allgemein für die Ressourcennutzung anwendbar sind. Um nun aber tiefer in die Materie einzusteigen und zu erfahren welche Verfahren es gibt und wo ihre Vor- und Nachteile liegen, habe ich mich mit verschiedenen Lösungen auseinander gesetzt.
  • Betrachten wir nun also ein Beispiel: Emergency Call Handling in P2P. Behalten wir im Hinterkopf, dass Fokus ist, eine Effizienzsteigerung im P2P System mittels klassischem Ansatz zu erreichen. Emergency Call Handling in P2P Systemen wird motiviert durch 2 Punkte. Zum einen sind VoIP Anwendungen im kommen, denn mindestens seit Skype gibt es einen Trend zum Umstieg auf VoIP. Ein Problem dass die VoIP Betreiber (wie auch Skype) dabei haben ist, dass sie keine Notrufe unterstützen. Emergency Call Handling wird aber ab 2009 verpflichtend in Europa, so dass VoIP Anbieter nachrüsten müssen. Der zweite Punkte ist, dass durch das All-IP Paradigma P2P Ansätze als Lösungen angewendet werden könnten. Ja, vielmehr sie durch ihre Skalierbarkeit sich unter anderem auch für Katastrophen Scenarien anbieten. Betrachten wir also die Anforderungen an eine Lösung. Zum einen ist ein Notruf ein Lokations-kritischer Service. Ein Anrufer möchte entweder die zu ihm nächstgelegene Polizeistation finden, oder die Station, die für ihn zuständig ist. KOMs P2P Simulator, PeerfactSim.KOM bietet ja schon Lösungen dafür an. Wichtiger (aus meinem Standpunkt aus gesehen) sind aber die QoS Anforderungen an die Übermittlung von Emergency Calls. Diese sollen so schnell wie möglich, d.h. mit minimalem Delay, und ohne Verlust, also ohne Loss, übertragen werden. Die QoS Anforderungen sind also eindeutig. Minimales Delay, kein Loss für Emergency Call Nachrichten. Der Effizienzgewinn besteht darin, diese neue Funktionalität für das System zu ermöglichen, ohne aber dafür zusätzliche Kosten zu erzeugen. Wie wir diese Anforderungen in PeerfactSim.KOM umgesetzt haben, sehen wir auf den nächsten 2 Folien.
  • Zunächste wurde die Bandbreite als Bottleneck identifiziert und ein Bandbreiten Management implementiert. Zu erwähnen ist, dass wir zwischen 2 Typen von Traffic d.h. Bandbreitennutzung unterscheiden. Zum einen die für Overlayoperationen, wie die Maitenance Nachrichten, aber auch Nutzeranfragen und Antworten. In diese Kategorie fallen die Emergency Call Anfragen. Die zweite Kategorie sind die Applikationsdatenströme, die direkt von einem Peer zum anderen übertragen werden. Wie zum Beispiel, Dateitransfers oder VoIP Telefonate. Diese sind nicht ins unserem Focus, wir konzentrieren uns auf einen schnellen Gesprächsaufbau, d.h. der Indentifikation mit wem man eigentlich sprechen möchte. Das Bandbreiten-Management wurde direkt unter das Overlay über dem Transport Layer implementiert. Es fängt dort Nachrichten nach unten ab, packt sie in eine Queue und entscheidet mittels verschiedener Scheduling Verfahren welche Nachricht bei freier Bandbreite zu übertragen ist, bzw. welche Nachrichten bei Überlast zu verwerfen sind. Um nun zu entscheiden welche Scheduling und Active Queue Management Verfahren anwendbar sind, haben wir die Kontakte der Peers uns näher angeschaut. Wir haben also Kademlia mit 10.000 Peers simuliert und interessantes festgestellt. Hier auf der Grafik links ist auf der X-Achse, die Anzahl der Kontakte pro Peer aufgetragen und auf der Y-Achse finden wir die durchschnittliche Anzahl an Nachrichten pro Kontakt. Das Fazit: Es exisiteren keine Flows. Bzw. ein „Flow“ besteht aus max. 2 Nachrichten, und von einem einzelnen Peer gehen extrem viele Flows aus. Wir können also keine zustandsbehafteten Scheduler verwenden, sondern müssen uns auf zustandlose beschränken, bei denen die Nachrichten selbst ihre QoS Informationen transportieren.
  • Dazu haben wir eine einfache Lösung entwickelt, die Nachrichten Prioritäten verwendet. Die Nachrichten haben individuelle Delay und Loss Prioritäten. HiPNOS.KOM beschreibt einen einfachen Scheduler und Active Queue Management, Nachrichten mit der höchsten Delay Priorität in der Queue werden zuerst durchgestellt, und Nachrichten mit der niedrigsten Loss Priorität werden zuerst verworfen bei Überlast. Das ganzen haben wir dann wieder in Kademlia mit 10.000 Peers und mit FIFO und Drop Tail als Referenzverfahren getestet. Hier sind die Ergebnisse. Wir sehen in der linken Grafik, das Delay der Nachrichten im Verhältnis zu ihrer Delay Priorität und rechts die Anzahl verworfener Nachrichten in Relation zu ihrer Loss Priorität. Ein hoher Prioritätswert bedeutet dabei hohe Priorität. Wir sehen, dass die Ergebnisse den Erwartungen entsprechen. Delay sinkt mit steigender Priorität, ebenso die Anzahl der verworfenen Pakete. Es stellt sich die Frage: Alles wunderbar? Was gibt es noch zu verbessern, bzw. viel wichtiger: was lernen wir daraus.
  • Betrachten wir nochmal den aktuellen Stand von P2P Systemen. Die Peers sind selbst organisiert, autonom, haben aber nur eine lokale Sicht, auf der sie ihre Entscheidungen basieren (wenn überhaupt). Die Qualität ihrer Optimierungsentscheidungen hängt stark von dem Szenario ab, für das sie ausgewählt wurden. Das Ziel ist aber eine Selbst-Organisation des Overlays. Dazu ist eine Globale Sicht durch ein Efficiency Management System notwendig. Es sammelt Daten über die Peers, das Overlay und allgemein über die Services und errechnet daraus eine Sicht, die von den einzelnen Layern genutzt werden kann um Effizienz-Entscheidungen fundiert treffen zu können. Fokus ist also ein Sammeln, Interpretieren und Anbieten von Informationen über das P2P System. Ein weiterer Punkt ist die Selbst-Organisation des P2P Systems. Wenn die Information über das System schon vorhanden ist, so kann man sie nutzen um zu berechnen in welchem Zustand sich das System befindet und wohin es sich entwicklen wird, so dass geeignete Maßnahmen getroffen werden können um das System in einen erwünschten Zustand zu überführen. Das System soll sich also selbst steuern und somit unterschiedliche Self-X Ansätze realisieren. (Wasser trinken)
  • In diesem Abschnitt betrachten wir die einzelnen Komponenten eines Efficiency Managment Systems. Ferner werfen wir noch einen Blick auf potenzielle Interessensgruppen für so ein System und definieren die Anforderungen an die System Komponenten.
  • Das Efficiency Management System besteht aus drei großen Komponenten. Zuallererst benötigt man eine Architektur, die die Informationen von den Peers einsammelt, dieser verarbeiten kann und wieder zur Verfügung stellt. Dieses Management Overlay wird aus Peers aus dem normalen Overlay gebildet. Ferner benötigen wir noch Modelle um die gemessenen Parameter mit einander in Verbindung zu bringen und Antworten für die verschiedenen Interessensgruppen liefern zu können. Das Ziel ist die Beschreibung der aktuellen Lage des Netzwerks, aber auch eine Voraussage, wohin sich das Netzwerk entwickeln wird. Das Modell soll Antworten liefern welche Schritte für einen optimalen Zustand notwendig sind. Und schließlich benötigt man eine Komponente, die beschreibt WIE die Informationen auf den verschiedenen Layern verwendet werden können um eine Effizienzsteigerung zu erwirken. Dabei ist die größte Herausforderung zu bestimmen, welche Fragen von dem System beantwortet werden sollen. Um nun die möglichen Fragen zu identifizieren und das Thema weiter zu motivieren, betrachten wir auf den folgenden 3 Folien einige Interessensgruppen an einem EMS.
  • 17.Joost: - wie ist die Service Capacity der Peers (= max. Upload), Wie ist die Nachfrage nach den einzelnen Peers, =&gt; wieviele Backup Server brauchen wir.
  • 13. Architektur - Aufgaben: - Overlay Management Overlay - Ressourceninformationen zusammensammeln - Aggregieren - dynamische OvMgmOvgröße - Fähigkeit Auswertungen/Interpretationen vorzunehmen
  • 19. Details to the idea / scientifical challanges - Architecture: - It is a supernode architecture (as a subset of the peers is managing the others) - Which structure does fit best, does best support the aggregation of res. information? - overlay independence
  • 14. Analysis/Auswertung - Erfassen der relevanten Parameter eines P2P Netzwerks - Erstellen von Overlay unabhängigen Aussagen - Overlay spezifische Aussagen-Plugins - Dynamische, on-time Auswertung
  • 21. Analysis - overlay independence - general approach =&gt; tending to specific results - Define states of the network, - Determine in which case to do what - what is the optimization goal in which network state? 22. Currently done by me: - scanning papers with strong analytical part, - identifying which are relevant parameters - what can be calculated
  • 15. Verwendung: - Erfordert ein Interface auf allen Ebenen des P2P Netzwerks - Jedes Layer soll in der Lage sein die Informationen nutzen zu können - Ermöglicht auf einfache Art eine effizientere Nutzung der vorhandenen Ressourcen - Eff.increase nur noch Pillepalle: Determine deficiencies of the system, lookup Opt.Crits., Choose best peer/ressource based on global knowledge
  • 24. Usage of information: - Common approach to increase efficiency - a lot exists - Efficient Matching can be done...
  • 20. Related Work: Several approaches exist: - SOMO - T-MAN - Quorum? =&gt; Limitations, what is missing
  • 26. Future work: - investigate in all three directions - in order to see where is most interesting challenges - learn the interdependencies and consider them in the evaluation
  • 28. Conclusion: - Present Architecture again, - point out the main scientific challanges
  • Kalman Graffi, Aleksandra Kovacevic, Patrick Mukherjee, Michael Benz, Christof Leng, Dirk Bradler, Julian Schröder-Bernhardi, and Nicolas Liebau. Peer-to-Peer-Forschung - Ueberblick und Herausforderungen, it-Special Issue on Peer-to-Peer, submitted on March 31, 2007 -&gt; accepted
  • Content Distribution: Per File: Emule, Amule
  • 27. Current Work: - Analytical Modelling of P2P =&gt; Get an overview - Possible architectures for an Overlay Management Overlay - How to monitor and store information on resource/service usage - and how to optimally match them
  • Transcript of "Efficiency Management in P2P Systems - 2007"

    1. 1. Efficiency Management in Peer-to-Peer Systems First Research Talk, 2007-06-18
    2. 2. Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency? </li></ul></ul><ul><ul><li>One example: Emergency Call Handling in P2P </li></ul></ul><ul><ul><li>Lessons learned </li></ul></ul><ul><li>Efficiency Management System </li></ul><ul><ul><li>Vision and components </li></ul></ul><ul><ul><li>Use Cases defined by interest groups </li></ul></ul><ul><ul><li>Requirements and challenges on the system </li></ul></ul><ul><li>Future work and summary </li></ul>
    3. 3. Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency? </li></ul></ul><ul><ul><li>One example: Emergency Call Handling in P2P </li></ul></ul><ul><ul><li>Lessons learned </li></ul></ul><ul><li>Efficiency Management System </li></ul><ul><ul><li>Vision and components </li></ul></ul><ul><ul><li>Use Cases defined by interest groups </li></ul></ul><ul><ul><li>Requirements and challenges on the system </li></ul></ul><ul><li>Future work and summary </li></ul>
    4. 4. QuaP2P - Efficiency in P2P <ul><li>Research group QuaP2P </li></ul><ul><ul><li>My part: Efficiency </li></ul></ul><ul><ul><li>Ratio between performance and costs </li></ul></ul><ul><li>3 areas of efficiency increase </li></ul><ul><li>Optimize the resource usage </li></ul><ul><ul><li>Decrease costs </li></ul></ul><ul><ul><li>Increase quality </li></ul></ul><ul><li>Goal to find general solutions </li></ul><ul><ul><li>i.e. overlay independent </li></ul></ul>Devices IP Infrastructure 3 $ $ P2P Overlay 2 ^ Peer IN OUT 10100110110001000110 1
    5. 5. My First Approach for Efficiency Gain <ul><li>How to get better quality / less costs? </li></ul><ul><ul><li>Identify problem statement </li></ul></ul><ul><ul><li>Define optimization criteria </li></ul></ul><ul><ul><li>Determine available resource bottlenecks </li></ul></ul><ul><ul><li>Identify constraints for a solution </li></ul></ul><ul><ul><li>Find allocation strategy for bottleneck resources </li></ul></ul><ul><li>-> Schedule resource usage in each peer individually </li></ul>
    6. 6. Scheduling and Active Queue Management <ul><li>Learn from network layer </li></ul><ul><ul><li>Scheduling </li></ul></ul><ul><ul><ul><li>Reorder tasks/messages in queue </li></ul></ul></ul><ul><ul><ul><li>Reference: First-in-First-Out </li></ul></ul></ul><ul><ul><li>Active Queue Management </li></ul></ul><ul><ul><ul><li>Active upon congestion of queue </li></ul></ul></ul><ul><ul><ul><li>Reference: Drop Tail </li></ul></ul></ul><ul><li>Mechanisms can be applied to various resources </li></ul>Resource Sched.+AQM 1. Message Scheduling Before: After: 2. Queue Management Before: After: Queue Limit
    7. 7. Example: Emergency Call Handling (ECH) over P2P <ul><li>ECH is not supported in VoIP ( ) </li></ul><ul><ul><li>2009: mandatory for VoIP providers </li></ul></ul><ul><ul><li>P2P: all-IP, scalable </li></ul></ul><ul><ul><li>Relevant for QuaP2P Catastrophe Scenario </li></ul></ul><ul><li>Requirements </li></ul><ul><ul><li>Location critical service </li></ul></ul><ul><ul><li>Time Critical Service , </li></ul></ul><ul><ul><ul><li>contact ES as soon as possible </li></ul></ul></ul><ul><ul><ul><li>without message loss </li></ul></ul></ul><ul><li>QoS for P2P messages needed </li></ul><ul><ul><li>QoS policy: low delay, low loss </li></ul></ul><ul><ul><li>New function, same costs </li></ul></ul><ul><ul><li>-> Increase the efficiency </li></ul></ul>Alabama Emergency Zones Alabama Density Population Snapshot of the simulated scenarios Source: US census Source: NENA
    8. 8. Solution: Overlay Bandwidth Management <ul><li>Extending PeerfactSim.KOM </li></ul><ul><ul><li>Simple message-based bandwidth management </li></ul></ul><ul><li>Two types of traffic </li></ul><ul><ul><li>Application traffic (direct P2P) </li></ul></ul><ul><ul><li>Overlay traffic ( ← focus) </li></ul></ul><ul><li>Simulating Kademlia, 10k peers </li></ul><ul><ul><li>To estimate shape of flows </li></ul></ul><ul><ul><li>Huge number of contacts with few messages each </li></ul></ul><ul><ul><li>Overlay flows do not exist </li></ul></ul><ul><li>Conclusion </li></ul><ul><ul><li>No flows -> message prio. & </li></ul></ul><ul><ul><li>stateless scheduler needed </li></ul></ul>
    9. 9. Evaluation Results of Simple Solution <ul><li>HiPNOS.KOM: Highest Priority First, No Starvation [6] </li></ul><ul><ul><li>Introduce message priorities (for loss and delay) </li></ul></ul><ul><ul><li>Reference solution: FIFO and Drop-Tail </li></ul></ul><ul><ul><li>Simulation: Kademlia, 10000 peers, lookup/store op. </li></ul></ul><ul><li>Results: </li></ul><ul><ul><li>QoS increases with priority -> easy solution works </li></ul></ul><ul><ul><li>Based on which information to choose priorities? </li></ul></ul>
    10. 10. Efficiency Management System <ul><li>“ If each peer knows which QoS policy to follow, </li></ul><ul><li>it is easy to apply (simple) solutions” </li></ul><ul><li>Efficiency Management (EM) System </li></ul><ul><ul><li>Approximate global view </li></ul></ul><ul><ul><li>Use global view on peers/overlay/services </li></ul></ul><ul><ul><ul><li>to define individual optimality criteria </li></ul></ul></ul><ul><ul><ul><li>to decide on QoS policy, which is best for the system </li></ul></ul></ul><ul><ul><li>Self-organization of the P2P system </li></ul></ul><ul><ul><ul><li>Identify current state and predict future state </li></ul></ul></ul><ul><ul><ul><li>Decide on next steps to reach target state. </li></ul></ul></ul><ul><li>Focus on information gathering, interpreting and providing </li></ul><ul><li> and self-X of the P2P system </li></ul>
    11. 11. Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency? </li></ul></ul><ul><ul><li>One example: Emergency Call Handling in P2P </li></ul></ul><ul><ul><li>Lessons learned </li></ul></ul><ul><li>Efficiency Management System </li></ul><ul><ul><li>Vision and components </li></ul></ul><ul><ul><li>Use Cases defined by interest groups </li></ul></ul><ul><ul><li>Requirements and challenges on the system </li></ul></ul><ul><li>Future work and summary </li></ul>
    12. 12. P2P Efficiency Management System Focus Efficiency Management Architecture Analysis, Modeling and Interpretation Using EMS to Gain Efficiency Peers α β λ μ Parameters f( α , β )=…= x g( λ , μ )=…=y h( α , λ )=…=z Models Interpreted state Architecture Choose priorities
    13. 13. External Interest Groups: OSP, ISP <ul><li>– P2P based Internet TV </li></ul><ul><li>Characteristics </li></ul><ul><ul><li>P2P Streaming </li></ul></ul><ul><ul><li>High demand for availability and bandwidth </li></ul></ul><ul><li>Backup servers needed, if quality is bad </li></ul><ul><ul><li>Which channels/files to provide? </li></ul></ul><ul><ul><li>How many? For what? Where? </li></ul></ul><ul><li>ISPs: P2P traffic is expensive </li></ul><ul><ul><li>(Web-)Cache top k files creating most of the traffic? </li></ul></ul><ul><ul><li>Monitoring P2P traffic </li></ul></ul>ISP A ISP B
    14. 14. Internal Interest Group: Replication Layer <ul><li>Content storage in P2P systems </li></ul><ul><ul><li>Churn is a problem </li></ul></ul><ul><ul><li>Data may get lost </li></ul></ul><ul><ul><li>-> Replication is a solution </li></ul></ul><ul><li>Challenges </li></ul><ul><ul><li>Which files to replicate? </li></ul></ul><ul><ul><ul><li>Most requested, rarest? </li></ul></ul></ul><ul><ul><li>On which peers? </li></ul></ul><ul><ul><ul><li>Most reliable? Highest bandwidth? </li></ul></ul></ul><ul><ul><li>How many replicas? </li></ul></ul><ul><ul><ul><li>Depends on requirements on availability </li></ul></ul></ul><ul><ul><li>By which peers? </li></ul></ul><ul><li>-> Efficiency Management System provides answers </li></ul>
    15. 15. EMS Architecture: Requirements <ul><li>Manages peer information </li></ul><ul><ul><li>Gathers, aggregates and provides information </li></ul></ul><ul><ul><li>Approximates global view </li></ul></ul><ul><li>Overlay-independent architecture </li></ul><ul><ul><li>Created from subset of the peers </li></ul></ul><ul><li>Able to perform calculations </li></ul><ul><ul><li>Analysis and interpretations </li></ul></ul><ul><li>Provides a query interface </li></ul><ul><ul><li>For all interested parties </li></ul></ul>Black box for EM architecture ------------ ------------ Local para-meters ------------ Arch. Model Using EMS
    16. 16. EMS Architecture: Challenges <ul><li>EMS built on top of overlay </li></ul><ul><ul><li>Topology of EMS Architecture </li></ul></ul><ul><ul><ul><li>Support for information aggregation </li></ul></ul></ul><ul><ul><ul><li>Overlay-independent solution </li></ul></ul></ul><ul><ul><ul><li>High level and detailed view supported </li></ul></ul></ul><ul><ul><li>Which peers to choose? </li></ul></ul><ul><ul><ul><li>Maintain robustness, load-balancing, scalability </li></ul></ul></ul><ul><ul><li>Define management peer responsibilities </li></ul></ul><ul><ul><ul><li>Static, dynamic or random? </li></ul></ul></ul><ul><ul><li>Updates and queries: reactive / proactive? </li></ul></ul><ul><ul><ul><li>Consider EMS usage, scenario </li></ul></ul></ul><ul><ul><ul><li>Adopt EMS in order to keep costs low </li></ul></ul></ul>Arch. Model Using EMS
    17. 17. <ul><li>Goal: Determine the state of the network </li></ul><ul><li>Need to know: </li></ul><ul><ul><li>Parameters of the P2P system </li></ul></ul><ul><ul><ul><li>I.e. peer/overlay/service characteristics </li></ul></ul></ul><ul><ul><li>Models of the system using basic parameters </li></ul></ul><ul><ul><li>Interests of querying parties </li></ul></ul><ul><li>Dynamical on-time evaluation of the system </li></ul><ul><ul><li>Information platform </li></ul></ul><ul><ul><li>Feedback mechanism </li></ul></ul>EMS Modeling: Requirements α β λ μ α β λ μ f(α, β)=…= x g(λ, μ)=…=y h(α, λ)=…=z x y z Arch. Model Using EMS
    18. 18. EMS Modeling: Challenges <ul><li>General analysis and interpretation of measurements </li></ul><ul><li>Query driven modeling: </li></ul><ul><ul><li>Identify interest groups and their requirements </li></ul></ul><ul><ul><li>Defining set of parameters available in the system </li></ul></ul><ul><ul><li>Create models to provide answers (distributed) </li></ul></ul><ul><li>Self-X driven modeling </li></ul><ul><ul><li>General model of the services and peers </li></ul></ul><ul><ul><li>Define states of the network </li></ul></ul><ul><ul><li>Determine current state and predict future state </li></ul></ul><ul><ul><li>Define policy to reach target state </li></ul></ul>Arch. Model Using EMS
    19. 19. EMS Information Usage: Requirements <ul><li>Information accessible by </li></ul><ul><ul><li>Each layer in the system </li></ul></ul><ul><ul><li>The Overlay Service Provider OSP </li></ul></ul><ul><ul><li>The Internet Service Provider ISP </li></ul></ul><ul><li>Information usage </li></ul><ul><ul><li>Determine priority of tasks </li></ul></ul><ul><ul><li>Easy to adopt QoS mechanisms </li></ul></ul><ul><ul><li>Optimize resource usage </li></ul></ul><ul><li>Efficiency gain </li></ul><ul><ul><li>Has to be higher than EMS costs </li></ul></ul><ul><ul><li>Compare to optimal solution in PeerfactSim.KOM </li></ul></ul>Arch. Model Using EMS
    20. 20. EMS Information Usage: Challenges <ul><li>Identify control layers: </li></ul><ul><ul><li>Which information is necessary on which layer? </li></ul></ul><ul><ul><ul><li>Resource allocation (in overlay) </li></ul></ul></ul><ul><ul><ul><li>Message priorization (in peers) … </li></ul></ul></ul><ul><ul><li>Which mechanisms can be applied? </li></ul></ul><ul><ul><ul><li>Simple if QoS policy clear </li></ul></ul></ul><ul><ul><li>Identify queries, which answers are needed </li></ul></ul><ul><ul><li>Usage is not main focus: </li></ul></ul><ul><ul><ul><li>Enough research in each application area </li></ul></ul></ul>Arch. Model Using EMS
    21. 21. Outline <ul><li>First approach to increase efficiency </li></ul><ul><ul><li>What is efficiency? </li></ul></ul><ul><ul><li>One example: Emergency Call Handling in P2P </li></ul></ul><ul><ul><li>Lessons learned </li></ul></ul><ul><li>Efficiency Management System </li></ul><ul><ul><li>Vision and components </li></ul></ul><ul><ul><li>Use Cases defined by interest groups </li></ul></ul><ul><ul><li>Requirements and challenges on the system </li></ul></ul><ul><li>Future work and summary </li></ul>
    22. 22. <ul><li>EMS Usage: </li></ul><ul><li>A lot for each layer </li></ul><ul><li>EMS Architecture: </li></ul><ul><li>SOMO: Tree-based information aggregation </li></ul><ul><li>T-MAN: Gossip-based information dissemination </li></ul><ul><li>Modeling: </li></ul><ul><li>Large number of papers with analytical evaluation </li></ul><ul><ul><li>Analysis is one of the general evaluation methods </li></ul></ul><ul><li>Only few on general P2P modeling </li></ul><ul><ul><li>Karl Aberer et al., 2005, The essence of P2P: A reference architecture for overlay networks </li></ul></ul>Related Work
    23. 23. Future Work <ul><li>Investigate in all three directions </li></ul><ul><ul><li>Focus on modeling and architecture </li></ul></ul><ul><ul><li>Next steps: </li></ul></ul><ul><ul><ul><li>General P2P Model </li></ul></ul></ul><ul><ul><ul><ul><li>Overlay-independent models </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Define system states </li></ul></ul></ul></ul><ul><ul><ul><li>Create EMS architecture </li></ul></ul></ul><ul><ul><ul><ul><li>Create design taxonomy and solution </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Implement in PeerfactSim.KOM </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Evaluate in comparison to global view </li></ul></ul></ul></ul><ul><ul><ul><li>Simple mechanisms using „global information“ </li></ul></ul></ul><ul><ul><ul><ul><li>Investigate costs and benefits </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Start with accounting and consumer/provider matching </li></ul></ul></ul></ul>Efficiency Management Architecture Analysis, Modeling and Interpretation Using EMS to Gain Efficiency
    24. 24. Summary: P2P with EMS and Self-X <ul><li>Until now: </li></ul><ul><ul><li>Static (local) optimization criteria </li></ul></ul><ul><ul><li>Self-X very philosophic </li></ul></ul><ul><li>Here: </li></ul><ul><ul><li>Vision to concretize: EMS </li></ul></ul><ul><li>Goal: Efficiency Management System </li></ul><ul><ul><li>Gathering and interpreting information about the system </li></ul></ul><ul><ul><li>Providing information to all layers in the system </li></ul></ul><ul><ul><li>Analyzing the state and deciding what to do </li></ul></ul><ul><ul><li>Shaping the system to reach target state </li></ul></ul><ul><li>Constraints: </li></ul><ul><ul><li>Dynamic system of autonomous peers </li></ul></ul><ul><ul><li>Solution planned to be general, overlay-independent </li></ul></ul><ul><li>Practical use for commercial applications </li></ul>Efficiency Management Architecture Analysis, Modeling and Interpretation Using EMS to Gain Efficiency
    25. 25. Thank You for Your Attention. Questions?
    26. 26. Publications
    27. 27. Publications: accepted <ul><li>[1] Kalman Graffi, Aleksandra Kovacevic, Patrick Mukherjee, Michael Benz, Christof Leng, Dirk Bradler, Julian Schröder-Bernhardi, and Nicolas Liebau. Peer-to-Peer-Forschung - Ueberblick und Herausforderungen, it-Special Issue on Peer-to-Peer, 2007 </li></ul><ul><li>[2] Kalman Graffi, Konstantin Pussep, Nicolas Liebau, and Ralf Steinmetz. Taxonomy of Active Queue Management Strategies in Context of Peer-to-Peer Scenarios , Technical Report, KOM-TR-2007-1, TU Darmstadt, submitted on December 1, 2006 </li></ul><ul><li>[3] Kalman Graffi, Nicolas Liebau, and Ralf Steinmetz. Taxonomy of Message Scheduling Strategies in Context of Peer-to-Peer Scenarios , Technical Report, KOM-TR-2007-2, TU Darmstadt, submitted on December 1, 2006 </li></ul>
    28. 28. Publications: under review <ul><li>[4] Kalman Graffi , Parag Mogre, Matthias Hollick, and Ralf Steinmetz. Detection of Colluding Misbehaving Nodes in Mobile Ad Hoc and Mesh Networks, GLOBECOM 2007, submitted on March 23, 2007 </li></ul><ul><li>[5] Kalman Graffi, Aleksandra Kovacevic, Nicolas Liebau, and Ralf Steinmetz. From Cells to Organisms: Long-Term Guarantees on Service Provisioning in Peer-to-Peer Networks , GLOBECOM 2007, submitted on March 23, 2007 </li></ul><ul><li>[6] Kalman Graffi , Sebastian Kaune, Konstantin Pussep, Aleksandra Kovacevic, Nicolas Liebau, and Ralf Steinmetz. Overlay Bandwidth Management: Scheduling and Active Queue Management of Overlay Flows, IEEE LCN 2007, submitted on April 17, 2007 </li></ul>
    29. 29. Publications: Invention Reports <ul><li>K. Graffi, P. Mogre, M. Hollick, C. Schwingenschlögl. “Name not public yet”, Invention Report in preparation , 2007 </li></ul><ul><li>P. Mogre, K. Graffi, M. Hollick, C. Schwingenschlögl. “Name not public yet”, Invention Report in preparation , 2007 </li></ul>
    30. 30. Publications: Not first author <ul><li>[7] Parag Mogre, Kalman Graffi, Matthias Hollick, and Ralf Steinmetz. AntSec, WatchAnt and AntRep: Innovative Security Mechanisms for Wireless Mesh Networks, IEEE LCN 2007, submitted on Apr.17, 2007 </li></ul><ul><li>[8] Aleksandra Kovacevic, Sebastian Kaune, Kalman Graffi, Nicolas Liebau, and Ralf Steinmetz. Towards Benchmarking of Peer-to-Peer Overlays, GLOBECOM 2007, submitted on March 23, 2007 </li></ul><ul><li>[9] Nicolas Liebau, Konstantin Pussep, Kalman Graffi, Sebastian Kaune, Eric Jahn, André Bayer, Ralf Steinmetz. The Impact Of The P2P Paradigm . AMCIS 2007 , August 2007 </li></ul>
    31. 31. Other Slides
    32. 32. More Related Work Efficiency Management Architecture Analysis, Modeling and Interpretation Using EMS to Gain Efficiency Various Strategies Chord,Pastry,Kademlia Bittorrent, Avalanche (SK) GIA, HiPNOS Using global view for eff. gain. Rare, as currentlly no global view (except server) Many simple architectures: SOMO, T-MAN, P2P-diet, Agenda, Res.Mgmt.Framew., SDIMS, CONE, PeerWindow, Willow, DASIS not discussing: which data, how to store data, A lot layer-specific: Evaluation of own solution Only few general: K.Aberer “the essence of P2P” Related Work on Efficiency Management System: Similar works: GRID resource management. Yalagandula DISS: A Scalable Information Management Middleware for Large Distributed Systems (other focus: Information retrieval and gathering, no further usage, no modeling)
    33. 33. Cooperation Partners using the EMS <ul><li>Several interested cooperation partners </li></ul><ul><li>- Dependability </li></ul><ul><ul><li>Replication management, storage based on </li></ul></ul><ul><ul><ul><li>Current state of network, peers and file </li></ul></ul></ul><ul><li>- Flexibility </li></ul><ul><ul><li>„Context“-measurement: create local view </li></ul></ul><ul><li>Content Distribution (Sebastian) </li></ul><ul><ul><li>Information about the peers needed </li></ul></ul><ul><li>Overlay Optimization (Sandra) </li></ul><ul><ul><li>How to choose super peers? </li></ul></ul>
    34. 34. Current Work <ul><li>Taxonomy on related work and deriving new solutions </li></ul><ul><li>Possible architectures for an EMS </li></ul><ul><ul><li>E.g.tree-based/unstructured, update/query strategies </li></ul></ul><ul><li>Analytical modeling of P2P systems </li></ul><ul><ul><li>Get overview, create “complete” model </li></ul></ul><ul><li>How to monitor and store information on resource usage </li></ul><ul><ul><li>In addition to static/dynamic peer/service descriptions </li></ul></ul><ul><li>Investigate matching strategies </li></ul><ul><ul><li>Optimal (?) service provider-consumer matching </li></ul></ul>

    ×