Title: Universal Inbox: Workshop
1Universal Inbox Workshop
- Bhaskaran Raman,
- ICEBERG Project, EECS, U.C.Berkeley
- Ericsson, Sweden, Aug 2000
2Developers Workshop Three Tracks
- Tuesday 22 August 2000
- 1015 - 1200 Track 1 ICEBERG Control Plane
- ICEBERG signaling protocol
- Clearinghouse Quality of Service and
secure billing - Automatic Path Creation service
- 1015 - 1200 Track 2 ICEBERG Applications
- Universal Inbox for personal mobility
and service mobility - MediaManager unified messaging
- 1015 - 1200 Track 3 ICEBERG Infrastructure
Testbed - ICEBERG testbed
- Video over wireless performance and
protocol issues - IP Telephony testbed for
congestion-based pricing
3Outline
- 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 providers perspective
- Scaling measurements for the components
- APC
- Preference Registry
4Putting it all together An Example
GSM Network
CA2
Cell-Phone (Alice)
Alice calls Bob call gets redirected to Bobs
preferred end-point in the shown steps
5Naming 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
6Name Space
Name trees corresponding to service-specific-ids
are combined in a single logical tree
7Name Space (Continued)
8Naming Service Implementation
- In ICEBERG v0
- LDAP server with modified schema
- No distribution mechanisms yet
- Tagged-tree schema of LDAP suited our
requirements well - OpenLDAP http//www.openldap.org/
- Should really be a Ninja cluster-based service
9Naming 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
10Outline
- 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 providers perspective
- Scaling measurements for the components
- APC
- Preference Registry
11Preference Specification
iPOP
Preference Registry
Preference Manager GUI
User
12Preference Specification GUI
User can specify a set of devices on which call
can be received
13Preference Specification GUI (Continued)
User can specify a set of time-spans
14Preference Specification GUI (Continued)
User can specify a groups of people (callers)
15Preference Specification GUI (Continued)
User can specify rules based on these definitions
16Preference Specification GUI (Continued)
Pecking order who can interrupt who
17Preference Specification GUI (Continued)
Call Simulator for checking rules for
correctness
18Example Preference Profile
- Setting group
- set group Unknown People
- if !string compare caller_uniqid
nobody_at_nowhere.com set group Unknown
People - if !string compare caller_uniqid
uidhelenjw,l3cs,l2berkeley,l1edu,typeuniq
set group Friends - if !string compare caller_uniqid
uidjshih,l3cs,l2berkeley,l1edu,typeuniq
set group Friends - if !string compare caller_uniqid
uidzmao,l3cs,l2berkeley,l1edu,typeuniq
set group Friends - Setting timespan
- set time expr hour 60 minute
- set timespan none
- if expr expr time gt 540 expr time lt
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
19Preference Registry Implementation
- TCL Scripts for preferences
- JACL Java-based interpreter
- Ninjas Cluster-based Distributed Hash Table for
storing users preferences
iPOP
20Some Numbers
- Release v0 implementation
- 55.3 requests/sec
- 71,000 users (2.8 calls/hour/user)
- About 36ms latency
- For 50-line dummy TCL script
- ICEBERG Release v0 based on Ninja iSpace
- Scaling bottlenecks due to RMI-based access
- Thread per client
- Next release based on Ninja vSpace
- Task-dispatch model
- No thread per client
21Outline
- 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 providers perspective
- Scaling measurements for the components
- APC
- Preference Registry
22Extensions to the Universal Inbox
23Extensions to the Universal Inbox
Device/Service AP Operators in APC Personal/Service mobility features
1 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/VoIP end-points
3 () Mail-push-client (4) Op1 (text to sun-audio) Op2 (sun-audio to PCM) Op3 (PCM to GSM) Email redirection to cell-phone/VoIP/Voice-mail
4 () Instant-message-client (5) (none) Instant message redirection to cell-phone/VoIP/Voice-mail
24Extensions to the Universal Inbox
Device/Service AP Operators in APC Personal/Service mobility features
5 () Jukebox-service (6) Op4 (MPEG3 to PCM) Jukebox access from cell-phone/VoIP
6 () MediaManager Service (7) (none) MediaManager access from cell-phone/VoIP
7 () PSTN end-points (8) Op5 (G.723 to PCM) Op6 (PCM to G.723) Op7 (GSM to PCM) Call redirection to PSTN, E-mail redirection to PSTN, Instant-message redirection to PSTN, Jukebox and MediaManager access from PSTN
25Adding Access to the Jukebox Service
26Implementation 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 MediaManager
- Allow access to the MediaManager 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)
27APIs for Extension Adding IAPs
Extend IAPWithCA Implement IAPIF
ICEBERG Release v0 http//iceberg.cs.berkeley.edu
/release/
28APIs for Extension Adding Operators
- Specify I/O types
- Specify ADU size
- For process-based operators
- Java-wrapper around executable
- I/O in STDIN/STDOUT
- Specify executable
- G.723 codec added in 2hrs
Extend Operator Implement OperatorIF
ICEBERG Release v0 http//iceberg.cs.berkeley.edu
/release/
29Extension Service Providers 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
30Outline
- 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 providers perspective
- Scaling measurements for the components
- APC
- Preference Registry
31Scalability 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
32Scalability 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
33Setup for Measurements
iPOP Cluster
34Path CreationLatency vs. Load
Untoast Operator
Toast Operator
About 50ms latency for path creation
35Path CreationThroughput vs. Load
Untoast Operator
About 7.2 path creations/sec at a load of 64
simultaneous paths
Toast Operator
36Calculation 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 gt (RL/t) for system to be stable
37Calculation of Scaling (Continued)
- For toast, throughput7.2 paths/sec at L64
- Throughput gt 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/4th of this for G.723 decoder
- G.723 encoder heavy-weight
38Scalability 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
39Additions to call-setup latency
- Universal Inboxs redirection mechanisms cause
extra delay - Preference registry lookup
- About 35ms
- Path creation at APC
- About 50ms
- Such latencies may be high for regular call setup
- Need to be brought down in the next round of
implementation