Advanced Network Services: P2P VoIP, location-based services and self-managing server farms

1. Advanced Network Services: P2P VoIP, location-based services and self-managing server farms Henning Schulzrinne (and members of the IRT Lab) Dept. of Computer Science Columbia University New York, NY Thomson

2. Overview • Quick overview of Internet Real-Time research group • Transition in multimedia services • “make the phone ring”  self-configuring, adaptive, “invisible” systems • P2P VoIP • Location-based services • Autonomic web servers Thomson

3. Overall IRT lab goals • Reliable, flexible and programmable communication infrastructure for Internet-based collaboration applications • Systematic evaluation by analysis and simulation • Demonstrate capability via prototypes • Contribute protocols to standardization • Convert prototypes into products and open-source software • Train students at all levels in current Internet research and engineering Thomson

4. Internet telephony and multimedia CINEMA – VoIP/multimedia and collaboration system QoS measurements network application reliability performance and server architecture APIs for SIP IM and presence systems ubiquitous computing using SIP application sharing emergency services (“911”) SIP security reputation systems, spam firewalls service creation languages CPL LESS Mobile and wireless systems 802.11 handoff acceleration 802.11 VoIP performance improvements personal, service and session mobility Peer-to-peer messaging  7DS Service and event discovery (GloServ) Generic signaling protocols (GIMPS) for QoS, NAT/FW, … Autonomic computing service discovery  mSLP automated server pooling  DotSlash IRT research topics Thomson

5. C C P P S C C P P C P Server-based vs peer-to-peer • Server-based • Cost: maintenance, configuration • Central points of failures • Managed SIP infrastructure • Controlled infrastructure (e.g., DNS) • Peer-to-peer • Robust: no central dependency • Self organizing, no configuration • Scalability ? Thomson

6. P2P-SIP • Differences to proprietary Skype architecture • Robust and efficient lookup using DHT • Interoperability • DHT algorithm uses SIP protocol messages • Hybrid architecture • First try DNS NAPTR/SRV • if no SIP server there, then lookup in SIP+P2P • Unlike file-sharing applications • Data storage, caching, delay, reliability • Disadvantages • Lookup delay and probabilistic security Thomson

7. d471f1 1 d467c4 d46a1c 8 d462ba 58 54 d4213f 14 10 47 21 Route(d46a1c) d13da3 42 38 32 65a1fc 38 24 30 P2P-SIPDesign Alternatives servers 1 54 10 38 24 30 clients Use DHT in server farm Use DHT for all clients; But some are resource limited Use DHT among super-nodes Thomson

8. Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP P2P-SIPNode architecture: registrar, proxy, user agent • DHT communication using SIP REGISTER • Known node: sip:15@192.2.1.3 • Unknown node: sip:17@sippeer.net • User: sip:alice@example.com Signup, Find buddies IM, call On reset Signout, transfer On startup Leave Find Join REG, INVITE, MESSAGE Peer found/ Detect NAT Multicast REG REG Thomson

9. 1 30 26 9 19 11 P2P-SIPImplementation 31 • sippeer: C++, Linux, Chord • Nodes join and form the DHT • Node failure is detected and DHT updated • Registrations transferred on node shutdown • only need extension for avoiding outbound proxy confusion • Co-located “classical” UA can use sippeer service with a P2P “adaptor” (built) 29 31 25 26 15 Thomson

10. Context-aware communication • context = “the interrelated conditions in which something exists or occurs” • anything known about the participants in the (potential) communication relationship • both at caller and callee: Thomson

11. Service creation Thomson

12. Web Hotspots Web Server Internet • A well-identified problem • Flash crowds, the Slashdot effect • 15 minutes of fame • Examples • Slashdotting, featured Google search, special events, breaking news, … Thomson

13. The Challenge • Short-term dramatic surge of request rate • Large & quick increase • Last for a short period • Existing mechanisms are not sufficient • Capacity planning, CDNs • Good for long term, not cost-effective for hotspots • Caching • Not fully controlled by origin server • Service degradation, admission control • Last resort, but only denies service to some Thomson

14. DotSlash counteract the Slashdot effect Rescue system Triggered automatically when load spikes Mutual-aid model  spread load across large server population Cost effective for rare events For both static (HTML) and dynamicallygenerated (PHP + mySQL) web pages Automated rescue process Self-configuring: build an adaptive distributed web server system on the fly Techniques: service discovery, dynamic virtual hosting, adaptive overload control, dynamic script replication Also applicable to other services SIP, SMTP, RTSP, … Our Approach Thomson

15. DotSlash for Dynamic Content • Remove the web server bottleneck • Dynamic Script Replication • LAMP configuration Apache MySQL origin server database (1) Client (2) (4) (5) PHP (6) (3) (7) rescue server (8) Apache Thomson

16. Increasing Max Request Rate: R Configuration: Rescue (LC) Rescue (LC) Rescue (LC) Rescue (LC) Rescue (LC) Rescue (LC) Origin (HC) Rescue (LC) DB (HC) Rescue (LC) Rescue (LC) No rescue: R=118 CPU: Origin=100% DB=45% With rescue: R=245 #rescue servers: 9 CPU: Origin=55% DB=100% 245/118>2 Thomson

17. Conclusion • Research in systems that automate routine functions • making them invisible to users • Examples: • automated call control and presence • autonomic setup of server clusters • self-configuring creation of collaboration networks  P2P SIP Thomson