Design Decisions / Lessons Learned

Monday 21 August 2000 10:15 - 10:35 Top-level design decisions Rationale for IP-based approach Why an infrastructure based approach? Leveraging cluster-computing environments: Ninja vSpace 10:35 - 12:00 Design of the ICEBERG components and capabilities Signaling protocol for flexible multi-party communication Service creation model Clearing House for resource reservation13:00 - 15:00 Design of the ICEBERG components and capabilities Automatic Path Creation service Naming service Preference Registry and Preference Manager Personal Activity Coordinator Universal Inbox for personal mobility and service mobility

Preference Registry: Outline

• Aug 21 2000, Monday– Preference registry

functionality– Preference manager

• Aug 22 2000, Tuesday– Details of implementation– Preference specification using

the preference manager GUI– Scaling numbers from

implementation

Preference Registry

• Redirection agent for incoming communication• Processes user’s preference profile• Preference registry decides user’s preferred end-point

Home Phone

Voice MailPager

Cell Phone Office Phone

Calls during business hours

Calls in theevening

AnonymousCalls

Friends & family calls

E-MailImportant

e-mail headers

Three levels of deciding factors

• User’s preference rules– Does not change often– Stored at preference registry

• Per-session factors– Caller-id– Time-of-day

• Dynamic factors– User’s location– User’s state

Preference Registry Functionality

• Input: Per-call-state, Dynamic state• Output: Callee’s preferred end-point• Input + User’s preference rules Output

Preference Registry

UserPreference

Profiles

Per Call Statee.g., Caller ID

Time of DayCaller End Point Type

Callee’s Preferred

End Point

Callee locationCallee state

OtherPersonal

State

PersonalActivity

Coordinator

Role in Call/Session Setup

Alice calls Bob; In step 4, Bob’s preference registry redirects the caller to Bob’s preferred end-point

GSM Network

Cell-Phone (Alice)

PSTN Network

Telephone (Bob)

Internet-Core

APC Service

Naming Service Bob’s Preference Registry

IAP1CA1 IAP2

CA21

2

34

5

67

89

4

Preference Registry Location

• Currently static– Can potentially be distributed and can move with the

user

• Located at user’s iPoP (ICEBERG Point of Presence)

• Location of iPoP given by the Naming Service (step 2 in the example)– (Naming service also gives the callee’s unique-id)

Preference Profile Representation

• Preferences can be complicated• Do not want to fundamentally restrict the

representation of profiles• Preference script can capture a wide-range of

preferences• Ideal for handling dynamic-input-based

decisions• Script safety issues can be handled like in

kernel packet filters (e.g., BPF/tcpdump)

Preference Profile Representation: Example

IF (9AM < hour < 5 PM)THEN Preferred-End-Point = Office-

PhoneIF (5 PM < hour < 11 PM)

THEN Preferred-End-Point = Home-PhoneIF (11 PM < hour < 9 AM)

THEN Preferred-End-Point = Voice-Mail

Preference Specification

• User uses Preference Manager GUI to create/modify rules for handling incoming communication

• GUI generates preference script and uploads it to the preference registry

PreferenceManager

GUIUser

iPOPPreferenceRegistry

Preference Specification GUI: Features

• User specifies the list of devices in which she can receive communication

• User can specify groups of known people who can call her

• She can specify time-spans during the day• Based on these, she can specify rules for

handling incoming communication

Preference Specification GUI: Features (Continued)

• Preference specification is not easy– Error-prone– User can easily make mistakes

• To handle this:– GUI has a call-simulator– User can give specific test cases and see if the

preference script indeed behaves as intended

Preference

Manager GUI

Preference Manager GUI (Continued)

Preference Registry Implementation

• TCL Scripts for preferences• JACL Java-based interpreter• Ninja’s Cluster-based Distributed Hash Table

for storing user’s preferences• 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”

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