advanced network services: p2p voip, location-based services and self-managing server farms
DESCRIPTION
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. Overview. Quick overview of Internet Real-Time research group - PowerPoint PPT PresentationTRANSCRIPT
March 31, 2005 Thomson 1
Advanced Network Services: P2P VoIP, Advanced Network Services: P2P VoIP, location-based services and self-location-based services and self-managing server farmsmanaging server farms
Henning Schulzrinne(and members of the IRT Lab)
Dept. of Computer ScienceColumbia University
New York, NY
March 31, 2005 Thomson 2
OverviewOverview 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 Thomson 3
Overall IRT lab goalsOverall 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 Thomson 4
IRT research topicsIRT 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
March 31, 2005 Thomson 5
Server-based vs peer-to-Server-based vs peer-to-peerpeer
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 Thomson 6
P2P-SIPP2P-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 Thomson 7
P2P-SIPP2P-SIPDesign AlternativesDesign Alternatives
65a1fc
d13da3
d4213f
d462bad467c4
d471f1
d46a1c
Route(d46a1c)
18
14
21
3238
58
47
10
24 30
54
38
42
Use DHT in server farm
Use DHT for all clients; But some are resource limited
Use DHT among super-nodes
servers
clients
1
10
2430
54
38
March 31, 2005 Thomson 8
P2P-SIPP2P-SIPNode architecture: registrar, proxy, user Node architecture: registrar, proxy, user agentagent
DHT communication using SIP REGISTER Known node: sip:[email protected] Unknown node: sip:[email protected] User: sip:[email protected]
User interface (buddy list, etc.)
SIPICE RTP/RTCPCodecs
Audio devicesDHT (Chord)
On startup
Discover
User location
Multicast REGPeer found/Detect NAT
REG REG, INVITE,MESSAGE
Signup,Find buddies
JoinFind
Leave
On resetSignout,transfer
IM,call
March 31, 2005 Thomson 9
P2P-SIPP2P-SIPImplementationImplementation
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)
1
11
9
30
26
31
15
29
25
19
31
26
March 31, 2005 Thomson 10
Context-aware Context-aware communicationcommunication
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 preferenceslocation location-based call routing
location eventsactivity/availability “rich” presencesensor data (mood, bio)
not yet, but similar in many aspects to location data
March 31, 2005 Thomson 11
Service creationService creation
March 31, 2005 Thomson 12
Web HotspotsWeb 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 Thomson 13
The ChallengeThe 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 Thomson 14
Our ApproachOur 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 Thomson 15
DotSlash for Dynamic DotSlash for Dynamic ContentContent Remove the web server bottleneck Dynamic Script Replication LAMP configuration
origin server database
rescue server
MySQLApache
Apache
(5) PHP (6)
(1)
(2)(3) (4)Client
(7)(8)
March 31, 2005 Thomson 16
Increasing Max Request Increasing Max Request Rate: RRate: R
No rescue: R=118
With rescue: R=245#rescue servers: 9
Origin (HC) DB (HC)Rescue (LC)
Configuration:Rescue (LC)Rescue (LC)Rescue (LC)Rescue (LC)Rescue (LC)Rescue (LC)Rescue (LC)Rescue (LC)
245/118>2
CPU: Origin=100% DB=45%
CPU: Origin=55% DB=100%
March 31, 2005 Thomson 17
ConclusionConclusion 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