Peer-to-peer and mobile networks gained significant attention of both research community and industry. Applying the peer-to-peer paradigm in mobile networks lead to several problems regarding the bandwidth demand of peer-to-peer networks. Time-critical messages are delayed and delivered unacceptably slow. In addition to this, scarce bandwidth is wasted on messages of less priority. Therefore, the focus of this paper is on bandwidth management issues at the overlay layer and how they can be solved. We present HiPNOS.KOM, a priority based scheduling and active queue management system. It guarantees better QoS for higher prioritized messages in upper network layers of peer-to-peer systems. Evaluation using the peer-to-peer simulator PeerfactSim.KOM shows that HiPNOS.KOM brings significant improvement in Kademlia in comparison to FIFO and Drop-Tail, strategies that are used nowadays on each peer. User initiated lookups have in Kademlia 24% smaller operation duration when using HiPNOS.KOM.
IEEE LCN 2007: Kalman Graffi - Overlay Bandwidth Management: Scheduling and Active Queue Management of Overlay Flows
1. Overlay Bandwidth Management: Scheduling and Active Queue Management of Overlay Flows Kalman Graffi , Konstantin Pussep, Sebastian Kaune, Aleksandra Kovacevic, Nicolas Liebau, and Ralf Steinmetz
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15. 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
Editor's Notes
25 Minuten für alles, d.h. 20 Minuten Vortrag
Wir haben ein unstrukturiertes P2P Netz gegeben. Ein Rechner tätigt für sein Subnetz, das an ihm angeschlossen ist, mehrere Anfragen über eine Verbindung mit relative wenig Bandbreite. Kommt nun ein weiterer Nutzer hinzu, der diese Verbindung ebenfalls nutzen möchte, aber dessen Anfrage an das Netzwerk weitaus wichtiger ist, da es z.B. ein Notruf ist. So werden seine Messages zwar bis zum Engpass gut weitergeleitet, doch ohne gesonderte Strategie für den Umgang mit Engpässen werden die Messages nach ihrer Eingangsreihenfolge abgearbeitet. Dabei verzögern die vielen unwichtigen Anfragen des blauen Servers, die wichtige Anfrage von dem Nutzer. Bis die Nachricht vom Nutzer an der Reihe ist, ist wertvolle Zeit vergangen. Geschieht das in jedem Schritt, so ist die Qualität mit der die Anfrage bearbeitet wird, für viele Anwendungen nicht mehr ausreichend. Als Lösung bietet sich an, Scheduling Mechanismen einzusetzen, um wichtigere Nachrichten höher priorisiert zu bearbeiten. Dadurch erreicht man, dass zeitkritische Anwendungen ebenso zufriedenstellend bearbeitet werden wie Durchsatzfokusierte. In diesem Fall haben wir bei gleichem Aufwand, das heißt bei gleicher Anzahl an Nachrichten die pro Zeiteinheit bearbeitet werden, eine höherwertige Leistung erbracht. Durch Forschung über die Effizienz von Peer-to-Peer Systemen können wir zum einen die Leistung erhöhen und dadurch mehr Nutzer für P2P begeistern aber auch die Kosten senken und damit mehr Geräten die Teilnahme an P2P Netzen ermöglichen. Ich danke fürs zuhören und hoffe das spannende Thema der Effizienz etwas zugänglicher gemacht zu haben.
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.
Aiming to handle the highest priority of SOS messages, we considered to implement HiPNOS.KOM [GKP+07], In order to evaluate the buffer management and the handling of priorities, the efficiency metrics of he simulator were extended. For instance, the number of messages per contacts per peer to verify whether the amount of messages per source/destination combination in a traffic generated by a P2P overlay is low. Up and download bandwidth utilization Number of received messages with differing loss and latency priorities With this metric, the amount of prioritized messages a peer receives can be determined. Number of dropped messages with differing loss priority Depending on the queue managing mechanism, messages are dropped when the buffer is full. With this metric, the amount of discarded messages with several priority levels is determined. For example, the figure shows how HiPNOS handles correctly the message priorities in contrast to FIFO.
Fair Queuing: Jeder Stream verschickt 1 Bit, nacheinander sind alle Streams dran Weighted Fair Queuing WFQ / Packet-by-Packet General Processor Sharing: Packet basiertes FQ: Stream mit niedrigstem Service wird bedient + Paketgröße auf empfangenen Service addiert Round Robin: Jeder Stream kommt mal dran => Große Paket => Vorteil Nachteil dieser Verfahren: Streams müssen identifizierbar sein, in unserem Fall nicht gegeben CSFQ: Äußerer Rand der Insel: bewertet Stream Prios: interne Submenge folgt den QoS Anforderungen. Doch wo ist der Rand im P2P Netzwerk? Kein Subnetz klar einkreisbar. Random Early Detection: Bis Bufferfüllung Thres_min: nichts verwerfen, von Thres_min bis Thres_max Drop-Rate proportional heben mit (Bufferfüllung-Thres_min), ab thres_max: alles verwerfen -> Problem: No priorities considered, Overlay dont have (message-type-based) congestion windows ->
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.