1. Universal In-box Bhaskaran Raman Iceberg, EECS ISRG Retreat, Jan 2000
January 11, 2000
Universal In-Box
Bhaskaran Raman
Iceberg, EECS
ISRG Retreat, Jan 2000
In this talk, I’ll be talking about the Universal In-box - an application that has been central to the design of Iceberg from the beginning. The focus of the talk will be on the experience gained from building the application - what was easy, what was hard, open questions, and future directions.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

2. Iceberg Retreat, January 2000
Universal In-box
January 11, 2000
Outline
Universal In-box: What is it?
Application requirements
How to satisfy the requirements?
Implementation status
Lessons learnt
Summary, open questions
The outline of the talk is as follows:
I’ll start out by explaining what we mean by the Universal In-box, its characteristics. I’ll explain this in the context of an integrated network scenario, namely, Iceberg.
Then, I’ll briefly mention what capabilities exist currently - capabilities similar to what the Universal In-box tries to offer. I won’t spend too much time on this since the purpose of the talk is not provide a thorough comparison with what exists. I mention these more to place the Iceberg scenario in context.
With that background, I’ll move on to discuss the application requirements. What are the different features, capabilities, or properties that we’d like to have of such an application, when it is deployed and under service.
Given the requirements, I’ll discuss how these are met in Iceberg; how the different Iceberg components provide the necessary flexibility.
Then, after mentioning what currently exists in implementation, I’ll present the lessons learnt from the experience of building the application.
I’ll end the talk with a summary and a set of open issues.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

3. Universal In-box: What is it?
January 11, 2000
Integration
Speech-to-Text
Speech-to-Voice Attached-
Call-to-Pager/ Notification
-to-Speech
All compositions
of the above!
Universal In-box
Let me start by explaining what we mean by the Universal In-box.
This slide is from one of the Iceberg overview talks. You’re probably familiar with it.
The “universal in-box” stands for unified management of different communication mechanisms. The unified management provides the notion of a “universal” in-box to the end user. The user can access or receive any communication from any end-device. Some examples are listed above. And the management is done in accordance with a policy or a flexible set of user-specified preferences.
Policy-based
Location-based
Activity-based
Personalization
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

4. Universal In-box: What is it?
January 11, 2000
Universal In-box: What is it?
One of the first Iceberg applications
Wide range of requirements
Canonical hybrid service
Related efforts:
commercial products
PCS efforts: UMTS, IMT2000, UPT
MPA (Stanford), TOPS (AT&T)
As I mentioned, the universal in-box was one of the first Iceberg applications that we built.
The wide range of requirements that the application has, that we’re going to talk about shortly, made it an appropriate choice.
As a canonical hybrid service, this application has driven a lot of the initial design. And the purpose of this talk is to present the experience in building the application, so that the feedback and further discussions can help in further design of Iceberg.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

5. Application Requirements (Goals)
Universal In-box
January 11, 2000
Application Requirements (Goals)
Extend to new networks
Different generations of PCS networks
Micro-cellular networks
Pico-cellular (BlueTooth Scatternets)
Extend to new devices
CDMA phones, 2-way pagers, Palm VII, Visor
Device of the future
The universal in-box, as its name might suggest, it a cross-network service.
This does not just mean that it should be able to operate in the different kinds of existing networks. More importantly, it means that we should be able to extend it to new networks. There are different kinds of PCS networks that are being deployed, multiple generations of these are planned. New networks with CDMA technology. Micro-cellular and pico-cellular networks would come into existence in the future.
When the universal in-box is deployed and is in use, making it available in these new networks should involve minimal effort. This is what we mean by the goal of “Extensibility” in Iceberg. This means a clean separation between the network dependent and network independent parts, and a flexible deployment model are required.
The same holds for new kinds of devices as well. When a new device with new capabilities is introduced, the service should extend to such a device with no changes to the core architecture. The same set of functional features should be available on the new device as well.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

6. Application Requirements (Goals)
Universal In-box
January 11, 2000
Application Requirements (Goals)
Accommodate new data formats
new codecs
better speech recognition/generation
Personalization
very important
Somewhat related to the previous requirement is the following. We should be able to integrate new codec technology, new audio/video formats, or new format conversion techniques with ease. These are important when we talk about different kinds of devices.
These extensibility goals form one class of “deploy-once, access-anywhere” requirements. The goal of Iceberg is not just to provide these for one application, but to provide these in a generic fashion for a wide-range of services.
Orthogonal to these extensibility goals is the customizability requirement. This is very crucial (switch slide) for a feature like the universal in-box.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

7. Application Requirements (Goals)
Universal In-box
Application Requirements (Goals)
January 11, 2000
Personalization is crucial
This picture is from one of the handout write-ups.
Being able to specify how to handle incoming communication is a crucial capability to have for the universal in-box. Where to receive what calls, which calls to go to /dev/null, which s to read out on cell-phone, which instant-messages to forward as , etc.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

8. Application Requirements (Goals)
Universal In-box
January 11, 2000
Application Requirements (Goals)
Further requirements
Scaling to a large user-base
Working in the wide-area
Resilient to failures
Security and privacy
There are further important requirements, like scaling to zillions of users, location independent operation in the wide-area. Such a service is likely to be used for mission-critical purposes. Availability and fault-tolerance are important.
When managing personal communication, privacy and security issues have to be handled. I’m not going to go into the details of this, but there’s a short write-up on this available as a handout, for those who missed the poster yesterday.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

9. Iceberg Retreat, January 2000
Universal In-box
January 11, 2000
Outline
Universal In-box: What is it?
Application requirements
How to satisfy the requirements?
Implementation status
Lessons learnt
Summary, open questions
Now that’s a wide range of requirements. Lets now see how these are met in Iceberg, and the underlying (switch slide) design principles.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

10. Meeting the Requirements
Universal In-box
January 11, 2000
Meeting the Requirements
Design principles
Network independence
Device independence
Pushing control to the callee
Leverage Ninja Service platform
for service availability and fault-tolerance
For extensibility, we need to have a clean separation of the “dependent” and “independent” portions. And build most of the application functionality in a network and device independent manner.
Pushing control of communication towards the callee, away from the caller, is the underlying design principle for achieving the goal of personalization. This was also identified in the Mobile People project.
For wide-area operation, build mechanisms in a location independent manner, and have an appropriate level of indirection for operation in the wide-area.
For the goals of making the service available all the time and making it scalable, we commit Error-33. We leverage Ninja. What this means is that the architectural components should be modeled as generic services that can run in Ninja-bases. And we should be clear on which component has what kind of state (i.e. hard vs. soft).
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

11. Iceberg Retreat, January 2000
Universal In-box
January 11, 2000
Iceberg Components
Here’s a quick look at the Iceberg Architecture (I’m hoping that Helen covers this in the tutorial earlier) with the different components. IAPs at the edges of the networks and different components in the Internet core: the Naming servers, Preference Registries, PAC, APC-Server.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

12. Meeting the Requirements
Universal In-box
January 11, 2000
Meeting the Requirements
Network Independence
Provided by IAP
Addition of a new n/w
Develop a new IAP
And deploy multiple IAPs
Device Independence
Device name independence
Device type independence
The IAP is the component that provides the separation between the network dependent and independent parts. What this means is that, extending the universal in-box, or any Iceberg service to a network, would involve developing an IAP to connect to the end-points in that network. And deploying a number of them at different points.
An IAP essentially provides a generic call setup interface to access an end-point in the network from the world outside.
The deployment is helped a great deal by the fact that the IAPs are independent of one another, and are also independent of the rest of the components of the network.
We split device independence into name independence and type independence.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

13. Meeting the Requirements
Universal In-box
January 11, 2000
Meeting the Requirements
Name independence
use any end-point id
hierarchical, distributed naming service
level of indirection, for wide-area operation
Data-Type independence
APC Service
Ninja paths (operators + connectors)
Adding data formats is as simple as writing the relevant operators
Name independence essentially means that you don’t have to worry about multiple name spaces that result when we use different kinds of devices: -addresses, telephone numbers, pager numbers, etc. Additionally, we don’t have to worry about problems like not being able to type an address on a POTS phone.
Name independence is provided by a distributed naming service akin in structure to the DNS. This is the level of indirection that I alluded to earlier. This is also used in some of the security mechanisms - I’m not going to go into these right now.
Device type independence is provided by the Automatic Path Creation Service that is based on paths. Adding support for new data formats could be as simple as writing an operator.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

14. Meeting the Requirements
Universal In-box
January 11, 2000
Meeting the Requirements
Personalization
Preference profiles
scripts
GUI for generating profiles
Preference-Registry
storing and processing profiles
PAC for dynamic inputs
Preference-Registry: a service in a Ninja-Base
The mechanism for personalization is centered around the Preference-Registry component. The PR stores and processes user preference profiles and provides an interface for getting at the current user preferences for handling communication.
We represent preference profiles as scripts and have a GUI for generating the scripts.
The PR interfaces with the PAC for getting dynamic inputs. This interface has not yet been implemented so far. We have implemented (switch slide)...
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

15. Meeting the Requirements
Preference Manager
February 25, 2019
Iceberg Retreat, January 2000

16. What has been implemented?
Universal In-box
January 11, 2000
What has been implemented?
IAPs
for GSM testbed, VAT, Voic service, Instant-Messaging (Sanctio)
APC Service (Emre/Barbara, Morley)
Naming Service: LDAP
Preference Registry: iSpace service
Preference Manager GUI (Rahul)
Personal Activity Coordinator (PAC) - Xia
Here’s the implementation status.
We have implemented IAPs for interfacing to GSM cell-phones, interfacing to the desktop telephony tool VAT, an bare-bones VoIP voic service, and recently one to interface to the instant-messaging system, Sanctio, built in Ninja.
We’ve been using the APC Service developed by Emre and Barbara for the Room-Control Service. It does not have support for real-time audio streams; the one Morley worked on last semester has - she’ll be talking about it in the parallel track.
We’ve been using an LDAP server to implement a Naming Server. This should really be a Ninja iSpace service.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

17. Lessons learnt: What was easy?
Universal In-box
January 11, 2000
Lessons learnt: What was easy?
Extension to include a new communication service (Sanctio)
Built IAP (proxy) to interface Sanctio end-points to Iceberg
Making the service available at all end-points after the extension
Cell-Phone, VAT, Potentially POTS-Phone
So what has the exercise taught us? Building the different components for providing universal in-box capabilities.
What were the things that were really easy?
One of the things that we implemented was an interface to an instant-messaging system. The Sanctio system was also built in Ninja, quite independent of Iceberg. Extending the universal in-box to include the instant-messaging system was quite simple. The particular capability we built was to read out instant-messages on an Iceberg end-point.
We had all the infrastructure components in place: the APC Service, the Pref-Reg service, the Naming Service. The interfacing, given all these things existing, involved building a proxy, or IAP, in Iceberg terminology. A no-frills implementation had less than 300 lines of Java code.
What’s important is not just the interfacing itself. But the fact that the interfacing had to be done only once, in a generic fashion. The service was now available in cell-phones as well as IP desktop end-points with no additional support. At that point, we did not have POTS end-points or pager end-points in our testbed. Even if those had existed, the effort involved would have been the same!
The crucial point here is that the effort involved in building a service is independent of the number of varied networks and devices it is made available on.
Effort involved in building a service is independent of the number of networks it is made available on
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

18. Lessons learnt: Why it was easy?
Universal In-box
January 11, 2000
Lessons learnt: Why it was easy?
What gave the flexibility?
Separation of concerns: network, device-name and device-type independence
Deployment flexibility - anyone can deploy an IAP
IAP can interface to a network or a generic service end-point
Modeling components as services
What really gave the flexibility was the separation of concerns. One just has to deal with what’s specific to that particular service - all other things are free (accessibility from different networks, and different devices).
Deployment flexibility is also an advantage. In deploying an IAP, I don’t have to worry about other components, services, or databases that might exist in the core network. I don’t have to worry about changing configurations anywhere. And anybody with a hook into a network (there’s a catch there) can deploy an IAP to interface the network to Iceberg services.
Since an IAP essentially stands for an interface to the external world, it can be written for interfacing with a network or with a generic service. In this case of the Sanction instant-messaging service, it was the latter.
Finally, modeling middleware components as services makes things easy. Can take advantage of a generic service building and service deploying infrastructure.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

19. Lessons learnt: What was hard?
Universal In-box
January 11, 2000
Lessons learnt: What was hard?
Getting the interfaces right
still may not be generic enough
can the pref-reg interface support other services?
Scaling measurements
Client problems:
socket problems, client saturation, RMI too slow
Server problems:
RMI too slow, JVM bugs, (thread) scheduling problems
What was hard?
Getting the interface between the components is certainly something to worry about. This changed quite a few times - the interface exported by the IAP, exported by the Pref-Reg. In all probability, the interfaces we have now may not be generic enough for all kinds of services. We’ll take this up for discussion in one of the break-out sessions.
One of the things that has been particularly hard is to measure the scaling performance of the components that we built - to see where the bottlenecks are. Hopefully, this would also come up in the other breakout session in the form of “What is the testing platform we need for this kind of evaluation”.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

20. Iceberg Retreat, January 2000
Universal In-box
January 11, 2000
Summary
Key idea: Infrastructure components for network/device independence, personalization
Important to get interfaces right
Good experience in building and extending a hybrid service
To summarize, the key idea behind the design for the universal in-box capability was the provision of network and device independence through different middleware components.
The universal in-box has been a good experience in building and extending a hybrid service. It has driven a lot of the design. And the purpose of this talk was to get more feedback to drive further design.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

21. Iceberg Retreat, January 2000
Universal In-box
January 11, 2000
What next?
Interface to new APC service
Interface to PAC
Implement security mechanisms
Usability of Preference-Manager
We are yet to interface the universal in-box with the new APC service that Morley has built, the PAC service. The architecture needs to be tested on more telephony and IN services; some interfaces are probably going to change. There are scaling and provisioning concerns. In the near future, we plan to implement the security mechanisms, and also on the usability of the preference manager GUI that has been developed.
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000

22. Further Open Questions
Universal In-box
January 11, 2000
Further Open Questions
Interfaces and Components:
What is a flexible interface between the Pref-Reg and the PAC?
Other middleware components for other services?
Testing platform for testing scalability, fault-tolerance, etc.
Handling feature interactions
Your question goes here…
There are a lot of open questions.
The question of a suitable interface to be exported by the Pref-Reg, and the PAC.
What other generic middleware components can be provided for other kinds of capabilities?
Handling feature interactions that are bound to get triggered when we have complicated capabilities.
Integration with billing mechanisms - how do you bill the use of existing 3rd party middleware components?
February 25, 2019
Iceberg Retreat, January 2000
Iceberg Retreat, January 2000