2013 IEEE International Conference on Cloud Engineering

The Impact of Mobile Multimedia Applications on Data Center Consolidation

Kiryong Ha∗ , Padmanabhan Pillai† , Grace Lewis‡ , Soumya Simanta‡ , Sarah Clinch§ ,
Nigel Davies§ and Mahadev Satyanarayanan∗
∗ Carnegie Mellon University, Email: {krha, satya}@cs.cmu.edu,
† Intel Labs,
Email: [email protected]
‡ CMU-SEI, Email: {ssimanta, grace}@sei.cmu.edu,
§ Lancaster University, Email: [email protected], [email protected]

Abstract—The convergence of mobile computing and cloud of this class of applications. In the past, centralization was
computing enables new multimedia applications that are both the dominant theme of cloud computing. This is reflected in
resource-intensive and interaction-intensive. For these appli- the consolidation of dispersed compute capacity into a few
cations, end-to-end network bandwidth and latency matter
greatly when cloud resources are used to augment the computa- large data centers. For example, Amazon Web Services spans
tional power and battery life of a mobile device. We first present the entire planet with just a handful of data centers located
quantitative evidence that this crucial design consideration in Oregon, northern California, Virginia, Ireland, Singapore,
to meet interactive performance criteria limits data center Tokyo, and São Paolo. The underlying value proposition of
consolidation. We then describe an architectural solution that is cloud computing is that centralization exploits economies
a seamless extension of today’s cloud computing infrastructure.
of scale to lower the marginal cost of system administration
Keywords-Cloud Computing; Mobile Computing; Data Cen- and operations. These economies of scale evaporate if too
ter Placement; Cloudlets; Virtual Machines; Network Latency;
many data centers have to be maintained and administered.
Wireless Networks; Face Recognition; Speech Recognition;
Object Recognition; Augmented Reality; Aggressive global consolidation of data centers implies
large average separation between a mobile device and its
I. I NTRODUCTION cloud. End-to-end communication then involves many net-
The convergence of cloud computing and mobile com- work hops and results in high latencies. Section IV quantifies
puting has begun. Apple’s Siri for the iPhone [1], which this point using measurements from Amazon EC2. Under
performs compute-intensive speech recognition in the cloud, these conditions, achieving crisp interactive response for
hints at the rich commercial opportunities in this emerging latency-sensitive mobile applications will be a challenge.
space. Rapid improvements in sensing, display quality, con- Limiting consolidation and locating small data centers much
nectivity, and computational capacity of mobile devices will closer to mobile devices would solve this problem, but it
lead to new cloud-enabled mobile applications that embody would sacrifice the key benefit of cloud computing.
voice-, image-, motion- and location-based interactivity. Siri How do we achieve the right balance? Can we support
is just the leading edge of this disruptive force. latency-sensitive and resource-intensive mobile applications
Many of these new applications will be interactive as well without sacrificing the consolidation benefits of cloud com-
as resource-intensive, pushing well beyond the processing, puting? Section V shows how a two-level architecture can
storage, and energy limits of mobile devices. When their reconcile this conflict. The first level of this hierarchy is
use of cloud resources is in the critical path of user in- today’s unmodified cloud infrastructure. The second level is
teraction, end-to-end operation latencies can be no more new. It consists of dispersed but unmanaged infrastructure
than a few tens of milliseconds. Violating this bound results with no hard state. Each second-level element is effectively
in distraction and annoyance to a mobile user who is a “second-class data center” with soft state generated locally
already attention-challenged. Such fine-grained cloud usage or cached on demand from the first level. Data center
is different from the coarse-grained usage models and SLA proximity to mobile devices is thus achieved by the second
guarantees that dominate cloud computing today. level without limiting the consolidation achievable at the
The central contribution of this paper is the experimental first level. Communication between first and second levels
evidence that these new applications force a fundamental is outside the critical path of interactive mobile applications.
change in cloud computing architecture. We describe five Throughout this paper, the term “cloud computing” refers
example applications of this genre in Section II, and experi- to transient use of computational cloud resources by mobile
mentally demonstrate in Section III that even with the rapid clients. Other forms of cloud usage such as processing of
improvements predicted for mobile computing hardware, large datasets (data-intensive computing) and asynchronous
such applications will benefit from cloud resources. The re- long-running computations (agent-based computing) are out-
mainder of the paper explores the architectural implications side the scope of this paper.

978-0-7695-4945-3/13 $26.00 © 2013 IEEE 166

DOI 10.1109/IC2E.2013.17
 II. M OBILE M ULTIMEDIA A PPLICATIONS efforts aim for general purpose information query, device
Beyond today’s familiar desktop, laptop, and smartphone control, and language translation using speech input on
applications is a new genre of software to seamlessly aug- mobile devices [1], [6], [7].
ment human perception and cognition. Consider Watson, The speech recognition application considered here is
IBM’s question-answering technology that publicly demon- based on an open-source speech-to-text framework based on
strated its prowess in 2011 [2]. Imagine such a tool being Hidden Markov Model (HMM) recognition systems [8]. It
available anywhere and anytime to rapidly respond to urgent takes as input digitized audio of a spoken English sentence,
questions posed by an attention-challenged mobile user. and attempts to extract all of the words in plain text format.
Such a vision may be within reach in the next decade. Free- This application is single-threaded. Since it is written in
form speech recognition, natural language translation, face Java, it can run on both Linux and Microsoft Windows. For
recognition, object recognition, dynamic action interpreta- this paper, we ran it on Linux.
tion from video, and body language interpretation are other
examples of this genre of futuristic applications. Although C. Object and Pose Identification (O BJECT)
a full-fledged cognitive assistance system is out of reach A third application is based on a computer vision al-
today, we investigate several smaller applications that are gorithm originally developed for robotics [9], but modified
building blocks towards this vision. Five such applications for use by handicapped users. The computer vision system
are described below. identifies known objects, and importantly, also recognizes
A. Face Recognition (FACE) the position and orientation of the objects relative to the
user. This information is then used to guide the user in
A most basic and fundamental perception task is the manipulating a particular object.
recognition of human faces. The problem has been long Here, the application identifies and locates known objects
studied in the computer vision community, and fast al- in a scene. The implementation runs on Linux, and makes
gorithms for detecting human faces in images have been use of multiple cores. The system extracts key visual ele-
available for some time [3]. Identification of individuals ments (SIFT features [10]) from an image, matches these
through computer vision is still an area of active research, against a database of features from a known set of objects,
spurred by applications in security and surveillance tasks. and finally performs geometric computations to determine
However, such technology is also very useful in mobile the pose of the identified object. For the experiments in this
devices for personal information management and cognitive paper, the database is populated with thousands of features
assistance. For example, an application that can recognize a extracted from more than 500 images of 13 different objects.
face and remind you who it is (by name, contact information,
or context in which you last met) can be quite useful to D. Mobile Augmented Reality (AUG R EAL)
everyone, and invaluable to those with cognitive or visual
impairments. Such an application is most useful if it can be The defining property of a mobile augmented reality
used anywhere, and can quickly provide a response to avoid application is the display of timely and relevant information
potentially awkward social situations. as an overlay on top of a live view of some scene. For
The face recognition application studied here detects faces example, it may show street names, restaurant ratings or
in an image, and attempts to identify the face from a pre- directional arrows overlaid on the scene captured through
populated database. The application uses a Haar Cascade of a smartphone’s camera. Special mobile devices that incor-
classifiers to do the detection, and then uses the Eigenfaces porate cameras and see-through displays in a wearable eye-
method [4] based on principal component analysis (PCA) glasses form factor [11] can be used instead of a smartphone.
to make an identification. The implementation is based on AUG R EAL uses computer vision to identify actual build-
OpenCV [5] image processing and computer vision routines, ings and landmarks in a scene, and label them precisely
and runs on a Microsoft Windows environment. Training in the view [12]. This is akin to an image-based query in
the classifiers and populating the database are done offline, Google Goggles [13], but running continuously on a live
so our experiments only consider the execution time of the video stream. AUG R EAL extracts a set of features from the
recognition task on a pre-trained system. scene image, and uses the feature descriptors to find similar-
looking entries in a database constructed using features from
B. Speech Recognition (S PEECH) labeled images of known landmarks and buildings. The
Speech as a modality of interaction between human users database search is kept tractable by spatially indexing the
and computers is a long studied area of research. Most data by geographic locations, and limiting search to a slice
success has been in very specific domains or in applications of the database relevant to the current GPS coordinates. The
requiring a very limited vocabulary, such as interactive voice prototype application uses a dataset of 1005 labeled images
response in phone answering services, and hands-free, in- of 200 buildings as the relevant database slice. AUG R EAL
vehicle control of cell phones. Several recent commercial runs on Microsoft Windows, and makes significant use of

167
 Application Average request size Response size Dell Latitude 2102 Samsung Galaxy S2
FACE 62 KB < 60 bytes CPU Intel Atom N550 ARM Cortex-A9
SPEECH 243 KB < 50 bytes 1.5 GHz per core 1.2 GHz per core
OBJECT 73 KB < 50 bytes 2 cores (4 threads) 2 cores
AUGREAL 26 KB < 20 bytes RAM 2 GB 1 GB
FLUID 16 bytes 25 KB Storage 320 GB 16 GB
Figure 1. Average request & response size of each application OS Linux, Windows Android
Figure 3. Dell Netbook Device Used in Experiments

Typical Server Typical Handheld

are simple text strings. In F LUID application, however, the
Year Processor Speed Device Speed
requests are streams of sensed motion information using
1997 Pentium II 266 MHz PalmPilot 16 MHz accelerometer data, so each request is just a few bytes. The
response data is the state of the simulated world, so unlike
2002 Itanium 1 GHz Blackberry 133 MHz the other applications, the responses here are much larger
5810 than the requests.

2007 Core 2 9.6 GHz Apple 412 MHz III. W HY C LOUD R ESOURCES ARE N ECESSARY
(4 cores) iPhone A. Mobile Hardware Performance
2011 Xeon X5 32 GHz Samsung 2.4 GHz Handheld or body-worn mobile devices are always
(2x6 cores) Galaxy S2 (2 cores) resource-poor relative to server hardware of comparable
vintage [16]. Figure 2, adapted from Flinn [14], illustrates
Figure 2. Evolution of Hardware Performance (adapted from Flinn [14]) the consistent large gap in the processing power of typical
server and mobile device hardware over a 15-year period.
OpenCV libraries [5], Intel Performance Primitives (IPP) This stubborn gap reflects a fundamental reality of user
libraries, and multiple processing threads. preferences: Moore’s Law has to be leveraged differently
on hardware that people carry or wear for extended periods
E. Physical Simulation and Rendering (F LUID)
of time. This is not just a temporary limitation of current
Our final application is used in computer graphics. Using mobile hardware technology, but is intrinsic to mobility. The
accelerometer readings from a mobile device, it physically most sought-after features of a mobile device always include
models the motion of imaginary fluids with which the user light weight, small size, long battery life, comfortable er-
can interact. For example, it can show liquid sloshing around gonomics, and tolerable heat dissipation. Processor speed,
in a container depicted on a smartphone screen, such as memory size, and disk capacity are secondary.
a glass of water carried by the user as he walks or runs. All the experiments in this paper use a Dell Latitude 2102
The application backend runs a physics simulation, based on as the mobile device. This small netbook machine is more
the predictive-corrective incompressible smoothed particles powerful than a typical smartphone today (Figure 3), but it
hydrodynamics (PCISPH) method [15]. We note that the is representative of mobile devices in the near future.
computational structure of this application is representative
of many other interactive applications, particularly “real- B. Extremes of Resource Demands
time” (i.e., not turn-based) games. At first glance, it may appear that today’s smartphones
F LUID is implemented as a multithreaded Linux are already powerful enough to support mobile multimedia
application. To ensure a good interactive experience, the applications without leveraging cloud resources. Some digi-
delay between user input and output state change has to tal cameras and smartphones support built-in face detection.
be very low, on the order of 100ms. In our experiments, Android 4.0 APIs support tracking of multiple faces and
F LUID simulates a 2218 particle system with 20 ms give detailed information about the location of eyes and
timesteps, generating up to 50 frames per second. mouth [17]. Google’s “Voice Actions for Android” per-
forms voice recognition to allow hands-free control of a
Figure 1 shows average request and response sizes for smartphone [18]. Lowe [19] describes many computer vision
each application. All applications send requests with input applications that run on mobile devices today.
data from the mobile device and receive back computed However, upon closer examination, the situation is much
results based on the inputs. The average request size is more complex and subtle. Consider computer vision, for
tens of kilobyte for a captured image and several hundreds example. Its computational requirements vary drastically
kilobytes for a recorded speech input. The response size depending on the operational conditions. For example, it
is typically less than 100 bytes as the returned results is possible to develop (near) frame-rate object recognition

168
 Application Condition 1 Condition 2 Condition 3 No Cloud With Cloud
SPEECH 0.057 s 1.04 s 4.08 s Application median 99% median 99%
FACE 0.30 s 3.92 s N/A SPEECH 1.22 s 6.69 s 0.23 s 1.25 s
Figure 4. Average response time of applications on mobile device under FACE 0.42 s 4.12 s 0.16 s 1.47 s
different conditions (see Sect. III-B) Figure 5. Response times with and without cloud resources.

(including face recognition [20]) operating on mobile com- such as low lighting and deliberately distorted optics.
puters if we assume restricted operational conditions such as Such data-dependent and context-dependent tradeoffs ap-
a small number of models (e.g., small number of identities ply across the board to virtually all applications of this
for person recognition), and limited variability in observa- genre. In continuous use under the widest possible range
tion conditions (e.g., frontal faces only). The computational of operating conditions, providing near real-time responses,
demands greatly increase with the generality of the problem and tuned for very low error rates, these applications have
formulation. For example, just two simple changes make ravenous appetites for processing, memory and energy re-
a huge difference: increasing the number of possible faces sources. They can easily overwhelm a mobile device.
from just a few close acquaintances to the entire set of
C. Improvement from Cloud Computing
people known to have entered a building, and reducing the
constraints on the observation conditions by allowing faces Performance improves considerably when cloud resources
to be at arbitrary viewpoints from the observer. are leveraged. Figure 5 shows the median and 99th percentile
response times for the S PEECH and FACE experiments of
To illustrate the great variability of execution times pos-
Figure 4 with and without use of cloud resources. For the
sible with perception applications, we perform a set of
speech case, we leverage an Amazon EC2 instance. For
experiments using two of the applications discussed earlier.
the face recognition application, we use a private cloud.
We run the S PEECH and FACE applications on the mobile
Although variability in execution times still exists, the
platform, and measure the response times for a wide variety
absolute response times are significantly improved. These
of inputs. Figure 4 shows the results. For the speech applica-
experiments confirm that leveraging cloud resources can
tion, execution times generally increase with the number of
improve user experience for mobile multimedia applications.
words the algorithm recognizes (correctly or otherwise) in an
utterance. Conditions 1, 2, 3 for this application correspond IV. E FFECTS OF C LOUD L OCATION
to sentences in which no words, 1–5 words, and 6–22 In reality, “the cloud” is an abstraction that maps to ser-
words are recognized, respectively. The response time varies vices in sparsely scattered data centers across the globe. As a
quite dramatically, by almost 2 orders of magnitude, and user travels, his mobile device experiences high variability in
is acceptable only when the application fails to recognize the end-to-end network latency and bandwidth to these data
any words. When short phrases are correctly recognized, the centers. We examine the significance of this variability for
response time is marginal, at just over 1 second, on average. mobile multimedia applications. Response time for remote
For longer sentences, when the application works at all, it operations is our primary metric. Energy consumed on the
just takes too long. For comparison, Agus et al. [21] report mobile device is a secondary metric. Application-specific
that human subjects recognize short target phrases within metrics such as frame rate are also relevant.
300 to 450 ms, and are able to tell that a sound is a human
voice within a mere 4 ms. A. Variable Network Quality to the Cloud
In the case of the face recognition application, the best In this paper, we focus on Amazon EC2 services provided
response times occur when there is a single, large, recog- by several data centers worldwide. We use the labels “East,”
nizable face in the image. These correspond to Condition 1 “West,” “EU,” and “Asia” to refer to the data centers located
in Figure 4. It fares the worst when it searches in vain at in Virginia, Oregon, Ireland and Singapore. We measured
smaller and smaller scales for a face in an image without any end-to-end latency and bandwidth to these data centers from
faces (Condition 2). Unfortunately, response time is close a WiFi-connected mobile device located on our campuses in
to the latter for images that only contain small faces. At Pittsburgh, PA and Lancaster, UK. We also repeated these
close to 4-second average response time in these conditions, measurements from off-campus sites with excellent last-mile
this application is unacceptably slow. For comparison, recent connectivity in these two cities. Figure 6 and 7 present our
experimental results on human subjects by Ramon et al. [22] measurements, and quantify our intuition that a traveling
show that recognition times under controlled conditions user will experience highly variable cloud connectivity.
range from 370 milliseconds for the fastest responses on There are also some surprises in the data.
familiar faces to 620 milliseconds for the slowest response One surprise is the amazingly good connectivity to EC2
on an unfamiliar face. Lewis et al. [23] report that human East from our Pittsburgh, PA campus. From a wired connec-
subjects take less than 700 milliseconds to determine the tion, we measured 8 ms ping times and 200 Mbps transfer
absence of faces in a scene, even under hostile conditions rates to this site. Such numbers are more typical of LAN

169
 Ideal Measured on campus Measured off campus
EC2 Latency BW to/from Cloud (Mbps) Latency (ms) BW to/from Cloud (Mbps) Latency (ms)
site (ms) Day 1 Day 2 Day 3 min. median. 90% Day 1 Day 2 Day 3 min. median. 90%

East 1.8 28 / 34 42 / 34 20 / 15 8.7 9.2 12.4 5.1 / 13.7 5.1 / 14.2 5.1 / 13.4 13.8 17.9 21.3
West 24.2 12 / 14 20 / 18 11 / 2.5 91.6 92.1 95.5 5.0 / 13.9 5.1 / 13.6 4.9 / 13.4 83.9 90.3 93.8
EU 36.8 3.6 / 0.9 13 / 0.4 7.6 / 0.9 98.3 99.3 103.0 4.9 / 13.8 5.0 / 11.8 4.8 / 13.3 110 112 115
Asia 102.5 10 / 0.5 2.4 / 0.2 3.0 / 0.4 255 265 272 4.6 / 9.4 4.6 / 9.2 4.4 / 9.7 266 277 286

Figure 6. Measured Network Quality to Amazon EC2 Sites from Carnegie Mellon University (Pittsburgh, PA) (”Ideal” is at speed of light)

Ideal Measured on campus Measured off campus

EC2 Latency BW to/from Cloud (Mbps) Latency (ms) BW to/from Cloud (Mbps) Latency (ms)
site (ms) Day 1 Day 2 Day 3 min. median. 90% Day 1 Day 2 Day 3 min. median. 90%

East 38.5 4.7 / 5.2 4.7 / 5.2 5.6 / 5.5 86.6 89.4 101 0.8 / 3.3 1.9 / 4.7 0.6 / 3.1 97.3 106 123
West 54.3 5.4 / 3.5 5.4 / 3.5 3.6 / 3.6 155 159 208 0.5 / 2.4 1.4 / 2.8 0.7 / 2.6 165 182 201
EU 1.7 6.7 / 10.4 6.7 / 10.4 8.0 / 10.5 16.2 32.7 63.4 1.7 / 9.4 2.5 / 14.5 1.4 / 7.6 31 43.6 64
Asia 73.2 4.7 / 2.6 4.7 / 2.6 6.2 / 2.7 273 279 325 0.3 / 1.6 1.4 / 1.9 0.5 / 1.6 259 272 291

Figure 7. Measured Network Quality to Amazon EC2 Sites from Lancaster University (Lancaster, UK) (”Ideal” is at speed of light)

connections than WAN transfers! We believe that this is data centers and blocks until it receives the result.
due to particularly favorable network routing between our The sixth case, labeled “1WiFi,” corresponds to the the-
campus and the EC2 East site. This hypothesis is confirmed oretical best-case for data center location. With today’s
by the poorer off-campus measurements shown in Figure 6. deployed wireless technology, this is exactly one WiFi hop
Thus, our EC2 East on-campus results best serve to indicate away from a mobile device. This can only be approximated
what one can expect from a LAN-connected private cloud. today in special situations: e.g., on a WiFi-covered campus,
Li et al. [24] report that average round trip time (RTT) from with access points connected to a private data center through
260 global vantage points to their optimal Amazon EC2 a lightly-loaded gigabit LAN backbone. If naively imple-
instances is 73.68 ms. Therefore, the EC2 West numbers mented at global scale, 1WiFi would lead to a proliferation
in Figure 6 are more typical of cloud connectivity. of data centers. Section V discusses how the consolidation
Another surprise is the great range of bandwidths ob- benefits of cloud computing can be preserved while scaling
served, particularly the upload/download asymmetry and out the 1WiFi configuration.
the significant variation between experiments. To mitigate Figure 8 compares the characteristics of the compute
this time-varying factor, we scheduled our experiments on platforms used in our configurations. For 1WiFi, we create
weekday nights when conditions were stable and bandwidth a minimal data center using a six-year old WiFi-connected
consistently high. All experiments in the rest of the paper server. The choice of this near-obsolete machine is delib-
were run under these conditions on campus in Pittsburgh. erate. By comparing it against a fast mobile device and
fast EC2 cloud instances, we have deliberately stacked the
B. Impact on Response Time deck against 1WiFi. Hence, any wins by this strategy in our
We next evaluate how cloud connectivity affects the experiments should be considered quite meaningful.
applications described in Section II. We consider six cases. FACE: Figure 9 summarizes the response times mea-
The first, labeled “Mobile,” runs the application entirely sured for FACE under different conditions. Here, we test with
on the mobile device. Cloud connectivity is irrelevant, but 300 images that may have known faces, unknown faces, or
the resource constraints of the mobile device dominate. In no faces at all. Processing on the mobile device alone can
four other cases, the mobile device performs the resource- provide tolerable response times for the easier images, but is
intensive part of each operation on one of the four Amazon crushed by the heavy-tailed distribution of processing costs.
Only 1WiFi can provide fast response (<200ms) most of
Mobile 1WiFi Cloud (East, West, EU, Asia) the time, and a tolerable worst case response time. Hence,
CPU Atom E5320 Xeon N550 X-Large Instance 1WiFi is the best approach to running FACE.
1.5 GHz 1.86 GHz 20 Compute Units
2 cores, 4 threads 4 cores 8 virtual cores S PEECH: Results for S PEECH are somewhat different
RAM 2 GB 4 GB 7 GB (Figure 10). Here, the application generally requires sig-
VMM none KVM Xen,VMware
nificant processing for each query, and data transfer costs
Figure 8. Platform specifications are modest. This changes the relative performance of the

170
 1 1
mobile
0.8 1WiFi 0.8
F 0.6
A east 0.6
C 0.4 west 0.4
E 0.2 eu
0.2
asia
0 0
0 200 400 600 800 1000 0 1000 2000 3000 4000 5000
Figure 9. FACE: Cumulative distribution function (CDF) of response times in ms (300 images).

1 1
mobile
S 0.8 1WIFI 0.8
P 0.6 east 0.6
E
E 0.4 west 0.4
C 0.2 eu 0.2
H 0 asia
0
0 200 400 600 800 1000 0 1000 2000 3000 4000 5000
Figure 10. S PEECH: CDF of response times in ms (500 WAV files, each recording one sentence).

1 1
O mobile
0.8 1WiFi 0.8
B
0.6 east 0.6
J
E 0.4 west 0.4
C 0.2 eu
0.2
T asia
0 0
0 200 400 600 800 1000 0 1000 2000 3000 4000 5000
Figure 11. O BJECT: CDF of response times in ms (300 images).

1 1
A mobile
U 0.8 0.8
1WiFi
G 0.6 east 0.6
R west
0.4 0.4
E
eu
A 0.2 0.2
asia
L 0 0
0 200 400 600 800 1000 0 1000 2000 3000 4000 5000
Figure 12. AUG R EAL: CDF of response times in ms (100 images).

1 mobile 1
F 0.8 1WiFi 0.8
L 0.6 east 0.6
U
I 0.4 west 0.4
D 0.2 eu
0.2
asia
0 0
0 200 400 600 800 1000 0 1000 2000 3000 4000 5000
Figure 13. F LUID: CDF of response times in ms (10 minute runs, accelerometer data sampled every 20ms). (see also Figure 14)

Mobile 1WiFi East West EU Asia

Normalized Displayed (W) 14.8 12.6 11.4 10.9 11.0 11.0
FACE
Simulation Frame Rate (J/query) 16.4 5.4 6.6 8.5 9.5 14.3
Speed (FPS) (W) 16.1 14.5 14.5 14.4 14.4 14.4
S PEECH
mobile 0.2 9.2 (J/query) 22.5 8.2 5.3 11.2 12.2 26.9
1WiFi 1.0 49.8 (W) 16.8 14.5 14.5 14.6 14.5 14.5
O BJECT
east 1.0 42.8 (J/query) 107.0 48.2 28.9 41.5 35.3 43.8
west 1.0 10.3 (W) 13.9 11.7 11.3 11.7 11.3 11.3
AUG R EAL
eu 1.0 3.6 (J/query) 3.3 1.1 3.1 5.1 5.2 9.4
asia 1.0 1.6 (W) 17.0 15.8 15.9 15.8 15.8 15.7
F LUID
Figure 14. Simulation speed, frame rate for F LUID. (J/frame) 1.9 0.3 0.4 1.8 4.6 10.7
Figure 15. Energy consumption on mobile device

171
 1 1
mobile
S 0.8 1WIFI-i7 0.8
P 0.6
E
east 0.6
E 0.4 west 0.4
C 0.2 eu 0.2
H 0 asia
0
0 200 400 600 800 1000 0 1000 2000 3000 4000 5000
Figure 16. Experiments of Figure 10 repeated with faster 1WiFi machine

1
local 1
O 0.8 1WiFi-i7
B 0.8
0.6 east
J 0.6
E 0.4 west
0.4
C 0.2 eu
0.2
T 0 asia
0
0 200 400 600 800 1000 0 1000 2000 3000 4000 5000
Figure 17. Experiments of Figure 11 repeated with faster 1WiFi machine

strategies significantly. As the response time is dominated reading), to when that input is reflected in the output.
by processing time, this favors the more capable but distant This largely reflects three factors: the execution time of a
servers in the cloud over the weak 1WiFi server. Processing simulation step, network latency, and data transfer time for
without cloud assistance is out of the question. For S PEECH, a frame from the simulation thread. As seen in Figure 13,
using the closest EC2 data center is the winning strategy. To local execution on the mobile device produces good response
understand the effect of a more powerful 1WiFi machine, times, since all but the first factor are essentially zero.
we repeated that experiment with an Intel i-3770 desktop. However, simulation speed and frame rate also need to be
The results shown in Figure 16 confirm that 1WiFi now considered (Figure 14). The simulation runs asynchronously
dominates the alternatives. to the inputs and display, and tries to match simulated time
O BJECT: Compared to the previous two applications, with wall-clock time. Since the mobile device cannot execute
O BJECT requires significantly greater compute resources. the simulation steps fast enough, fluid motions are less than
Unfortunately, the processing load is so large that none of one fifth of realistic speeds. The cloud strategies do not
the approaches yield acceptable interactive response times have this issue, but due to bandwidth and network latencies,
(Figure 11). This application really needs more resources cannot deliver the results of the simulation fast enough to
than our single VM instances or weak 1WiFi server can sustain the full frame rate. Only 1WiFi and East can deliver
provide. To bring response times down to reasonable levels both good responsiveness and high frame rates.
for interactive use, we will either need to parallelize the
application beyond a single machine/VM boundary and em- C. Impact on Energy Usage
ploy a processing cluster, or make use of GPU hardware to Battery life is a key attribute of a mobile device. Exe-
accelerate critical routines. Both of these potential solutions cuting resource-intensive operations in the cloud can greatly
are beyond the scope of this paper. Using the faster 1WiFi reduce the energy consumed on the mobile device by the
machine (Intel i-3770) does help significantly (Figure 17). processor(s), memory and storage. However, it increases
AUG R EAL: This application employs a low-cost fea- network use and wireless energy consumption. Since peak
ture extraction algorithm, and an efficient approximate processor power consumption exceeds wireless power con-
nearest-neighbor algorithm to match features in its database. sumption on today’s high-end mobile devices, this tradeoff
While these processing costs are modest, data transfer costs favors cloud processing as computational demands increase.
are high because of image transmission. Therefore, as shown Network latency has recently been shown to increase energy
in Figure 12, none of the EC2 cases is adequate for this ap- consumption for remote execution by as much as 50%, even
plication. They generally provide slower response times than if bandwidth and computation are held constant [25], [14].
execution on the mobile device. 1WiFi, on the other hand, This is because hardware elements of the mobile device
works extremely well for this application, providing very fast remain in higher-power states for longer periods of time.
response times (around 100ms) needed for crisp interactions. Figure 15 summarizes energy consumption on our mobile
This is clearly the winning strategy for AUG R EAL. device for the experiments described in Section IV-B. For
F LUID: Response time for F LUID is defined as the time each application, the first row shows the power dissipation
between the sensing of a user action (i.e., accelerometer in watts, averaged over the whole experiment. In all cases,

172
 Today’s
Unmodified Cloud
(Level 1 Data Centers)

(a) Outdoor (b) Solar Powered (c) Indoor

Figure 19. Unattended Micro Data Centers (Sources: [28], [29])
Internet
V. S CALING O UT 1W I F I
We thus face contradictory requirements. On the one hand,
1WiFi 1WiFi 1WiFi
the 1WiFi property is valuable for mobile computing. On
the other hand, it works against consolidation because there
Level 2 data center
Level 2 data center Level 2 data center
and associated
have to be many data centers at the edges of the Internet
and associated and associated
mobile devices mobile devices mobile devices to ensure 1WiFi cloud access everywhere. Consolidation is
Figure 18. Two-level Hierarchical Cloud Architecture the essence of cloud computing because dispersion induces
diseconomies of scale: the marginal cost of administering
this quantity shows little variation across data centers. Local machines in a centralized data center is typically lower than
execution on the mobile device incurs the highest power when they are spread over smaller data centers. How can
dissipation. Note that the netbook platform has a high we reconcile these contradictory requirements?
baseline idle power dissipation (around 10W), so the relative
improvement in power is likely to be larger on more energy- A. Concept
efficient hardware.
We assert that the only practical solution to this problem
Average power dissipation only tells part of the story.
is a hierarchical organization of data centers, as shown in
Cloud use also tends to shorten the time to obtain a result.
Figure 18. Level 1 of this hierarchy is today’s unmodified
When this is factored in, the energy consumed per query
cloud infrastructure such as Amazon’s EC2 data centers.
or frame is dramatically improved. These results are shown
Level 2 consists of stateless data centers at the edges of
in the second row for each application in Figure 15. In the
the Internet, servicing currently-associated mobile devices.
best case, the energy consumed per result is reduced by a
We envision an appliance-like deployment model for
factor of 3 to 6. The strategies that exhibit the greatest energy
Level 2 data centers. They are not actively managed after
efficiency are also the ones that give the best response times.
installation. Instead, soft state (such as virtual machine
D. Summary and Discussion images and files from a distributed file system) is cached on
The results of Sections IV-B and IV-C confirm that logical their local storage from one or more Level 1 data centers. It
proximity to data center is essential for mobile applications is the absence of hard state at Level 2 that keeps management
that are highly interactive and resource intensive. By “log- overhead low. Consolidation or reconfiguration of Level 1
ical proximity” we mean the end-to-end properties of high data centers does not affect the 1WiFi property at Level 2.
bandwidth, low latency and low jitter. Physical proximity Adding a new Level 2 data center or replacing an existing
is only weakly correlated with logical proximity because of one only requires modest setup and configuration. Once
the well-known “last mile” problem [26]. configured, a Level 2 data center can dynamically self-
1WiFi represents the best attainable logical proximity. provision from Level 1 data centers.
Our results show that this extreme case is indeed valuable Physical motion of a mobile device may take it far from
for many of the applications studied, both in terms of the Level 2 data center with which it is currently associated.
response time and energy efficiency. It is important to keep Beyond a certain distance, the 1WiFi property may no
in mind that these are representative of a new genre of longer hold. In that case, a mechanism similar to wireless
cognitive assistance applications that are inspired by the access point handoff can be executed to seamlessly switch
sensing and user interaction capabilities of mobile devices. association to a different Level 2 data center.
Mobile participation in server-based multiplayer games such
as Doom 3 is another use case that can benefit from logical B. Physical Realization
proximity [27]. The emergence of such applications can be The hardware technology for Level 2 data centers is al-
accelerated by deploying infrastructure that assures mobile ready here today for reasons unrelated to mobile computing.
users of continuous logical proximity to the cloud. The situ- For example, Myoonet has pioneered the concept of micro
ation is analogous to the dawn of personal computing, when data centers for use in developing countries (Figure 19(a)
the dramatic lowering of user interaction latency relative to and (b)) [28]. AOL has recently introduced indoor micro-
time-sharing led to entirely new application metaphors such data centers for enterprises (Figure 19(c)) [29]. Today, these
as the spreadsheet and the WYSIWYG editor. micro data centers are being used as Level 1 data centers

173
in private clouds. By removing hard state and adding self- tamper-evident enclosures, remote surveillance, and TPM-
provisioning, they can be repurposed as Level 2 data centers. based attestation will all be more important at Level 2.
In the future, one can envision optimized Level 2 data The speed of provisioning is another major differentiator
centers for 1WiFi. For example, with modest engineering between Level 1 and Level 2. Today, Level 1 data centers
effort, a WiFi access point could be transformed into a are optimized for launching VM images that already exist
“nano,” “pico,” or “femto” Level 2 data center by adding in their storage tier. They do not provide fast options for
processing, memory and storage. instantiating a new custom image. One must either launch an
While much innovation and evolution will undoubtedly existing image and laboriously modify it, or suffer the long,
occur in the form factors and configurations of future Level tedious upload of the custom image over a WAN. In contrast,
2 data centers, we can identify four key attributes that any Level 2 data centers need to be much more agile in their
such implementation must possess: provisioning. Their association with mobile devices is highly
• Only soft state: It does not have any hard state, but only dynamic, with considerable churn due to user mobility. A
cached state from Level 1. It may also buffer data from user from far away may unexpectedly show up at a Level
a mobile device en route to Level 1. 2 data center (e.g., if he just got off an international flight)
• Powerful, well-connected and safe: It is powerful and try to use it for an application such as a personalized
enough to handle resource-intensive applications from language translator. For that user, the provisioning delay
multiple associated mobile devices. Bandwidth between before he is able to use the application impacts usability.
Level 1 and Level 2 is good, typical WAN latency is We see at least three different approaches to rapid provi-
acceptable, and network failures are rare. Battery life is sioning at Level 2. One approach is to exploit higher-level
not a concern. It can be trusted as a computing platform. hints of user mobility (e.g., derived from online schedules,
• Close at hand: It is easily deployable within one Wi-Fi travel information, real-time tracking, explicit user guid-
hop of associated mobile devices. ance, etc.) to pre-provision Level 2 data centers. A second
• Builds on standard cloud technology: It leverages and approach is to launch a VM instance at Level 2 without
reuses Level 1 software infrastructure and standards provisioning delay, and then demand page the VM state as
(e.g. OpenStack [30]) as much as possible. execution proceeds. This reduces startup delay at the cost of
unpredictable delays during execution. The feasibility of this
C. Operating Environment approach has been shown in the Internet Suspend/Resume
system [31] and other similar systems. A third approach is to
There is significant overlap in the requirements specifi- synthesize the desired VM state from a pre-cached base VM
cations for Levels 1 and 2. At both levels, there is the and a relatively small dynamically-transmitted overlay [32],
need for: (a) strong isolation between untrusted user-level [33], [34]. Exploring the tradeoffs and optimizations in this
computations; (b) mechanisms for authentication, access space will be important future research, but the feasibility
control, and metering; (c) dynamic resource allocation for of dynamic provisioning is not in doubt.
user-level computations; and, (d) the ability to support a Unique to Level 2 is the problem of dynamic discovery by
very wide range of user-level computations, with minimal re- mobile clients, as a precursor to association. One approach
strictions on their process structure, programming languages is manual selection, using a mechanism similar to what is
or operating systems. At Level 1, these requirements are already in use today for choosing WiFi networks based on
met today using the virtual machine (VM) abstraction. For their SSIDs. More sophisticated solutions could also be built,
precisely the same reasons they are so valuable at Level 1, leveraging existing low-level service discovery mechanisms
we foresee VMs as central to Level 2. such as UPnP, Bluetooth Service Discovery, Avahi, and Jini.
A rich ecosystem of VM-based mechanisms, policies and
practices already exists for Level 1, but some changes may VI. D ISCUSSION
be needed for Level 2. For example, cooling and power are
major concerns at Level 1 but are less important important A. When Level 1 is Unreachable
at Level 2 because data centers are much smaller and ease The hierarchical organization of Figure 18 was derived
of deployment is the dominant concern. solely from considerations of performance and consolida-
Trust is a differentiator between the two levels. A Level 1 tion. As a bonus, it also improves availability. Once a
data center is effectively a small fort, with careful attention Level 2 data center has been provisioned for an associated
paid to physical security of the perimeter. Tampering of mobile device, WAN network failures or Level 1 data center
hardware within Level 1 is assumed to be impossible. failures are no longer disruptive. This achieves disconnected
Mechanisms such as TPM-based attestation are therefore not operation, a concept originally developed for distributed file
often used at this level. In contrast, a Level 2 data center systems [35]. Simanta et al [36], [37] explore the tradeoffs
has weak perimeter security even if it is located in a locked between performance and availability in the methods used
closet or above the ceiling. Hence, tamper-resistant and to dynamically provision Level 2 from Level 1.

174
 The improved availability of the two-level architecture VII. R ELATED W ORK
applies even to mobile applications that are not latency- This is the first work to rigorously explore the impact
sensitive. Any mobile application that uses the cloud for of mobile multimedia applications on data center consoli-
remote execution can benefit. Although not widely discussed dation. The concept of “cyber foraging” by mobile devices
today, the economic advantages of data center consolidation (i.e., leveraging nearby resources) was first articulated in
come at the cost of reduced autonomy and vulnerability to 2001 [44]. Flinn [14] describes the extensive work on this
cloud failure. These are not hypothetical worries, as shown topic since then. A 2009 position paper [33] argued that end-
by the day-long outage of Siri in 2011 [38], [39], the multi- to-end latency was the critical determinant of whether public
hour weather-related outage of Amazon’s data center in clouds were adequate for deeply immersive applications.
Virginia in June 2012 [40], and the extended Christmas Eve It introduced the concept of “cloudlets,” which correspond
2012 outage of Netflix’s video streaming service due to an to Level 2 data centers in this paper. However, that work
Amazon failure [41]. As users become reliant on mobile offered no experimental evidence to support its claim. While
multimedia applications, they will face inconvenience and cloudlets were shown to be sufficient by construction, they
frustration when a cloud service for a critical application were not shown to be necessary. One way to view this paper
is unavailable. These concerns are especially significant in is that it provides the empirical evidence that cloudlets are
domains such as military operations and disaster recovery. not a luxury, but indeed a necessity in the face of real world
network connectivity to public cloud infrastructure.
B. Data Placement Recent work by others corroborates the conclusions of
this paper. Clinch et al. [45] explore the need for logical
Although we have mainly considered the computational proximity when using a large static display from a mo-
aspects of a distributed offload infrastructure, appropriately bile device. Their results are consistent with the findings
handling data placement can be important for many appli- reported here. Soyata et al. [46] use Monte Carlo simulation
cations. If an application requires a relatively small data to explore how a face recognition algorithm should be
set for its operation, then the application VM can wholly partitioned across multiple back-end computation engines.
contain the needed data, and we can trivially migrate and They conclude that a cloudlet-based strategy is optimal, and
offload the executable and data as a single unit. At the provide experimental validation.
other extreme, for an application that uses a very large data
set in an unpredictable manner, there is little one can do VIII. C ONCLUSION
to effectively place data. Rather, one must fetch data as The convergence of mobile computing and cloud com-
needed from Level 1 datacenters, or if this is too expensive, puting enables new multimedia applications that are both
restrict the application to running in the central datacenter. resource-intensive and interaction-intensive. For these appli-
Most applications will likely fall between these extremes – cations, end-to-end network bandwidth and latency matter
they may have substantial data sets, but will typically use greatly when cloud resources are used to augment the
only a subset, and exhibit locality in access. In many cases, computational power and battery life of a mobile device.
we can predict the likely data required from context, and In this paper, we have presented quantitative evidence that
hoard [35] this data at the Level 2 datacenters. For example, latency considerations limit data center consolidation. We
in a map application, physical location is highly correlated have shown how this challenge can be addressed by a two-
with accessed map data, so the geographical region around level hierarchical structure that seamlessly extends today’s
the Level 2 data center can be locally cached. Similarly, for a cloud computing infrastructure.
face recognition database, the faces of people who reside in
the local region are likely to be most important. Automatic IX. ACKNOWLEDGEMENTS
caching capabilities of distributed file systems like the Coda This research was supported by the National Science Foundation (NSF)
under grant numbers CNS-0833882 and IIS-1065336, by an Intel Science
File System [42] or the OceanStore project [43] can exploit and Technology Center grant, and by the Department of Defense (DoD)
this locality, mediate the distribution and modification of under Contract No. FA8721-05-C-0003 for the operation of the Software
data between Level 1 and Level 2 data centers, as well as Engineering Institute (SEI), a federally funded research and development
center. Any opinions, findings, conclusions or recommendations expressed
provide resiliency in face of failures. Unfortunately, most in this material are those of the authors and do not necessarily represent the
cloud-sourced data repositories today (e.g., GoogleMaps, views of the NSF, Intel, DoD, SEI, or Carnegie Mellon University. This
Flickr, etc.) do not provide a distributed file system interface. material has been approved for public release and unlimited distribution
except as restricted by copyright.
For these, we can imagine a solution that instantiates local
proxies on the Level 2 datacenters that provide intelligent R EFERENCES
caching of data from these repositories. Applications and [1] Apple, “iPhone 4S - Ask Siri to help you get things done,” http:
mobile devices associated with a Level 2 data center can //www.apple.com/iphone/features/siri.html.
[2] C. Thompson, “What is I.B.M.’s Watson?” New York Times
direct their requests to these proxies rather than directly to Magazine, June 2011, http://www.nytimes.com/2010/06/20/magazine/
the cloud to benefit from local data hoarding. 20Computer-t.html.

175
 [3] P. Viola and M. Jones, “Robust Real-time Object Detection,” in [29] R. Miller, “AOL Brings Micro Data Center Indoors, Adds
International Journal of Computer Vision, 2001. Wheels,” http://www.datacenterknowledge.com/archives/2012/08/13/
[4] M. Turk and A. Pentland, “Eigenfaces for recognition,” Journal of aol-brings-micro-data-center-indoors-adds-wheels, August 2012.
Cognitive Neuroscience, vol. 3, no. 1, pp. 71–86, 1991. [30] O. Stack, “Open source software for building private and public
[5] OpenCV, “OpenCV Wiki,” http://opencv.willowgarage.com/wiki/. cloud,” January 2013, http://www.openstack.org/.
[6] Jibbigo, “Jibbigo Voice Translator Apps,” http://www.jibbigo.com. [31] M. Kozuch, M. Satyanarayanan, T. Bressoud, and Y. Ke, “Efficient
[7] Vlingo, “Voice to Text Applications Powered by Intelligent Voice State Transfer for Internet Suspend/Resume,” Intel Research Pittburgh,
Recognition,” http://www.vlingo.com. Tech. Rep. IRP-TR-02-03, May 2002.
[8] Sphinx-4, “Sphinx-4: A Speech Recognizer Written Entirely in [32] A. Wolbach, J. Harkes, S. Chellappa, and M. Satyanarayanan, “Tran-
the Java Programming Language,” http://cmusphinx.sourceforge.net/ sient Customization of Mobile Computing Infrastructure,” in Proc. of
sphinx4/. the MobiVirt 2008 Workshop on Virtualization in Mobile Computing,
[9] S. Srinivasa, D. Ferguson, C. Helfrich, D. Berenson, A. Collet Breckenridge, CO, June 2008.
Romea, R. Diankov, G. Gallagher, G. Hollinger, J. Kuffner, and J. M. [33] M. Satyanarayanan, V. Bahl, R. Caceres, and N. Davies, “The Case
Vandeweghe, “Herb: a home exploring robotic butler,” Autonomous for VM-based Cloudlets in Mobile Computing,” IEEE Pervasive
Robots, vol. 28, no. 1, pp. 5–20, January 2010. Computing, vol. 8, no. 4, Oct-Dec 2009.
[10] D. G. Lowe, “Distinctive image features from scale-invariant key- [34] K. Ha, P. Pillai, W. Richter, Y. Abe, and M. Satyanarayanan, “Just-in-
points,” International Journal of Computer Vision, vol. 60, no. 2, pp. Time Provisioning for Cyber Foraging,” CMU School of Computer
91–110, 2004. Science, Tech. Rep. CMU-CS-12-148, December 2012.
[11] Gizmag, “Lumus glasses let you watch video, and the real world,” [35] J. J. Kistler and M. Satyanarayanan, “Disconnected Operation in the
2012, http://www.gizmag.com/lumus-see-through-video-glasses/ Coda File System,” ACM Transactions on Computer Systems, vol. 10,
20840/. no. 1, February 1992.
[12] G. Takacs, M. E. Choubassi, Y. Wu, and I. Kozintsev, “3D mobile [36] S. Simanta, G. Lewis, E. Morris, K. Ha, and M. Satyanarayanan, “A
augmented reality in urban scenes,” in Proceedings of IEEE Interna- Reference Architecture for Mobile Code Offload in Hostile Environ-
tional Conference on Multimedia and Expo, Barcelona, Spain, July ments,” in Proceedings of WICSA/EICSA 2012: Joint 10th Working
2011. IEEE/IFIP Conference on Software Architecture and 6th European
[13] Google, “Google Goggles,” http://http://www.google.com/mobile/ Conference on Software Architecture, Helsinki, Finland, August 2012.
goggles. [37] S. Simanta, K. Ha, G. Lewis, E. Morris, and M. Satyanarayanan, “A
[14] J. Flinn, Cyber Foraging: Bridging Mobile and Cloud Computing via Reference Architecture for Mobile Code Offload in Hostile Environ-
Opportunistic Offload. Morgan & Claypool Publishers, 2012. ments,” in Fourth International Conference on Mobile Computing,
[15] B. Solenthaler and R. Pajarola, “Predictive-corrective incompressible Applications and Services, Seattle, WA, October 2012.
SPH,” ACM Transactions on Graphics, vol. 28, no. 3, 2009. [38] S. J. Purewal, “Siri Goes Down For a Day; Apple Says Network
[16] M. Satyanarayanan, “Fundamental Challenges in Mobile Computing,” Outages Are Possible,” PCWorld, November 2011.
in Proceedings of the ACM Symposium on Principles of Distributed [39] A. Savvas, “Firms will flee cloud if lessons from Siri and RIM outages
Computing, Ottawa, Canada, 1996. not learned,” CFO World, November 2011.
[17] R. Paul, “First look: Android 4.0 SDK opens up face recognition [40] R. McMillan, “(Real) Storm Crushes Amazon Cloud, Knocks out
APIs,” October 2010, http://arstechnica.com/gadgets/news/2011/10/ Netflix, Pinterest, Instagram,” Wired, June 2012.
first-look-android-40-sdk-opens-up-face\-recognition-apis.ars. [41] D. Kucera, “Amazon apologizes for Christmas Eve
[18] Google, “Voice Actions for Android,” 2011, http://www.google.com/ outage affecting Netflix,” December 2012, http://articles.
mobile/voice-actions/. washingtonpost.com/2012-12-31/business/36103607 1
[19] D. Lowe, “The Computer Vision Industry ,” 2010, http://people.cs. amazon-web-services-christmas-eve-outage-largest-online-retailer.
ubc.ca/∼lowe/vision.html. [42] M. Satyanarayanan, “The Evolution of Coda,” ACM Transactions on
[20] P. J. Phillips, W. T. Scruggs, A. J. O’Toole, P. Flynn, K. W. Bowyer, Computer Systems, vol. 20, no. 2, May 2002.
C. L. Schott, and M. Sharpe, “FRVT 2006 and ICE 2006 Large-Scale [43] S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and J. Ku-
Results,” National Institute of Standards and Technology, Tech. Rep. biatowicz, “Pond: the oceanstore prototype,” in Proceedings of the
NISTIR 7408, March 2007. 2nd USENIX Conference on File and Storage Technologies, 2003,
[21] T. Agus, C. Suied, S. Thorpe, and D. Pressnitzer, “Characteristics of pp. 1–14.
human voice processing,” in Proceedings of 2010 IEEE International [44] M. Satyanarayanan, “Pervasive Computing: Vision and Challenges,”
Symposium on Circuits and Systems (ISCAS), Paris, France, June IEEE Personal Communications, vol. 8, August 2001.
2010. [45] S. Clinch, J. Harkes, A. Friday, N. Davies, and M. Satyanarayanan,
[22] M. Ramon, S. Caharel, and B. Rossion, “The speed of recognition “How Close is Close Enough? Understanding the Role of Cloudlets in
of personally familiar faces,” Perception, vol. 40, no. 4, pp. 437–449, Supporting Display Appropriation by Mobile Users,” in Proceedings
2011. of the IEEE International Conference on Pervasive Computing and
[23] M. B. Lewis and A. J. Edmonds, “Face detection: Mapping human Communications (PerCom 2012), Lugano, Switzerland, March 2012.
performance,” Perception, vol. 32, pp. 903–920, 2003. [46] T. Soyata, R. Muraleedharan, C. Funai, M. Kwon, and W. Heinzelman,
[24] A. Li, X. Yang, S. Kandula, and M. Zhang, “Cloudcmp: comparing “Cloud-Vision: Real-Time face recognition using a Mobile-Cloudlet-
public cloud providers,” in Proceedings of the 10th annual conference Cloud acceleration architecture,” in 17th IEEE Symp. on Computers
on Internet measurement. ACM, 2010, pp. 1–14. and Communications, Cappadocia, Turkey, July 2012.
[25] E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman, S. Saroiu,
R. Chandra, and P. Bahl, “MAUI: Making Smartphones Last Longer
with Code Offload,” in Proceedings of the 8th International Confer-
ence on Mobile Systems, Applications, and Services, San Francisco,
CA, June 2010.
[26] S. Sundaresan, W. de Donato, N. Feamster, R. Teixeira, S. Crawford,
and A. Pescape, “Broadband Internet Performance: A View From the
Gateway,” in Proceedings of ACM SIGCOMM 2011, Toronto, ON,
August 2011.
[27] S. K. Barker and P. Shenoy, “Empirical Evaluation of Latency-
sensitive Application Performance in the Cloud,” in Proceedings of
ACM Multimedia Systems, Phoenix, AZ, February 2010.
[28] Myoonet, “Unique Scalable Data Centers,” December 2011, http://
www.myoonet.com/unique.html.

176