Elisha : Improved Mobile Peer to Peer Connectivity Using Fixed Identifiers

Many popular applications use persistent sessions to create long-term connections between communicating nodes. However, when both nodes are highly mobile, the likelihood that they become disconnected increases drastically as their session continues. Traditional routing architect ures have used a triangular layout with a fixed server to act as a "middle-man" for passing messages between the two mobile nodes. Elisha is a novel, subscribe-publish routing scheme that allows highly mobile peers to connect to each other directly via standard Internet protocols. By removing the nee d for a fixed server Elisha achieves reduced end-to-end network latency and removes the need for virtualized connections. Moreover, by separating a node’s identity from its location-based IP address, Elisha allows devices to be labeled and tracked, regardless of what access points they con nect to the network through. 1. BACKGROUND AND INTRODUCTION For several years, users have been connecting to the Internet from mobile devices. Unlike traditional fixed computers, which were the only platform for connectivity when many of the Internet protocols were established, these nodes can travel between access points and change the IP addresses that denote their connections. This method of connectivity has not generally presented a problem, as typical Internet applications delivered payloads over such a short window of time that the device’s IP address would not change. However, recent advents in mobile technology have increased the pervasiveness with which applications requiring long-lasting sessions are used. For example, video communication applications such as Skype are typically used from a mobile phone device over the span of several minutes or hours. In order to prevent disconnection when a device changes the access point through which they are connected, several protocols have been created to allow a highly mobile node to connect to the Internet for a long duration of time. Virtual Private Networks[10][6] use virtual connections to a designated server to reroute packets such that it appears as if the client is connecting from within a private network regardless of where the actual connection occurs. Mobile IP[11] uses a fixed home agent to connect a mobile node with a foreign Internet host. The home agent uses a virtual tunnel, along with IP layer packet encapsulation, to intercept all transmissions to and from the mobile node. Both of these methods of connecting to the Internet incur serious reductions in throughput due to the requirement that all traffic be forwarded through a centralized server. Several other schemes have attempted to sidestep the use of a centralized server through the use of multihoming. Multihoming uses the different interfaces available on a mobile device, such as 3G and WiFi, to duplicate network traffic in an attempt to increase reliability and throughput. For example, SCTP[13] uses multihomed endpoints to provide reliable, sequenced stream transmissions to a mobile device. Novel schemes have attempted to layer this protocol on top of Mobile IP[5][1] to achieve greater reliability and throughput. Multipath TCP[12][14][15] attempts to achieve reliability through multihoming, dynamic monitoring and alteration of interface throughput, and a slow-handoff process that occurs when an interface becomes inactive. However, these schemes are founded on the assumptions that two interfaces are readily available and that only one of the nodes is highly mobile. When two nodes are mobile, as is often the case in current peer-to-peer mobile device applications, the robustness of the previous protocols degrade. Consider the scenario depicted in figure 1. Alice and Bob are communicating over a single association, possibly multihomed. In section (b) of the figure, both Alice and Bob move to new locations at the same time, triggering changes in the interfaces at which they can be reached. Using SCTP, Multipath TCP, or any other multihomed scheme, the association will not be updated in time and Bob and Alice will try to send data to their respective peers’ old IP address, as indicated by the solid unidirectional arrows in section (b). Instead, the two should ideally be sending packets to each others’ new interfaces as indicated by the bidirectional dashed line.