March 31, 2005Thomson1 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

March 31, 2005 Thomson2 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

March 31, 2005 Thomson3 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

March 31, 2005 Thomson4 IRT research topics 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 handoff acceleration 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

March 31, 2005 Thomson5 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 ? C C C C C S P P P P P

March 31, 2005 Thomson6 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

March 31, 2005 Thomson7 P2P-SIP Design Alternatives 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) Use DHT in server farm Use DHT for all clients; But some are resource limited Use DHT among super-nodes servers clients

March 31, 2005 Thomson8 P2P-SIP Node architecture: registrar, proxy, user agent DHT communication using SIP REGISTER Known node: Unknown node: User: User interface (buddy list, etc.)SIPICERTP/RTCPCodecsAudio devicesDHT (Chord) On startup DiscoverUser location Multicast REGPeer found/ Detect NAT REG REG, INVITE, MESSAGE Signup, Find buddies Join Find Leave On reset Signout, transfer IM, call

March 31, 2005 Thomson9 P2P-SIP Implementation 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)

March 31, 2005 Thomson10 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: timeCPL, LESS = service creation languages capabilitiescaller preferences locationlocation-based call routing location events activity/availability“rich” presence sensor data (mood, bio)not yet, but similar in many aspects to location data

March 31, 2005 Thomson11 Service creation

March 31, 2005 Thomson12 Web Hotspots A well-identified problem Flash crowds, the Slashdot effect 15 minutes of fame Examples Slashdotting, featured Google search, special events, breaking news, … Web Server Internet

March 31, 2005 Thomson13 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

March 31, 2005 Thomson14 Our Approach 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 dynamically generated (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, …

March 31, 2005 Thomson15 DotSlash for Dynamic Content Remove the web server bottleneck Dynamic Script Replication LAMP configuration origin serverdatabase rescue server MySQLApache (5) PHP(6) (1) (2) (3) (4) Client (7) (8)

March 31, 2005 Thomson16 Increasing Max Request Rate: R No rescue: R=118 With rescue: R=245 #rescue servers: 9 Origin (HC)DB (HC) Rescue (LC) Configuration: Rescue (LC) 245/118>2 CPU: Origin=100% DB=45% CPU: Origin=55% DB=100%

March 31, 2005 Thomson17 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