1. 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 reservation 13: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

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

3. Preference Registry Redirection agent for incoming communication Processes user’s preference profile Preference registry decides user’s preferred end-point Home Phone Voice Mail Pager Cell Phone Office Phone Calls during business hours Calls in the evening Anonymous Calls Friends & family calls E-Mail Important e-mail headers

4. 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

5. Preference Registry Functionality Input: Per-call-state, Dynamic state Output: Callee’s preferred end-point Input + User’s preference rules  Output Preference Registry User Preference Profiles Per Call State e.g., Caller ID Time of Day Caller End Point Type Callee’s Preferred End Point Callee location Callee state Other Personal State Personal Activity Coordinator

6. 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 IAP1 CA1 IAP2 CA2 1 2 3 4 5 6 7 8 9 4

7. 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)

8. 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)

9. Preference Profile Representation: Example IF (9AM < hour < 5 PM) THEN Preferred-End-Point = Office-Phone IF (5 PM < hour < 11 PM) THEN Preferred-End-Point = Home-Phone IF (11 PM < hour < 9 AM) THEN Preferred-End-Point = Voice-Mail

10. 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 Preference Manager GUI User iPOP Preference Registry

11. 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

12. 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

13. Preference Manager GUI

14. Preference Manager GUI (Continued)

15. 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”

16. 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