Host Mobility

Would we like mobility to be transparent to applications?

Maybe mobility should be visible to the application so it can adjust to changes in pricing, network bandwidth, quality, etc. Applications may simply work better with knowledge about host mobility.

Where should we implement this?

Are sockets no longer the correct abstraction to think about? The next step may be a QoS enabled socket that notifies owner when "things" change - i.e. the host is moving to a different network, there is a change in pricing, etc.

• Session Layer (OSI)
  Layer on top of TCP, beneath the application. This may open multiple TCP streams and reestablish connections as necessary as hosts move, on behalf of the application. In essence, the session layer must implement a reliable transport ontop of TCP.
• Inside TCP Layer
  Modify TCP to be mobile aware, allow migration of hosts. Hard to deploy since both endhosts must have this version of TCP. Problems can also arise if both hosts move simultaneously
• At The IP Layer
  Mobile IP - mobile host has a home network with forwarding agent that tunnels traffic to mobile host. Can be optimized by notifying sender of mobile host's real current location. Could also leave IP as is, and send routing changes as the host moves, but this has scalability problems.
• Leverage Naming (DNS)
  DNS lookup can give the current location, when a host moves, notify DNS server. DNS has weak consistency, and changes need to propagate fast enough for this to be effective - set TTL to 0 to force senders to lookup fresh. This is fine for new connections, but doesn't handle migration. An aware app could detect lost connection and relookup from DNS to reestablish.
• MAC Layer Mobility
  On the same LAN, the basestations can handle tradeoffs
• Punt it to application
  Let application deal with it. Think resuming transfers of a broken FTP session that can be resumed.
• Internet Rendezvous
  Perhaps the IP abstraction isn't appropriate for mobility - a mailbox idea, internet rendezvous, may be more appropriate. A statically located dropbox somewhere on the network is used a central point, with a mobile sender dropping information there, and a mobile receiver picking it up.

How should mobility within a LAN, between basestations, be handled?

• The mobile devices could notify their nearest base station of their presence, and when an ARP for any of its known users goes by, the base station could respond, and then forward the packet
• The base stations could just be routers, with mobile devices notifying the base stations of their presence
• The base stations could act as bridges, simply rebroadcasting ARP messages, but this isn't scalable.

TCP doesn't hold up well in wireless networks because they are lossy, and TCP assumes a loss means congestion. How can we fix this problem to improve performance?

• Link layer
  As in 802.11, one can perform recovery in Link Layer by using ARQs to recover from loss & restransmitting the lost packets. This can be done faster than TCP because of more appropriate timeouts (and it doesn't trigger backoff)
• FEC
  Forward error correction over wireless links to reduce the loss rate is another solution
• Split connection
  A split connection can be used, opening two TCP streams: one over the wireless link and one over a proxy between the two hosts. This may be a suitable approach if there is no link layer recovery support.