Peertopeer systems for autonomic VoIP and web hotspot handling

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)

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

4
What is SIP? Why P2P-SIP?
(1) REGISTER alice_at_columbia.edu
gt128.59.19.194
(2) INVITE alice_at_columbia.edu
(3) Contact 128.59.19.194
Alices host 128.59.19.194
Bobs host
columbia.edu
Problem in client-server maintenance,
configuration, controlled infrastructure
5
How to combine SIP P2P?

• P2P-over-SIP
• Additionally, implement P2P using SIP messaging

• SIP-using-P2P
• Replace SIP location service by a P2P protocol

P2P network
REGISTER
INVITE alice
FIND
INSERT
P2P-SIP overlay
Alice 128.59.19.194
INVITE sipalice_at_128.59.19.194
Alice 128.59.19.194
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!
7
Hybrid architecture

• Cross register, or
• Locate during call setup
• DNS, or
• P2P-SIP hierarchy

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

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

11
Implementation SIPpeer
Signup, Find buddies
IM, call
On reset
Signout, transfer
On startup
Leave
Find
Join
REGISTER, INVITE, MESSAGE
Multicast REGISTER
Peer found/ Detect NAT
REGISTER
SIP-over-P2P
P2P-using-SIP
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
13
DotSlash An Automated Web Hotspot Rescue System

• Weibin Zhao
• Henning Schulzrinne
• Department of Computer Science
• Columbia University

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

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

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

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

18
Handling Load Spikes

• Request redirection
• DNS-RR reduce arrival rate
• HTTP redirect increase service rate
• Handle different bottlenecks

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
20
Rescue Example (2)

• Replicate scripts dynamically

Apache
PHP
origin server
database server
(1)
(6) PHP
client
(5) PHP
(2)
(4)
(3)
(7)
rescue server
(8)
MySQL
Apache
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
22
Server States
Origin server Get help from others
SOS state
Allocate rescue server
Release all rescues
Normal state
Accept SOS request
Shutdown all rescues
Rescue server Provide help to others
Rescue state
23
Adaptive Overload Control

• Objective
• CPU/network in desired load region
• Origin server
• Allocate/release rescue servers
• Adjust redirect probability
• Rescue server
• Accept SOS requests
• Shutdown rescues
• Adjust allowed redirect rate

24
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

SHM
other dotsd
Apache
dotsd
mod_dots
DSRP
HTTP
client
SLP
DNS
BIND
mSLP
25
Caching TTL and Hit Ratio (Read-Only)
26
CPU Utilization (Read-Only)
27
Evaluation

• Workload generation
• httperf for static content
• RUBBoS (bulletin board) for dynamic content
• Testbed
• LAN cluster and WAN (PlanetLab) nodes
• Linux Redhat 9.0, Apache 2.0.49, MySQL 4.0.18,
  PHP 4.3.6
• Metrics
• Max request rate and max data rate supported

28
Performance

• Static content (httperf)
• 10-fold improvement
• Relieve network and web server bottlenecks
• Dynamic content (RUBBoS)
• Completely remove web/application server
  bottleneck
• Relieve database server bottleneck
• Overall improvement 10 times for read-only mix,
  5 times for submission mix

29
Conclusion

• DotSlash prototype
• Applicable to both static and dynamic content
• Promising performance improvement
• On-going work
• Address security issues in deployment
• Release DotSlash as open source software
• For further information
• http//www.cs.columbia.edu/IRT/dotslash
• DotSlash framework WCW 2004
• Dynamic script replication Global Internet 2005
• On-demand query result cache TR CUCS-035-05
  (under submission)