Reviews: CloneCloud

[Rodrigo Fonseca]

Hi,

Please post your reviews to CloneCloud here.

Thanks,
Rodrigo

[James Chin]

Paper Title: “CloneCloud: Boosting Mobile Device Applications Through
Cloud Clone Execution”

Authors(s): Byung-Gon Chun, Sunghwan Ihm, Petros Maniatis, and Mayur
Naik

Date: 2010

Novel Idea: This paper presents CloneCloud, a system that
automatically transforms mobile applications to benefit from the
cloud. The system is a flexible application partitioner and execution
runtime that enables unmodified mobile applications running in an
application-level virtual machine to seamlessly off-load part of their
execution from mobile devices onto device clones operating in a
computational cloud. CloneCloud uses a combination of static analysis
and dynamic profiling to optimally and automatically partition an
application so that it migrates, executes in the cloud, and re-
integrates computation in a fine-grained manner that makes efficient
use of resources.

Main Result(s): The authors’ evaluation shows that CloneCloud can
achieve up to 21.2x speedup of the smartphone applications they
tested, without programmer involvement, demonstrating the feasibility
of their approach. The results also show that CloneCloud allows
different partitioning for different inputs and networks.

Impact: CloneCloud opens up a path for a rich research agenda in
hybrid mobile-cloud systems. The underlying motivation for such a
system lies in the following intuition: as long as execution on the
cloud is significantly faster than execution on the mobile device (or
more reliable, more secure, etc.), paying the cost for sending the
relevant data and code from the device to the cloud and back may be
worth it. A fundamental design goal for CloneCloud is to allow such
fine-grained flexibility on what to run where, which traditional
client-server partitionings hardwire early on in the development
process. Another design goal for CloneCloud is to take the programmer
out of the business of application partitioning.

Evidence: For the evaluation of their prototype, the authors
implemented three mobile applications. They evaluated running those
applications either on an Android Dev Phone 1—representing the status
quo, monolithic execution—or by optimally partitioning them for two
execution settings: one with WiFi connectivity and one with 3G
connectivity. The applications they considered were a virus scanner,
image
search, and privacy-preserving targeted advertising.

Prior Work: CloneCloud is built upon previous research work done in
automatic partitioning, migration, and remote execution, and it
combines these technologies in a non-trivial way. First, it uses a
partitioning framework that combines static program analysis with
dynamic program profiling. It does partitioning in a method level,
allows placing methods that access native state remotely if they meet
partitioning constraints generated by the partitioning framework, and
uses partitioning that optimizes certain metrics. CloneCloud performs
migrating specific threads with relevant execution state including
relevant reachable heap objects. It performs migration on demand if
doing so is beneficial, and it can merge a migrated state back to the
original process.

Competitive Work: [Same as prior work.]

Reproducibility: The findings appear to be reproducible if one follows
the testing procedures outlined in this paper and has access to the
code for CloneCloud.

Question: How strong is CloneCloud in terms of fault tolerance?

Criticism: CloneCloud is limited in some respects by its inability to
migrate native state and to export unique native resources remotely.

Ideas for further work: Extend CloneCloud’s architecture to support
full concurrency between the mobile device and clones by adding thread
synchronization, heap object synchronization, on-demand paging to
access remote objects, etc.; extend CloneCloud’s basic system to check
that the execution done in the remote machine is trusted.

[Shah]

Title:

CloneCloud: Boosting Mobile Device Applications Through Cloud Clone
Execution

Authors:

[1] Byung-Gon Chun

[2] Sunghwan Ihm

[3] Petros Maniatis

[4] Mayur Naik

Source and Date:

September 16, 2010. Research Article.

Novel Idea:

The authors present the idea that cloud computing can be used to
benefit mobile devices.

Main Result:

The scientists present CloneCloud a novel system that uses a
combination of static analysis, dynamic profiling and other techniques
to transform mobile applications to employ cloud computing.

Impact:

Since this paper was only launched around two months ago, its impact
is yet to be determined.

Evidence:

The authors conduct experiments on three mobile applications and
evaluated them. All are for an Android Dev Phone 1. The applications
were run in a monolithic execution mode, a mode that employed WiFi and
one that used 3G connectivity. Further, the applications they consider
are a virus scanner, image search and privacy-preserving targeted
advertising. They then conduct experiments that measure performance
under the various workload sizes.

Prior Work:

In Section 7 the authors acknowledge that CloneCloud is built on much
previous work and proceed to divide this work into the following bins:

[1] Paritioning

[2] Migration

[3] Remote Execution

For the first, they mention, among others, Coign, MAUI, Pleiades and
Wishbone. For the second, they refer to MERPATI. For the last, among
other cited work they refer to a system called Slingshot.

Competitive Work:

Much of the work cited in the previous section can also be viewed as
competitive. The authors don’t necessarily make a clear distinction
between the two in this paper.

Reproducibility

The results are not reproducible since the applications that the
researchers used are not available freely. Also, not enough details
are available to make the experiments themselves reproducible.

Question:

Will this paper be presented at a conference?

Criticism:

The authors have a typo in the fourth paragraph in Section 4. The
first sentence is missing a ‘the’:

The migrator functionality manipulates the internal state of the
application-layer virtual machine;

Ideas for Further Work:

As the authors state in Section 8, for future work, they’d like to
explore ‘hardware augmentation that uses multiple copies of the system
image executed in different ways.’

[Matt Mallozzi]

Matt Mallozzi

11/23/10

Title:

CloneCloud: Boosting Mobile Device Applications Through Cloud Clone

Execution

Authors:

Chun, Ihm, Maniatis, Naik

Date:

2010

Novel Idea:

Offloading code executing on a mobile phone to the cloud in a fine-grained

way that aims to improve performance, reliability, energy consumption, etc.

in a way that requires no programmer effort or knowledge.

Main Results:

An implementation and evaluation of a system which meets the stated goals.

The implementation uses Android for a mobile OS and Ubuntu as the

non-mobile OS, where the managed code platform is Java (or Dalvik, on the

Android phone).

Impact:

This could have an even larger impact than MAUI, because not only can it

do everything MAUI can at a high level (optimizing for energy with little

source modification), but it has the potential to optimize for more than

just energy with zero programmer effort.

Evidence:

Like for MAUI, a few sample applications were written to test the system.

However, I think MAUI's selection of a framerate-sensitive game as one of

its sample applications was a better choice than any of CloneCloud's

sample application choices - the largest performance issue with something

like this will almost certainly be latency, so something so noticably

latency-sensitive makes a great test case.

Prior Work:

Like MAUI, this work evolves out of previous efforts that relied on manual

partitioning or coarse-grained migration.

Competitive Work:

MAUI is very similar, with the major differences being in the level of

programmer effort and the resource(s) being optimized.

Reproducibility:

CloneCloud makes heavy use of existing technologies, so much of the

reproducibility is already handled. Depending on how much of their

modifications to these existing systems are publicly available, piecing

these systems together could be moderately to extremely difficult.

Criticism:

This system also only tests with one phone!

What happened to microbenchmarks?

[Abhiram Natarajan]

Paper Title: CloneCloud: Boosting Mobile Device Applications Through
Cloud Clone Execution

Author(s): Byung-Gon Chun, Sunghwan Ihm, Petro Maniatis, Mayur Naik

Date: 26 Sep 2010, ARXIV

Novel Idea: Usage of static analysis and dynamic profiling to

optimally and automatically partition an application so that it

migrates, executes in the cloud, and re-integrates computation in a

fine-grained manner that makes efficient use of resources.

Main Result(s): CloneCloud, a system that automatically transforms
mobile applications to benefit from the cloud. CloneCloud boosts
unmodified mobile applications by seamlessly off-loading part of their
execution from the mobile device onto device clones operating in a
computational cloud.

Impact: The system is a flexible application partitioner and execution

runtime that enables unmodified mobile applications running in an
application-level virtual machine to seamlessly off-load part of their
execution from mobile devices onto device clones operating in a
computational cloud.

Evidence: The authors build a prototype that delivers up to 21.2x
speedup for some applications, without programmer involvement,
demonstrating feasibility for the approach, and opening up a path for

a rich research agenda in hybrid mobile-cloud systems.

Prior Work: There is relevant work in the following areas-
(1) Partitioning - Coign, Wishbone, Pleiades, MAUI, J-Orchestra,
Links, Hopes, UML-based HIlda, Swift
(2) Migration - MERPATI, Jessica, Java/DSM, Jessica2, cJVM, Emerald
(3) Remote Execution - Cyber Foraging, Data staging, Slignshot, ISR

Competitive Work: The authors evaluate their prototype by implementing
three mobile applications on various platforms. They also analyse the
time to run the partitioning framework.

Reproducibility: There seems to be a good bit of detail about the
system architecture. Although reproducing their exact results would
not be easy, a prototype should be buildable.

On Nov 22, 8:01 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote:

[Hammurabi Mendes]

Paper Title

CloneCloud: Boosting Mobile Device Applications Through Cloud Clone Execution

Authors

Byung-Gon Chun, Sunghwan Ihm, Petros Maniatis, Mayur Naik

Date

26-Sep-2010 (arXiv)

Novel Idea

Migrating mobile application VMs to server execution at thread
granularity and without manual intervention by the programmer.

Main Results

The system offloads application VM to execute on Cloud servers, aiming
gains on performance. The approach doesn't require user intervention,
operates at thread-level and can use specialized resource system calls
from both the mobile device and from the server system.

Impact

The paper mentions that most smartphone applications are "low-margin",
so using automated mechanism to offload application is definitely more
viable to these situations.

Evidence

The paper first describes how the application is partitioned and what
are the issues involved. It describes how profile trees are created
for the applications, the associated cost assignment, and how the
optimization problem is formulated.

The evaluation consists of three applications subject to variations in
input size. The results show that when WiFi is available, the offload
tends to occur more frequently as compared to the 3G case (as the 3G
connectivity is slower, it has such impact on the optimization
calculation).

Prior Work + Competitive Work

The related work section is extensive. When discussing previous work
in partitioning, systems as Coign, Wishbone, Pleiades and MAUI are
cited. The paper also mentions systems for partitioning Java programs,
and others that concern on doing the same on other high-level
languages.

Concerning migration, they mention MERPATI (which they claim to assume
a cluster of homogeneous machines connected via a fast network).
Interestingly (!), they cite some distributed shared memory approaches
(Jessica, Java/DSM).

Finally, they discuss some approaches for remotely executing code.

Reproducibility

The paper doesn't provide a clear description of the applications
tested, but ones with similar characteristics could be found given the
overwhelming variety of those.

The server side of the evaluation section is poorly discussed, which
clearly compromises the reproducibility.

Questions + Criticism

[Criticism] I believe that the evaluation section focuses solely in
one dimension of the problem (namely speedup), and forgets the others.
The connectivity dimension is somewhat covered (WiFi vs 3G), but I
think this distinction is too coarse-grained: with different latencies
in the WiFi case (like the MAUI paper), interesting information
regarding whether the code is offloaded or not could provide a better
insight on the solver "fitness".

[Question] How the cost of migrating could be dynamically evaluated,
in order to be taken into account in the optimization framework?

On Mon, Nov 22, 2010 at 8:01 PM, Rodrigo Fonseca
<rodrigo...@gmail.com> wrote:

[Siddhartha Jain]

Siddhartha Jain

Title: CloneCloud

Novel Idea:
Targeted towards improving performance rather that energy efficiency unlike MAUI. The partitioning is done dynamically. First the legal partitions are identified by the static analyzer. Then the application is profiled by the dynamic profiler. The optimization solver finds a legal partition based on this information. The partitioning process is done offline.

Main Results:
The partitioning process is described and results are given.

Evidence:
We observe a good amount of speedup for various apps.

Prior Work:
Coign partitions apps built out of COM components. The partition points are the COMs. Wishbone and Pleidas convert a program into multiple pieces of code. Prior work on JVM migration.

Reproducibility:
Doesn't seem to be publicly available so hard to reproduce.          

On Mon, Nov 22, 2010 at 8:01 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[Basil Crow]

Title: CloneCloud: Boosting Mobile Device Applications Through Cloud
Clone Execution

Authors: Byung-Gon Chun, Sunghwan Ihm, Petros Maniatis, and Mayur Naik

Date: 26 September 2010

Novel idea: A combination of static analysis and dynamic profiling can
be used to partition a mobile application effectively without any
explicit annotations from the developer. Additionally, we can migrate
entire threads efficiently and automatically from mobile device to
server.

Main results: The CloneCloud implementation uses Android and the
Dalvik VM and results in a 21x speedup for some applications.

Evidence: The authors tested CloneCloud with a virus scanner, image
search, and targeted-advertising. CloneCloud chose to keep local more
workloads when using 3G than when using Wifi.

Competitive work: Unlike MAUI, CloneCloud works on unmodified
executables and does not require the developer to explicitly annotate
"remoteable" functions.

Reproducibility: Although the implementation details are significantly
more detailed in this paper than in MAUI, there still does not seem to
be any source code available.

Criticism: The performance evaluation section could be stronger.

On Mon, Nov 22, 2010 at 8:01 PM, Rodrigo Fonseca
<rodrigo...@gmail.com> wrote:
>

[Jake Eakle]

CloneCloud:BoostingMobileDeviceApplications 

ThroughCloudCloneExecution

Byung-GonChun, Sunghwan Ihm, Petros Maniatis, Mayur Naik

Paper Title
Author(s)
Date	2010
Novel Idea	This paper is interestingly similar to MAUI, but comes at it from a broader angle. It's nice to read two contemporary, directly competing papers and see how they differ. CloneCloud has two major differences from MAUI: It explicitly targets any and all resources that can be enhanced by migration to the cloud, not just battery life (though in their prototype they focus on execution time); and it wants to remove all effort from the programmer entirely.
Main Result(s)	As this is very similar to MAUI, about which I have just written a lot, I will take a page from MAUI and attempt to save bandwidth by simply computing the delta. The code and environment analysis portion of CloneCloud's approach is more in-depth than MAUI's, but also more brittle - since they run everything offline and store it in a table, they may not be able to correctly optimize for unforeseen conditions. However, they also thereby avoid a major source of overhead, which may compensate for this even in the worst scenarios (which should be uncommon if you did the analysis well).  CloneCloud offloads entire threads, which in a single-threaded app isn't much different from what MAUI does as the points at which offload and reintegration can happen are still method entrance and exit. However, their model is more formal and abstract, which seems to have the concrete benefit of making it clear to them how to handle multi-threaded programs, which the MAUI authors seemed to struggle with. They do also employ a heap delta strategy to reduce migration bandwidth, but they seem to use a coarser-grained approach, taking a delta only from the original Android Zygote process rather than from constantly updated checkpoints.
Impact	Again, hopefully lots soon!
Evidence	Since their tested goal is execution time rather than battery life, it's hard to directly compare this section to MAUI, but it seems to be of comparable quality (though, as with everything in this paper, it takes a higher view -- MAUI got into the nitty-gritty of TCP slow start, these guys treat the network as a black box and just report final times). Their speedups are quite a bit greater, but they are also running very different kinds of applications. MAUI's evaluation section is maybe a little more honest, in that they choose examples (games, voice recognition, face recognition) that exemplify the largely user-facing nature of phone apps. CloneCloud's examples, while reasonable, avoid highly interactive user interfaces, with two of them, virus scanning and ad targeting, normally running entirely behind the scenes.
Prior Work	Similar list of prior VM work, of which there is tons.
Reproducibility	Significantly less than MAUI, I would say. Their implementation section is less than a page long, and while it tells you generally what they did, it doesn't go very far toward helping you do the same.
Question	How bad is it if they get the shared-native-state annotations wrong? It seems like it would be pretty bad, since they don't migrate that state at all, and presumably things could need it to like, work. Why don't they address this?
Criticism	This paper takes a much higher view than MAUI did, and as a result is at once more and less useful. It seems like they are building a more solid theoretical foundation for their work, but at the expense of attention to detail. There are a lot of things they gloss over: how the configurations and inputs to do dynamic analysis on are chosen; where all the partition binaries are stored (they can't all be on the phone, right? right??);
Ideas for further work	I suppose the natural thing is a more side-by-side comparison of this and MAUI. Some questions to look into include: when does on-device profiling give you important flexibility? Can MAUI's model extend cleanly to multithreaded apps like CloneCloud does?

-- 
A warb degombs the brangy. Your gitch zanks and leils the warb.

[Rodrigo Fonseca]

On Behalf of Tom:

CloneCloud: Boosting Mobile Device Applications Through Cloud Clone Execution

Byung-Gon Chun, Sunghwan Ihm, Petros Maniatis, Mayur Naik

26 Sept 2010

Novel Idea:

Rapid advancements in mobile device technology, combined with the rise in popularity of "cloud" and remote computing motivate the authors to improve mobile applications by offloading computation to remote services. While this practice is itself not quite novel, the manner in which they go about doing so is.  They combine static and dynamic runtime analysis to determine when/which portions of an application can benefit from a shift from local to remote computation on a VM clone of the device. By targeting applications that run on top of a virtual machine layer (i.e. Java and .Net) the analysis and migration process is simplified. Their constraint solver can be tweaked to constrain different resources, but they focus primarily on application speed.

Main Result:

They implement a prototype on the Andriod platform (Java) with promising results, claiming up to 21.2X speedup on their test applications.  Their performance improvements are pretty good, especially considering that their system requires no source code changes and minimal involvement of the developer. 

Evidence:

They evaluate 3 applications (virus scanning, image processing and personalized ads) with and without CloneCloud connected via WiFi and 3G.

Impact:

While the performance improvement is great, but I think it will require WiFi and 3G/4G providers to offer CloneCloud computing services before it can really catch on.`

Reproducibility:

They provide a good high level overview of their system, but it lacks some important details which might make it hard to build a similar system. If the code is open source (I don't know), that might not be much of an issue.  I think we'd need far more detail about the test applications in order to verify their test results.

Prior/Competitive Work:

MAUI, which is geared solely toward reducing energy consumption and requires source level annotations.  Lots of prior work on partitioning applications both manually (Wishbone, Peiades, Links, Hops, Hilda) and automatically (Coign, J-Orchestra). In the application migration scene they mention various efforts to migrate java apps and do distributed JVMs.  Finally they cite research in remote execution, when expensive/compute intensive resources are accessed remotely.

Questions:

How many method calls/optimization points were in each of their test applications? They noted that they limited the granularity to the method level for the sake of keeping the ILP problem solvable in a resonable amount of time. Does an application ever become too big to optimize?  On that note, is the hardness of the optimization the reason why they only optimize for one constriant (speed) and not multiple constraints?

Criticism:

MAUI was careful to note that RTT's played an important role on deciding when to offload computation, and CloneCloud doesn't really consider this in their evaluation. They give the latencies for WiFi and 3G (66ms and 416ms respectively), but they don't consider the effect of multiple/varying latencies.  

Also, it would have been nice to see some numbers on the overhead of various aspects of their system. How long does the constraint solver take? How much memory does the object mapping table use?  etc.

Future Work:

There are many enhancements to be made to improve the CloneCloud experience.  For example, I don't think they consider the load on the server when deciding to offload computation.  On a busy cloud service, this would probably be something that has to be taken into consideration.

Also, it would be interesting to see a comparison between MAUI and CloneCloud optimizing for energy rather than speed.

On Mon, Nov 22, 2010 at 8:01 PM, Rodrigo Fonseca <rodrigo...@gmail.com> wrote:

[Joost]

Title: CloneCloud: Boosting Mobile Device Applications Through Cloud
Clone Execution
Authors: Byung-Gon Chun, Sunghwan Ihm, Petros Maniatis, Mayur Naik
Date: September 2010

Novel Idea: By moving heavy computation from mobile devices into the
cloud, users can experience much faster queries and device speed.
Main Results: The authors successfully implemented a system which
seeks to partition computation between the phone and the cloud. The
partitioning is done based on an optimization algorithm which takes
into account connection strength, size of computation, and amount of
data that needs to be transferred.
Impact: As such technology becomes more ubiquitous it is likely that
every phone will have some computations being performed off-site,
though for the moment this seems to be a more theoretical research
area, as few applications use anywhere near the computation necessary
to gain significant performance increases for the user.
Evidence: The authors ran a Virus Scan, an Image Search, and a
Behavior profiling, using sets three sets for each (all an order of
magnitude apart in size ie 1Mb 10MB 100MB). They showed that the
smaller operations stay local and don't make use of the cloud
computation, though the larger imputes did indeed migrate to the
cloud, and show at the top levels an order of magnitude increase in
throughput.
Prior Work: In terms of partitioning they built mostly off of work
related to MAUI and Microsoft COM, though other systems were also
referenced. With regards to Migration of data they built largely on
work in Java Virtual Machines. And finally in terms of remote
execution their research builds on cyber foraging.
Reproducibility: Given sufficient time and resources, the authors
provided enough of a design overview, and implementation summary to
design an experiment that tests similar methods.
Criticism/Question: Aren't most instances where a user would run a
computation heavy procedure already on the cloud through the fact that
the user would be running these applications through a web browser on
his/her phone. Also wouldn't it make more sense for developers to run
most of this through a specified server or cluster so as to gain the
most benefit from caching and precomputing as possible.

On Nov 22, 8:01 pm, Rodrigo Fonseca <rodrigo.fons...@gmail.com> wrote: