17-811 Self-Healing Systems: Class Discussion Summary

Summary of Class Discussion for April 7 by Owen Cheng
 

Administrative items

1. Class schedule updated, pairing of presentation due to time constraint and to fit in guest speakers.
2. Wed, Apr 22, Asim can come later, Professor will email about pushing class meeting time back
3. Final report
• Explaining to somebody else who might be interested
• Easy intro of area
• Pointers to more detailed reading
• End goal: Tech report of class
• Est. 5-10 pages, not self-contained paper, but the most relevant aspects, a large portion being annotated bib of ~dozen papers

Joao on Ubicomp, and what adaptation means in context

1. Papers
1. Balan, Sousa, Satya. paper: extract the nuts-and-bolt mechanisms and interfaces
2. Problem characterization
1. Dynamic variation of environment capabilities, no idea at all of what resources might be available
2. Dynamic variation from users:
1. "Daily tasks"--continuous, constantly interrupted,
3. Goal: maximize utility in terms of cost-benefit
1. new cost dimension--cost of opportunity
2. Examples:
1. Between task A and related task B, if user wants to do A, system can inform user of better resources for task B.
2. ...
4. Primary tools/techniques are "models"
3. Jungsoo's scenario:
1. Moving to a cluster of computers, which device would the system choose?
2. Joao: User picks location (assuming adequate location info), and system figures out which best device near that user's location; system may suggest alternative location.
3. David: Interesting interactions between the system and the user, because the user cannot really be controlled.
1. In part, to avoid distraction; balance of how much transparency in the system's doing and how much the user has to be aware of.
4. Joao: At present, we're not dealing with user competition, but we can certainly build more sophistication on top of the task framework.
4. Rainbow and Kramer's solutions both fall short in the Ubicomp context, in terms of missing models of environment and the users.
5. Aura approach:
• Supplier has a "blue" layer, which communicates in the same protocol as the Aura components, in terms of models.
• The Rainbow approach is encapsulated in the "Supplier" box (in Rainbow's context, its framework is global, in the Aura context, it's kept local at the supplier level, i.e., the model is only the local parts relevant to component.)
• David: Mid-point between the Kramer and Rainbow approaches
• Bhuricha: Who knows about what suppliers are out there?
• Joao: EM monitors and manages what suppliers are in the environment, but cannot control the suppliers' behavior
• David: In contrast to Rainbow, is there a disadvantage in needing to wrap the components?
• Joao: Perhaps, but if the "Translator" layer is generic enough, the same Rainbow approach can be applied across the suppliers, and the assumption (to treat the suppliers as adaptive components with the "blue" layer) remains the same.

 
• Vahe: Blue layer represents adaptation at the application layer; what's the criteria of painting a layer blue?
• Joao: Blue indicates the part that holds representation of the models
• Vahe: What's painted in blue in Aura, do we actually represent that?
• Joao: Yes, EM does hold model of environment and suppliers (refer to data structures Vahe and Joao discussed from another meeting), but cannot control the behavior of the suppliers.

 
• Paul: [...]

 
• Vahe: Say if adaptation occurs in a lower layer (say Chroma), does user observe that directly through the green boxes?
• Joao: What the user sees is actually a result of the policies in the blue boxes

 
• Paul: Contradition of policies, e.g., Supplier not following policy, is that a problem?
• Joao: Not really, because EM would monitor to make sure that the Supplier's behavior conforms to policy; if not, EM may bring in another Supplier

 
• David: Raised the issue of whether the middle green box "Service Suppliers" is something missing in Rainbow, i.e., why have we not felt the need for such a box in Rainbow.
• Joao: Notion of abstract service as service description vs "service" referring to applications. The needs of Ubicomp requires this abstract notion of service, to cope with resource heterogeniety. In a world that is not changing so dynamically, this abstract notion does not appear to add any benefit
• Owen: If Rainbow is managing a system built of web services, where the notion of service can be abstract, fulfilled by any implementation of that service contract, then that "service suppliers" notion might become necessary.

 
• Knowledge of User shrinks as we move down the layers, while knowledge of environment grows.
• Bradley/David: perhaps we need to be careful about saying "knows alot about the environment" in the lower layers, because it's not the global env't, but low-level details of the localized env't of a component that it knows.
• David: also, might consider another column that represents the "globalness" of the knowledge of env't, which grows as we move up the layers.

 
• Note symmetry of I/O with A/M. I.e., output of one is input of another, and so is the monitoring of one the adaptation of the other.
• This paradigm suggests that monitoring information from one layer becomes the adaptative info of the other layer, rather than a command to that layer.
• This reflects the deeper issue of assumption of reliability: command paradigm implies reliable components/interactions, but in this world, there is no way to rely on the commanded component to do as commanded, which would result in brokenness. The monitor/adapt paradigm relaxes this requirement in reliable interaction and allows a component to seek another component if current interaction is not what's expected.