• Save
Kalman Graffi - Monitoring and Managing Quality in P2P-based Online Social Networks -  2011
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Kalman Graffi - Monitoring and Managing Quality in P2P-based Online Social Networks - 2011

on

  • 629 views

Dr.-Ing. Kalman Graffi presents in this talk in Karlsruhe 2011 research results on both quality-controlled p2p systems and p2p-based online social networks. Monitoring the quality of service of ...

Dr.-Ing. Kalman Graffi presents in this talk in Karlsruhe 2011 research results on both quality-controlled p2p systems and p2p-based online social networks. Monitoring the quality of service of peer-to-peer systems, helps commercial system providers and users to observe the behavior of the system. With an automated re-configuration approach misleading trends and quality issues can be tackled, resulting in a self-optimizing peer-to-peer network. However, new application areas need to be investigated for the p2p paradigm. Online social networks are very popular nowadays, using a p2p based approach could both benefit the system providers and users. With LifeSocial, an operational peer-to-peer-based prototype will be presented. The solution is reliable, monitored, secure and provides in addition to the typical functionalities of online social networks some collaborative elements. An overview and videos are given in www.lifesocial.org

Bio:
Kalman Graffi graduated from the Technische Universität Darstadt with the degree Dr.-Ing. in electrical engineering, a diploma in computer science and a diploma in mathematics.
He is focusing on the monitoring and management of peer-to-peer systems as well as on peer-to-peer based online social networks.

Statistics

Views

Total Views
629
Views on SlideShare
629
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Create a new overlay/mechanism for every case?  Reuse existing overlays / mechanisms
  • “ The well-defined and controllable behavior of a system with respect to quantitative parameters ” Does the system meet the expectations? How can we know? Download counter? Application GUI?
  • Tree topology characteristics All peers part of spanning tree Peer positions calculated Churn-resistant protocols based on IDs
  • | | November 19, 2007
  • Model: behavior synthesis Simulation: large scale, detailed Testbed: accurate prototype
  • MODELL! Log_beta(N) * UI = ???
  • MODELL für Kosten? Warum 3KB/s ?
  • | | November 19, 2007
  • | | November 19, 2007

Kalman Graffi - Monitoring and Managing Quality in P2P-based Online Social Networks - 2011 Presentation Transcript

  • 1. Monitoring and Managing Quality in P2P-based Online Social Networks
  • 2. Communication Paradigms in the Internet
    • Internet application trends
      • Large-scale applications
      • User-generated content
      • User-to-user communication
    • Example
      • Online social networks
      • Access to user profiles and pictures
    • Client / server paradigm
      • Server cluster as provider
      • Good: controlled quality
      • Bad: costs
    • Peer-to-peer (p2p) paradigm
      • Infrastructure hosted by peers
      • Good: shared costs
      • Bad: quality?
  • 3. Motivation
    • Typical motivation for p2p applications
      • Client / Server is bad  P2P is needed
    • My motivation: P2P is dying
      • BitTorrent, edonkey, …, file sharing  One click hosting
      • Skype  technological issues, although simple functionality
      • Wuala, data storage  very centralized
      • Joost (p2p tv), Groove (groupware)  Not anymore P2P
    • The Cloud is killing the purpose of P2P on user devices
      • Quality and costs are guaranteed
    • To survive, P2P needs:
      • Controlled quality and new applications
  • 4. Challenges for Quality of P2P Systems
    • Distributed character
      • Distributed solutions and overlays needed
    • Undefined scale
      • From tens to several millions
    • Peer fluctuation (churn)
      • Peers join / leave the system autonomously
    • Peer heterogeneity
      • Varying capacities and connectivity
    • Static configurations are insufficient
      • Requirements known when system is deployed
      • Updates are difficult
  • 5. Approaches to Address Quality Challenges
    • Building a quality-aware p2p application
      • Identify: application scope, scenario, expected dynamics
      • Build software
        • relying on peer capacities
        • to meet (quality) expectations
    • 1. Simple access to peer capacities in network
      • Reliable usage of the capacities
      • Support for mechanism design
    • 2. Observe and control system quality
      • Maintain high service quality
      • Interest of users and application provider
  • 6. Agenda of the talk
    • Quality in p2p systems: General mechanisms for monitoring the system and peer information in p2p systems and managing the quality of the p2p system and capacity reservations
    • My contributions
      • SkyEye.KOM : Monitoring
        • Statistics on system behavior
        • Capacity-based peer search
      • SkyNet.KOM : Autonomic management cycle
      • P 3 R 3 O.KOM : Reliable capacity reservation
      • LifeSocial.KOM : Platform for online social networks
  • 7. Agenda
    • Introduction
    • Overview on my System Management Approach
      • System Monitoring – SkyEye
      • System Management – SkyNet
    • P2P-based Online Social Networks
      • LifeSocial – Secure, Distributed, Controlled
    • Conclusions
  • 8. System Management Overview
    • Goal
      • System automatically adapts to meet predefined target metric intervals
    • Traditional approach
      • Build mechanism / overlay for
        • Specific scenario
        • Expected dynamics
      • Limited reusabilty
    • Approach
      • Research on viable concepts
      •  SkyNet.KOM : Automated self-configuration framework
    • Challenges
      • Precise monitoring of system behavior
      • Quick information transport
      • Closing the management cycle
    Metric Metric Goal
  • 9. Running Example: Improving the Lookup Delay
    • P2P overlay functions
      • Overlay provides ID-based routing
      • Peers are responsible for ID ranges
      • Used for
        • ID-based document storage
        • ID-based role assignment
    • Classic p2p overlay “Chord”
      • Low routing delay desired
      • Routing delay influenced by hop count
      •  Target metric for hop count: [ 7, 10 ]
      • Influencing parameter: finger table size
    •  Approach for adapting hop count to [7,10]
      • Monitor metric status
      • Analyze derivation from target metric
      • Re-configure system if needed
    100ms 100ms 100ms 2207 2906 3485 2011 1622 1008 709 611 Hop Count Routing
  • 10. Agenda
    • Introduction
    • Overview on my System Management Approach
      • System Monitoring – SkyEye
      • System Management – SkyNet
    • P2P-based Online Social Networks
      • LifeSocial – Secure, Distributed, Controlled
    • Conclusions
  • 11. SkyEye.KOM: Tree Topology
    • Concept of new layer
      • Decouples from specific p2p overlay
      • Unified ID space [0,1]
    • Tree of information domains
      • Domain: ID range for monitoring
      • Domain size split in β parts per level
      • Domain IDs build tree topology
    • Peers to Domain ID assignment
      • Peer ID p , level l  Domain IDs
      • If peer is responsible: position defined
    Internet 0.5 0.25 0.375 0,3125 0.75 0.875 0.625 0.125 Domain Domain ID 0.3125 1 10 50 20 30 40 45 15 P2P Overlay 0 1 0.09 0.2 0.31 0,4 0.5 0.6 0.75 0.9 0.375 0.25 0.5
  • 12. SkyEye.KOM: Communication Protocol
    • Gathering global view
      • Information type: Lookup time, tree and network structure, overhead (types), …
      • Every peer measures local status
      • Periodically sent to parent peer
        •  Update Interval ( UI )
    • Aggregation
      • Direct: count, sum, minimum, maximum, sum of squares
      • Derived: mean, variance, std. deviation
    • Dissemination of global view
      • Global view in root
      • Every update message is acknowledged
      • Contains global view from level above
    • Metric update protocol:
    • Gather and disseminate time O( log β (N) · UI )
    Local measures, (synchronized signal in simulations) Aggregated view Global view
  • 13. Evaluation of SkyEye.KOM
    • Evaluation goal
      • Understanding SkyEye.KOM’s behavior
      • Measuring performance and costs
    • Evaluation methodology
      • Analytical model:
        • Parameter study
        • Tree characteristics
      • Simulation:
        • Parameter study
        • Detailed single run
      • Testbed evaluation:
        • Churn behavior
        • Accurate costs
    • Simulator – PeerfactSim.KOM
      • Delay: global network positioning model
      • Churn: based on KAD, exponential churn
    • Simulation Setup
      • N=10,000, exponential and KAD churn
  • 14. Simulation Run – N=10000, UI=60s, β=4
    • Precision: synchronized signal
      • Sine, periodicity: 1800s
      • Shows monitoring error and freshness
    • Results
      • Precise measurement
      • Age of information: ca. 200s
    • Costs: traffic overhead
      • Shows average load on peers
      • Load is well balanced
    • Results
      • Traffic overhead: 100–140 bytes/s
      • Calculation of average is churn-resistant
  • 15. Testbed Evaluation: Validation of Results
    • Results
      • Previous good results validated
      • Even 50% peer fail is not crucial
      • Short outliers due to joining peers
      • 3kb/s bandwidth consumption (UI=5s)
      • Average calculation not affected by churn
    • Testbed evaluation
      • Testing behavior under strong churn
      • Metrics: peer count and traffic overhead
    • Setup:
      • N =500 (on 37 PCs), UI =5 sec, β = 2
      • 10%, 20%, 50% and random churn
    10% 20% Random 50% 50%
  • 16. Agenda
    • Introduction
    • Overview on my System Management Approach
      • System Monitoring – SkyEye
      • System Management – SkyNet
    • P2P-based Online Social Networks
      • LifeSocial – Secure, Distributed, Controlled
    • Conclusions
  • 17. Control Theory in P2P Systems
    • Service quality of the p2p system
      • Application-specific metric intervals
      • Response time [100ms,400ms]
    • Goal
      • System automatically adapts to meet predefined Target metrics
    • Main idea
      • Research on viable approaches
      • Autonomic computing for p2p systems
    System Provider Users Direct setting of configuration Mechanisms on peers Global p2p system Network dynamics Peer heterogeneity Application shift Metric goals Controller Configuration New configuration Information dissemination Monitoring: information gathering Service quality
  • 18. Planning a new Configuration
    • Analysis and planning step
      • Detects metric violation
      • Step-wise adaptation of configuration
      • Approaching target metric interval
    • Changes need time
      • Analyze slope of metric history
      • Act only if changes settled
      • Prevent configuration oscillation
    ? Metric goal Current metric Parameters
  • 19. Re-Configuration of the System
    • Management protocol
      • Gather current system parameters
      • Distribute new parameter configuration
    • Approach
      • Extension of SkyEye.KOM
        • Gather statistics on parameter settings
      • Root: detects violation, plans new configuration
      • New configuration:
        • Spread with SkyEye.KOM in ACKs
        • Applied by peers locally
    • Planning step
      • Various approaches possible
      • My goal: closing the management cycle
    Statistics: metrics and paramters Global view on metrics & new parameters ? Local metric statistics Global metric statistics Metric Update Metric ACK Local parameter statistics New parameter settings
  • 20. Management of the Hop Count in Chord
    • Managing the behavior of Chord
      • Main metric: hop count
      •  Target metric: [ 7, 10 ]
      • Parameter: finger table size
    • Rules for violation of the goal metric
    • Evaluation goal
      • Target metrics are reached and held
      • Feasibility of management cycle
    • Simulation Setup
      • N =10000, UI =30s, β =4
    2207 2906 3485 2011 1622 1008 709 611 Hop Count Routing + 100 % Hop count too large - 10 % Hop count too small Finger table size Static Rule Approach
  • 21. Evaluation Results on SkyNet.KOM
      • Target metric approximation from 2 sides
      • Corresponding effects on lookup delay
    • Results
      • Metric interval [7,10] is reached and held
      • Management cycle is closed
    8 100 Hop Count 80 20 Finger Table Size 2 Steps Initial Start: too large 7.1 5.7 Hop Count 117 160 Finger Table Size 3 Steps Initial Start: too small
  • 22. Summary and Implications
    • Monitoring and management of p2p systems
      • Always up-to-date view on system statistics
      • Control of quality metrics through distributed control loop
    • Usage of p2p overlays “off the shelf”
      • For various scenarios / environments
    • Generalization
      • Applicable on any metrics and parameters
    • Research on
      • Identification and modeling of interdependencies
    • Monitoring and management
      • Towards p2p as reliable IT architecture
  • 23. Agenda
    • Introduction
    • Overview on my System Management Approach
      • System Monitoring – SkyEye
      • System Management – SkyNet
    • P2P-based Online Social Networks
      • LifeSocial – Secure, Distributed, Controlled
    • Conclusions
  • 24. What might be the next P2P application?
  • 25. Online Social Networks
    • What are ‘Online Communities’ technically?
        • Web-based applications (StudiVZ, Facebook, MySpace, Xing)
        • Provide different services for community members
    Plugin architecture Events Personal information and photos Friends Social interaction Games
  • 26. Goals and Motivations
    • Users want
    • Storing and searching for content
      • Profiles, friend lists, …
      • Pictures, shared “Wall” editing, …
    • User to user interaction
      • Chatting, VoIP, …
      • Games
    • Security
      • Access control on their data
      • Secure, confidential communication
    • Fun!
    • System providers want
    • High profit
      • Many users
      • Personalized advertisements
    • Low operational costs
      • For servers, electricity, cooling …
      • For personnel, legal issues
    • Controlled Quality of Service
      • To attract and keep users
      • Providing reliable, high quality services
    •  Money!
    Our goal: all of the above following the P2P paradigm
  • 27.
    • How do they work?
    • What is the architecture beneath?
  • 28. Current IT Paradigm: Client / Server
    • Web-based solution
      • Lots of operational costs!
      • Rough estimation: 1$/y per user
      • Facebook: 500M users !
    € € € €
  • 29. Alternatives? – Peer-to-Peer based Platforms
    • Idea:
      • Use capacities of user devices (Moore’s law!)
      • Interconnect users with p2p-overlay
      • Provide all functionality in a distributed way
      • Shift the load and costs to the users
    • Platforms:
      • LifeSocial.KOM
      • SafeBook, PeerSon
    € € €
  • 30. Our Solution: LifeSocial.KOM
    • Researched since end of 2007
      • Ca. 10 diploma / bachelor theses on this topic
      • Ca. 20 students programming plugins / GUIs in “Praktika” / project seminars
    • See: www.lifesocial.org
  • 31.
    • How does it look like?
    • What can you do?
  • 32. Agenda
    • Introduction
    • Overview on my System Management Approach
      • System Monitoring – SkyEye
      • System Management – SkyNet
    • P2P-based Online Social Networks
      • LifeSocial – Secure, Distributed, Controlled
    • Conclusions
  • 33. Screenshots  See: www.lifesocial.org
  • 34. See: www.lifesocial.org  See: www.lifesocial.org
  • 35. Screenshots  See: www.lifesocial.org
  • 36. Screenshots  See: www.lifesocial.org
  • 37.
    • How does this work?
    • What is the architecture beneath?
  • 38. Architecture Overview on LifeSocial.KOM
    • Extendable framework for user interface components
    • Stand-alone applications, core functionality and optional functionality of the system. Extendable.
    • Caching of data objects and messages
    • Monitoring of the quality of service
    • Low-delay user-to-user communication
    • Storage (store, modify, retrieve, delete)
    • Distributed storage and replication
    • Organization of nodes in an overlay network
    • Standard Internet protocols
  • 39. Challenges and Lessons Learned
    • Interconnecting the peers
      • Overlay needed for ID-based, consistent routing
      • Issues:
        • For academia (Chord, CAN)
        • Different purpose (Kademlia, unstructured overlays)
        • Homebrew: design and evaluation takes time
    •  FreePastry
    • Data Storage / Replication
      • Reliable + consistent data storage: read, write, update
      • Load balancing?
      • Even more complicated
    •  PAST, comes with FreePastry
      • ID-based storage and retrieval
  • 40. Document Types, Obvious Storage Keys
    • High granularity of stored data objects
    • Better load balancing of the resources
    • Used for
      • Atomic data: profiles, login info, “emails”
      • Linked lists: friend lists, groups, multicast
    • Allows for complex data structures
    Profile storage key p = “User_Kalman_Graffi” Name: Kalman Age: 27 University: Technische Universität Darmstadt  See: K. Graffi et al., “A Distributed Platform for Multimedia Online Communities” In: IEEE International Symposium on Multimedia '08 (IEEE ISM’09), December 2008.
  • 41. Data Positioning in the Network replica replica replica replica replica request responsibility range
  • 42. SECURITY
    • Security is 2nd most important
      • After efficiency!
    • Goals:
      • Authentification of hosts
      • Encrypted messaging
      • Access control lists (on sensible data)
    • Idea:
      • Use PublicKeys as NodeIDs
        •  allows instant authentication and encrypted communication
      • Encrypt all stored data with unique symmetric key
        • Encrypt the symmetric key for all privileged reader
        • Attach the ENCRYPTED symmetric key to the encrypted data
  • 43. Detailed Idea of Distributed Access Control
    • Step 1:
    • PeerID
    • = UserID
    • = PublicKey
    • = f(username,
    • passphrase)
    • Secure comm.:
    • - encrypted
    • - signed
    SharedItem objectID Header Privileged users Payload Signed CryptedItem objectID Key list userID A – key A userID B – key B userID C – key C Byte array containing encrypted SharedItem Encrpyted with … 5  See: K. Graffi et al., “Practical Security in P2P-based Social Networks” In: IEEE Local Computer Networks '09 (IEEE LCN’09), October 2009. Symmetric Key Pub User A Symmetric Key Pub User B Encrpyted with Pub User A Pub User B [userID A] = [userID B] = extract 1 Serialized and encrypted with symmetic key 2 userIDs are public keys 3 wrap symmetric key with public key 4
  • 44. Simple Idea of Distributed Access Control
    • How to provide Access Control in a distributed environment?
    • Goal: Assign read-rights on objects to privileged users
    • Mechanism: Sym. encrypted objects, asym. encrypted sym. keys
     See: K. Graffi et al., “Practical Security in P2P-based Social Networks” In: IEEE Local Computer Networks '09 (IEEE LCN’09), October 2009. For
  • 45.
    • When it is distributed,
    • how do you know that it works?
    • What is the quality?
  • 46. Monitoring and Evaluation
    • Integration of a monitoring solution
      • Totally distributed, precise and cheap
    • Global system statistics
      • Statistics on
        • CPU / bandwidth usage
        • Data retrieval delays
        • Messages sent / received
        • Number of peers
        • Objects in Cache
        • Friends and clustering coefficient
      • Statistical information: avg, min, max, standard dev., sum,...
     See: K. Graffi et al., “Monitoring and Management of Structured Peer-to-Peer Systems” In: IEEE Peer-to-Peer Computing '09 (IEEE P2P’09), September 2009.
  • 47. Some Statistics (1)
  • 48. Some Statistics (2)
  • 49. Some Statistics (3)
  • 50. Plugin Architecture Overview
  • 51. See: www.lifesocial.org  See: www.lifesocial.org
  • 52. Summary
    • IT solutions for social networks
      • Currently centralized and very costly
      • Scales only with high monetary invests
    • Distributed, p2p-based platforms
      • Data storage is totally distributed
      • Costs are shared among the users
    • LifeSocial.KOM
      • Operational prototype
      • Secure, reliable storage and messaging
      • Monitoring mechanism to observe (and control) the quality of service
      • Rich, extendable functionality through Plugin-based architecture
      • See videos on www.lifesocial.org
    • Analysis of needs:
    • Users want
      • Storing and searching for content
      • User to user interaction
      • Security
    • System provider want
      • Low operational costs
      • Controlled quality of service
      • High profit
    • Next steps:
      • Integrate management mechanisms
      • Run Internet-wide beta-test
      • Deploy
  • 53. Issues and Challenges in Academia
    • Engineering a prototype is not considered as research
    • Programming effort hard to mount
    • How to test large-scale distributed systems?
    • Successfull standalone P2P application known?
      • Filesharing?
      • Skype?  is it working now?
      • ???
    • Who needs P2P – we have the cloud!
      • Guaranteed quality! Controllable costs!
      • Easier to maintain / operate
  • 54. Summary
    • System management: SkyNet.KOM
      • Reach and hold preset metric intervals
      • Through monitoring and self-configuration
    • System monitoring: SkyEye.KOM
      • Global view on statistics of running system
      • Precise yet cost effective monitoring
    • Resource management
      • Convenient access to peer capacities
      • Reliable capacity reservation
    • Application scenario: LifeSocial
      • P2P-based online social network
      • Demonstration of feasibility
  • 55. Questions? Have a look at: www.lifesocial.org www.skynet-project.com www.kom.tu-darmstadt.de Does my p2p system work?
  • 56. Backup Slides
  • 57. Monitoring of P2P Systems
    • System view:
      • Global statistics on set of metrics
      • Avg., std. dev., sum, min., max.
      • Long list of aggregatable metrics
    • Example:
      • Global statistics on bandwidth usage
    • Use:
      • Observe quality (performance, costs) of running p2p system
    • Peer view:
      • Overview on the peers’ capacities
      • Peer specific capacity information
      • Allows capacity-based peer search
    • Example:
      • Bandwidth capacities of a single peer
    • Use:
      • Mechanisms find desired capacities
    Query for 2 peers: Online time < 60m Peers B, D
  • 58. SkyEye.KOM: Protocols
  • 59. Interdependencies: Finger Table Size, Contacts, Hop Count, Lookup Delay
    • Contacts ~~ log(FT Size )
    • Hop Count !~ log Contacts (N)
    • Approach:
      • Modify FT Size  effect on Contacts
      • Modify Contacts  effect on Hop Count
  • 60. Selected Results from the Testbed Evaluation
  • 61. Comparison of Benchmark Signals
  • 62. Modules in SkyEye.KOM
  • 63. SkyEye.KOM – Variants
    • Variant: synchronized updates
    • Idea:
      • Loosely synchronize updates messages
      • Push results once global view is created
      • Tradeoff: freshness vs. costs
    • Approach:
      • Push with ACKs: synchronization delay
      • Peers adapt their update offset
      • Updates processed in a row
      • Push global view with “special-ACK”
    • Variant: smoothing of results
    • Idea:
      • Eliminate monitoring outliers with history-based smoothing: median / exponential
      • Tradeoff: freshness vs. less outliers
    • Approach:
      • History of measurements: H = {m 1 ,…,m h }
      • Final measure s H = smooth(H)
      • Median: s H = m (|H|+1)/2 with sorted m i
      • Exponential smoothing: s H = α m h + (1- α ) s H-1
  • 64. Quality Properties of SkyEye.KOM
    • Applicability
      • Applicable on every (KBR-compatible) structured p2p overlay
      • Independent of any application
      • Unified ID space, using core DHT functions
    • Robustness
      • Handling Churn, coping with link losses
      •  If peer fails: automatically replaced in the DHT
      •  Updates are routed to new peer for aggregation
    • Scalability
      • Scaling in terms of participating peers and exchanged information
      • Low costs per peer: bound tree node degree (1+ β)
      • Costs independent of node’s tree position, ~1Kb/update
    • Performance
      • High precision, low outliers
      • Information age limited by tree depth, O(log β (N))
      •  Influenced by update period
    • Retrievability
      • Monitoring all peers in the network
      •  All peers are in the monitoring tree
    • Efficiency
      • Lightweight solution, low complexity: easier to use, more robust
      • Just two message types: Update, ACK
      • No signaling complexity and overhead
  • 65. Additional Slides on Management
  • 66. Comparison of C/S Solution with SkyEye.KOM
  • 67. Overview on Quantity of Monitored Statistics
    • Total metric quantity:
      • Simulation: 370+10•Depth
      • Prototype: 255+20•Depth
  • 68. Comparison of Benchmark Signals
    • Benchmarking signals
      • Sine and ZigZag, periodicity: 1800s=30m
      • Synchronized injection of signals
      • Allows to benchmark monitoring precision
      • Age of information: around 200s
    • Freshness
      • = Average age of aggregated information = ½ of time to gather and disseminate = ½ log β (N) · UI = ½ log 4 (10000) · 60s = ½ · 398s = 199s
      • Model and simulations match
  • 69. Parameter Studies: Identification of Tradeoffs
    • Varied parameters
      • Update interval UI: 15, 30, 60, 120, 240s
      • Branching factor β = 2, 4, 8
      • Number of peers N = 1000, 10000
      • (Mean) costs depend on UI (not β or N)
    • Tradeoff
      • Monitoring precision (of sums) vs. costs
        • Monitoring error depends on UI , β, N
        • Low relative error requires more traffic
      • Increase effort until precision is sufficient
  • 70. Management Goals
    • Service quality of the p2p system
      • Application-specific metric intervals
      • Response time [100ms,400ms]
    • Goal
      • System automatically adapts to meet predefined Target metrics
    • Main idea
      • Research on viable approaches
      • Autonomic computing for p2p systems
    System Provider Users Direct setting of configuration Mechanisms on peers Global p2p system Network dynamics Peer heterogeneity Application shift Metric goals Controller Configuration New configuration Information dissemination Monitoring: information gathering Service quality
  • 71.