Vo. IP - 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) hgs@cs. columbia. edu Lucent-Alcatel Stuttgart January 31, 2008 Oct. 2007
Outline • Vo. IP maturing: vision vs. reality – presence and location-based services – user-programmable services • Vo. IP 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 2
The three Cs of Internet applications grossly simplified. . . communications research focus Oct. 2007 commerce community what users care about 3
Killer Application • Carriers looking for killer application – justify huge infrastructure investment – “video conferencing” (*1950 – † 2000) – ? • “There is no killer application” – Network television block buster You. Tube 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 4
Evolution of Vo. IP long-distance calling, ca. 1930 “does it do call transfer? ” “amazing – the phone rings” 2000 -2003 replacing the global phone system going beyond the black phone catching up with the digital PBX 1996 -2000 “How can I make it stop ringing? ” “Can it really replace the phone system? ” Oct. 2007 2004 -2005 20065
IETF Vo. IP efforts ECRIT ENUM SIMPLE (emergency calling) (E. 164 translation) (presence) uses GEOPRIV uses SPEERMINT (geo + privacy) may use XCON uses (conf. control) SIP IPTEL (protocol) provides (peering) uses SIPPING (usage, requirements) SPEECHSC (tel URL) (speech services) usually used with AVT (RTP, SRTP, media) IETF RAI area Oct. 2007 MMUSIC (SDP, RTSP, ICE) SIGTRAN (signaling transport) 6
Old vs. new old 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, Sun. Rocket media 4 k. Hz audio wideband audio, video, IM, shared apps, … 4 k. Hz audio services CLASS (CLID, call forwarding, 3 -way calling, . . . ) user-created services (web model) presence still CLASS user IDs E. 164 email-like E. 164 IM handles Oct. 2007 7
Presence and event notification Oct. 2007
Left to do: glue protocols • 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 9
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 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 capabilities caller preferences location-based call routing location events activity/availability presence sensor data (mood, bio) Oct. 2007 CPL privacy issues similar to location data 11
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 12
GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) target presentity caller Oct. 2007 publication interface PUBLISH INVITE location server presence agent notification interface location recipient GEOPRIV watcher SIP presence SUBSCRIBE NOTIFY INVITE callee SIP call 13
Presentity and Watchers Bob’s Presentity PUBLISH Presence Server (PS) SUBSCRIBE NOTIFY Watchers Available, Busy, Somewhat available, Invisible Bob’s status, location Bob’s Filters (Rules), PIDF *) wife PUBLISH son R u there ? friend BUZZ Cell Phone PC-IM Client Bob’s play station Bob’s Presence User Agents (PUA) Oct. 2007 *) - PIDF = Presence Information Data Format external world 14
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 24 x 7 • 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 15
Presence data architecture presence sources PUBLISH create view (compose) raw presence document XCAP select best source resolve contradictions composition policy (not defined yet) Oct. 2007 privacy filtering depends on watcher XCAP privacy policy draft-ietf-simple-presence-data-model 16
Presence data architecture candidate presence document remove data not of interest watcher Oct. 2007 watcher filter raw presence document post-processing composition (merging) SUBSCRIBE difference to previous notification NOTIFY final presence document 17
Presence data model person “calendar” “cell” “manual” (presentity) (views) services alice@example. com audio, video, text r 42@example. com video devices Oct. 2007 18
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”) – – Oct. 2007 activities, current and planned surroundings (noise, privacy, vehicle, …) contact information composing (typing, recording audio/video IM, …) 19
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 20
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 21
CIPID: Contact Information • More long-term identification of contacts • Elements: – – – Oct. 2007 card – contact Information home page icon – to represent user map – pointer to map for user sound – presentity is available 22
The role of presence for call routing • Two modes: PUBLISH – 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) PA translate RPID CPL NOTIFY LESS INVITE Oct. 2007 23
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 Oct. 2007 <tuple id="sg 89 ae"> <status> <gp: geopriv> <gp: location-info> <gml: location> <gml: Point gml: id="point 1“ srs. Name="epsg: 4326"> <gml: coordinates>37: 46: 30 N 122: 25: 10 W </gml: coordinates> </gml: Point> </gml: location> </gp: location-info> <gp: usage-rules> <gp: retransmission-allowed>no </gp: retransmission-allowed> <gp: retention-expiry>2003 -06 -23 T 04: 57: 29 Z </gp: retention-expiry> </gp: usage-rules> </gp: geopriv> </status> <timestamp>2003 -06 -22 T 20: 57: 29 Z</timestamp> </tuple> 24
Privacy policy relationships common policy geopriv-specific presence-specific RPID Oct. 2007 future CIPID 25
Privacy rules • Conditions – – identity, sphere time of day current location identity as <uri> or <domain> + <except> • Actions – watcher confirmation • Transformations – include information – reduced accuracy Oct. 2007 • 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 26
<actions> <conditions> <transformations> <ruleset> Example rules document Oct. 2007 <rule id=1> <identity><id>user@example. com</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> 27
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” Oct. 2007 28
Location-based services Oct. 2007
Location-based services people & vehicle tracking product tracking indoor routing car park assistance directions traffic management emergency calls Tracking Emergency Navigation automotive assistance shopping guides travel & tourist guides Advertising Information Billing locationbased services mobile yellow pages travel planner banners & alerts road tolling facility Games Infrastructure geocaching Leisure Management customer relationship mobile games fleet (scheduling) Communications location-aware call handling Oct. 2007 buddy finder instant messaging security environmental Foundations of Location-based Services (Steinger, Neun, Edwardes), modified) 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 delivery@pizza. com 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 determination options Method CDP or LLDPMED DHCP HELD GPS manual entry Layer L 2 L 3 L 7 (HTTP) - user advantages • simple to implement • built into switch • direct port/room mapping • simple to implement • network locality • traverses NATs • can be operated by L 2 provider • accurate • mobile devices • no carrier cooperation • no infrastructure changes • no carrier cooperation problems may be hard to automate for large enterprises mapping MAC address to location? mapping IP address to switch port? • indoor coverage • acquisition time • fails for mobile devices • unreliable for nomadic Use Ethernet LANs Enterprise LANs Some ISPs DSL, cable mobile devices fall back Oct. 2007 33
Location delivery GPS HELD HTTP DHCP wire map LLDP-MED Oct. 2007 34
Local Switch Automatic Number Identification Automatic Location Identification Oct. 2007 Collaboration between local phone providers and local public safety agencies 35
What makes Vo. IP 112/911 hard? POTS PSTN-emulation Vo. IP (landline) phone number limited to limited area landline phone number no phone number or anywhere in US (cf. phone number German 180) anywhere around the world regional carrier national or continentwide carrier enterprise “carrier” or anybody with a peer-to -peer device voice provider = line provider (~ business relationship) voice provider ≠ ISP national protocols and call routing probably North America + EU international protocols and routing location = line location mostly residential or small business stationary, nomadic, wireless Oct. 2007 end-to-end Vo. IP 36
UA recognition & UA resolution location information mapping DHCP LLDP-MED 9 -1 -1 (dial string) INVITE urn: service: sos To: urn: service: sos Route: sip: psap@leonianj. gov <location> Oct. 2007 leonianj. gov identification TBD mapping may recurse INVITE urn: service: sos To: urn: service: sos Route: sip: fire@leonianj. gov <location> 37
Lo. ST: Location-to-URL Mapping VSP 1 cluster serving VSP 1 replicate root information cluster serves VSP 2 123 Broad Ave Leonia Bergen County NJ US Lo. ST NJ US sip: psap@leonianj. gov root NY US nodes search referral Bergen County NJ US Leonia NJ US Oct. 2007 38
Program location-based services Oct. 2007 39
Oct. 2007 40
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 *) - Verizon Service Assurance Business Intelligence Toolkit 41
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/Vo. IP soft client Oct. 2007 42
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 Field Tech Laptop-Connect Presence Server (PS) VZ Data/Real Time VZ VPN via Wi. Fi or Ethernet GPS EVDO Wi. Fi Oct. 2007 43
SABIT PALS Architecture GPS DB DB Location from vehicle SABIT System EVDO HTTP/ SIP Gateway PUBLISH Presence Server SUBSCRIBE NOTIFY Watcher Media Server Gateway MSC/HLR PUBLISH SIP Proxy SABIT Supervisor “sees” mobile employees via the web-interface Mobile Employee’s status is relayed through multiple devices Systems View Oct. 2007 44
SABIT PALS Supervisor Application Oct. 2007 45
Communications Webpage Oct. 2007 46
Roadmap • • • Introduction Presence Location-based services Server scaling P 2 P SIP Standardization and interoperability Oct. 2007 47
SIP server overload Springsteen tickets!! earthquake vote for your favorite… overloaded INVITE 503 overloaded • Proxies will return 503 --> retry elsewhere • Just adds more load • Retransmissions exacerbate the problem Oct. 2007 48
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 #1 REGISTER #300, 000 reboot after power outage Oct. 2007 49
Overload control • • Current discussion in design team Feedback control: rate-based or window-based Avoid congestion collapse Deal with multiple upstream sources goodput capacity offered load Oct. 2007 50
Coordinated Overload Control Architecture Coordinated overload control with explicit feedback ietf-hilt draft model 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 51
Scaling servers & TCP • Need TCP • – TLS support: customer privacy, theft of service, … – running series of tests to identify differences – difference mainly in • particularly for Wi. Fi – 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 Oct. 2007 Concern: TCP (and TLS) much less efficient than UDP • connection setup cost • message splitting (may need preparsing 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 52
SIP server measurements TCP • Initial INVITE measurements – Open. SER – 400 calls/sec for TCP – roughly 260 calls/sec for TLS sipd REGISTER test Oct. 2007 Kumiko Ono, Charles Shen, Erich Nahum 53
Roadmap • • • Introduction Presence Location-based services Server scaling P 2 P SIP Standardization and interoperability Oct. 2007 54
P 2 P SIP • Why? generic DHT service p 2 p network – no infrastructure available: emergency coordination – don’t want to set up infrastructure: small companies – Skype envy : -) • P 2 P provider B P 2 P technology for DNS – user location • only modest impact on expenses • but makes signaling encryption cheap P 2 P provider A – NAT traversal • matters for relaying traditional provider – services (conferencing, …) • how prevalent? • New IETF working group formed – likely, multiple DHTs – common control and look-up protocol? Oct. 2007 zeroconf LAN 55
P 2 P SIP -- components • Multicast-DNS (zeroconf) SIP enhancements for LAN – announce UAs and their capabilities • Client-P 2 P protocol – GET, PUT mappings – mapping: proxy or UA • P 2 P protocol – get routing table, join, leave, … – independent of DHT? – replaces DNS for SIP, not proxy Oct. 2007 56
Zeroconf: solution for bootstrapping • Three requirements for zero configuration networks: 1) 2) 3) • Solutions and implementations: – – Oct. 2007 IP address assignment without a DHCP server Host name resolution without a DNS server Local service discovery without any rendezvous server RFC 3927: Link-local addressing standard for 1) DNS-SD/m. DNS: Apple’s protocol for 2) & 3) Bonjour: DNS-SD/m. DNS implementation by Apple Avahi: DNS-SD/m. DNS implementation for Linux and BSD 57
DNS-SD/m. DNS 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. Joe’s Music. _daap. _tcp. local. 1: n mapping Tom’s Music. _daap. _tcp. local. SRV 0 0 3689 Toms-machine. local. Tom’s Music. _daap. _tcp. local. TXT "Version=196613" "i. TSh Version=196608" "Machine ID=6070 CABB 0585" "Password=true” Toms-machine. local. • 160. 39. 225. 12 Multicast DNS (m. DNS) – – – Oct. 2007 A Run by every host in a local link Queries & answers are sent via multicast All record names end in “. local. ” 58
z 2 z: Zeroconf-to-Zeroconf interconnection rendezvous point - Open. DHT Import/export services z 2 z Zeroconf subnet A Oct. 2007 z 2 z Zeroconf subnet B 59
How z 2 z works (exporting) Open. DHT put: key= z 2 z. _daap. _tcp. columbia value= Tom’s Music 160. 39. 225. 12: 3689 z 2 z Password=true …… 2) Send resolve request (i. e. , SRV, A, and TXT query) for each service Tom’s Music. _daap. _tcp. local Oct. 2007 1) Send browse request (i. e. , PTR query) for service type: _daap. _tcp Joe’s Music. _daap. _tcp. local 160. 39. 225. 12 Tom’s Computer Password=true …… 160. 39. 225. 13 Joe’s Computer Password=false …… 3) Export them by putting into Open. DHT 60
z 2 z implementation • C++ Prototype using xmlrpc-c for Open. DHT access – Proof of concept – Porting problem due to Bonjour and Cygwin incompatibility • z 2 z v 1. 0 released – Rewritten in Java from scratch – Open-source (BSD license) – Available in Source. Forge (https: //sourceforge. net/projects/z 2 z) • Paper describing design and implementation detail – z 2 z: Discovering Zeroconf Services Beyond Local Link • Lee, Schulzrinne, Kellerer, and Despotovic – Submitted to IEEE Globecom’ 07 Workshop on Service Discovery Oct. 2007 61
Zeroconf for SIP • Enable SIP communication when proxy and registrar are not available – Good use case for z 2 z – Fill in the gap of P 2 P-SIP effort: • local & small scale (10 s to 100 s) • 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 62
SIP URI advertisement • Example _sipuri. _udp. local. PTR sip: bob@a. com. _sipuri. _udp. local. PTR sip: joe@a. com. _sipuri. _udp. local. sip: bob@a. com. _sipuri. _udp. local. SRV 0 0 5060 bobs-host. local. sip: bob@a. com. _sipuri. _udp. local. TXT txtvers=1 name=Bob contact=sip: bob@bobs-host. local. • Service instance name: Instance. Service. Domain – Instance = ( SIP-URI / SIPS-URI ) [ SP description ] – Service = “_sipuri. _udp” / “_sipuri. _tcp” / “_sipuri. _sctp” – E. g. ) sip: bob@example. com - 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 (RFC 3840) Oct. 2007 63
Peer-to-Peer Protocol (P 2 PP) Salman Abdul Baset, Henning Schulzrinne Columbia University Oct. 2007
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 – Vo. IP – streaming • • P 2 PSIP architecture Peer-to-peer protocol (P 2 PP) P 2 PP design issues Implementation Oct. 2007 65
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 66
Performance impact / requirement Peer-to-peer systems High Service discovery Data size NAT Replication Medium Data size NAT Replication Low NAT File sharing Oct. 2007 Data size Vo. IP Streaming 67
P 2 PSIP: Concepts • Decentralized SIP – Replace SIP proxy and registrar with p 2 p endpoints • Supernode architecture – P 2 PSIP peers • participate in the p 2 p overlay – P 2 PSIP clients • Oct. 2007 use peers to locate users and resources 68
![P 2 PSIP architecture [ Bootstrap / authentication server ] alice@example. com Overlay 2](https://present5.com/presentation/286ccee4f1fc4bba7b91f90ca6e3ebcc/image-69.jpg "P 2 PSIP architecture [ Bootstrap / authentication server ] alice@example. com Overlay 2")
P 2 PSIP architecture [ Bootstrap / authentication server ] alice@example. com Overlay 2 SIP NAT Overlay 1 P 2 P NAT STUN TLS / SSL A peer in P 2 PSIP bob@example. com Oct. 2007 A client 69
Peer-to-Peer Protocol (P 2 PP) • P 2 P 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 p 2 p protocol • Not a new DHT! • It is hard! – Too many structured and unstructured p 2 p protocols – Too many design choices! • Lets consider DHTs Oct. 2007 70
DHTs Lookup correctness (neighbor table) Lookup performance (routing table) DHT Geometry Distance function Chord Accordion 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 of two IDs None Routing table Oct. 2007 71
Periodic recovery Finger table Routing-table stabilization Tree Lookup correctness Parallel requests Routing-table size Recursive routing Kademlia Prefix-match Modulo addition One. Hop Accordion Leaf-set Pastry Bootstrapping Updating routing-table from lookup requests XOR Tapestry Proximity neighbor selection Lookup performance Hybrid Successor Strict vs. surrogate routing Oct. 2007 Bamboo Ring Reactive recovery Chord Proximity route selection Routing-table exploration 72
How to design P 2 PP? • Structured – Identify commonalities in DHTs • Routing table (finger table) • Neighbor table (successor list, leaf-set) – Separate core routing mechanisms from DHT-independent issues. • Unstructured – may not always find all keys • Incorporate mechanisms for – – Oct. 2007 discovery NAT / firewall traversal churn, identity and trust management request routing (recursive / iterative / parallel) 73
How to design P 2 PP? DHT-independent Bootstrapping Routing-table stabilization Reactive vs. periodic recovery Parallel requests Recursive routing DHT-specific Not restricted to one DHT Bamboo Chord Lookup performance Tapestry Kademlia Lookup correctness Pastry One. Hop Successor / leaf-set Finger table / routing table Routing-table size Proximity neighbor selection Proximity route selection Oct. 2007 DHT-specific Accordion Modulo addition Prefix-match XOR Geometry Updating routing-table from lookup requests Ring Strict vs. surrogate routing Tree Routing-table exploration Hybrid 74
Chord (Strict routing-table management) id=x Neighbor table (successor) Routing table x+2 i Immediately succeeds routing-table id Oct. 2007 x+2 i+1 x+2 i+2 x+2 i+3 75 Node
Peer-to-Peer Protocol (P 2 PP) • A binary protocol • Geared towards IP telephony but equally applicable to file sharing, streaming, and p 2 p-Vo. D • Multiple DHT and unstructured p 2 p protocol support • Application API • NAT traversal – using STUN, TURN and ICE – ICE encoding in P 2 PP • Request routing – recursive, iterative, parallel – per message • Supports hierarchy (super nodes [peers], ordinary nodes [clients]) • Reliable or unreliable transport (TCP or UDP) Oct. 2007 76
Peer-to-Peer Protocol (P 2 PP) • Security – DTLS, signatures • Multiple hash function support – SHA 1, SHA 256, MD 4, MD 5 • Diagnostics – churn rate, messages sent/received • Node capabilities – bw determination, CPU utilization, number of neighbors, mobility Oct. 2007 77
Join JP BS P 5 P 7 P 9 1. Query 2. 200 P 5, P 30, P 2 P-Options 3+. STUN (ICE candidate gathering) 4. Join 5. Join 6. 200 7. 200 N(P 9, P 15) JP (P 10) 8. Join 9. 200 10. Transfer 11. 200 Oct. 2007 78
Call establishment P 1 P 3 1. Lookup-Peer (P 7) 6. 200 (P 7 Peer-Info) P 5 2. Lookup-Peer (P 7) 5. 200 (P 7 Peer-Info) P 7 3. Lookup-Peer (P 7) 4. 200 (P 7 Peer-Info) 7. INVITE 8. 200 Ok 9. ACK Media Oct. 2007 79
Implementation • • Chord, Kademlia, Bamboo (in-progress) SHA 1, SHA 256, MD 5, MD 4 Windows, Linux Integrated with Open. Wengo (Vo. IP phone) • Available for download (Linux + Windows) http: //www 1. cs. columbia. edu/~salman/p 2 pp/setupp 2 pp. html Oct. 2007 80
Implementation insert (key, value, callback) callback (resp) lookup (key, callback) Bootstrap Client Chord. Peer Kad. Peer Other. Peer Node Distance Routing table Big. Int Neighbor table Sys Transactions Transport / timers UDP Oct. 2007 Parser / encoder TCP 81
Screen snapshot • Alice and Bob are part of Kademlia network • Alice calls Bob • The lookup is performed using P 2 PP • Call is established using SIP Oct. 2007 82
P 2 P summary • P 2 P techniques now becoming mainstream – motivated by low opex, ease of deployment – building block, rather than application • Many operational issues – interconnection: z 2 z – local peering: Bonjour for SIP – start-up and recovery: cf. Skype failure • P 2 PP: Common platform protocol – application-neutral – extensible mechanism Oct. 2007 83
Roadmap • • Introduction Presence Location-based services Server scaling P 2 P SIP Vo. IP over Wi. Fi Standardization and interoperability Oct. 2007 84
Issues for Vo. IP over Wi. Fi L 7 (SIP) templatebased compression personal & service mobility vertical hand-off (VCC) duplicate address detection L 2 (MAC) network attachment detection selective scanning L 2 authentication & authorization cooperative roaming MAC for delay-sensitive traffic admission control L 1 (PHY) Oct. 2007 cooperative roaming caching AP discovery L 3 (IP) p. DAD APC DPCF QP-CAT IBIT fading interference by other APs 85
Fast Layer 2 Handoff Measurement Results – Oct. 2007 Handoff time 86
Passive DAD Overview DHCP server Address Usage Collector (AUC) TCP Connection Flag IP Client ID IP IP 1 IP 2 IP 3 MAC Expire Client ID MAC 1 MAC 2 MAC 3 570 580 590 DUID 1 DUID 2 DUID 3 MAC 1 MAC 2 MAC 3 Broadcast-ARP-DHCP Router/Relay Agent SUBNET • • • AUC builds DUID: MAC pair table (DHCP traffic only) AUC builds IP: MAC pair table (broadcast and ARP traffic) The AUC sends a packet to the DHCP server when: – – – • Oct. 2007 a new pair IP: MAC is added to the table a potential duplicate address has been detected a potential unauthorized IP has been detected DHCP server checks if the pair is correct or not and it records the IP address as in use. (DHCP has the final decision!) 87
Cooperative Roaming Measurement Results Oct. 2007 88
Dynamic PCF (DPCF) Simulation Results Delay and throughput of 28 Vo. IP traffic and data traffic Throughput (kb/s) 2500 600 544. 8 FTP Throughput Vo. IP Delay (90%) 487. 4 500 400. 0 2000 400 311. 5 1500 300 182. 5 1000 67. 4 500 24. 8 17. 8 10. 6 0 200 DCF PCF DPCF 0 End-to-End Delay (ms) 3000 100 21. 9 DCF PCF DPCF 1 26. 1 29. 2 DCF PCF DPCF 3 0 Number of Data Sessions Oct. 2007 89
QP-CAT Basic flow of QP-CAT Emulate new Vo. IP traffic Compute Additional Transmission Decrease the queue size Predict the future queue size Additional transmission Packets from a virtual new flow + channel Actual packets additional current packets Oct. 2007 90
QP-CAT Simulation results 18 calls (actual) 16 calls + 1 virtual call (predicted by QP-CAT) 16 calls (actual) 17 calls + 1 virtual call (predicted by QP-CAT) 17 th call is admitted 16 calls + 1 virtual call (predicted by QP-CAT) 17 calls (actual) 17 calls + 1 virtual call (predicted by QP-CAT) 18 th call starts 17 calls (actual) Vo. IP traffic with 34 kb/s 20 ms Packetization Interval Oct. 2007 91
Template-based Compression Incoming INVITE – Compression Original size Sig. Comp only Template + Sig. Comp Template + SD + Sig. Comp Full Flow (Bytes) 1182 592 149 115 81 87 Optimized Flow (Bytes) 1182 658 149 122 81 87 Oct. 2007 92
Roadmap • • Introduction Presence Location-based services Server scaling P 2 P SIP Vo. IP over Wi. Fi Standardization and interoperability Oct. 2007 93
SIP, SIPPING & SIMPLE – 00 drafts includes draft-ietf-*-00 and draft-personal-*-00 Oct. 2007 94
RFC publication Oct. 2007 95
IETF WG: SIP in 2006 & 2007 • ~ 44 SIP-related RFCs published in 2006 – – – • BFCP, conferencing SDP revision rich presence Activities: – – hitchhiker’s guide infrastructure: • • – services: • • Oct. 2007 GRUUs (random identifiers) URI lists XCAP configuration SIP MIB 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’/ 96
IETF WG: SIPPING • 31 RFCs published in 2006 • Policy – media policy – SBC functions • Services – – – Oct. 2007 service examples call transfer configuration framework spam and spit text-over-IP transcoding • Testing and operations – – – – IPv 6 transition race condition examples IPv 6 torture tests SIP offer-answer examples overload requirements configuration voice quality reporting 97
Interoperability SIPREAL BOF at IETF 70? • 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 Wi. Fi certification – most implementations still single-vendor (enterprise, carrier) or vendorsupplied (VSP) – SFTF (test framework) still limited • Need profiles to guide implementers Oct. 2007 98
Trouble in Standards Land • Proliferation of transition standards: 2. 5 G, 2. 6 G, 3. 5 G, … – true even for emergency calling… • Splintering of standardization efforts across SDOs OASIS W 3 C ISO (MPEG) – primary: data formats data exchange IETF IEEE • IEEE, IETF, W 3 C, OASIS, ISO L 2. 5 -L 7 protocols L 1 -L 2 – architectural: • Packet. Cable, ETSI, 3 GPP 2, OMA, UMA, ATIS, … – specialized: – operational, marketing: 3 GPP • SIP Forum, IPCC, … Oct. 2007 Packet. Cable • NENA 99
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 • – often from core equipment vendors, not software vendors or carriers • – often dealing with transition to hostile & “random” network – network ossification Oct. 2007 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) – many groups are essentially maintaining standards written a decade (or two) ago • DNS, IPv 4, IPv 6, BGP, DHCP; RTP, SIP, RTSP • constrained by design choices made long ago Stale IETF leadership – some efforts such as SAML and SASL • tendency to re-invent the wheel in each group 100
IETF issue: timeliness • Most drafts spend lots of time in 90%complete state • – lack of energy (moved on to new -00) – optimizers vs. satisfiers • • – 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 multiple choices that have noncommensurate 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 Oct. 2007 IETF meetings are often not productive • 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 101
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 102
Conclusion • Even after 10+ years, Vo. IP mostly still “cheaper calls” • New services and models: – – (rich) presence location-based services user-programmable services P 2 P SIP • Scaling to carrier-scale and under duress • Current standardization processes slow and complexityinducing Oct. 2007 103
Скачать презентацию Vo IP — beyond replicating the limitations of
286ccee4f1fc4bba7b91f90ca6e3ebcc.ppt