Architecture transparency

To make the distributed architecture and the THOP mechanism transparent to the clients, it is necessary to modify the source IP address and the TCP timestamp option of the server response packets in such a way that they seem to be generated by the Web switch. The modification of the source IP address is obtained in the following way. Each time a TCP connection is cloned at the server, a special field in the TCP control block, saddr, is filled with the source IP address of the Web switch. On the other hand, ordinary TCP connections leave this field empty. When the server sends data over a TCP connection, it checks the value of the saddr field in the corresponding TCP control block. If it is not empty, the source IP address is changed with the value contained in the saddr field because the TCP connection has been cloned through the TCP Handoff mechanism. Another critical issue to preserve architecture transparency concerns the use of the TCP PAWS algorithm [17]. The use of a timestamp encapsulated as a TCP option is very useful for the detection of segments carrying wrapped sequence numbers. As a consequence, the PAWS algorithm is adopted by many TCP implementations, and must be taken into account when sending responses transparently to the clients. However, a key requirement of the PAWS algorithm is that timestamps be always non decreasing. This is not guaranteed in a clustered environment where switch and server nodes have their own independent timestamps. It must be guaranteed that the timestamp written in the response packets be greater than the value stored at the client. In our Web switch, this is achieved through the following approach. To preserve the semantics of PAWS, the server uses its own timestamp. The server can transform its timestamp into a value that is compatible with the value expected by the client from the Web switch. This transformation is a two-stage process working as following. Let $T^{tr}_{sw}$ be the TCP timestamp value at the switch node, when the TCP connection is transferred. Moreover, let $T^{acc}_{se}$ be the TCP timestamp value at the server when the TCP connection is accepted and $T^{trn}_{se}$ the TCP timestamp value at the server when a packet is transmitted. As soon as the server accepts a connection request, it computes the temporal difference between the two timestamps:

$$\delta = max(0, T^{tr}_{sw} - T^{acc}_{se} + 1)$$ (2)

A non positive value of $\delta$ implies that $T^{tr}_{sw} < T^{acc}_{se}$; hence, the client sees a non decreasing timestamp and there is no need for spoofing it. A positive value of $\delta$ indicates that $T^{tr}_{sw} \geq T^{acc}_{se}$. The use of the server TCP timestamps would confuse the PAWS algorithm. For this reason, when the server transmits a packet, it writes into the packet the following, augmented timestamp $T^{aug}_{se}$:

$$T^{aug}_{se} = T_{se} + \delta$$ (3)

Finally, when the server receives a client packet containing a timestamp $T_{sw}$, it must convert that value (which, we recall, is coherent with the switch) into its real value $T_{se}$:

$$T_{se} = T_{sw} - \delta$$ (4)

If $\delta=0$, there is no need of converting the timestamp at all. Otherwise, if $\delta>0$, the correct value is deduced.