Universal Inbox Workshop Bhaskaran Raman ICEBERG Project EECS
Universal Inbox: Workshop Bhaskaran Raman, ICEBERG Project, EECS, U. C. Berkeley Ericsson, Sweden, Aug 2000
Developers Workshop: Three Tracks Tuesday 22 August 2000 10: 15 - 12: 00 Track #1: ICEBERG Control Plane ICEBERG signaling protocol Clearinghouse: Quality of Service and secure billing Automatic Path Creation service 10: 15 - 12: 00 Track #2: ICEBERG Applications Universal Inbox for personal mobility and service mobility Media. Manager: unified messaging 10: 15 - 12: 00 Track #3: ICEBERG Infrastructure & Testbed ICEBERG testbed Video over wireless: performance and protocol issues IP Telephony testbed for congestion-based pricing
Outline • • • Walk-through of redirection mechanism Details of the name-tree Preference specification Extensions to the Universal Inbox APIs for extension – Adding IAPs – Adding APC operators • Extension: Service provider’s perspective • Scaling measurements for the components – APC – Preference Registry
Putting it all together: An Example Naming Service GSM Netwo rk 1 2 IAP 1 9 Cell. Phone (Alice) Bob’s Preferen ce Registry 4 3 CA 1 7 8 PSTN Netwo rk Internet. Core CA 2 IAP 2 5 6 Telepho ne (Bob) APC Service Alice calls Bob; call gets redirected to Bob’s preferred endpoint in the shown steps
Naming Service • Distributed level of indirection • Lookup based on any identity (not just unique-id) – Need to handle legacy devices – Gives more flexibility • Hierarchy for distribution
Name Space Name trees corresponding to service-specific-ids are combined in a single logical tree
Name Space (Continued) Tagged-tree – each level is tagged with a specific tag (similar to LDAP/X. 500 tree) Tag 1 = Value 1 Tag 2 = Value 2 Hierarchical tree-traversal for name lookup Sub-tree owned by a particular domain (or service provider) Tag 3 = Value 3 Tag 2 = Value 2’
Naming Service: Implementation • In ICEBERG v 0: – LDAP server with modified schema – No distribution mechanisms yet • Tagged-tree schema of LDAP suited our requirements well • Open. LDAP: http: //www. openldap. org/ • Should really be a Ninja cluster-based service
Naming Service: More Details • DNS Extension can also be used for hierarchical structure • Caching semantics are probably different – Detailed study required • Tagging not possible if DNS is used – Okay, but clumsy
Outline • • • Walk-through of redirection mechanism Details of the name-tree Preference specification Extensions to the Universal Inbox APIs for extension – Adding IAPs – Adding APC operators • Extension: Service provider’s perspective • Scaling measurements for the components – APC – Preference Registry
Preference Specification User Preference Manager GUI Preference Registry i. POP
Preference Specification GUI User can specify a set of devices on which call can be received Logical Name IAP Location Callee Identity at that IAP
Preference Specification GUI (Continued) User can specify a set of time-spans
Preference Specification GUI (Continued) User can specify a groups of people (callers)
Preference Specification GUI (Continued) User can specify rules based on these definitions
Preference Specification GUI (Continued) Pecking order: who can interrupt who
Preference Specification GUI (Continued) Call Simulator – for checking rules for correctness
Example Preference Profile # Setting $group set group {Unknown People} if ![string compare $caller_uniqid {nobody@nowhere. com}] { set group {Unknown People} } if ![string compare $caller_uniqid {uid=helenjw, l 3=cs, l 2=berkeley, l 1=edu, type=uniq}] { set group {Friends} } if ![string compare $caller_uniqid {uid=jshih, l 3=cs, l 2=berkeley, l 1=edu, type=uniq}] { set group {Friends} } if ![string compare $caller_uniqid {uid=zmao, l 3=cs, l 2=berkeley, l 1=edu, type=uniq}] { set group {Friends} } # Setting $timespan set time [expr $hour * 60 + $minute] set timespan {none} if [expr $time >= 540] && [expr $time <= 1020]] { set timespan {Office-Hours} } # Inserting Rules set outgoing {drop call} if [expr ![string compare $timespan {Office-Hours}] && ![string compare $group {Friends}]] { set outgoing {cell-phone} } set outgoing {drop}
Preference Registry Implementation • TCL Scripts for preferences • JACL Java-based interpreter • Ninja’s Cluster-based Distributed Hash Table for storing user’s preferences Back-End nodes store the preference profiles Front-End processes users’ preference-profiles Back-End i. POP Front-End Back-End
Some Numbers • Release v 0 implementation: – – 55. 3 requests/sec 71, 000 users (2. 8 calls/hour/user) About 36 ms latency For 50 -line dummy TCL script • ICEBERG Release v 0: based on Ninja i. Space • Scaling bottlenecks due to RMI-based access – Thread per client • Next release: based on Ninja v. Space – Task-dispatch model – No “thread per client”
Outline • • • Walk-through of redirection mechanism Details of the name-tree Preference specification Extensions to the Universal Inbox APIs for extension – Adding IAPs – Adding APC operators • Extension: Service provider’s perspective • Scaling measurements for the components – APC – Preference Registry
Extensions to the Universal Inbox
Extensions to the Universal Inbox 1 Device/Service AP Operators in APC Personal/Service mobility features Cell-Phones (#1) & Voice-over-IP (#2) (none) Call redirection/screening based on time-of-day & caller -id 2 (+) Voice-mail (#3) (none) Call redirection to voice-mail also possible, Voice-mail access from cell-phone/Vo. IP end-points 3 (+) Mail-push-client (#4) Op 1 (text to sun-audio) Op 2 (sun-audio to PCM) Op 3 (PCM to GSM) Email redirection to cellphone/Vo. IP/Voice-mail 4 (+) Instantmessage-client (#5) (none) Instant message redirection to cell-phone/Vo. IP/Voicemail
Extensions to the Universal Inbox Device/Service AP Operators in APC Personal/Service mobility features Op 4 (MPEG 3 to PCM) Jukebox access from cellphone/Vo. IP 5 (+) Jukebox-service (#6) 6 (+) Media. Manager Service (#7) (none) Media. Manager access from cell-phone/Vo. IP 7 (+) PSTN endpoints (#8) Op 5 (G. 723 to PCM) Op 6 (PCM to G. 723) Op 7 (GSM to PCM) Call redirection to PSTN, E -mail redirection to PSTN, Instant-message redirection to PSTN, Jukebox and Media. Manager access from PSTN
Adding Access to the Jukebox Service Ninja’s cluster-based Jukebox music service for streaming MP 3 s Jukebox IAP Internet-Core IAP added to enable service access from ICEBERG devices Access enabled from all ICEBERG end-points – service mobility GSM IAP VAT IAP
Implementation Experience with Extension • Examples of extension: – IAP for Ninja Jukebox • Allow service access from voice-enabled end-points • ~ 700 lines of Java • Also required addition of operators to APC service: MPEG-3 to PCM – IAP for Media. Manager • Allow access to the Media. Manager service • Similar code-size and effort • No other component had to be touched – Operators for G. 723 • Getting codec to work required effort • But, adding to APC was ~ two hours of work ( simple API for adding operators)
API’s for Extension: Adding IAPs Setup(), Terminate(), DTMF(), IAP Service. Handoff() CA Setup(), Terminate(), DTMF() Device- or service-specific part Generic part Start. Connection( ), Clean. Up() APC Extend IAPWith. CA Implement IAPIF
API’s for Extension: Adding Operators • • • APC – Java-wrapper around executable – I/O in STDIN/STDOUT – Specify executable Operator 1 Operator 2 New Operator 3 Specify I/O types Specify ADU size For process-based operators: • G. 723 codec added in 2 hrs Extend Operator Implement Operator. IF
Extension: Service Provider’s Perspective • Addition of IAPs – Deployed by service provider (e. g. , Jukebox service provider) – Or, network provider (e. g. , Cell-Phone IAP, at MSC) – Also requires addition of entries to Preference Registry, and Naming Servers • Third party providers • Addition of operators at APC – Done at third-party APC service provider – in the core network
Outline • • • Walk-through of redirection mechanism Details of the name-tree Preference specification Extensions to the Universal Inbox APIs for extension – Adding IAPs – Adding APC operators • Extension: Service provider’s perspective • Scaling measurements for the components – APC – Preference Registry
Scalability Analysis • Shared infrastructure components scaling and provisioning concerns • Would like to – Answer provisioning questions – Identify scaling bottlenecks • Three shared core components are: – APC – Preference Registry – Naming service
Scalability Analysis: APC • One round of performance optimization – Originally, operators were unix processes and one would run for each path – Now, operators can be shared across paths • Performance for the following operators – Null (copies input to output), – Toast (PCM to GSM), Untoast (GSM to PCM), and – G. 723 encoder, decoder • Path creation latency and throughput measured as a function of increasing load
Setup for Measurements Back-End node runs the operators Front-End handles the incoming requests; creates logical and physical path Back-End i. POP Cluster Front-End 500 MHz Pentium-III 2 -way multiprocessor running Linux-2. 2 with IBM’s JDK 1. 1. 8 400 MHz Pentium-II 6 ms away from the cluster (1 ms round-trip) Client
Path Creation: Latency vs. Load Untoast Operator Toast Operator About 50 ms latency for path creation
Path Creation: Throughput vs. Load Untoast Operator About 7. 2 path creations/sec at a load of 64 simultaneous paths Toast Operator
Calculation of Scaling • On average – 2. 8 calls/hour/user – Average duration of calls (path) is 2. 6 minutes • R = Call arrival rate, t = average duration of a call • L = average number of calls at a given time = R x t – A measure of the load in the system • Throughput of the system (rate of path creation) should be > (R=L/t) for system to be stable
Calculation of Scaling (Continued) • For “toast”, throughput=7. 2 paths/sec at L=64 – Throughput > L/t = 0. 44 calls/sec • Number of users N = R/call-arrival-rate • N = 0. 44/sec / 2. 8/hour = 571 • Encouraging since the telephone network uses expensive hardware equipment for these transformations (TRAU at the Inter-Working Function) • About 1/4 th of this for G. 723 decoder • G. 723 encoder: heavy-weight
Scalability Analysis: Preference Registry • Uses cluster-based distributed storage for storing preference profiles • Throughput: 55. 3 requests/sec (for dummy user preference profiles) • N = 55. 3/sec / 2. 8/hour = 71, 100 • This means about 71, 100 users for a single preference registry • Clearly not a scaling bottleneck
Additions to call-setup latency • Universal Inbox’s redirection mechanisms cause extra delay • Preference registry lookup – About 35 ms • Path creation at APC – About 50 ms • Such latencies may be high for regular call setup – Need to be brought down in the next round of implementation
- Slides: 39