1 / 16

Design Decisions / Lessons Learned

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

dee
Download Presentation

Design Decisions / Lessons Learned

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  6. Naming Service Bob’s Preference Registry PSTN Network GSM Network 2 4 4 3 CA1 1 5 IAP2 IAP1 CA2 7 9 6 8 Internet-Core Cell-Phone (Alice) Telephone (Bob) APC Service Role in Call/Session Setup Alice calls Bob; In step 4, Bob’s preference registry redirects the caller to Bob’s preferred end-point

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

  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

More Related