1. The Convergence of Mobile and Cloud Computing Ramesh Govindan ramesh@usc.edu University of Southern California 1

2. 2 A Seductive Question… Network Fabric The Cloud When 4 billion smartphones are Internet-connected, how (if at all) should the Internet architecture change?

3. Bridging the Capability Gap 3 Capability Time As the Smartphone becomes the primary computing device… What the device is capable of What users will want

4. Bridging the Capability Gap Dealing with Constraints Energy-Delay Tradeoffs in a Video Documentation System Overcoming Constraints Toward Cloud-Assisted Interactive Mobile Perception 4

5. Energy Constraint 5 Battery Life is an issue for Usability Opportunity: Multiple peripherals and sensors Intelligently use peripherals and sensors to reduce energy consumption

6. The Urban Tomography System Video Collection 10 years ago Video Collectio n Today M. Ra, J. Paek, A. Sharma, R. Govindan, M. Krieger, M. Neely, “Energy-Delay Tradeoffs in Smartphone Applications”, ACM Mobisys 2010. M. Ra, J. Paek, A. Sharma, R. Govindan, M. Krieger, M. Neely, “Energy-Delay Tradeoffs in Smartphone Applications”, ACM Mobisys 2010.

7. Users Transportation SecurityPost-Disaster Urban Planning Documenting Post-Katrina Reconstruction

8. Leveraging Delay-Tolerance Delay-Tolerance Many of our users are delay-tolerant Transportation Security Transportation Security Dealing with Child development Issues Dealing with Child development Issues Planning Research Planning Research But tolerance varies considerably

9. VideoAudio. SensingLarge Database. Data-Intensive Data-Intensive, Delay-Tolerant Applications Monitoring Personal resources Dietary Habits Urban Documentation Participator y Sensing Large Database (e.g. WPS) Maps Media Application Context Prefetching Download Upload Delay-Tolerant

10. Our Focus Transferring Large Volumes of Data Leverage Delay Tolerance Reduce the energy cost

11. EDGE/3GWiFi Energy (J/bit) Availability Channel Quality Trade-offs HIGH LOW HIGH LOW Time-Varying Delay transmission Adapt to wireless channel quality

12. A Motivating Example EDGE 3G WiFi video 1 arrives video 2 arrives 40 KB/s 200 KB/s 50 KB/s 10 KB/s TIME

13. Strawman Approaches MotivationProblem Solutions Approach EvaluationConclusion EDGE 3G WiFi video 1 video 2 Delay Energy 246 242 95 305 50 320 J J sec Min-DelayWiFi-OnlyEnergy-Optimal Optimal can save significant energy MD ME EO MD ME EO Challenge: How to design the optimal trade-off algorithm? Challenge: How to design the optimal trade-off algorithm?

14. Our Approach Use Lyapunov Optimization Derive Control Algorithm

15. Lyapunov Optimization Sender Receiver Control Algorithm Control Algorithm Lyapunov Analysis Lyapunov Analysis 1. Queue Stability Penalty Function Penalty Function 2. Penalty Minimization Queue length will not go to the infinity

16. Energy Cost Model Energy Cost Model How we use the framework Sender Receiver Control Algorithm Control Algorithm Lyapunov Analysis Lyapunov Analysis 1. Queue Stability 2. Penalty Minimization 1. Delay Tolerance 2. Energy Minimization

17. Higher rate Derived Control Decision SALSA (Stable and Adaptive Link Selection Algorithm) AP Q Q Large Queue Backlog E E Low Energy Cost Queue Backlog Queue Backlog × −× Estimated Rate Estimated Rate Energy Cost Energy Cost V V Over Links All Links

18. Importance of V Queue Backlog Queue Backlog × −× Estimated Rate Estimated Rate Energy Cost Energy Cost V V SALSA (Stable and Adaptive Link Selection Algorithm) Setting V Large Setting V Large Defer the Transmission Defer the Transmission Over Links All Links

19. Tuning Delay-Tolerance No Yes TIME Achievable Rate Achievable Rate No Yes V V Queueing Delay Transportation SecurityUrban Documentation Transmit?

20. SALSA Whether, When, Which Delayed Transmission Delayed Transmission Tunable Delay-Tolerance Tunable Delay-Tolerance SALSA

21. Main Results Ignore link quality SALSAKnow-WiFiStatic-DelayWiFi-onlyMin-Delay Ignore queue backlog Since SALSA takes all factors into account, it performs closest to the optimal Since SALSA takes all factors into account, it performs closest to the optimal

22. The Bottom Line Additional Delay Gain? Loss? Save 2% ~ 80% of battery capacity Save 2% ~ 80% of battery capacity + 2 min ~ 2 hour Energy Savings Battery

23. Bridging the Capability Gap Dealing with Constraints Energy-Delay Tradeoffs in a Video Documentation System Overcoming Constraints Toward Cloud-Assisted Interactive Mobile Perception 23

24. Interactive Mobile Perception Perception application is very relevant for mobile devices. Smartphone technology High data rate sensors Rich Sensors and Smart Mobile Devices Computer Vision Language Translation Natural language processing, etc. Advent of Inference Technology - Interactive. (low latency 10 ~ 100ms) - High data rate. (media data) - Computationally Intensive. (ML/Vision-based algorithms) - Interactive. (low latency 10 ~ 100ms) - High data rate. (media data) - Computationally Intensive. (ML/Vision-based algorithms) M. Ra, A. Sheth, L. Mummert, P. Pillai, D. Wetherall, Odessa: Enabling Interactive Perception Applications on Mobile Devices, ACM MobiSys 2011 M. Ra, A. Sheth, L. Mummert, P. Pillai, D. Wetherall, Odessa: Enabling Interactive Perception Applications on Mobile Devices, ACM MobiSys 2011

25. HandVu –Vision-based hand gesture recognition app. for mobile phones EyePhone –Vision based eye tracking for mobile phone UI, Dartmouth. Scenarios –Sweeping your phone across room full of people to recognize faces.. –Object pose estimation for activity recognition Mobile Perception Applications

26. Challenge Constraint Many perception applications require significant compute power Many perception applications require significant compute power Overcoming the constraint Offload computation to the “cloud” Offloading decision is non-trivial, since wireless network bandwidth is also constrained Offloading decision is non-trivial, since wireless network bandwidth is also constrained 26

27. Odessa A system that automatically and dynamically offloads components of a perception data-flow to the cloud A system that automatically and dynamically offloads components of a perception data-flow to the cloud 27

28. The Sprout System An application is represented as a synchronous data flow graph Components  Stages  Connectors  Servers Several perception applications already implemented Sprout does not support mobile devices, and statically configures processing pipelines Odessa is built on top of Sprout

29. Applications Face Recognition Pose Estimation Gesture Recognition 29

30. Odessa Goals and Techniques High Throughput (frames per second) Low Latency (time to process a single frame) High Throughput (frames per second) Low Latency (time to process a single frame) Offloading Parallelism Offloading Parallelism

31. Motivation: Offloading Variable on Inputs for Face Recognition Variable on Inputs for Face Recognition Variability on network conditions Variability on different devices Offloading decision should be adaptive. A static decision may not work. Offloading decision should be adaptive. A static decision may not work.

32. Parallelism 1. Data Parallelism 2. Pipeline Parallelism Frame 1 Frame 2 Frame 1 Frame 3 Frame 1 Frame 2 Frame 3 Throughput Makespan Throughput Makespan Throughput

33. Motivation: Data Parallelism Accuracy and execution time of face detection stage (face recognition) Avg. execution time of SIFT feature extraction stage. (object and pose recognition) The level of data parallelism affects accuracy and performance much, and it should consider precedence partition. The level of data parallelism affects accuracy and performance much, and it should consider precedence partition.

34. Motivation: Pipelining - Desirable # of tokens may be different. - How do we even know right # of tokens a priori? - Desirable # of tokens may be different. - How do we even know right # of tokens a priori? A static choice of pipeline parallelism can lead to suboptimal makespan or leave the pipeline underutilized. A static choice of pipeline parallelism can lead to suboptimal makespan or leave the pipeline underutilized.

35. Odessa Design Lightweight Application Profiler Lightweight Application Profiler Uses statistics from application pipeline to make decisions Uses statistics from application pipeline to make decisions Decision Engine Adapts data parallelism and stage offloading. Adapts data parallelism and stage offloading. Adapts pipeline parallelism Adapts pipeline parallelism

36. Profiler Stage Start Stage Decision Engine Decision Engine Piggybacking Suppress duplicated information Suppress duplicated information Report statistics to the decision engine per frame Report statistics to the decision engine per frame Report Light- weight Light- weight Cycles, Parallel Stages Cycles, Parallel Stages

37. Decision Engine Pick a Bottleneck Stage (Start Point) Compute Stage? Estimate Necessary Costs Choose the Best Choice; Offload, Spawn or Do nothing. Bottleneck is Network Edge Consider data parallelism and stage offloading simultaneously Consider data parallelism and stage offloading simultaneously No Yes Incremental Algorithm Incremental Algorithm

38. Evaluation Throughput Makespan Odessa finds an optimal configuration automatically. Odessa finds an optimal configuration automatically.

39. Comparison FPS: Higher is better Makespan: Lower is better Odessa shows 3x improvement over competing strategies Odessa shows 3x improvement over competing strategies

40. Convergence Interesting research opportunities at the boundary between mobile and cloud computing Interesting research opportunities at the boundary between mobile and cloud computing 40