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.
34.
Notes de l'éditeur
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, => wieviele Backup Server brauchen wir.
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 => 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? => 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 -> accepted
Content Distribution: Per File: Emule, Amule
27. Current Work: - Analytical Modelling of P2P => 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
![Outline ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)