KG_0805_ACM_NOSSDAV_Presentation_06.ppt

KOM - Multimedia Communications LabProf. Dr.-Ing. Ralf Steinmetz (Director)

Dept. of Electrical Engineering and Information TechnologyDept. of Computer Science (adjunct Professor)

TUD – Technische Universität Darmstadt Merckstr. 25, D-64283 Darmstadt, Germany

Tel.+49 6151 166150, Fax. +49 6151 166152 www.KOM.tu-darmstadt.de

© author(s) of these slides 2008 including research results of the research network KOM and TU Darmstadt otherwise as specified at the respective slide

httc – Hessian Telemedia Technology

Competence-Center e.V - www.httc.de

Dipl.-Math., Dipl.-Inform. Kalman GraffiKalman.Graffi@KOM.tu-darmstadt.de

12. April 2023

Load Balancing for Multimedia Streaming in Heterogeneous Peer-to-Peer Systems

Kalman Graffi, Sebastian Kaune, Konstantin Pussep, Aleksandra Kovacevic, Ralf Steinmetz

KOM – Multimedia Communications Lab 2

Outline

Introduction to P2P-based Multimedia Streaming

Model of Content Block based Streaming

Architecture for Load Balanced P2P Streaming Requirements System Architecture Task Allocation using a Scoring Function

Evaluation Simulation Setup Metrics Results

Conclusion

KOM – Multimedia Communications Lab 3

Introduction to P2P Multimedia Streaming

Large-scale multimedia streaming scenario A lot of users, sharing multimedia content between each other Peer-to-peer technology keeps the costs down How to balance the load on the peers and to support heterogeneity?

Streaming Architecture

KOM – Multimedia Communications Lab 4

Model of Content Block based Streaming

Streamable multimedia content C is split in m blocks with unique IDs

Model:

Two sets per block ID with peerIDs:

Owners and Demanders

Within an architecture that is distributed scalable

Typical system load: Maximum 100 providers per block

MM content CB1 B2 B3 B4 B5

B5

B4

B3

B2

B1

B5

B4

B3

B2

B1

Demand Set Wi

Owner Set Hi

P1

P2

P3

P4

P5

P6

P7

P1

P2

P3

P4

P5

P6

P7

KOM – Multimedia Communications Lab 5

Matching Problem

Content block based allocation of

block provider to block requester

Matching problem:What is the best strategy to matchpeers from Wi to Hi

considering: Peer load Heterogeneity of the peers

Leaving peers the freedom to define maximum load levels considers their current load

Leading to Balanced load regarding the

stream provision in the system

P3

P4

P5

P3

P4

P5

P1

P2

P6

P7

Block iRequester

Block iProvider

Block iRequester

Block iProvider

P1

P2

P6

P7

KOM – Multimedia Communications Lab 6

Outline

Introduction to P2P Streaming

Model of Content Block based Streaming

Architecture for Load Balanced P2P Streaming Requirements System Architecture Task Allocation using a Scoring Function

Evaluation Simulation Setup Metrics Results

Conclusion

KOM – Multimedia Communications Lab 7

Requirements on the Architecture Design

Functional requirements Users can announce their multimedia content Users find providers for desired content using the architecture Users can define a maximum load they are willing to carry The architecture solves the matching problem

Non-functional requirements No central element is used The matching problem is solved in a load balancing way

Supporting peer heterogeneity: considering the individual load Load balancing: aiming at an equal utilization of the block providers

Focus is on non-functional requirements Optimizing system wide aspects Leaving the path of traditional P2P patterns

KOM – Multimedia Communications Lab 8

Main Idea of the Solution

Optimizing system wide aspects Supporting peer heterogeneity Achieving load balancing

Main Idea Give the freedom of contribution back to peers

Peers define maximum load to carry Current capabilities are considered Strong peers add more, weak peers less

Give the control of load back to the system: System decides on load dispatching

Load balancing is a system wide state

In contrary to individual peers choosing other peers to contribute

KOM – Multimedia Communications Lab 9

Distributed Hybrid System Architecture

Network Structure: All entities are participants (peers) in a DHT DHT peers store per block ID (i)

a set of block providers (Hi)

Announcement: All peers (from Hi) register themselves for all of their

content blocks (Bi) at the peer responsible for the corresponding block ID (Ri)

Periodically, peers from Hi update their state at Ri

Peers chose themselves how much to announce

Motivation for design decisions: DHTs allow for role assignment Block ID mapping to peers is easy Hybrid approach:

centralize overview, distribute load

P3

P4

P5

Block 3requester

Block 3provider

P1

P2

P6

P7

DHT

10

Responsible for block 3

Peer Qual./Load

P1

P2

P6

okgoodweak

okP7

KOM – Multimedia Communications Lab 10

Distributed Hybrid System Architecture

Query Requesting peers (from Wi) ask Ri for

a content provider from Hi In the example: peer 5 asks for block 3

Matching on Ri

Ri uses a scoring function and the states of the peers in Hi to determine the most suitable provider

Ri answers with address of one provider, that is then used to stream the content

Load balancing aspect Block maintaining peer (Ri) focuses on a fair load allocation Various optimization strategies can be adopted

DHT

10

Responsible for block 3

Peer Qual./Load

P1

P2

P6

okgoodweak

okP7

Get provider for block 3Provider to

use: peer 2

KOM – Multimedia Communications Lab 11

Task Allocation using a Scoring Function

Question: How to derive “quality” of the providers?

Idea: Map each content provider to a linear scale Consider network status, load, heterogeneity and online duration Allocate tasks to peers based on their position on the scale Load is balanced by peers (Ri) responsible for the content

Peer (p) related information parameters, time dependent1. Allocated tasks for the system

2. Estimation of local tasks / load

3. Bandwidth quality of the peer

4. Online time of the peer

Scoring function determines most suitable provider

)(tI LTP)(tI BqP

)(tI ATP

)(tI OTP

)()()()(),( 4321 tItItItItpc OTP

BqP

LTP

ATPs RTimePeerstpcs :),(

KOM – Multimedia Communications Lab 12

Outline

Introduction to P2P Streaming

Model of Content Block based Streaming

Architecture for Load Balanced P2P Streaming Requirements System Architecture Task Allocation using a Scoring Function

Evaluation Simulation Setup Metrics Results

Conclusion

KOM – Multimedia Communications Lab 13

Simulation Setup and Metrics

Simulation environment PeerfactSim.KOM – the Peer-to-Peer Systems Simulator Focus on block based access:

25, 50, 75 and 100 peers interested per multimedia block 25 – 100 requests in total

Reference solution: random task assignment

Metrics Costs for one assignment: Cost for all assignments: Sum of all costs S(.) using strategy RND or SF Profit:

Measuring load balancing: standard deviation in the load distribution

)()()()(),( 4321 tItItItItpc OTP

BqP

LTP

ATPs

)(

)()(

SFS

SFSRNDS

KOM – Multimedia Communications Lab 14

Finding suitable Parameter Settings

For the setting of α1, α2, α3 and α4 :

Fix α3 (Bq) and α4 (OT) to 25%

Scenario: 100 peers, 100 requests

Observation: Best results for α1 = 45% and α2 = 5%

Load is balanced (low deviation)

Using this paramter setting Leads to more balanced load Higher „profit“ in comparison to

random load allocation

setup1 setup2 setup3 setup4 setup5

α1 / AT 5% 15% 25% 35% 45%

α2 / LT 45% 35% 25% 15% 5%

Profit 65% 62% 56% 62% 77%

KOM – Multimedia Communications Lab 15

Improved Load Balance

Metric for load balance

Simulation setup Peers, requests: 25/25,50/50,75/75,100/100 Varying allocation strategy: SF, RND

Observation SF leads to decreased deviation in peer load Load balancing is improved up to 53%

KOM – Multimedia Communications Lab 16

Tradeoff between Costs and Performance

Scoring function requires information on the peers (AT, LT, Bq, OT)

Generates traffic costs Fresh information generates more costs Does optimal update interval exist?

Simulation setup 100 peers, 100 requests Varying update interval Values vary continuously between 0 and 2

Observation High update intervals lead (as expected) to

Less traffic overhead Older information

But: No turning point identifiable Costs for performance nearly linear

KOM – Multimedia Communications Lab 17

Outline

Introduction to P2P Streaming

Model of Content Block based Streaming

Architecture for Load Balanced P2P Streaming Requirements System Architecture Task Allocation using a Scoring Function

Evaluation Simulation Setup Metrics Results

Conclusion

KOM – Multimedia Communications Lab 18

Conclusion

Architecture for multimedia content streaming Applicable on any DHT, load-balanced, supporting peer heterogeneity Designated peers are responsible for dispatching load to content providers They use a scoring function, which considers

Peer load (Active Tasks, Local Tasks) Peer heterogeneity (Bandwidth quality, Online Time)

Improved system performance: System controls load allocation, as load balancing is a system-wide metric In comparison to a random load dispatcher,

The scoring function results in up to 109% better choices The load deviation in the system is reduced by 53%

KOM – Multimedia Communications Lab 19

Further Questions ?

Peers

αβλ

μ

Parameters

f(α, β)=…=xg(λ, μ)=…=yh(α, λ)=…=z

ModelsInterpreted state

Architecture

Information Management Architecture

Analysis, Modeling and Interpretation

Using Info. to Gain

Efficiency