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

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

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

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

4
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
• 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

5
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 ?

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 SIPP2P
• Unlike file-sharing applications
• Data storage, caching, delay, reliability
• Disadvantages
• Lookup delay and probabilistic security

7
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
8
P2P-SIPNode architecture registrar, proxy, user
agent
Signup, Find buddies
IM, call
On reset
Signout, transfer
On startup
Leave
Find
Join
REG, INVITE, MESSAGE
Multicast REG
Peer found/ Detect NAT
REG

• DHT communication using SIP REGISTER
• Known node sip15_at_192.2.1.3
• Unknown node sip17_at_sippeer.net
• User sipalice_at_example.com

9
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
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

time CPL, LESS service creation languages
capabilities caller preferences
location location-based call routing location events
activity/availability rich presence
sensor data (mood, bio) not yet, but similar in many aspects to location data
11
Service creation
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,

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

14
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,

15
DotSlash for Dynamic Content

• Remove the web server bottleneck
• Dynamic Script Replication
• LAMP configuration

MySQL
Apache
origin server
database
(1)
(2)
Client
(5) PHP
(6)
(4)
(3)
(7)
rescue server
(8)
Apache
16
Increasing Max Request Rate R
Configuration
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
Origin (HC)
DB (HC)
Rescue (LC)
Rescue (LC)
Rescue (LC)
No rescue R118
CPU Origin100 DB45
With rescue R245
rescue servers 9
CPU Origin55 DB100
245/118gt2
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