Reconsidering Internet Mobility Alex C. Snoeren, Hari Balakrishnan, M. Frans Kaashoek MIT Laboratory for Computer Science

A Model of Mobility Hosts change attachment point  Move from home, to office, to …  Use multiple physical technologies Mobility events are rare  When compared with packet RTTs Long Running Applications  SSH Tunnels  Streaming apps

Services Required Locate the mobile host or service Preserve communication  Support changes in network attachment Expect and support disconnection  Gracefully detect lack of connectivity  Conserve resources during disconnection  Reconnect quickly and efficiently Keep the application informed!

Naming is not Enough Naming can abstract location details  E.g., Mobile IP uses “home IP address”  But specifies both timing and granularity Mobility is more than a naming problem  Apps need different semantics (IP, DNS)  Handle resolution failures (disconnection)  Lookup granularity is application specific Don’t prescribe a naming scheme!

 Proxies provide transparency  Applications oblivious to changes  Must highly engineer and place well The Problem with Proxies WAP Proxy End host support more flexible  Can integrate with other resources  Simplifies trust model  Can be equally transparent

Migrate Architecture Naming Service (Dynamic DNS) Mobile Host foo.bar.edu Location Query (DNS Lookup) Session Initiation xxx.xxx.xxx.xxx Correspondent Host Location Update (DNS Update) Session Migration yyy.yyy.yyy.yyy

Positioning Mobility Services Kernel User space Application Network Layer Link Layer Session Layer Transport Protocol Transparency Generality

Migrate Approach Provide services in a Session Layer  Applications define what a “session” is: A single RPC-like packet exchange A bundle of semantically-related streams Or any combination in between Manage sessions as a group Resources can be associated with network activity, and allocated accordingly Support is strictly optional

Session Layer Services Provide robust communication across changes of end-point addresses  Resynchronize transport protocols Detect and handle disconnectivity  Buffer, discard, or distill connections Manage related system resources  Memory, timers, files, devices Marshall and store session state

A Conference Session vic vat wb Session Layer DiscardDistill Buffer Application Resources System Resources User spaceKernel

Application Migrate Framework Session Layer Network Layer Link Layer Transport Protocol Session Creation Connectivity Monitor Connectivity Updates Policy Engine Policy Decisions Session Callbacks

Robust Communication Application Session Layer TCP Handle disconnection  Block or buffer sockets of reliable connections  Proactively discard unreliable datagrams Restart transport layers?  Rebind network endpoints  Replay buffered data TCP

Disconnection and Hibernation Monitor network connectivity  Exploit transport/network layer signals  Support application hints  Interface with network monitoring agents Support application-dependent behavior  Default handlers can spool to disk  Virtualize remote services  Invoke application-specific handlers

Resource Management Notify application to hibernate  Blocked apps can be swapped out  Shared files and devices can be released System resources can be reallocated  Similar to Resource Containers  Timers, locks, semaphores released  Buffer space drained/paged

State Management Enable state migration  Associate application and system state  Transfer from kernel to app, host to host Context management  State may depend on path characteristics  Support transcoding, different transport protocol, etc.

Summary Mobility services are session oriented  Often several related network activities Naming neither necessary nor sufficient  Applications have different needs Resource management is key  Especially with large numbers of hibernated sessions Sessions enable state management

The Session API Session creation  Applications specify resources and end points (e.g. TCP connections, UDP port/address pairs) Connectivity Monitor  Status can be signaled from above (application), below (transport stack), or separate monitor Callback Register  Applications can register to be notified on disconnection, reconnection, and/or changes in network attachment point

Supporting Disconnection Current approaches: Generally do not address disconnection  Proxies often assumed always connected Our approach: Handle unexpected disconnections  Many disconnections are unplanned

Reconnection Hosts contact correspondent peers  “Lost” hosts may force naming lookup  Session state is resynchronized Transport sessions may need to be restarted Application processing resumed  Notification of reconnection delivered  System resources are reallocated

Enabling graceful reconnection Current approaches: Obscure network characteristics  Hide path dynamics & resource availability Our approach: Notify higher layers of changes  Enable application adaptation Eliminate lower-layer dependence  Enable rebinding of network endpoints

A Model of Mobility Move from home, to office, to coffee shop, across multiple access technologies, all without restarting applications. Periods between movement >> Round Trip Times