Tactics Based Remote Execution for Mobile Computing

Motivation 

Today, mobile phones are the most popular computing devices but continue to be constrained on resources. Many useful and interactive applications are extremely resource intensive. Using local or on device resources not only increase latency but are often inaccurate e.g. speech translation. Performance in general can be greatly improved by outsourcing heavy tasks or opportunistically using extra resources in the environment allowing smaller devices to run intensive adaptive mobile applications.

Main Points 

- Chroma is a runtime system which dynamically adapts to different conditions of resource availability. This system is built using tactics.  

- Tactics is an abstraction which takes into account application specific knowledge required for optimal remote execution. 

- Chroma aims to be a simple system for application writers which is optimal ( or close to ) under all conditions and completely seamless from the user's perspective

- Chroma's design can be broken down into two parts :
1. Tactic description - done at code level in the application which provides information regarding execution plan and tactic number 

2. Selecting the best tactic for Remote execution which is done using brute force. 

>>> The number of tactics may not be small. This paper has no data to back this claim. 

- Additionally, the selection process takes as input the remote execution tactic description, a utility function ( user specific objective function ), resource availability and a resource demand predictor. 

>>> The demand predictor uses history based prediction which may not necessarily be accurate because a lot of parameters may have changed in under a minute. The inherent nature of using a mobile device e.g., network congestion, change of location, change of input parameters etc 

  

- Paritioning of an application in Chroma means identifying the application components which can be remotely executed.  Meaningful partitions cannot  be automatically determined. They use application specific knowledge to avoid sub optimal partitioning.  

Others

- Currently, They have battery consumption de-prioritized and users don't have flexibility to define utility functions to change this. 

- They perform data decomposition on certain tasks but don't describe how it is done, e.g. what are the correctness guarantee? 

- I am unsure how the initialization of history logs for tactic selection is done. Are they using unseen training data to learn prediction values. This may bias the output of the prediction model. 

- They assume coarse grained tasks and tasks with simple data dependencies. i.e., based on prototypes only. Another limitation for real world applications. For e.g. global shared data etc.