Overlay Bandwidth Management: Scheduling and Active Queue Management of Overlay Flows Kalman Graffi , Konstantin Pussep, S...
Example: Bandwidth Usage in Unst. P2P Overlay Queries I cannot hear you Help! Emergency! Unimportant Bandwidth usage : <ul...
Outline <ul><li>Motivation and Scope </li></ul><ul><li>Background: Scheduling and Active Queue Management </li></ul><ul><l...
Motivation for Bandwidth Management <ul><li>Emerging commercial P2P applications require </li></ul><ul><ul><li>Quality of ...
Which Flows are in Focus?  <ul><li>Types of flows in P2P systems </li></ul><ul><li>Layer 4 traffic flows:  </li></ul><ul><...
<ul><li>Learn from network layer </li></ul><ul><ul><li>Scheduling </li></ul></ul><ul><ul><ul><li>Reorder tasks/messages in...
Overlay Bandwidth Management <ul><li>Generally applicable overlay bandwidth management </li></ul><ul><ul><li>New layer  Ne...
<ul><li>Observation </li></ul><ul><ul><li>Huge number of contacts with few messages each </li></ul></ul><ul><ul><li>Overla...
Requirements and Related Work <ul><li>Requirements: </li></ul><ul><ul><li>QoS attributes per message (defined by higher la...
<ul><li>HiPNOS.KOM: Highest Priority First, No Starvation </li></ul><ul><ul><li>Introduce (independent) message priorities...
Evaluation Setup <ul><li>Compare HiPNOS.KOM with reference solution </li></ul><ul><ul><li>First In, First Out: reference s...
Evaluation Results of HiPNOS.KOM <ul><li>Results: </li></ul><ul><li>Quality of service increases with priority  </li></ul>...
Future Work <ul><li>Observation: </li></ul><ul><ul><li>QoS requirements fulfilled: higher prio., better QoS </li></ul></ul...
Conclusion <ul><li>Problem: QoS for overlays currently not supported </li></ul><ul><ul><li>Overlays cannot be used for cri...
Questions? Kalman Graffi Peer-to-Peer Research Group Dept. of Electrical Engineering and Information Technology Multimedia...
Upcoming SlideShare
Loading in …5
×

IEEE LCN 2007: Kalman Graffi - Overlay Bandwidth Management: Scheduling and Active Queue Management of Overlay Flows

571 views

Published on

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
571
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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 =&gt; Große Paket =&gt; 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 -&gt; Problem: No priorities considered, Overlay dont have (message-type-based) congestion windows -&gt;
  • 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.
  • IEEE LCN 2007: Kalman Graffi - Overlay Bandwidth Management: Scheduling and Active Queue Management of Overlay Flows

    1. 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. 2. Example: Bandwidth Usage in Unst. P2P Overlay Queries I cannot hear you Help! Emergency! Unimportant Bandwidth usage : <ul><ul><li>Irrelevant search queries starve relevant queries </li></ul></ul><ul><ul><li>Overlay flow specific QoS demands unconsidered </li></ul></ul>
    3. 3. Outline <ul><li>Motivation and Scope </li></ul><ul><li>Background: Scheduling and Active Queue Management </li></ul><ul><li>Contribution: </li></ul><ul><ul><li>Characteristics of Overlay Flows </li></ul></ul><ul><ul><li>Requirements and Related Work </li></ul></ul><ul><ul><li>Overlay Bandwidth Management Layer </li></ul></ul><ul><ul><li>HiPNOS.KOM - Our Solution </li></ul></ul><ul><li>Evaluation </li></ul><ul><li>Future Work and Conclusion </li></ul>
    4. 4. Motivation for Bandwidth Management <ul><li>Emerging commercial P2P applications require </li></ul><ul><ul><li>Quality of Service </li></ul></ul><ul><ul><li>Crucial for long-term success of P2P paradigm </li></ul></ul><ul><li>Most critical resource in P2P systems: bandwidth </li></ul><ul><ul><li>In most cases the bottleneck in the system </li></ul></ul><ul><ul><li>Required for maintenance and service provisioning </li></ul></ul><ul><li>P2P specific bandwidth management needed </li></ul><ul><ul><li>Control the bandwidth, provide QoS </li></ul></ul><ul><ul><li>Overlay independent solution </li></ul></ul>
    5. 5. Which Flows are in Focus? <ul><li>Types of flows in P2P systems </li></ul><ul><li>Layer 4 traffic flows: </li></ul><ul><ul><li>Underlay perspective </li></ul></ul><ul><ul><li>Out of scope </li></ul></ul><ul><li>Direct P2P communication: </li></ul><ul><ul><li>File transfer, application traffic, … </li></ul></ul><ul><ul><li>Few, but large data streams (elephants) </li></ul></ul><ul><ul><li>(Often) with low priority for the system </li></ul></ul><ul><li>Overlay flows </li></ul><ul><ul><li>Multi-hop: maintenance, user queries… </li></ul></ul><ul><ul><li>Many, small messages (mice) </li></ul></ul><ul><ul><li>Varying relevance for system </li></ul></ul><ul><li> Provide QoS to overlay flow according to its relevance </li></ul>
    6. 6. <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>Drop msg. upon congestion of queue </li></ul></ul></ul><ul><ul><ul><li>Reference: Drop Tail </li></ul></ul></ul><ul><li> Research challenge: how to apply on overlay layer? </li></ul>Scheduling and Active Queue Management Message Sched.+AQM 1. Message Scheduling Before: After: 2. Queue Management Before: After: Queue Limit
    7. 7. Overlay Bandwidth Management <ul><li>Generally applicable overlay bandwidth management </li></ul><ul><ul><li>New layer Network Wrapper : API between overlay and underlay </li></ul></ul><ul><li>Research challenge:  Which requirements are defined </li></ul><ul><ul><li>by overlay flow characteristics </li></ul></ul><ul><ul><li>for the SCHED + AQM used </li></ul></ul>Buffer management In-from overlay Insert msg in buffer Apply AQM mech. Timeout Pick next msg (SCHED) Out to underlay Bandwidth available? Receive message yes no
    8. 8. <ul><li>Observation </li></ul><ul><ul><li>Huge number of contacts with few messages each </li></ul></ul><ul><ul><li>Overlay “flows” and traditional flows differ significantly </li></ul></ul><ul><li>Conclusion </li></ul><ul><ul><li>Stateless scheduler needed </li></ul></ul><ul><ul><li>Quality of service information are stored in messages </li></ul></ul>Analyzing Overlay Flows in Kademlia <ul><li>Simulation of Kademlia </li></ul><ul><li>Setup: </li></ul><ul><ul><li>PeerfactSim.KOM </li></ul></ul><ul><ul><li>10,000 peers, all join, random store/lookup </li></ul></ul><ul><li>Metrics: </li></ul><ul><ul><li># of contacts per peer </li></ul></ul><ul><ul><li># of msg per contact </li></ul></ul>Results:
    9. 9. Requirements and Related Work <ul><li>Requirements: </li></ul><ul><ul><li>QoS attributes per message (defined by higher layer): </li></ul></ul><ul><ul><ul><li>Introduce delay priority ( ϵ P D ) and loss priority ( ϵ P L ) </li></ul></ul></ul><ul><ul><li>Quality req.: </li></ul></ul><ul><li>Related Work  see paper/Technical Reports of author </li></ul><ul><ul><li>SCHED and AQM proposed for routing layer (L3) </li></ul></ul><ul><ul><ul><li> Expect long-term flows, not existing in overlays </li></ul></ul></ul><ul><ul><li>Overlay bandwidth management in overlays </li></ul></ul><ul><ul><ul><li>Mobile P2P (on UMTS/GSM), P2P multimedia streams </li></ul></ul></ul><ul><ul><ul><li> Focus on underlay/multimedia characteristics </li></ul></ul></ul><ul><ul><ul><li>GIA [Chawathe, 2003], controls incoming traffic </li></ul></ul></ul><ul><li> Sched. and AQM mechanism for overlay flows needed </li></ul>
    10. 10. <ul><li>HiPNOS.KOM: Highest Priority First, No Starvation </li></ul><ul><ul><li>Introduce (independent) message priorities </li></ul></ul><ul><ul><ul><li>For loss – criticality (1 byte) </li></ul></ul></ul><ul><ul><ul><li>For delay – criticality (1 byte) </li></ul></ul></ul><ul><li>Active Queue Management solution: </li></ul><ul><ul><li>If buffer size exceeded: </li></ul></ul><ul><ul><ul><li>Drop message with lowest loss-prio. </li></ul></ul></ul><ul><li>Scheduling solution </li></ul><ul><ul><li>If bandwidth available: </li></ul></ul><ul><ul><ul><li>Pick message with highest latency-prio. </li></ul></ul></ul><ul><li>Avoid starvation </li></ul><ul><ul><li>Periodically increase delay-prio. of queued messages </li></ul></ul>Our Solution: Sched. and AQM of Overlay Flows In-from overlay Insert msg in buffer Apply AQM mech. Timeout Pick next msg (SCHED) Out to underlay Bandwidth available? Receive message yes no
    11. 11. Evaluation Setup <ul><li>Compare HiPNOS.KOM with reference solution </li></ul><ul><ul><li>First In, First Out: reference scheduling solution </li></ul></ul><ul><ul><li>Drop Tail: reference active queue management mech. </li></ul></ul><ul><li>Simulation Setup: </li></ul><ul><ul><li>Simulated: Kademlia on PeerfactSim.KOM </li></ul></ul><ul><ul><li>Scenario: </li></ul></ul><ul><ul><ul><li>10000 peers join, heterogeneous bandwidths </li></ul></ul></ul><ul><ul><ul><li>Peers perform random store/lookup operations </li></ul></ul></ul><ul><ul><ul><li>Msgs with random delay/loss priorities: -128 to 127 </li></ul></ul></ul><ul><ul><li>Varying: HiPNOS.KOM and FIFO/Drop Tail </li></ul></ul><ul><ul><li>20 simulation runs per setup </li></ul></ul><ul><ul><li>Metrics: Delay of msgs and number of dropped msgs </li></ul></ul>
    12. 12. Evaluation Results of HiPNOS.KOM <ul><li>Results: </li></ul><ul><li>Quality of service increases with priority </li></ul><ul><ul><li>Delay antiproportional to priority </li></ul></ul><ul><ul><li>Loss decreases with increasing priority </li></ul></ul><ul><li> QoS requirements of overlay flows can be fulfilled </li></ul>
    13. 13. Future Work <ul><li>Observation: </li></ul><ul><ul><li>QoS requirements fulfilled: higher prio., better QoS </li></ul></ul><ul><ul><li>Even minimal mechanisms are sufficient </li></ul></ul><ul><li>Conclusion: </li></ul><ul><ul><li>Shift of research focus: </li></ul></ul><ul><ul><ul><li>Not how to provide QoS for overlay flows (solved) </li></ul></ul></ul><ul><ul><ul><li>But how set QoS priorities of overlay messages </li></ul></ul></ul><ul><li>Next steps: </li></ul><ul><ul><li>Emergency Call Handling (ECH) over P2P Overlays </li></ul></ul><ul><ul><ul><li>Globase.KOM used to find closest Emergency Station </li></ul></ul></ul><ul><ul><ul><li>ECH messages have highest priority in overlay </li></ul></ul></ul><ul><ul><ul><li>Fulfills legal and technical requirements for ECH </li></ul></ul></ul><ul><ul><li>Security issues </li></ul></ul><ul><ul><li>Evaluate with more overlay types (unstructured…) </li></ul></ul>
    14. 14. Conclusion <ul><li>Problem: QoS for overlays currently not supported </li></ul><ul><ul><li>Overlays cannot be used for critical applications </li></ul></ul><ul><ul><li>Heterogeneity of message relevance not supported </li></ul></ul><ul><li>Contribution: </li></ul><ul><ul><li>Overlay flow characteristics identified: only mice flows </li></ul></ul><ul><ul><li>Introduce message priorities for loss and delay </li></ul></ul><ul><ul><li>HiPNOS.KOM enables P2P overlays to support QoS demands </li></ul></ul><ul><li>Evaluation: </li></ul><ul><ul><li>Good/expected results show effectiveness of solution </li></ul></ul><ul><li>Impact: </li></ul><ul><ul><li>Increase of stability, scalability, robustness … </li></ul></ul><ul><ul><ul><li>of overlay and application </li></ul></ul></ul><ul><ul><ul><li>for low (no?) costs </li></ul></ul></ul><ul><ul><li>Enables QoS-based applications </li></ul></ul>
    15. 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

    ×