Embed Size (px)
DESCRIPTION
VoIP - beyond replicating the limitations of the past. Henning Schulzrinne Dept. of Computer Science, Columbia University, New York (based on work in collaboration with IRT students & staff, as well as the IETF GEOPRIV and SIMPLE WGs) [email protected] IIT VoIP Conference and Expo - PowerPoint PPT Presentation
Citation preview
VoIP - beyond replicating the limitations of the past
Henning SchulzrinneDept. of Computer Science, Columbia University, New York
(based on work in collaboration with IRT students & staff, as well as the IETF GEOPRIV and SIMPLE WGs)
IIT VoIP Conference and ExpoWheaton, IllinoisOctober 25, 2007
Oct. 2007 2
Outline
• VoIP maturing: vision vs. reality– presence and location-based services– user-programmable services
• VoIP challenges– scaling– peer-to-peer systems– spam/SPIT– emergency calling
• The state of SIP standardization, year 11– developments in 2006 & upcoming highlights– trouble in standards land– interoperability
Oct. 2007 3
The three Cs of Internet applications
communications communitycommerce
grossly simplified...
researchfocus
what users care aboutwhat users care about
Oct. 2007 4
Killer Application
• Carriers looking for killer application– justify huge infrastructure investment– “video conferencing” (*1950 – †2000)– ?
• “There is no killer application”– Network television block buster YouTube hit– “Army of one”– Users create their own custom applications that are important to
them– Little historical evidence that carriers (or equipment vendors) will
find that application if it exists
• Killer app = application that kills the carrier
Oct. 2007 5
Evolution of VoIP
“amazing – the
phone rings”
“does it docall transfer?”
“How can I make it
stop ringing?”
1996-2000 2000-2003 2004-2005
catching upwith the digital PBX
long-distance calling,ca. 1930
going beyondthe black phone
2006-
“Can it really
replace the phone
system?”
replacing theglobal phone system
Oct. 2007 6
IETF VoIP efforts
SIP(protocol)
SIPPING(usage, requirements)
ECRIT(emergency calling)
AVT(RTP, SRTP, media)
ENUM(E.164 translation)
IPTEL(tel URL)
SIMPLE(presence)
GEOPRIV(geo + privacy)
usesmay use
uses
provides
usuallyused with
IETF RAI area
MMUSIC(SDP, RTSP, ICE)
XCON(conf. control)
SPEERMINT(peering)
uses
SPEECHSC(speech services)
SIGTRAN(signaling transport)
uses
Oct. 2007 7
Old vs. newold reality new idea new reality
service provider
ILEC, CLEC email-like, run by enterprise, homes
E.164-driven; MSOs, some ILECs, Skype, European SIP providers, Vonage, SunRocket
media 4 kHz audio wideband audio, video, IM, shared apps, …
4 kHz audio
services CLASS (CLID, call forwarding, 3-way calling, ...)
user-created services(web model)presence
still CLASS
user IDs E.164 email-like E.164IM handles
Presence and event notification
Oct. 2007 9
Left to do: glue protocolsQuickTime™ and a
TIFF (Uncompressed) decompressorare needed to see this picture.
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
• Lots of devices and services– cars– household– environment
• Generally, stand-alone– e.g., GPS can’t talk to camera
• Home– home control networks have generally
failed• cost, complexity
• Environment– “Internet of things”– tag bus stops, buildings, cars, ...
Oct. 2007 10
Left to do: event notification
• notify (small) group of users when something of interest happens– presence = change of communications state– email, voicemail alerts– environmental conditions– vehicle status– emergency alerts
• kludges– HTTP with pending response– inverse HTTP --> doesn’t work with NATs
• Lots of research (e.g., SIENA)• IETF efforts starting
– SIP-based– XMPP
Oct. 2007 11
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
capabilities caller preferences
location location-based call routinglocation events
activity/availability presence
sensor data (mood, bio) privacy issues similar to location data
Oct. 2007 12
The role of presence
• Guess-and-ring– high probability of failure:
• “telephone tag”• inappropriate time (call during
meeting)• inappropriate media (audio in
public place)– current solutions:
• voice mail tedious, doesn’t scale, hard to search and catalogue, no indication of when call might be returned
• automated call back rarely used, too inflexible
most successful calls are now scheduled by email
• Presence-based– facilitates unscheduled
communications– provide recipient-specific
information– only contact in real-time if
destination is willing and able– appropriately use synchronous
vs. asynchronous communication
– guide media use (text vs. audio)
– predict availability in the near future (timed presence)
Prediction: almost all (professional) communication will be presence-initiated or
pre-scheduled
Oct. 2007 13
GEOPRIV and SIMPLE architectures
target locationserver
locationrecipient
rulemaker
presentity
caller
presenceagent watcher
callee
GEOPRIV
SIPpresence
SIPcall
PUBLISHNOTIFY
SUBSCRIBE
INVITE
publicationinterface
notificationinterface
XCAP(rules)
INVITE
DHCP
Oct. 2007 14
Presentity and Watchers
Bob’s status, location
Watchers
Available, Busy, Somewhat available,
InvisibleInvisible
wife
son
externalworld
PUBLISH SUBSCRIBE
NOTIFY
Bob’sPresentity WatchersWatchers
Bob’s Presence User Agents (PUA)
PC-IM Client
R u there ?
Bob’s play station
Cell
Phone
BUZZ
PUBLISH
Bob’s Filters
(Rules), PIDF *)
PresenceServer(PS)
*) - PIDF = Presence Information Data Format
friend
Oct. 2007 15
Basic presence
• Role of presence– initially: “can I send an instant message and expect a
response?”– now: “should I use voice or IM? is my call going to interrupt a
meeting? is the callee awake?”• Yahoo, MSN, Skype presence services:
– on-line & off-line• useful in modem days – but many people are (technically) on-line
24x7• thus, need to provide more context
– + simple status (“not at my desk”)• entered manually rarely correct• does not provide enough context for directing interactive
communications
Oct. 2007 16
Presence data architecture
rawpresencedocument
createview
(compose)privacyfiltering
draft-ietf-simple-presence-data-model
compositionpolicy
privacypolicy
presence sources
XCAP XCAP
(not defined yet)
depends on watcherselect best sourceresolve contradictions
PUBLISH
Oct. 2007 17
Presence data architecture
candidatepresencedocument
watcherfilter
rawpresencedocument
post-processingcomposition(merging)
finalpresencedocument
differenceto previous notification
SUBSCRIBE
NOTIFY
remove data not of interest
watcher
Oct. 2007 18
Presence data model
“calendar” “cell” “manual”
[email protected], video, text
person(presentity)
(views)
services
devices
Oct. 2007 19
Rich presence
• More information• automatically derived from
– sensors: physical presence, movement– electronic activity: calendars
• Rich information:– multiple contacts per presentity
• device (cell, PDA, phone, …)• service (“audio”)
– activities, current and planned– surroundings (noise, privacy, vehicle, …)– contact information– composing (typing, recording audio/video IM, …)
Oct. 2007 20
RPID: rich presence<person> <tuple> <device>
<activities>
<class>
<mood>
<place-is>
<place-type>
<privacy>
<relationship>
<service-class>
<sphere>
<status-icon>
<time-offset>
<user-input>
Oct. 2007 21
RPID = rich presence
• Provide watchers with better information about the what, where, how of presentities
• facilitate appropriate communications:– “wait until end of meeting”– “use text messaging instead of phone call”– “make quick call before flight takes off”
• designed to be derivable from calendar information– or provided by sensors in the environment
• allow filtering by “sphere” – the parts of our life– don’t show recreation details to colleagues
Oct. 2007 22
CIPID: Contact Information
• More long-term identification of contacts• Elements:
– card – contact Information – home page– icon – to represent user– map – pointer to map for user– sound – presentity is available
Oct. 2007 23
The role of presence for call routing
• Two modes:– watcher uses presence
information to select suitable contacts
• advisory – caller may not adhere to suggestions and still call when you’re in a meeting
– user call routing policy informed by presence
• likely less flexible – machine intelligence
• “if activities indicate meeting, route to tuple indicating assistant”
• “try most-recently-active contact first” (seq. forking)
LESS
translateRPID
CPL
PA
PUBLISH
NOTIFY
INVITE
Oct. 2007 24
Presence and privacy
• All presence data, particularly location, is highly sensitive
• Basic location object (PIDF-LO) describes– distribution (binary)– retention duration
• Policy rules for more detailed access control– who can subscribe to
my presence– who can see what
when
<tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1“
srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W
</gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no
</gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z
</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp></tuple>
Oct. 2007 25
Privacy policy relationships
geopriv-specific presence-specific
common policy
RPID CIPID
future
Oct. 2007 26
Privacy rules
• Conditions– identity, sphere– time of day– current location– identity as <uri> or <domain>
+ <except>• Actions
– watcher confirmation• Transformations
– include information– reduced accuracy
• User gets maximum of permissions across all matching rules– privacy-safe composition:
removal of a rule can only reduce privileges
• Extendable to new presence data– rich presence– biological sensors– mood sensors
Oct. 2007 27
Example rules document
<identity><id>[email protected]</id></identity>
<sub-handling>allow</sub-handling>
<provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme></provide-services><provide-person>true</provide-person><provide-activities>true</provide-activities><provide-user-input>bare</provide-user-input>
<rul
eset
>
<rule id=1>
<con
ditio
ns>
<tra
nsfo
rmat
ion
s><a
ctio
ns>
Oct. 2007 28
Creating and manipulating rules
• Uploaded in whole or part via XCAP• XML not user-visible• Web or application UI, similar to mail filtering• Can also be location-dependent
– “if at home, colleagues don’t get presence information”• Possibly implementation-defined “privacy levels”
Location-based services
Oct. 2007 30
Location-based services
• Finding services based on location– physical services (stores, restaurants, ATMs, …)– electronic services (media I/O, printer, display, …)– not covered here
• Using location to improve (network) services– communication
• incoming communications changes based on where I am– configuration
• devices in room adapt to their current users– awareness
• others are (selectively) made aware of my location– security
• proximity grants temporary access to local resources
Oct. 2007 31
Location-based SIP services
• Location-aware inbound routing– do not forward call if time at callee location is [11 pm, 8 am]– only forward time-for-lunch if destination is on campus– do not ring phone if I’m in a theater
• outbound call routing– contact nearest emergency call center– send [email protected] to nearest branch
• location-based events– subscribe to locations, not people– Alice has entered the meeting room– subscriber may be device in room our lab stereo changes
CDs for each person that enters the room
Oct. 2007 32
Location delivery
DHCP
HTTP
GPS
HELD
LLDP-MED
wiremap
Oct. 2007 33
Location-based service language
false
trueNOTIFY
action alert
conditions
proximity
occupancy
time
IM
actions
alert
message
log
call
transfer
join
events
incoming
outgoing
notify
message
subscription
Oct. 2007 34
Program location-based services
Oct. 2007 35
Oct. 2007 36 *) - Verizon Service Assurance Business Intelligence Toolkit
Application: Verizon SABIT PALS
• SABIT = web-based mobile employee productivity management system
• PALS - Presence-Aware Location-Based Service– Advanced communication services based on aggregation of
presence information– Enhanced vehicle management system
• Presence/availability information of a user is combined with the location information (of the vehicle) to achieve an integrated communication environment– “only call when vehicle is stopped”
Oct. 2007 37
SABIT PALS Solution
Integrates:• Status and diagnostic information of the vehicle• Mobile employee’s location data obtained from a GPS
device in a vehicle• Mobile employee’s presence information data obtained
from his/her cell-phone• Laptop-based IM/VoIP soft client
Oct. 2007 38
GPSEVDO
WiFi
VZ Data/Real TimeVZ VPN
Field Tech Laptop-Connect
via WiFi or Ethernet
Components of PALS architecture
• Integrated In-Vehicle Device (IIVD – Vehicle Events)
• SABIT System• HTTP-SIP Gateway (LBS Presence User
Agent)• Media Server• Watcher or Supervisor Application• Presence Server (PS)
Oct. 2007 39
SABIT PALS Architecture
PUBLISH PresenceServer NOTIFY
DB
MSC/HLR
SUBSCRIBE Watcher
Watcher
SABIT System
Mobile Employee’s status is relayed through multiple devices
EVDO
GPS
SIP Proxy
Systems View
DB
HTTP/ SIPGatewayHTTP
Location from vehicle
PUBLISH
Media ServerGateway
SABIT Supervisor “sees” mobile employees via the web-interface
Oct. 2007 40
SABIT PALS Supervisor Application
Oct. 2007 41
Communications Webpage
Oct. 2007 42
Roadmap
• Introduction• Presence• Location-based services• Server scaling• P2P SIP• Standardization and interoperability
Oct. 2007 43
SIP server overload
• Proxies will return 503 --> retry elsewhere• Just adds more load• Retransmissions exacerbate the problem
overloaded
overloaded
overloaded
INVITE
503
Springsteen tickets!!earthquake
vote for your favorite…
Oct. 2007 44
Avalanche restart
• Large number of terminals all start at once• Typically, after power outage• Overwhelms registrar• Possible loss of registrations due to retransmission time-out
#300,000
#1
reboot afterpower outage
REGISTER
Oct. 2007 45
Overload control
• Current discussion in design team• Feedback control: rate-based or window-based• Avoid congestion collapse• Deal with multiple upstream sources
capacity
goodput
offered load
S5
S1
S2
S3
S4
UA
UA
Oct. 2007 46
Coordinated Overload Control Architecture
Sending Entity (SE) Receiving Entity (RE)
Load Sample
Feedback
Throttle
SIP SIP
Control Function
MonitorActuator
Control Function
Coordinated overload control with explicit feedback ietf-hilt draft model
SIP
Overload Control
Sending Entity (SE)
SIP
Overload Control
Overload Feedback
Overload DetectionOverload Enforcement
Receiving Entity (RE)
Feedback scope: explicit feedback treated hop-by-hop vs. end-to-end
hop-by-hop feedback is generally believed to be more feasible
Oct. 2007 47
Scaling servers & TCP
• Need TCP– TLS support: customer
privacy, theft of service, …• particularly for WiFi
– many SIP messages now exceed reasonable UDP size (fragmentation)
• e.g., INVITE for IMS: 1182 bytes
• Concern: UA support– improving: 82% of systems at
recent SIPit’19 had TCP support
– only 45% support TLS
• Concern: TCP (and TLS) much less efficient than UDP
– running series of tests to identify differences
– difference mainly in• connection setup cost• message splitting (may need pre-
parsing or incremental parsers)• thread count (one per socket?)
• Our model: – 300,000 customers/servers
• 0.1 Erlang, 180 sec/call– 600,000 BHCA --> 167 req/sec– 300,000 registrations --> 83
req/sec– $0.001/subscriber
Oct. 2007 48
SIP server measurements
• Initial INVITE measurements– OpenSER– 400 calls/sec for TCP– roughly 260 calls/sec for TLS
sipd REGISTER test
Kumiko Ono, Charles Shen, Erich Nahum
TCP
Oct. 2007 49
Roadmap
• Introduction• Presence• Location-based services• Server scaling• P2P SIP• Standardization and interoperability
Oct. 2007 50
LAN
P2P SIP
• Why?– no infrastructure available: emergency
coordination– don’t want to set up infrastructure: small
companies– Skype envy :-)
• P2P technology for– user location
• only modest impact on expenses• but makes signaling encryption cheap
– NAT traversal• matters for relaying
– services (conferencing, …)• how prevalent?
• New IETF working group formed– likely, multiple DHTs– common control and look-up protocol?
P2P provider A
P2P provider B
p2p network
traditional provider
DNS
zeroconf
generic DHT service
Oct. 2007 51
P2P SIP -- components
• Multicast-DNS (zeroconf) SIP enhancements for LAN– announce UAs and their
capabilities
• Client-P2P protocol– GET, PUT mappings– mapping: proxy or UA
• P2P protocol– get routing table, join, leave, …– independent of DHT?– replaces DNS for SIP, not proxy
Oct. 2007 52
Zeroconf: solution for bootstrapping
• Three requirements for zero configuration networks:1) IP address assignment without a DHCP server2) Host name resolution without a DNS server3) Local service discovery without any rendezvous server
• Solutions and implementations:– RFC3927: Link-local addressing standard for 1)– DNS-SD/mDNS: Apple’s protocol for 2) & 3)– Bonjour: DNS-SD/mDNS implementation by Apple – Avahi: DNS-SD/mDNS implementation for Linux and BSD
Oct. 2007 53
DNS-SD/mDNS overview• DNS-Based Service Discovery (DNS-SD) adds a level of
indirection to SRV using PTR:_daap._tcp.local. PTR Tom’s Music._daap._tcp.local._daap._tcp.local. PTR Joe’s Music._daap._tcp.local.
Tom’s Music._daap._tcp.local. SRV 0 0 3689 Toms-machine.local.
Tom’s Music._daap._tcp.local. TXT "Version=196613" "iTSh Version=196608" "Machine ID=6070CABB0585" "Password=true”
Toms-machine.local. A 160.39.225.12
• Multicast DNS (mDNS)– Run by every host in a local link– Queries & answers are sent via multicast– All record names end in “.local.”
1:n mapping
Oct. 2007 54
z2z: Zeroconf-to-Zeroconf interconnection
rendezvous point - OpenDHT
z2z
Import/exportservices
Zeroconf subnet A
z2z
Import/exportservices
Zeroconf subnet B
Oct. 2007 55
Demo: global iTunes sharing
• Exporting iTunes shares under key “columbia”:$ z2z --export:opendht _daap._tcp --key “columbia”
• Importing services stored under key “columbia”:$ z2z --import:opendht --key “columbia”
Oct. 2007 56
How z2z works (exporting)
OpenDHT
z2z
Send browse request (i.e., PTR query) for service type: _daap._tcp
1)
Tom’s Music._daap._tcp.local
Joe’s Music._daap._tcp.local
Send resolve request (i.e., SRV, A, and TXT query) for each service
2)
160.39.225.12Tom’s ComputerPassword=true……
160.39.225.13Joe’s ComputerPassword=false……
Export them by putting into OpenDHT
3)
put:key= z2z._daap._tcp.columbiavalue= Tom’s Music 160.39.225.12:3689 Password=true ……
Oct. 2007 57
How z2z works (importing)
OpenDHT
z2z
Issue get call into OpenDHT
1)
Add “A” record into mDNS
2)
Import services by registering them (i.e., add PTR, SRV, TXT records to the local mDNS)
3)
get:key=z2z._daap._tcp.columbiavalue=Tom’s Music
160.39.225.12:3689……
value=Joe’s Music…… mDNS
“A” record for 160.39.225.12
Tom’s Music._daap._tcp.local_remote-160.39.225.12.local……
Oct. 2007 58
z2z implementation
• C++ Prototype using xmlrpc-c for OpenDHT access– Proof of concept– Porting problem due to Bonjour and Cygwin incompatibility
• z2z v1.0 released – Rewritten in Java from scratch– Open-source (BSD license)– Available in SourceForge (https://sourceforge.net/projects/z2z)
• Paper describing design and implementation detail– z2z: Discovering Zeroconf Services Beyond Local Link
• Lee, Schulzrinne, Kellerer, and Despotovic– Submitted to IEEE Globecom’07 Workshop on Service Discovery
Oct. 2007 59
Zeroconf for SIP
• Enable SIP communication when proxy and registrar are not available– Good use case for z2z– Fill in the gap of P2P-SIP effort:
• local & small scale (10s to 100s)• high mobility• avoid construction of DHT
• Internet Draft published and presented at IETF-68– SIP URI Service Discovery using DNS-SD
• Lee, Schulzrinne, Kellerer, and Despotovic• http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-01
Oct. 2007 60
SIP URI advertisement• Example
_sipuri._udp.local. PTR sip:[email protected]._sipuri._udp.local. _sipuri._udp.local. PTR sip:[email protected]._sipuri._udp.local. sip:[email protected]._sipuri._udp.local. SRV
0 0 5060 bobs-host.local. sip:[email protected]._sipuri._udp.local. TXT txtvers=1 name=Bob contact=sip:[email protected].• Service instance name: Instance.Service.Domain
– Instance = ( SIP-URI / SIPS-URI ) [ SP description ]– Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp”– E.g.) sip:[email protected] - PDA._sipuri._udp.local.
• Contact TXT record attribute– Similar to Contact SIP header except:
• It contains only a single URI• Non-SIP URIs are not allowed
– UA capabilities advertised via field parameters (RFC3840)
Peer-to-Peer Protocol (P2PP)Salman Abdul Baset, Henning Schulzrinne
Columbia University
Oct. 2007 62
Overview
• Objective: key (opaque) data– distributed data structure with O(log N) or O(1) [rarely]
• Practical issues in peer-to-peer systems• Peer-to-peer systems
– file sharing– VoIP– streaming
• P2PSIP architecture• Peer-to-peer protocol (P2PP)• P2PP design issues• Implementation
Oct. 2007 63
Practical issues in peer-to-peer systems
• Bootstrap / service discovery
• NAT and firewall traversal• TCP or UDP?
• Routing-table management• Operation during churn
• Availability and replication
• Identity and trust management
Oct. 2007 64
Peer-to-peer systems
File sharing VoIP Streaming
Low
Medium
High
NAT
NAT
NAT
Data size
Data size
Data size
Per
form
ance
impa
ct /
requ
irem
ent
Service discovery
Replication
Replication
Replication
Oct. 2007 65
P2PSIP: Concepts
• Decentralized SIP– Replace SIP proxy and registrar with p2p
endpoints• Supernode architecture
– P2PSIP peers• participate in the p2p overlay
– P2PSIP clients• use peers to locate users and resources
Oct. 2007 66
P2PSIP architecture
SIP
P2P STUN
TLS / SSL
A peer in P2PSIP
NAT
NAT
A client
[ Bootstrap / authentication server ]
Overlay1
Overlay2
Oct. 2007 67
Peer-to-Peer Protocol (P2PP)
• P2P applications have common requirements such as discovery, NAT traversal, relay selection, replication, and churn management.
• Goals– A protocol to potentially implement any structured or unstructured
protocol.– Not dependent on a single DHT or p2p protocol
• Not a new DHT!
• It is hard!– Too many structured and unstructured p2p protocols– Too many design choices!
• Lets consider DHTs
Oct. 2007 68
DHTs
DHT Geometry Distance function
Lookup correctness
(neighbor table)
Lookup performance
(routing table)
ChordAccordion Ring Modulo numeric
difference Successor list Finger table
Tapestry, Pastry,
Bamboo
Hybrid =Tree + Ring
Prefix match. If fails, then modulo
numeric difference
Leaf-set (Pastry) Routing table
Kademlia XOR XOR of two IDs None Routing table
Oct. 2007 69
Kademlia
XOR
Finger table
Parallel requests
Recursive routing Pastry
Bamboo
ChordSuccessor
Modulo additionPrefix-match
Leaf-set
Routing-table stabilization
Lookup correctness
Lookup performanceProximity neighbor selection
Proximity route selection
Routing-table size
Strict vs. surrogate routing
OneHop
Bootstrapping
Updating routing-table from lookup requests
Tapestry Ring
Tree
HybridReactive recovery
Periodic recovery Accordion
Routing-table exploration
Oct. 2007 70
How to design P2PP?
• Structured– Identify commonalities in DHTs
• Routing table (finger table)• Neighbor table (successor list, leaf-set)
– Separate core routing mechanisms from from DHT-independent issues.• Unstructured
– may not always find all keys• Incorporate mechanisms for
– discovery– NAT / firewall traversal– churn, identity and trust management– request routing (recursive / iterative / parallel)
Oct. 2007 71
Parallel requests
Recursive routing
Routing-table stabilization
Proximity neighbor selection
Proximity route selection
Bootstrapping
Reactive vs. periodic recovery
DHT-independent
Kademlia
XOR
Pastry
Bamboo Chord
Modulo addition
Prefix-match
OneHop
Tapestry
Ring
Tree
Hybrid
DHT-specific
Accordion
Finger table / routingtable
Successor / leaf-set
Lookup correctness
Lookup performance
Routing-table size
Strict vs. surrogate routing
Updating routing-table from lookup requests
DHT-specific Not restricted toone DHT
Routing-table exploration
Geometry
How to design P2PP?
Oct. 2007 72
Chord (Strict routing-table management)
Neighbor table(successor)
Node
x+2i
x+2i+1
x+2i+2
x+2i+3
id=x
Routing table
Immediately succeeds routing-table id
Oct. 2007 73
Peer-to-Peer Protocol (P2PP)
• A binary protocol• Geared towards IP telephony but equally applicable to file sharing,
streaming, and p2p-VoD• Multiple DHT and unstructured p2p protocol support• Application API• NAT traversal
– using STUN, TURN and ICE– ICE encoding in P2PP
• Request routing– recursive, iterative, parallel– per message
• Supports hierarchy (super nodes [peers], ordinary nodes [clients])• Reliable or unreliable transport (TCP or UDP)
Oct. 2007 74
Peer-to-Peer Protocol (P2PP)
• Security– DTLS, TLS, signatures
• Multiple hash function support– SHA1, SHA256, MD4, MD5
• Diagnostics– churn rate, messages sent/received
• Node capabilities– bw determination, CPU utilization, number of neighbors, mobility
Oct. 2007 75
JoinJP BS P5 P7
1. Query
2. 200
P5, P30, P2P-Options
4. Join
9. 200
N(P9, P15)
5. Join
7. 200
P9
JP(P10)
8. Join
6. 200
N(P9, P15)
10. Transfer
11. 200
3+. STUN (ICE candidate gathering)
Oct. 2007 76
Call establishmentP1 P3 P5 P7
1. Lookup-Peer (P7)
5. 200 (P7 Peer-Info)
2. Lookup-Peer (P7) 3. Lookup-Peer (P7)
4. 200 (P7 Peer-Info)
6. 200 (P7 Peer-Info)
7. INVITE
8. 200 Ok
9. ACK
Media
Oct. 2007 77
Implementation
• Chord, Kademlia, Bamboo (in-progress)• SHA1, SHA256, MD5, MD4• Windows, Linux• Integrated with OpenWengo (VoIP phone)
• Available for download (Linux + Windows)http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html
Oct. 2007 78
Implementation
Transport / timers
Node
BigInt
Parser / encoder
UDP TCP
Transactions
ClientBootstrap ChordPeer KadPeer OtherPeer
Sys
insert (key, value, callback)callback (resp)
lookup (key, callback)
Routing table
Neighbor table
Distance
Oct. 2007 79
Screen snapshot• Alice and Bob are
part of Kademlia network
• Alice calls Bob• The lookup is
performed using P2PP
• Call is established using SIP
Oct. 2007 80
P2P summary
• P2P techniques now becoming mainstream– motivated by low opex, ease of deployment– building block, rather than application
• Many operational issues– interconnection: z2z– local peering: Bonjour for SIP– start-up and recovery: cf. Skype failure
• P2PP: Common platform protocol– application-neutral– extensible mechanism
Oct. 2007 81
Roadmap
• Introduction• Presence• Location-based services• Server scaling• P2P SIP• Standardization and interoperability
Oct. 2007 82
SIP, SIPPING & SIMPLE –00 drafts
includes draft-ietf-*-00 and draft-personal-*-00
01020304050607080
19992000200120022003200420052006
SIPSIPPINGSIMPLE
Oct. 2007 83
RFC publication
0
2
4
6
8
10
12
14
2001 2002 2003 2004 2005 2006
SIPSIPPINGSIMPLE
Oct. 2007 84
IETF WG: SIP in 2006 & 2007
• ~ 44 SIP-related RFCs published in 2006– BFCP, conferencing – SDP revision– rich presence
• Activities:– hitchhiker’s guide– infrastructure:
• GRUUs (random identifiers)• URI lists• XCAP configuration• SIP MIB
– services:• rejecting anonymous requests• consent framework• location conveyance• session policy
– security:• end-to-middle security• certificates• SAML• sips clarification
– NAT:• connection re-use• SIP outbound• ICE (in MMUSIC)
see http://tools.ietf.org/wg/sip’/
Oct. 2007 85
IETF WG: SIPPING
• 31 RFCs published in 2006• Policy
– media policy– SBC functions
• Services– service examples– call transfer– configuration framework– spam and spit– text-over-IP– transcoding
• Testing and operations– IPv6 transition– race condition examples– IPv6 torture tests– SIP offer-answer examples– overload requirements– configuration– voice quality reporting
Oct. 2007 86
Interoperability
• Generally no interoperability problems for basic SIP functionality– basic call, digest registration (mostly...), call transfer, voice mail
• Weaker in advanced scenarios and backward compatibility– handling TCP, TLS– NAT support (symmetric RTP, ICE, STUN, ...)– multipart bodies– SIP torture tests– call transfer, call pick-up– video and voice codec interoperability (H.264, anything beyond G.711)
• SIPit useful, but no equivalent of WiFi certification– most implementations still single-vendor (enterprise, carrier) or vendor-
supplied (VSP)– SFTF (test framework) still limited
• Need profiles to guide implementers
SIPREAL BOFat IETF 70?
Oct. 2007 87
Trouble in Standards Land
• Proliferation of transition standards: 2.5G, 2.6G, 3.5G, …
– true even for emergency calling…• Splintering of standardization efforts
across SDOs– primary:
• IEEE, IETF, W3C, OASIS, ISO– architectural:
• PacketCable, ETSI, 3GPP, 3GPP2, OMA, UMA, ATIS, …
– specialized:• NENA
– operational, marketing:• SIP Forum, IPCC, …
OASIS
IEEE
IETF
W3CISO (MPEG)
L2.5-L7protocols
dataexchange
dataformats
L1-L2
3GPP
Pack
etCa
ble
Oct. 2007 88
IETF issues
• SIP WGs: small number (dozen?) of core authors (80/20)
– some now becoming managers…– or moving to other topics
• IETF: research engineering maintenance
– many groups are essentially maintaining standards written a decade (or two) ago
• DNS, IPv4, IPv6, BGP, DHCP; RTP, SIP, RTSP
• constrained by design choices made long ago
– often dealing with transition to hostile & “random” network
– network ossification
• Stale IETF leadership– often from core equipment
vendors, not software vendors or carriers
• fair amount of not-invented-here syndrome
• late to recognize wide usage of XML and web standards
• late to deal with NATs• security tends to be per-protocol
(silo)– some efforts such as SAML and
SASL
• tendency to re-invent the wheel in each group
Oct. 2007 89
IETF issue: timeliness
• Most drafts spend lots of time in 90%-complete state
– lack of energy (moved on to new -00)– optimizers vs. satisfiers
• multiple choices that have non-commensurate trade-offs
• Notorious examples:– SIP request history: Feb. 2002 – May
2005 (RFC 4244)– Session timers: Feb. 1999 – May 2005
(RFC 4028)– Resource priority: Feb. 2001 – Feb
2006 (RFC 4412)• New framework/requirements phase
adds 1-2 years of delay• Three bursts of activity/year, with
silence in-between– occasional interim meetings
• IETF meetings are often not productive
– most topics gets 5-10 minutes lack context, focus on minutiae
– no background same people as on mailing list
– 5 people discuss, 195 people read email
• No formal issue tracking– some WGs use tools, haphazardly
• Gets worse over time:– dependencies increase,
sometimes undiscovered– backwards compatibility issues– more background needed to
contribute
Oct. 2007 90
IETF issues: timeliness
• WG chairs run meetings, but are not managing WG progress– very little control of deadlines
• e.g., all SIMPLE deadlines are probably a year behind– little push to come to working group last call (WGLC)– limited timeliness accountability of authors and editors– chairs often provide limited editorial feedback
• IESG review can get stuck in long feedback loop– author – AD – WG chairs– sometimes lack of accountability (AD-authored documents)
• RFC editor often takes 6+ months to process document– dependencies; IANA; editor queue; author delays– e.g., session timer: Aug. 2004 – May 2005
Oct. 2007 91
Conclusion
• Even after 10+ years, VoIP mostly still “cheaper calls”• New services and models:
– (rich) presence– location-based services– user-programmable services– P2P SIP
• Scaling to carrier-scale and under duress• Current standardization processes slow and complexity-
inducing
