1 / 24

Peer-to-peer systems for autonomic VoIP and web hotspot handling

Peer-to-peer systems for autonomic VoIP and web hotspot handling. Kundan Singh, Weibin Zhao and Henning Schulzrinne Internet Real Time Laboratory Computer Science Dept., Columbia University, New York http://www.cs.columbia.edu/IRT/p2p-sip. P2P for autonomic computing.

jana
Download Presentation

Peer-to-peer systems for autonomic VoIP and web hotspot handling

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. Peer-to-peer systems for autonomic VoIP and web hotspot handling Kundan Singh, Weibin Zhao and Henning Schulzrinne Internet Real Time Laboratory Computer Science Dept., Columbia University, New York http://www.cs.columbia.edu/IRT/p2p-sip

  2. P2P for autonomic computing • Autonomic at the application layer: • Robust against partial network faults • Resources grow as user population grows • Self-configuring • Traditional p2p systems • file storage • motivation is often legal, not technical, efficiency • usually unstructured, optimized for Zipf-like popularity • Other p2p applications: • Skype demonstrates usefulness for VoIP  • identifier lookup • NAT traversal: media traversal • OpenDHT (and similar) as emerging common infrastructure? • Non-DHT systems with smaller scope  web hotspot rescue • Network management (see our IRTF slides) Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  3. Aside: autonomic characteristics • Autonomic characteristics (self-*) determine success for consumer applications: • web-based email programs • consumer IM • Skype • Apple Rendezvous, DHCP • IETF and IEEE slowly starting to take note: • old techniques (ICMP) no longer working • netconf: XML-based network configuration instead of CLI and (rarely) SNMP • XCAP: generic XML configuration manipulation • SIP auto-configuration work • IEEE 802.1 network discovery (LLDP, …) • concerns about network complexity Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  4. What is SIP? Why P2P-SIP? (1) REGISTER (2) INVITE alice Peer-to-peer network Alice 128.59.19.194 (3) 128.59.19.194 No central server, but more lookup latency (1) REGISTER alice@columbia.edu =>128.59.19.194 (2) INVITE alice@columbia.edu (3) Contact: 128.59.19.194 Alice’s host 128.59.19.194 Bob’s host columbia.edu Problem in client-server: maintenance, configuration, controlled infrastructure Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  5. How to combine SIP + P2P? SIP-using-P2P Replace SIP location service by a P2P protocol P2P-over-SIP Additionally, implement P2P using SIP messaging P2P network REGISTER INVITE alice FIND INSERT P2P-SIP overlay Alice 128.59.19.194 INVITE sip:alice@128.59.19.194 Alice 128.59.19.194 Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  6. Deployment scenarios P P P P P P P P P P P P P P P P2P database P2P proxies P2P clients Zero-conf server farm; Trusted servers and user identities Global, e.g., OpenDHT; Clients or proxies can use; Trusted deployed peers (?) Plug and play; May use adaptors; Untrusted peers Interoperate among these! Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  7. Hybrid architecture • Cross register, or • Locate during call setup • DNS, or • P2P-SIP hierarchy Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  8. What else can be P2P? • Rendezvous/signaling (SIP) • Configuration storage • Media storage (e.g., voice mail) • Identity assertion (?) • PSTN gateway (?) • NAT/media relay (find best one) Trust models are different for different components! Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  9. What is our P2P-SIP? • Unlike server-based SIP architecture • Unlike proprietary Skype architecture • Robust and efficient lookup using DHT • Interoperability • DHT algorithm uses SIP communication • Hybrid architecture • Lookup in SIP+P2P • Unlike file-sharing applications • Data storage, caching, delay, reliability • Disadvantages • Lookup delay and security Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  10. Implementation: SIPpeer • Platform: Unix (Linux), C++ • Modes: • Chord: using SIP for P2P maintenance • OpenDHT: using external P2P data storage • Scenarios: • P2P client, P2P proxies • Adaptor for existing phones • Cisco, X-lite, Windows Messenger, SIPc • Server farm Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  11. Implementation: SIPpeer Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP Signup, Find buddies IM, call On reset Signout, transfer On startup Leave Find Join REGISTER, INVITE, MESSAGE Peer found/ Detect NAT Multicast REGISTER REGISTER SIP-over-P2P P2P-using-SIP Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  12. SIP p2p summary and open issues Advantages Out-of-box experience Robust catastrophic failure-unlikely Inherently scalable more with more nodes Status IETF involvement Columbia SIPpeer Security issues Trust, reputation malicious node, sybil attack SPAM, DDoS Privacy, anonymity (?) Other issues Lookup latency,proximity P2P-SIP vs SIP-using-P2P Why should I run as super-node? http://www.p2psip.org and http://www.cs.columbia.edu/IRT/p2p-sip Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  13. DotSlash: An Automated Web Hotspot Rescue System Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  14. The Problem • Web hotspots • Also known as flash crowds or the Slashdot effect • Short-term dramatic load spikes at web servers • Existing mechanisms are not sufficient • Over-provisioning • Inefficient for rare events • Difficult because the peak load is hard to predict • CDNs • Expensive for small web sites that experience the Slashdot effect Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  15. The Challenges • Automate hotspot handling • Eliminate human intervention to react quickly • Improve availability during critical periods (“15 minutes of fame”) • Allocate resources dynamically • Static configuration is insufficient for unexpected dramatic load spikes • Address different bottlenecks • Access network, web server, application server, and database server Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  16. Our Approach • DotSlash • An automated web hotspot rescue system by building an adaptive distributed web server system on the fly • Advantages • Self-configuring • Service discovery, adaptive control, dynamic virtual hosting • Scalable, easy to use, and transparent to clients Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  17. DotSlash Overview • Rescue model • Mutual aid community using spare capacity • Potential usage by web hosting companies • DotSlash components • Workload monitoring • Rescue server discovery • Load migration (request redirection) • Dynamic virtual hosting • Adaptive rescue and overload control Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  18. Handling Load Spikes • Request redirection • DNS-RR: reduce arrival rate • HTTP redirect: increase service rate • Handle different bottlenecks Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  19. Rescue Example • Cache static content client1 (2) HTTP redirect (4) (3) (1) reverse proxy origin server rescue server (3) (4) (1) client2 DNS server (2) DNS round robin Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  20. Rescue Example (2) • Replicate scripts dynamically Apache PHP origin server database server (1) (6) PHP client (2) (5) PHP (4) (3) (7) rescue server (8) MySQL Apache Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  21. Rescue Example (3) • Cache query results on demand database server query result cache origin server client data driver database server query result cache rescue server data driver Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  22. Implementation • Based on LAMP (Linux, Apache, MySQL, PHP) • Apache module (mod_dots), DotSlash daemon (dotsd), DotSlash rescue protocol (DSRP) • Dynamic DNS using BIND with dot-slash.net • Service discovery using enhanced SLP Apache mod_dots SHM dotsd other dotsd DSRP HTTP client SLP DNS BIND mSLP Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  23. Caching TTL and Hit Ratio (Read-Only) Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

  24. CPU Utilization (Read-Only) Dagstuhl Seminar on Autonomic Systems (Jan. 2006)

More Related