Sunday, July 7, 2013

Transferable TCP connection

There are a number of situations in which the migration of TCP/IP connections can be useful. For instance, when there are requirements of load balancing, quality of service, fault tolerance, security. The visible increased performance in cluster based  applications are asking for attention of developers. Most commonly  transport layer mobility scheme is implemented by using a split-connection proxy architecture and a technique called TCP Splice that gives split-connection proxy systems the same end-to-end semantics as normal TCP connections. The TCP connection endpoint migration allows arbitrary server-side connection endpoint assignments to server nodes in cluster-based servers. The mechanism is client transparent and supports back-end level request dispatching. It has been implemented in the Linux kernel and can be used as part of a policy-based software architecture for request distribution. We show that the TCP connection end point migration can be successfully used for request distribution in cluster-based Web servers, both for persistent and non-persistent HTTP  connections

TCP handoff is a technique to handoff one TCP socket endpoint from one node to the other seamlessly, which is to migrate the established TCP state from the original node to the new node, so that the new node can send packets to the other TCP endpoint directly. TCPHA (TCP HAndoff) implements an architecture for scalable content-aware request distribution in cluster-base servers. It implements Kernel layer-7 switching based on TCP Handoff protocol for the Linux operating system. Since the overhead of layer-7 switching in user-space is very high, it is good to implement it inside the kernel in order to avoid the overhead of context switching and memory copying between user-space and kernel-space. Furthermore, the responses are sent directly back to clients without passing through the dispatcher, which can greatly improve the performance of cluster.

 SockMi is a solution for the migration of TCP/IP connections between Linux systems. Only the migrating peer of  the connection needs to reside on a Linux system. The migration is completely transparent to the other peer that can reside on a system running any operating system. This solution does not require changes to existing Linux kernel data structures and algorithms and can be activated in any phase of the connection. Both 2.4 and 2.6 versions of the Linux kernel are supported. With respect to other solutions, SockMi
 i) is able to migrate both ends of a connection;
ii) does not require cooperation on both ends;
iii) may be used by a stream socket in any state;
iv) does not require proxy systems;
v) may be activated via the standard sysctl command



The latest of  transport protocol TSMP, which seeks to support data transfer for the emerging usage paradigm of ”single user, multiple devices” in a TCP compatible manner. Through its novel naming and proxy-based designs, TSMP is able to retain the current client and server protocol operations of the legacy TCP protocol and TCP-based applications while placing new functions at the proxy.

Reliable sockets (ROCKS) and reliable packets(RACKS) are two systems that provide transparent network connection mobility and protect sockets-based applications from network failures. ROCKS does not require kernel modifications and work at user-level. Each system can detect failure within seconds of its occurrence, preserve the endpoint of a failed connection in a suspended state for an arbitrary period of time, and automatically reconnect, even when one end of the connection changes IP address, without loss of inflight data. ROCKS are transparent to applications but they must be present at both ends of the connection

As mentioned in here,  the operation of a server wishing to migrate one of its connection endpoints is described in following figure . As soon asa migration request is issued (i.e., a migration SYN is sent to the remote server), the connection moves to a wait state.While in the wait state, any incoming packet is stored in a connection checkpoint.
Upon receiving a migration SYN, a server targeted by a migration will duplicate locally the endpoint of the initiator of the migration. Packets flowing between the client and the new server have to respect the
sequence numbers agreed upon with the old server by the time of the migration. Since the new server-side endpoint is set up by relying on the TCP connection setup protocol, the migration requester has to choose a proper “client” ISN. Additionally, it also has to impose the ISN that the target node will use as its own ISN during the connection setup protocol. Letting the target server choose its own ISN would
not permit matching the server sequence numbers currently in use.