lecture 2: infrastructure support for mobility · good to provide flow isolation and qos good for...

Lecture 2: Infrastructure Support for Mobility Cristian Borcea

Department of Computer Science

NJIT

System support for mobility

Internet suspend/resume

Cloud & cloudlets

Application offloading

Network support for mobility/Future Internet

MobilityFirst

GENI

▪ OpenFlow

2

Goal/assumption: users carry no computing device Solved in the ‘60s, right?

Thin client connects to servers

Problem: latency for interactive applications Distributed file systems (e.g., Coda)?

Problems ▪ Volatile state (e.g., application state) not preserved during mobility

▪ Users see local computing environment (instead of one common personal computing environment)

Process migration Problems

▪ Difficult to do it both correctly and efficiently

▪ Portability 3

Inspired by laptop’s Suspend/Resume Use virtualization & distributed file systems (DFS)

to achieve Suspend/Resume across computers User personal computing environment encapsulated in a

virtual machine (VM)

VMs are suspended, transferred using DFS to another computer, and resumed there

User’s virtual PC

DFS

Computer 1 Computer 2 4

Software abstraction Behaves like hardware

Encapsulates all OS and application state ▪ Unmodified OS (not aware of

virtual machine monitor - VMM)

Virtualization layer (VMM) Extra level of indirection

Decouples hardware, OS

Enforces isolation

Multiplexes physical hardware across VMs

5

Takes complete control of the machine hardware

Creates virtual machines

Gets out of the way whenever possible and allows the

virtual machine to execute directly on the hardware in a

non-privileged mode

Regains control whenever the virtual machine tries to

perform an operation that may affect the correct

operation of other virtual machines or of the hardware

Safely emulates the operation before returning control to the virtual

machine

6

VMware for virtualization Suspended VM contains OS &

application state

Host OSs linked with Coda VM state maintained at servers

When suspend is triggered, old computer cannot be turned off until all state is transferred

▪ “Dirty” VM state transferred in the background to servers

Coda uses hoarding to transfer VMs faster when destination computer known

▪ Warming the cache in advance 7

VMs configured to use Fauxide as sole virtual disk Fauxide: loadable Linux kernel

module

I/O requests forwarded to Vulpes Vulpes: user-level process which

implements state transfer policy

▪ Maps VM state to Coda file

Live VM migration techniques could be used instead Need to be adapted to WAN

(designed for LAN) 8

VM state is encrypted prior to storage by Coda

Neither client nor server caches contain unencrypted VM state

Compromise of Coda servers would at most result in denial of service

Explicit authentication is required prior to VM state resumption

How to determine if an ISR client is safe?

Decision left to users

9

System support for mobility

Internet suspend/resume

Cloud & cloudlets

Application offloading

Network support for mobility/Future Internet

MobilityFirst

GENI

▪ OpenFlow

10

Utility computing: our data and applications are hosted somewhere in the Internet (“in the cloud”)

Most services we access over the Internet are in the cloud (e.g., Google, Amazon, Yahoo)

Benefits:

Providers: economies of scale by having many users sharing the same infrastructure

Consumers: reduced cost and overhead

Cloud infrastructure = Data centers with 100,000’s servers 11

Store large data sets & perform complex computations in the cloud Applications: mashups, augmented reality, real-time translation or

image recognition, and ISR

Could maintain virtual copy of mobile device (VM) in the cloud & potentially offload computations there Faster response time

Energy savings 12

13

Ping to 1st hop

End-end ping

“The wireless delay in the 3G network dominates the whole network path delay, e.g., latency to the first pingable hop is

around 200ms, which is close to the end-to-end Ping

latency to landmark servers distributed across the U.S.”

Cloudlet = compute cluster + wireless access point + wired

Internet access

Mobiles offload computation to cloudlet instead of cloud Improves throughput as well (not only latency)

Cloud still used in the common architecture

Cloudlets could form mesh networks or be used for DTN support in

case of disaster situations when Internet become unavailable

Low-latency high-bandwidth 1-hop wireless network

(e.g., WiFi)

Cloudlet WAN to distant cloud on Internet

Cloud

14

Cloudlet Cloud

State Only soft state Hard and soft state

Management Appliance model: self-managed; little

professional attention

Utility model: professionally administered, 24x7 operator coverage

Environment “Data center in a box” at customer premises

Machine room with power conditioning and cooling

Ownership Decentralized ownership by local business

Centralized ownership by Amazon, Google, etc.

Network LAN latency and bandwidth

Internet latency and bandwidth

Sharing Few users at a time 100s to 1000s of users 15

No: too large, too slow for transient use Solution: assemble VM on the fly (dynamic VM

synthesis)

Cloudlets come with large, relatively static, widely-used piece (“base VM”) ▪ Or download it in the background from the cloud

Deliver small patch (“VM overlay”) just before use

Discard VM after use

VM overlay can come from

Mobile device over wireless link

Cloud under control of mobile device 16

Kimberley: proof-of-concept tool that synthesises VMs Launches BaseVM and then executes two mobile-provided scripts to

configure VM and start an application

KCM: Kimberley control manager for service discovery and network management Leverages Linux’s Avahi

VNC – virtual network computing protocol (similar to X-Windows)

17

System support for mobility

Internet suspend/resume

Cloud & cloudlets

Application offloading

Network support for mobility/Future Internet

MobilityFirst

GENI

▪ OpenFlow

18

MAUI: Mobile Assistance Using Infrastructure Combines profiling with ILP (integer linear programming) solver

▪ Makes dynamic offloading decisions

▪ Optimizes for energy reduction

▪ Profiles devices, network, and applications

Leverages Microsoft .NET CLR to simplify program partitioning

Maui server Smartphone

App

Client Proxy

Profiler

Solver

Maui Runtime

Server Proxy

Profiler

Solver

Maui Runtime

App

RPC

RPC

Maui Controller

19

Build application as a standalone phone app Add .NET attributes to indicate “remoteable”

Fine-grain offloading improves performance

20

Proxy Intercepts application calls

With help from solver, chooses local or remote execution

Synchronizes app state between “local” and “remote” Language runtime support

Portability between ARM & x86 through CLR (common language runtime) ▪ CLR apps compiled to CIL intermediate language

Identifies methods with [Remoteable] tag ▪ Automate generation of RPC stubs

▪ Automate state extraction & serialization

Uses static analysis to generate call graph 21

Profiler Call graph

Execution Time

State size

Network Latency

Network Bandwidth

Device Profile CPU Cycles

Network power cost Network delay Computational delay

Computational power Cost

Computational delay

Annotate

d

call graph

22

Global optimization for the entire program Partitioning strategy: minimize energy consumed by

smart phone subject to set of latency constraints Default: latency must not increase more than 5% vs. local-only

execution 23

Face recognition call graph

System support for mobility

Internet suspend/resume

Cloud & cloudlets

Application offloading

Network support for mobility/Future Internet

MobilityFirst

GENI

▪ OpenFlow

24

Separation of names (ID) from

network addresses (NA)

Globally unique name (GUID)

for network attached objects

User name, device ID, content,

context

Multiple domain-specific naming

services

Why?

Better support for mobile

computing

Examples in the following slides 25

Why? DNS is way too slow for mobile devices

Replace DNS with fast name resolution service (~100ms) Use P2P/DHT techniques to make it scale to 10B names 26

Introduce DTN features in routers Store-and-forward routing

Co-exists with current packet-switching routing

Why? Deal better with disconnections and varying link quality for mobiles

27

Packet headers contain both GUID and NA NA used for “fast” path, with fallback to GUID where needed

Why? Enables flexibility for multicast, anycast and other late binding

services

▪ E.g., GUID could be a context-aware name based on location and sensor types 28

29

Independent of forwarding type, which remains unreliable Packets or files (in store-and-forward) can still be dropped

Why? Recall I-TCP: improved throughput for wireless links

Also helps deal with disconnections & could supports content caching

Public keys addresses for hosts & networks

Ensure accountability of traffic

Ubiquitous access-control infrastructure

Secure routing

But to protect privacy, users need to change them often

Emphasis on achieving robust performance under network

stress or failure

Byzantine fault tolerance as a goal

Transform malicious attacks into benign failures

No globally trusted root for naming or addressing

Tolerate DDoS better

30

System support for mobility

Internet suspend/resume

Cloud & cloudlets

Application offloading

Network support for mobility/Future Internet

MobilityFirst

GENI

▪ OpenFlow

31

Virtual laboratory for exploring future Internets at scale Install the software I want throughout my network slice

(into firewalls, routers, clouds, …) And keep my slice isolated from your slice, so we don’t interfere with

each other

Can run many different “future internets” in parallel

32

33

WiMAX

ShadowNet

Salt Lake City Kansas City

DC Atlanta

Stanford UCLA UC Boulder Wisconsin Rutgers Polytech UMass Columbia

OpenFlow Backbones Seattle Salt Lake City Sunnyvale Denver Kansas City Houston Chicago DC Atlanta

OpenFlow Stanford

U Washington Wisconsin

Indiana Rutgers

Princeton Clemson

Georgia Tech

Toroki LightSwitch 4810

Arista 7124S Switch

HP ProCurve 5400 Switch Juniper MX240 Ethernet Services Router

NEC IP8800 Ethernet Switch

NEC WiMAX Base Station HTC Android smart phone

GENI racks

Installed OpenFlow & PC racks within two US research

networks to support end-to-end slices (IP or non-IP) 34

National LambdaRail

Internet2

UCLA campus test-bed for vehicular networking

50 cars, vans and buses of campus fleet

Communication through WiFi

Plan to add WiMAX

UMass DOME test-bed

35 computer-equipped buses

▪ WiFi & 3G

Mesh network built in cooperation with the town of

Amherst (WiFi)

Plan to add WiMAX

35

GENI used to experiment with delay-tolerant data collection protocols over WiMAX and 4G 36

37

Source routing (SR) within a

virtual topology (VT)

VT: flexible way to advertise

services

SR: flexible way for users to pick

routes

▪ Sources use end-to-end

observations to switch paths

Used OpenFlow in GENI’s

switches

Ethernet switches/routers with

internal flow table & standardized

interface to add/remove flows

Many commercial switches

support OpenFlow

38

Controller

OpenFlow Switch

Flow Table

Secure Channel

PC

hw

sw

API

Net Services

39

OpenFlow Protocol

C C C

FLOWVISOR

OpenFlow Protocol

Research Team A

Controller

Research Team B

Controller

Production Net Controller

Isolated Network

Slices

Physical Infrastructure Packet & Circuit Switches: wired, wireless, optical

media

Control Plane API

Control Plane API

Good to provide flow isolation and QoS Good for mobility

E.g., controller could track user locations and reprogram the flow tables to allow seamless handoff

Difficult to scale to large number of flows if dynamic flow addition/removal are needed

Load balancing over multiple controllers possible

Fault-tolerance could be a problem

Goal is to make controllers stateless for simpler design

Not appropriate for per-packet processing

E.g., packet inspection for intrusion detection

Potential solution: route such packets through programmable switch (e.g., NetFPGA)

40

System support for mobility

http://isr.cmu.edu/

http://2010.middleware-conference.org/Middleware2010-Keynote-VenkatPadmanabhan.pdf

http://research.microsoft.com/en-us/events/mcs2010/technical_program.aspx

http://www.eecs.umich.edu/~hjx/mobisys10.pdf

http://research.microsoft.com/pubs/102364/cloudlets09.pdf

http://research.microsoft.com/en-us/projects/maui/ 41

Network support for mobility/Future Internet

http://mobilityfirst.winlab.rutgers.edu/

http://www.geni.net/

http://www.openflow.org/

http://www.vehicularlab.org/index.php/projects/testbed

http://prisms.cs.umass.edu/dome/

http://www.winlab.rutgers.edu/~suhas/SuhasMathur_Mobisys2010.pdf

http://www.sigcomm.org/sites/default/files/ccr/papers/2009/October/1594977-1592583.pdf

42

1. Two decades of mobile computing

2. Infrastructure support for mobility

3. Mobile social computing

MobiSoC: a centralized middleware for mobile social applications

Prometheus: a P2P social data management service

GPI & GDC: group identification algorithms based on location & co-

location traces

4. People-centric sensing

5. Programming mobile ad hoc networks

6. Vehicular computing and networking

7. Privacy and security in mobile computing

43