Transcript presentation source - Networks and Mobile Systems

Session-Based Mobility
An End-to-End Approach
Alex C. Snoeren
MIT Laboratory for Computer Science
(with Hari Balakrishnan, Frans Kaashoek, and Jon Salz)
An Example: SSH Session
server
client
elm
X
app
shell
ssh
SSHd
• Remote log in / port forwarding
 Provides secure remote communication
 Data compressed and encrypted as a stream
Today’s Network Abstraction
SSH
Client
TCP
IP
<18.31.0.139, 2345>
IP
TCP
SSH
Server
<169.229.60.64, 22>
application
must perform
ad-hoc
• SystemEach
provides
a connection
service
recovery
disconnection
or fail
 Binds
[<IP,and
port>,
<IP, port>] management,
tuple
• Any change invalidates the connection
• No support for periods of disconnectivity
Mobile Networking Challenges
1. Changing end points



Change in node attachment point
Multi-homing (multiple network interfaces)
Readdressing: DHCP renewal, NAT crash, etc.
2. Internet “Suspend/Resume”



Wireless device goes out of range
Save device power or connectivity costs
Transient Internet connectivity outage
Complete solution needs to address both
Current Approaches
• Only solve half the problem
 Mobile IP, VIP, Physical Media Independence, …
 MSOCKS, SLM, Application check-pointing, …
• Don’t support intelligent adaptation
 Rocks, Mobile sockets, Mobile file systems, …
• Use application-specific point solutions
 RTSP, SCTP, SIP multimedia calls, …
 Web shopping carts, J2EE servlets, …
 HTTP range requests, FTP restart points, …
Reconsider System Abstraction
• Many applications create “sessions”
 Long-lived: collections of connections
 Entity of processing and resource allocation
• Can we provide a useful system abstraction?
 Flexible enough for different users, applications
 Efficient to implement, leverage shared resources
 Easy to use, but backwards compatible
Session is the salient mobility entity
1, 2, 3… Mobility
1. System Session Abstraction [SBK’01]


Collaborative management of end point changes
Support for unmodified legacy apps [SaSB’02]
2. Preserving Reliable Connections

TCP connection migration [SB’00]
3. Session Continuations [SSaBK’02]


Application-guided disconnection handling
System support for long-lived sessions [SAB’01]
Goals: Minimally Invasive
• Overhead only on mobility events
• As secure as non-mobile situations
• Require no infrastructure support
 Demonstrate pure end-to-end solution
 Deployable via proxies if desired
• Enable
intelligentissession
Transparency
alwaysadaptation
an option
Managing Changing End Points
• Applications handle discovery
 Lots of ways to resolve to <IP, port> pair
• User specifies local network policy
 Different users, different choices
• System manages tracking
 Clear semantics, scalable, and efficient
End-to-End Session Tracking
Discovery Update
(e.g., DNS Update)
Discovery Query
(e.g., DNS Lookup)
Discovery Service
(e.g., Dynamic DNS)
Session Initiation
<yyy.yyy.yyy.yyy, Q>
<xxx.xxx.xxx.xxx, P>
Session Update
Correspondent
Node
Mobile Node
foo.bar.edu
xxx.xxx.xxx.xxx
yyy.yyy.yyy.yyy
System Session Abstraction
• Set of network connections
to remote end point
 All involved in single
collaborative activity
• Application identifies end
points, initiates connections
• System manages tracking
 Maintains semantics of
reliable protocols
 Exposes changes to apps
that register interest
/* Find remote end point */
dhost = gethostbyname(dst);
/* Validate remote end point */
daddr = valid_address(dhost);
/* Create a new session */
sid = session_create(flags, …);
/* Specify end points discovery */
set_lookupfunc(sid, gethostbyname,
dst, hostname);
/* Create two connections */
connect(a, daddr, …);
add_connection(sid, a);
connect(b, daddr, …);
add_connection(sid, b);
/* Register interest in changes */
register_handler(sid, mobhandler);
App
Challenge/Response
Protocol
Diffie-Hellman Key Exchange
Mobility Daemon
Connecting
Not
Supported
Mobility Daemon
Established
C, P
Migrating
Frozen
C, P
Lost
Policy Engine
add_connection()
session_create()
Session Layer
App
Session Layer
Policy Engine
Robust Session Management
Dynamic Library Interposition
• Intercept POSIX API
 Wrap each connection in
its own session
Legacy
fd
Application
connect(…)
sid = session_create();
add_connection(sid, …);
libmigrate
Session Handle
connect(…)
fd
libc
syscall(connect,…)
Migrate
Daemon
Session
Establishment
fd
Kernel
PART 1
• Problem: Track changing end points
• Solution: System session abstraction
PART 2
• Problem: Preserve reliable connections
• Solution: TCP Migrate Options
PART 3
• Problem: Internet “Suspend/Resume”
• Solution: Session continuations
Connection Preservation
App
Session
Layer
Kernel
Kernel Session
App
Layer
• Provide stable view of dynamic kernel socket
• But what about reliable connections?
 User level: Double buffer, session layer re-sync
 Full access: Extend transport protocol
Transmission Control Protocol
• The reliable protocol
 91% of all bytes, 83% of
all packets [CAIDA ’00]
 SSH, FTP, HTTPS,
telnet, IMAP, SMTP, etc.
• SYN/ACK handshake
 Negotiates options,
sequence space
• Reliable transport
 In-order delivery
 Retransmits lost data
TCP Connection Migration
• Resume previous connection with new one
 Provide special Migrate TCP option
 Sent on SYN packets of new connection
• Preserve buffers and sequence space
 Retransmission engine just works
 Compatible with SACK, FACK, Snoop…
• Entirely backwards compatible
mobile
fixed
1.
2.
3.
TCP
Connection
Migration
1. Initial SYN
4.
2. SYN/ACK
3. ACK (with data)
4. Normal data transfer
5.
6.
7.
5. Migrate SYN
6. Migrate SYN/ACK
7. ACK (with data)
• 2 new transitions
between existing states
- and • 1 new state
handles pathological
race condition
recv: SYN (migrate T, R)
send: SYN, ACK
TCP State
Machine
Changes
MIGRATE_WAIT
2MSL timeout
Migration Trace
SYN/ACK
Buffered
Packets
(old address)
Migrate SYN
A Lossy Trace with SACK
SYN/ACK
Buffered
Packets
(old address)
ACK
w/SACK
Migrate SYN
PART 1
• Problem: Track changing end points
• Solution: System session abstraction
PART 2
• Problem: Preserve reliable connections
• Solution: TCP Migrate Options
PART 3
• Problem: Internet “Suspend/Resume”
• Solution: Session continuations
Internet Suspend/Resume
• Intelligent disconnection handling
 Buffer otherwise lost communications
 Emulate remote services locally
 Release resources while disconnected
• Graceful resumption handling
 Reallocate resources and restore state
 Adapt to new network conditions
 Indicate how to resume processing
Motivating Continuations
• Observation: complete context inappropriate
 Some previous state irrelevant, or, even worse,
 Invalidated due to change in conditions
 (C.f. TCP Connection state)
• Similar problem in programming languages
 Block when state and context is complex
 Pass continuation if state and context is small
• Continuations can request blocking behavior
Using Continuations
• Expand session notion




Align with application
Annotate state, resources,
associated computation
Include system state
App
SL
User level
Kernel
• Provide synchronization and preservation assistance
 Shared attribute/value store
 Persist local system IPC, file descriptors
• System invokes continuation at session resumption
 Generated in response to disconnection notification
Conserving Session Resources
Resources dedicated to
active session
emacs
>>
Resources dedicated to
suspended session
SSHd
Socket
Buffers
Network
Ports
Open
Files
Release system
resources as well
Kernel
Continuation generation is recursive!
SSH Continuation
• Don’t suspend until it’s convenient
 Process pending data, deliver to app or network
• Only a minimum of state to preserve
 Auth, crypto, and compression state
 Preserve IPC to child processes
• Notify child processes of disconnection
 Tunneled apps share connectivity fate
Added ~250 LOC in an afternoon
2000
Shared Pages
Memory Usage (KB)
1800
1600
Non-Shared Pages
1400
System Resources
300
250
1200
200
Session
Continuation
1000
150
800
600
100
Startup Latency
400
Session Overhead
50
200
0
0
SSHd
FTPd
SSHd
FTPd
Anecdotal evidence of size and speed
Restart Latency (msec)
Continuation Efficiency
Continuation Solution Spectrum
• Fast TCP handoff
 One RTT
• Normal movement
 Four RTTs + re-sync
+
• Suspend/Resume
 Complete flexibility
Conclusion & Future Directions
• Sessions are viable system abstractions
 Useful, flexible, and easy to use
 Admit robust, efficient implementation
• Continuations enable “suspend/resume”
• Useful for mobility across hosts?
 Continuations eliminate dependencies
 An area for future exploration…