ACM NOSSDAV 2008 - Kalman Graffi - Load Balancing for Multimedia Streaming in Heterogeneous Peer-to-Peer Systems

667 views

Published on

Multimedia streaming of mostly user generated content is an ongoing trend, not only since the upcoming of Last.fm and YouTube. A distributed decentralized multimedia streaming architecture can spread the (traffic) costs to the user nodes, but requires to provide for load balancing and consider the heterogeneity of the participating nodes. We propose a DHT-based information gathering and analyzing architecture which controls the streaming request assignment in the system and thoroughly evaluate it in comparison to a distributed stateless strategy. We evaluated the impact of the key parameters in the allocation function which considers the capabilities of the nodes and their contribution to the system. Identifying the quality-bandwidth tradeoffs of the information gathering system, we show that with our proposed system a 53% better load balancing can be reached and the efficiency of the system is significantly improved.

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

  • Be the first to like this

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

No notes for slide
  • | | November 19, 2007
  • ACM NOSSDAV 2008 - Kalman Graffi - Load Balancing for Multimedia Streaming in Heterogeneous Peer-to-Peer Systems

    1. 1. Load Balancing for Multimedia Streaming in Heterogeneous Peer-to-Peer Systems Kalman Graffi, Sebastian Kaune, Konstantin Pussep, Aleksandra Kovacevic, Ralf Steinmetz
    2. 2. Outline <ul><li>Introduction to P2P-based Multimedia Streaming </li></ul><ul><li>Model of Content Block based Streaming </li></ul><ul><li>Architecture for Load Balanced P2P Streaming </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>System Architecture </li></ul></ul><ul><ul><li>Task Allocation using a Scoring Function </li></ul></ul><ul><li>Evaluation </li></ul><ul><ul><li>Simulation Setup </li></ul></ul><ul><ul><li>Metrics </li></ul></ul><ul><ul><li>Results </li></ul></ul><ul><li>Conclusion </li></ul>
    3. 3. Introduction to P2P Multimedia Streaming <ul><li>Large-scale multimedia streaming scenario </li></ul><ul><ul><li>A lot of users, sharing multimedia content between each other </li></ul></ul><ul><ul><li>Peer-to-peer technology keeps the costs down </li></ul></ul><ul><ul><li>How to balance the load on the peers and to support heterogeneity? </li></ul></ul>Streaming Architecture
    4. 4. Model of Content Block based Streaming <ul><li>Streamable multimedia content C is split in m blocks with unique IDs </li></ul><ul><li>Model: </li></ul><ul><li>Two sets per block ID with peerIDs: </li></ul><ul><li>Owners and Demanders </li></ul><ul><ul><li>Within an architecture that is </li></ul></ul><ul><ul><ul><li>distributed </li></ul></ul></ul><ul><ul><ul><li>scalable </li></ul></ul></ul><ul><li>Typical system load: </li></ul><ul><ul><li>Maximum 100 providers per block </li></ul></ul>MM content C B1 B2 B3 B4 B5 B5 B4 B3 B2 B1 B5 B4 B3 B2 B1 Demand Set W i Owner Set H i P1 P2 P3 P4 P5 P6 P7 P1 P2 P3 P4 P5 P6 P7
    5. 5. Matching Problem <ul><li>Content block based allocation of </li></ul><ul><li>block provider to block requester </li></ul><ul><li>Matching problem: What is the best strategy to match peers from W i to H i </li></ul><ul><ul><li>considering: </li></ul></ul><ul><ul><ul><li>Peer load </li></ul></ul></ul><ul><ul><ul><li>Heterogeneity of the peers </li></ul></ul></ul><ul><ul><li>Leaving peers the freedom to </li></ul></ul><ul><ul><ul><li>define maximum load levels </li></ul></ul></ul><ul><ul><ul><li>considers their current load </li></ul></ul></ul><ul><ul><li>Leading to </li></ul></ul><ul><ul><ul><li>Balanced load regarding the stream provision in the system </li></ul></ul></ul>P3 P4 P5 P3 P4 P5 P1 P2 P6 P7 Block i Requester Block i Provider Block i Requester Block i Provider P1 P2 P6 P7
    6. 6. Outline <ul><li>Introduction to P2P Streaming </li></ul><ul><li>Model of Content Block based Streaming </li></ul><ul><li>Architecture for Load Balanced P2P Streaming </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>System Architecture </li></ul></ul><ul><ul><li>Task Allocation using a Scoring Function </li></ul></ul><ul><li>Evaluation </li></ul><ul><ul><li>Simulation Setup </li></ul></ul><ul><ul><li>Metrics </li></ul></ul><ul><ul><li>Results </li></ul></ul><ul><li>Conclusion </li></ul>
    7. 7. Requirements on the Architecture Design <ul><li>Functional requirements </li></ul><ul><ul><li>Users can announce their multimedia content </li></ul></ul><ul><ul><li>Users find providers for desired content using the architecture </li></ul></ul><ul><ul><li>Users can define a maximum load they are willing to carry </li></ul></ul><ul><ul><li>The architecture solves the matching problem </li></ul></ul><ul><li>Non-functional requirements </li></ul><ul><ul><li>No central element is used </li></ul></ul><ul><ul><li>The matching problem is solved in a load balancing way </li></ul></ul><ul><ul><ul><li>Supporting peer heterogeneity : considering the individual load </li></ul></ul></ul><ul><ul><ul><li>Load balancing : aiming at an equal utilization of the block providers </li></ul></ul></ul><ul><li>Focus is on non-functional requirements </li></ul><ul><ul><li>Optimizing system wide aspects  Leaving the path of traditional P2P patterns </li></ul></ul>
    8. 8. Main Idea of the Solution <ul><li>Optimizing system wide aspects </li></ul><ul><ul><li>Supporting peer heterogeneity </li></ul></ul><ul><ul><li>Achieving load balancing </li></ul></ul><ul><li>Main Idea </li></ul><ul><ul><li>Give the freedom of contribution back to peers </li></ul></ul><ul><ul><ul><li>Peers define maximum load to carry </li></ul></ul></ul><ul><ul><ul><li>Current capabilities are considered </li></ul></ul></ul><ul><ul><ul><li>Strong peers add more, weak peers less </li></ul></ul></ul><ul><ul><li>Give the control of load back to the system: </li></ul></ul><ul><ul><ul><li>System decides on load dispatching </li></ul></ul></ul><ul><ul><ul><ul><li>Load balancing is a system wide state </li></ul></ul></ul></ul><ul><ul><ul><li>In contrary to individual peers choosing other peers to contribute </li></ul></ul></ul>
    9. 9. Distributed Hybrid System Architecture <ul><li>Network Structure: </li></ul><ul><ul><li>All entities are participants (peers) in a DHT </li></ul></ul><ul><ul><li>DHT peers store per block ID ( i ) a set of block providers ( H i ) </li></ul></ul><ul><li>Announcement: </li></ul><ul><ul><li>All peers (from H i ) register themselves for all of their content blocks ( B i ) at the peer responsible for the corresponding block ID ( R i ) </li></ul></ul><ul><ul><li>Periodically, peers from H i update their state at R i </li></ul></ul><ul><ul><li>Peers chose themselves how much to announce </li></ul></ul><ul><li>Motivation for design decisions: </li></ul><ul><ul><li>DHTs allow for role assignment </li></ul></ul><ul><ul><li>Block ID mapping to peers is easy </li></ul></ul><ul><ul><li>Hybrid approach: centralize overview, distribute load </li></ul></ul>P3 P4 P5 Block 3 requester Block 3 provider P1 P2 P6 P7 DHT 10 Responsible for block 3 Peer Qual./Load P1 P2 P6 ok goodweak ok P7
    10. 10. Distributed Hybrid System Architecture <ul><li>Query </li></ul><ul><ul><li>Requesting peers (from W i ) ask R i for a content provider from H i </li></ul></ul><ul><ul><li>In the example: peer 5 asks for block 3 </li></ul></ul><ul><li>Matching on R i </li></ul><ul><ul><li>R i uses a scoring function and the states of the peers in H i to determine the most suitable provider </li></ul></ul><ul><ul><li>R i answers with address of one provider, that is then used to stream the content </li></ul></ul><ul><li>Load balancing aspect </li></ul><ul><ul><li>Block maintaining peer ( R i ) focuses on a fair load allocation </li></ul></ul><ul><ul><li>Various optimization strategies can be adopted </li></ul></ul>DHT 10 Responsible for block 3 Peer Qual./Load P1 P2 P6 ok goodweak ok P7 Get provider for block 3 Provider to use: peer 2
    11. 11. Task Allocation using a Scoring Function <ul><li>Question: How to derive “quality” of the providers? </li></ul><ul><li>Idea: Map each content provider to a linear scale </li></ul><ul><ul><li>Consider network status, load, heterogeneity and online duration </li></ul></ul><ul><ul><li>Allocate tasks to peers based on their position on the scale </li></ul></ul><ul><ul><li>Load is balanced by peers ( R i ) responsible for the content </li></ul></ul><ul><li>Peer (p) related information parameters, time dependent </li></ul><ul><ul><li>Allocated tasks for the system </li></ul></ul><ul><ul><li>Estimation of local tasks / load </li></ul></ul><ul><ul><li>Bandwidth quality of the peer </li></ul></ul><ul><ul><li>Online time of the peer </li></ul></ul><ul><li>Scoring function determines most suitable provider </li></ul>
    12. 12. Outline <ul><li>Introduction to P2P Streaming </li></ul><ul><li>Model of Content Block based Streaming </li></ul><ul><li>Architecture for Load Balanced P2P Streaming </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>System Architecture </li></ul></ul><ul><ul><li>Task Allocation using a Scoring Function </li></ul></ul><ul><li>Evaluation </li></ul><ul><ul><li>Simulation Setup </li></ul></ul><ul><ul><li>Metrics </li></ul></ul><ul><ul><li>Results </li></ul></ul><ul><li>Conclusion </li></ul>
    13. 13. Simulation Setup and Metrics <ul><li>Simulation environment </li></ul><ul><ul><li>PeerfactSim.KOM – the Peer-to-Peer Systems Simulator </li></ul></ul><ul><ul><li>Focus on block based access: </li></ul></ul><ul><ul><ul><li>25, 50, 75 and 100 peers interested per multimedia block </li></ul></ul></ul><ul><ul><ul><li>25 – 100 requests in total </li></ul></ul></ul><ul><ul><li>Reference solution: random task assignment </li></ul></ul><ul><li>Metrics </li></ul><ul><ul><li>Costs for one assignment: </li></ul></ul><ul><ul><li>Cost for all assignments: Sum of all costs S( . ) using strategy RND or SF </li></ul></ul><ul><ul><li>Profit: </li></ul></ul><ul><ul><li>Measuring load balancing: standard deviation in the load distribution </li></ul></ul>
    14. 14. Finding suitable Parameter Settings <ul><li>For the setting of α 1 , α 2 , α 3 and α 4 : </li></ul><ul><ul><li>Fix α 3 (Bq) and α 4 (OT) to 25% </li></ul></ul><ul><ul><li>Scenario: 100 peers, 100 requests </li></ul></ul><ul><li>Observation: </li></ul><ul><ul><li>Best results for α 1 = 45% and α 2 = 5% </li></ul></ul><ul><ul><li>Load is balanced (low deviation) </li></ul></ul><ul><li>Using this paramter setting </li></ul><ul><ul><li>Leads to more balanced load </li></ul></ul><ul><ul><li>Higher „profit“ in comparison to random load allocation </li></ul></ul>77% 62% 56% 62% 65% Profit 5% 15% 25% 35% 45% α 2 / LT 45% 35% 25% 15% 5% α 1 / AT setup5 setup4 setup3 setup2 setup1
    15. 15. Improved Load Balance <ul><li>Metric for load balance </li></ul><ul><li>Simulation setup </li></ul><ul><ul><li>Peers, requests: 25/25,50/50,75/75,100/100 </li></ul></ul><ul><ul><li>Varying allocation strategy: SF, RND </li></ul></ul><ul><li>Observation </li></ul><ul><ul><li>SF leads to decreased deviation in peer load </li></ul></ul><ul><ul><li>Load balancing is improved up to 53% </li></ul></ul>
    16. 16. Tradeoff between Costs and Performance <ul><li>Scoring function requires information on the peers (AT, LT, Bq, OT) </li></ul><ul><ul><li>Generates traffic costs </li></ul></ul><ul><ul><li>Fresh information generates more costs </li></ul></ul><ul><ul><li>Does optimal update interval exist? </li></ul></ul><ul><li>Simulation setup </li></ul><ul><ul><li>100 peers, 100 requests </li></ul></ul><ul><ul><li>Varying update interval </li></ul></ul><ul><ul><li>Values vary continuously between 0 and 2 </li></ul></ul><ul><li>Observation </li></ul><ul><ul><li>High update intervals lead (as expected) to </li></ul></ul><ul><ul><ul><li>Less traffic overhead </li></ul></ul></ul><ul><ul><ul><li>Older information </li></ul></ul></ul><ul><ul><li>But: No turning point identifiable </li></ul></ul><ul><ul><li>Costs for performance nearly linear </li></ul></ul>
    17. 17. Outline <ul><li>Introduction to P2P Streaming </li></ul><ul><li>Model of Content Block based Streaming </li></ul><ul><li>Architecture for Load Balanced P2P Streaming </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>System Architecture </li></ul></ul><ul><ul><li>Task Allocation using a Scoring Function </li></ul></ul><ul><li>Evaluation </li></ul><ul><ul><li>Simulation Setup </li></ul></ul><ul><ul><li>Metrics </li></ul></ul><ul><ul><li>Results </li></ul></ul><ul><li>Conclusion </li></ul>
    18. 18. Conclusion <ul><li>Architecture for multimedia content streaming </li></ul><ul><ul><li>Applicable on any DHT, load-balanced, supporting peer heterogeneity </li></ul></ul><ul><ul><li>Designated peers are responsible for dispatching load to content providers </li></ul></ul><ul><ul><li>They use a scoring function, which considers </li></ul></ul><ul><ul><ul><li>Peer load (Active Tasks, Local Tasks) </li></ul></ul></ul><ul><ul><ul><li>Peer heterogeneity (Bandwidth quality, Online Time) </li></ul></ul></ul><ul><li>Improved system performance: </li></ul><ul><ul><li>System controls load allocation, as load balancing is a system-wide metric </li></ul></ul><ul><ul><li>In comparison to a random load dispatcher, </li></ul></ul><ul><ul><ul><li>The scoring function results in up to 109% better choices </li></ul></ul></ul><ul><ul><ul><li>The load deviation in the system is reduced by 53% </li></ul></ul></ul>
    19. 19. Further Questions ? Peers α β λ μ Parameters f( α , β )=…= x g( λ , μ )=…=y h( α , λ )=…=z Models Interpreted state Architecture Information Management Architecture Analysis, Modeling and Interpretation Using Info. to Gain Efficiency
    20. 20. Distributed Hybrid System Architecture DHT 10 Verantwortlich für die Ress. X Peer Qual./Last P1 P2 P6 0.7 0.9 0.2 0.5 P7 Anbieter für Ressource X ? Zu verwendender Anbieter: Knoten 2

    ×