1 / 21

H. deMeer and K. Tutschku

H. deMeer and K. Tutschku. An Application-level Active Networks Based Architecture for the Performance Management of Peer-to-Peer Services. OPENSIG 2001 Workshop: „Next Generation Network Programming“ London, 24./25. September 2001. Overview. What is Peer-to-Peer Networking?

neo
Télécharger la présentation

H. deMeer and K. Tutschku

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. H. deMeer and K. Tutschku An Application-level Active Networks Based Architecture for the Performance Management of Peer-to-Peer Services OPENSIG 2001 Workshop: „Next Generation Network Programming“ London, 24./25. September 2001

  2. Overview • What is Peer-to-Peer Networking? • Selected P2P Architectures • Resource and Performance Management of P2P Services • Goals and Approaches • ALAN-based Architecture for P2P Performance Management • ALAN superpeers • superpeer implementation • Conclusion H. DeMeer / K. Tutschku

  3. Peer-to-Peer: Introduction • Tremendous industrial hype and strong research attention: • Napster: 40 million user deployments in two years • O’Reilly P2P conference, March 2001 / panel at InfoCom 2001 • Typical applications: • file sharing (Napster, Gnutella) • group collaboration (Jxta [Sun], Groove) • distributed storage (PAST/Farsite [Microsoft], Chord [MIT]) • distributed computation (SETI@home) H. DeMeer / K. Tutschku

  4. Peer-to-Peer: Features • Basic features: • distributed architecture • composed of voluntary and ad-hoc membership of peers • symmetric roles (serving, downloading, routing) throughout system: servent= server + client • weak connectivity: handles variable connectivity as the norm available at the edges of the Internet • Hope: • instant services, no cost of administration, re-use of resource • quality and robustness scales with size of infrastructure • Many many challenges: • trust, semantics, location, efficiency/performance, operation, robustness H. DeMeer / K. Tutschku

  5. Selected P2P Applications - SETI@home • Purpose: • uses idle CPU cycles on ordinary PCs for massively parallel analysis of extraterrestrial radio signals • Architecture: • central SETI@home server distributes data • analyses done locally by SETI@home screen saver • Classification (according K. Kant): • (scattered, organized, isolated, non_RT) • Similar architectures: • Napster H. DeMeer / K. Tutschku

  6. Selected P2P Applications - Gnutella (1) • Purpose: • distributed and anonymous file sharing • Servents operate completely without central control • Exploits unused storage on edge nodes • Characteristics: • message broadcasting for node discovering and search requests; • forming of overlay network; connecting: join the “several known hosts” • user data transfer: store and forward using HTTP • Classification: • (scattered, scattered, isolated, non_RT) H. DeMeer / K. Tutschku

  7. Selected P2P Applications - Gnutella (2) Ping Ping Ping • Call-and-Response protocol mechanism: node discovery • flooding of PING/PONG messages; broadcasting range limited by TTL counter . • short time memory of messages already seen; prevents re-broadcasting; GUIDs to distinguish msg G-Node G-Node Ping Pong H. DeMeer / K. Tutschku

  8. Selected P2P Applications - Gnutella (3) G-Node C G-Node D Node A • Call-and-Response protocol mechanism: search query / download 1) Node A asks Node B for data. 3) B forwards the request to its neighbors. G-Node A G-Node B 4) These return any match- ing info. 6) B returns matching info 5) B looks up source of request. 2) B keeps a record that A initiated the request 7) A may initiate download using HTTP • search: Query/Query-Response (flooding!) • download: GET/PUSH. (direct transmission) H. DeMeer / K. Tutschku

  9. Selected P2P Applications - Gnutella (4) • Limitations/Difficulties: • unstable/loose connectivity of the servents • performance management difficult • scalability: e.g. TTL=10, every node broadcasts to six others • msg; problem in huge networks • low TTL, low search horizon • denial-of-service attacks • Challenges: • Robustness • availability of resources; hard to predict the consequences of failures; administrative actions • Performance • bandwidth consumption; scalability; end-to-end quality-of-service; overload / network planning H. DeMeer / K. Tutschku

  10. P2P Resource/Performance Management • Goals: • maximizes a peer’s utility to the overall system while minimizing its potential threat • increase stability • introduce administrative rules • Problems to tackle: • resource discovery/allocation • reduction of synchronization traffic • aggregation and self-organization • simple overuse (e.g. freeloaders) • bandwidth/latency/packet loss H. DeMeer / K. Tutschku

  11. P2P Resource/Performance Management • Approaches: • enhance P2P protocols: • topology construction (JXTA) • sophisticated group multicasting (Lee et al., 2001) • accountability: • used in Free Haven project / Mojo Nation • restricting access: “micro payments” • selecting favored users: reputation system • superpeers: • Morpheus/KaZaA, Clip2’s Gnutella Reflector • Virtual Active Peer • based on Application-Level Active Networks H. DeMeer / K. Tutschku

  12. “Virtual Active Peer” Architecture • Superpeer: • layering provides control capability • facilitates limited topology management • Application-level Routing • optimizes for different metrics (e.g. privacy, policies, latency) • provides smart multicast, caching and replication capabilities H. DeMeer / K. Tutschku

  13. Application Level Active Networks (ALAN) • proposed by Fry and Ghosh [1999] • active elements on application level • system consists of proxylets and EEPs: • proxylets: • dynamic code modules specifying the protocol handling • single copy stored on central server; identified by reference (URL) • EEPs: • execution environment for proxylets; located at strategic points • proxylets ctrl: load, run, modify, stop • dynamic deployment • system proxylets: routing, discovery, and error handling H. DeMeer / K. Tutschku

  14. ALAN – Architecture Monitor Interface Execution Environment for Proxylets (EEP) Protocol Server Proxylet Server Proxylet Gnutella Active Peer Proxylet Peer Control Interface Peer Super- peer Gnutella Mon. Interface Gnutella Ctrl Interface H. DeMeer / K. Tutschku

  15. Superpeer Architecture Gnutella Active Proxylet Application Optimization Layer Virtual Ctrl Cache Network Optimization Layer • Application Optimization Layer: • management of peer-to-peer relation on application level; using application level performance metrics • enforcement of connections with predictable performance • Virtual Control Cache: • application-level aggregation capability • facilitates differentiation • Network Optimization Layer: • optimal mapping wrt. transport network capabilities • enables dynamic traffic engineering H. DeMeer / K. Tutschku

  16. Superpeer Architecture Gnutella Active Proxylet Application Optimization Layer Topology Ctrl Policy Ctrl Performance Monitoring Virtual Ctrl Cache Network Optimization Layer • Topology control: • set-up of stable connec-tions to other EEPs • instantiation of new active peers at other EEPs • termination of Gnutella connections • distribution of announce-ments (ping msg) • Policy control: • user, network, or servent based • TTL / connectivity • prioritization / localiza-tion • Perf. Mon: • query traffic • ping/pong traffic • robustness of connectivity • response time • throughput H. DeMeer / K. Tutschku

  17. P2P JTella Dependencies GNUTellaConnection host, port Router ConnectionList, HostCache HostCache HostFeed IncomingConnectionManager Router, ConnectionList, ConnectionData SearchMonitorSession MessageReceiver OutgoingConnectionManager Router, ConnectionList, ConnectionData KeepAliveThread ConnectionData OriginateTable MessageReceiver ServerSocket BoundedQueuemessageQueue NodeConnection RouteTable queryhit RouteMessage HostCache RouteTablequery Message esp.Ping-, Pong-, Push-, Query- and QueryReplyMessage StarterPool RouteTablepings Vector searchReceivers VectorpushReceivers • Active Peer Proxylet: • based on JTella 0.6 API • full Gnutella routing capability • layered architecture • on-going implementation Gnutella Proxylet (Application Optimization Layer) H. DeMeer / K. Tutschku

  18. Self-Organization • active peers topology control permits local self-organization • e.g. accepting only peers with similar response time • forming of zones of similar performance • proxylet ctrl permits initiation of new active peers • superpeer architecture able adapt to to spatially varying performance condition H. DeMeer / K. Tutschku

  19. Approach to the Management of Wireless Ad-hoc Networks • Wireless ad-hoc networks: • highly distributed architecture • weak relationship between participating nodes • highly varying link performance • constantly changing set of moving/dis-appearing nodes • highly dependent on routing • forming of zones of similar performance • based on radio link performance metrics H. DeMeer / K. Tutschku

  20. Conclusion & Outlook • P2P networking is a promising paradigm for services operating at the edges of the network • weak connectivity of P2P services challenges the resource and performance management • ALAN-based “Virtual Active Peer” approach • combines the advantages of distributed and centralized ctrl architectures • facilitates methods to increase service stability and service performance • permits the forming of zones of equal performance • Outlook: • performance management schemes require new models • networks dynamics: what is best node to connect to? residual time of servents in the system? • combined synchronization/user data traffic model? H. DeMeer / K. Tutschku

  21. Thank you Q & A End of talk H. DeMeer / K. Tutschku

More Related