This document discusses monitoring and managing peer-to-peer systems. It aims to coordinate millions of autonomous peers to provide controlled quality of service. Specifically, it addresses how to monitor system-specific and peer-specific metrics to analyze the current system state. It then proposes a self-configuration framework where the root peer derives and distributes new parameter configurations to reach predefined quality goals. The evaluation shows this approach enables quick convergence to quality intervals while imposing low overhead.

1. Monitoring and Management
of Peer-to-Peer Systems
How to coordinate millions of autonomous peers
to provide controlled quality of service?
KOM - Multimedia Communications Lab
Prof. Dr.-Ing. Ralf Steinmetz (director)
Dept. of Electrical Engineering and Information Technology
Dept. of Computer Science (adjunct professor)
TUD – Technische Universität Darmstadt
Dipl.-Math. Dipl.-Inform. Kalman Graffi Merckstr. 25, D-64283 Darmstadt, Germany
Tel.+49 6151 164959, Fax. +49 6151 166152
graffi@KOM.tu-darmstadt.de www.KOM.tu-darmstadt.de
20090929_Kalman.Graffi_Madrid.Carmen.ppt 17. Februar 2011
© author(s) of these slides 2008 including research results of the research network KOM and TU Darmstadt otherwise as specified at the respective slide

2. The Peer-to-Peer Paradigm
Evolution of applications / QoS demands
Single purpose applications:
File sharing (high bandwidth)
Voice over IP (real-time)
Video-on-demand (real-time and bandwidth)
In the future: Multi-purpose/goal applications
App-based online community platforms
Potential for high user interaction
Possible IT infrastructures:
H(„ my data“ )
Client/Server, server farms, SoA, Cloud, Grid, P2P = 3107
1008 1622 2011
709 2207
Peer-to-peer systems
?
Users build infrastructure 611
3485
2906
Service is provided from users to users
12.5.7.31
Scale well berkeley.edu planet-lab.org
peer-to-peer.info
95.7.6.10
89.11.20.15
Provide unreliable quality of service 86.8.10.18 7.31.10.25
See: K. Graffi, AsKo, et al. “Peer-to-Peer Forschung - Überblick und Herausforderungen” KOM – Multimedia Communications Lab 2
In: it - Information Technology (Methods and Applications of Informatics and Information Technology), vol. 46, no. 5, p. 272-279, July 2007

3. Dynamics in P2P System
Assume fixed combination of mechanisms and configuration
Challenges for providing quality in p2p systems:
Various applications
Distributed storage
Content delivery
User
Discovery and contacting of users
Peer heterogeneity Application
Manage-
Peer capacities ment
Connectivity Overlay
User behavior
Access patterns Devices
Churn
Network
Create a new overlay/mechanism for every case?
No, reuse existing overlays/mechanisms
Goal: Monitor and manage the quality of service of the p2p systems
KOM – Multimedia Communications Lab 3

4. Overview on my work
Goal: Monitor and manage the quality of service of the p2p systems
Target group: p2p system providers
Goal Monitor and managing the quality of service of the p2p systems
Controlled system metrics Reliable resource reservation
Monitoring
… of system-specific metrics, … of peer-specific metrics,
global view on system status capacity-based peer search
Management
Autonomic self-configuration cycle Distributed redundancy control for
to reach and hold preset quality goals guaranteed resource provisioning
Evaluation
Analytical model, simulations, Analytical model, simulations
testbed
Example P2P platform for app-based application composition with monitored QoS
Application
LifeSocial.KOM – a P2P-based Onlince Social Network
KOM – Multimedia Communications Lab 4

5. Management of P2P Systems through
Automated Self-Configuration
Quality of Service
“The well-defined and controllable behavior of a system with respect to quantitative
parameters”
Defined by system provider, aimed by system
Quality goals are predefined
Application and scenario specific
e.g. Metric intervals
Examples
Goal interval for hop count: [7,10]
Standard deviation of peer load: max 500%
Goal
Configuration should adapt to quality goals
Automated meeting of predefined metric intervals
Step 1: Monitor current system state
Step 2: Analysis state, plan new parameter configuration
Step 3: Distribute and adopt new parameter configuration on all peers
KOM – Multimedia Communications Lab 5

6. System- and Peer-specific Information
Global system statistics Peer-specific information
Statistics: Capacities:
Average CPU usage Max / current bandwidth
Average bandwidth utilization Operating System, Java version
Average hop count CPU power
Messages sent / received Free disk space
Number of peers Responsibility range
Message sizess Parent coordinator
… …
Statistical information: List-based concatenation
avg, min, max, standard dev., sum,... E.g. peer 101, up bandwidth 27kb/s, …
Information is aggragatable: Information is NOT aggragatable:
Size of information remains the same Size of information grows with number
Independent of number of peers of peers
Leads to overhead issues
K. Graffi et al. “SkyEye.KOM: An Information Management Over-Overlay for Getting the Oracle View on Structured P2P Systems”Communications Lab
KOM – Multimedia 6
IEEE International Conference on Parallel and Distributed Systems (IEEE ICPADS ‘08), December 2008

7. Gathering System-specific Information
Design decisions:
new layer, for structured p2p overlays, tree
topology, proactive information gathering,
static position assignment
Equal roles for all peers
Load similar for all peers in all positions
Aggregation of statistics
Sum, min, max, average
Standard deviation, count
[µ,σ,σ²,Σ,
min,max]
Statistic updates [µ,σ,σ²,Σ,
Periodically sent to parent peer min,max]
Aggregated in each node ( same size)
Global view in root [µ,σ,σ²,Σ,
Every update is ACKed with global min,max]
view from above
Root analyzes information and pushes a new
configuration to all peers
KOM – Multimedia Communications Lab 7

8. Gathering System-specific Information
Design decisions:
new layer, for structured p2p overlays, tree
topology, proactive information gathering,
static position assignment
Equal roles for all peers
Load similar for all peers in all positions
Aggregation of statistics
Sum, min, max, average
Standard deviation, count + new parameter [µ,σ,σ²,Σ,
configuration min, max]
Statistic updates
[µ,σ,σ²,Σ,
Periodically sent to parent peer min, max]
Aggregated in each node ( same size)
Global view in root
Every update is ACKed with global [µ,σ,σ²,Σ,
min, max]
view from above
Root analyzes information and pushes a new
configuration to all peers
KOM – Multimedia Communications Lab 8

9. Some Remarks on SkyEye.KOM and
Monitoring System Statistics
Why is it generally applicable on DHTs?
Unified ID space, using core DHT functions
(Key based Routing API)
Coordinator_ID
C 0 0,5
Why is it robust against churn? C_ID 0,25 C_ID
1 1 0,75
If peer fails: automatically replaced in the DHT C C
Updates are routed to new peer for aggregation C_ID 0,125 C_ID 0,625 C_ID 0,875
2 2
C2 C_ID 0,375 C C
2
C
Why are costs low?
C_ID
One update: ~1kb, 0,3125 C3
Out + in degree = 1 + tree degree (2 or 4)
Independent of position in the tree! 0,09 0,2 0,31 0,4 0,5 0,6 0,75 0,9
0 1
Age of information:
50 1
Limited by tree depth, O(log (N)) 10
45 DHT
Influenced by update period 15
40 20
30
Just two message types: Update, ACK
Assumed functions:
route(msg, key), isMyKey(key)
KOM – Multimedia Communications Lab 9

10. Gathering Peer-specific Information
Type of information
Individual Peer ID and peer specific information:
Free storage space, CPU power, bandwidth capabilities, online time, …
Responsibility range, node degree, Coordinator ID, …
Desired query
Capacity-based peer search:
Find N peers with e.g. node degree > 20, free storage space > 10MB, online time > 10h
Challenge:
Information cannot be aggregated grows in size
Costs may overload the Coordinators
Supporting Peers for Load Balancing
Each peer defines max. load
Coordinator may choose strong Supporting Peers
Workload delegated to supporting peer
Results in a tree with strong peers
KOM – Multimedia Communications Lab 10

11. Gathering Peer-specific Information: Protocol
Update information: Query format:
Peer 11, RAM = 700MB, Online = 12h 5_of_
RAM_>_1024_Int,CPU_>2048_Int
… Threshold
150MB
Query
C0 Match 1 C0
15MB Match 2
Match 3
Threshold
50MB
42MB
37MB
C1 C1
11MB 20MB
Query
Threshold 10MB
16MB Match 1
15MB
Match 2
C2 SP C2 SP
Threshold Query
200MB Query Query
10MB Match 1
Threshold Address Match 1
20MB 20MB of the Match 2
10MB
Support-Peer Match 3
Match 4
C3 C3 Match 5
10MB
KOM – Multimedia Communications Lab 11

12. System Monitoring Performance
Tree degree = 4
Update interval = 60sec
K.See: K.D. Stingl et al.“Monitoringand Management ofof Structured Peer-to-Peer Systems” IEEE P2P 2009
Graffi, Graffi et al., “Monitoring and Management Structured P2P Systems” submitted to KOM – Multimedia Communications Lab 12
In: IEEE Peer-to-Peer Computing '09 (IEEE P2P’09), September 2009.

13. System Monitoring Costs
Tree degree = 4
Update interval = 60sec
K.See: K.D. Stingl et al.“Monitoringand Management ofof Structured Peer-to-Peer Systems” IEEE P2P 2009
Graffi, Graffi et al., “Monitoring and Management Structured P2P Systems” submitted to KOM – Multimedia Communications Lab 13
In: IEEE Peer-to-Peer Computing '09 (IEEE P2P’09), September 2009.

14. SkyEye.KOM: Tree Growth and Depth
Logarithmic Tree Depth
Example tree
Tree degree (TD) = 2
Balanced, if ID space balanced
Peers may be Coordinators at various
levels not always 2 children
KOM – Multimedia Communications Lab 14

15. Testbed: Topology of the Tree
Topology
link to Coordinator
responsibility
range
With 44 Peers 8 tree
levels are used
(2 above minimum)
Minimum (=O(logN))
not reached due to
non uniform peer ID
distribution
KOM – Multimedia Communications Lab 15

16. SkyEye.KOM: Peer-specific Information
Observations Quality of Information:
Scope of view not complete Less useful peer information is dropped
Determined by individual load limits of Tradeoff: Completeness vs. load limits
Coordinators and Support Peers Peers in the results: >98% are online
Exchange of root
Load limit of new root = 270
Current load = 440
Support peer chosen
Actual screenshot of demo
KOM – Multimedia Communications Lab 16

17. SkyEye.KOM: Peer-specific Information
Query – originators and solvers Effect of query complexity
Scenario with 5000 peers Queries demanding better resources
Most peers around level 10 are solved higher in the tree
Most queries solved between root and “Good” peers bubble up in the tree
peers at level 5
KOM – Multimedia Communications Lab 17

18. A Self-Configuration Framework for P2P
Systems
Steps prepared Metric goals
Predefined quality goals given Metrics Analysis Parameter
Parameters and Plan
P2P overlay parametrizable
Monitoring reveals current system state
Steps needed
Root is deciding component
Derive new parameter configuration
Based on
Predefined metric intervals Metric
Current metrics and parameter goal
configuration Current
Distribute new configuration metric
timely to all peers
Parameters
Goal: System reaches and holds
predefined metric intervals
See: K. Graffi et al., “Monitoring and Management of Structured Peer-to-Peer Systems” KOM – Multimedia Communications Lab 18
In: IEEE Peer-to-Peer Computing '09 (IEEE P2P’09), September 2009.

19. Deriving a new Configuration
Prevent configuration oscillation
Give time for changes to take effect
Analyze slope of metric history
Act only if small, i.e. changes settled
Goal
Manage the p2p system so that it fulfills
our demands on a defined metric set
Evaluation in next step
Monitoring an overlay (Chord)
Set goal intervals: hop count [7;10]
Goal Metric
Static rules: Adapt finger table size by
10% (down) or 100% (up)
KOM – Multimedia Communications Lab 19

20. Starting with High Hop Count
Too large hop count is detected Quick convergence towards goal
Finger table size: increase by 100% One iteration: 12 update intervals
Initial FT size: 20, at end 80 Quality goal is reached and kept
KOM – Multimedia Communications Lab 20

21. Starting with Low Hop Count
Too small hop count is detected Quick convergence towards goal
Finger table size: decrease by 10% One iteration: 12 update intervals
Initial FT size: 160, at end 116 Quality goal is reached and kept
KOM – Multimedia Communications Lab 21

22. Summary on Management of P2P Systems
Main question:
How to control a p2p system so that it fulfills
our demands on a defined metric set?
Self-Configuration Framework
Uses SkyEye.KOM to monitor the system state and deploy new configuration
No additional protocol complexity
Extendable for more metrics and parameters
Evaluation shows:
Overhead is very small (piggybacking parameters in monitoring messages)
Preset quality intervals are quickly reached and hold
KOM – Multimedia Communications Lab 22

23. Summary
Management of P2P overlays
Reach and hold preset quality intervals
Through monitoring and self-configuration
Coordinated resource usage
Parameterization influences quality metrics
Identifying optimization goals needs monitoring
Monitoring: SkyEye.KOM
Global view on statistics of running system:
avg./std./min./max on all metrics
Gathering peer-specific information
Precise yet cost effective monitoring
Self-Configuration Cycle in Chord
Automated rule application
Preset quality intervals are reached and hold
KOM – Multimedia Communications Lab 23

24. Outlook on Reliable Resource Reservations
Reservation managers
Resource providers
KOM – Multimedia Communications Lab 24

25. Thank you for your attention! Questions?
KOM – Multimedia Communications Lab 25