Universal Inbox: Workshop

1
Universal Inbox Workshop

• Bhaskaran Raman,
• ICEBERG Project, EECS, U.C.Berkeley
• Ericsson, Sweden, Aug 2000

2
Developers 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

3
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 providers perspective
• Scaling measurements for the components
• APC
• Preference Registry

4
Putting 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
5
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

6
Name Space
Name trees corresponding to service-specific-ids
are combined in a single logical tree
7
Name Space (Continued)
8
Naming 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

9
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

10
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 providers perspective
• Scaling measurements for the components
• APC
• Preference Registry

11
Preference Specification
iPOP
Preference Registry
Preference Manager GUI
User
12
Preference Specification GUI
User can specify a set of devices on which call
can be received
13
Preference Specification GUI (Continued)
User can specify a set of time-spans
14
Preference Specification GUI (Continued)
User can specify a groups of people (callers)
15
Preference Specification GUI (Continued)
User can specify rules based on these definitions
16
Preference Specification GUI (Continued)
Pecking order who can interrupt who
17
Preference Specification GUI (Continued)
Call Simulator for checking rules for
correctness
18
Example 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

19
Preference Registry Implementation

• TCL Scripts for preferences
• JACL Java-based interpreter
• Ninjas Cluster-based Distributed Hash Table for
  storing users preferences

iPOP
20
Some 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

21
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 providers perspective
• Scaling measurements for the components
• APC
• Preference Registry

22
Extensions to the Universal Inbox
23
Extensions 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
24
Extensions 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
25
Adding Access to the Jukebox Service
26
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 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)

27
APIs for Extension Adding IAPs
Extend IAPWithCA Implement IAPIF
ICEBERG Release v0 http//iceberg.cs.berkeley.edu
/release/
28
APIs 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/
29
Extension 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

30
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 providers perspective
• Scaling measurements for the components
• APC
• Preference Registry

31
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

32
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

33
Setup for Measurements
iPOP Cluster
34
Path CreationLatency vs. Load
Untoast Operator
Toast Operator
About 50ms latency for path creation
35
Path CreationThroughput vs. Load
Untoast Operator
About 7.2 path creations/sec at a load of 64
simultaneous paths
Toast Operator
36
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 gt (RL/t) for system to be stable

37
Calculation 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

38
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

39
Additions 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