lecture 2: infrastructure support for mobility · good to provide flow isolation and qos good for...
TRANSCRIPT
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