Efficiency requirements

The TCP connection transfer is one of the most critical phases because it must satisfy a rather complicated set of requirements. We identify also the other main issues for an efficient implementation of the one-way Web cluster. TCP connection transfer. The whole handoff process requires that established TCP connections be transferred from one node (specifically, the switch) to another (a chosen Web server). To complete this operation, the internal state of a TCP connection, identified by the Transmission Control Block (TCB) [23], must be communicated to a Web server node, in order to be able to recreate that connection in the same state it was before being transferred. Besides this, the Web server node must also receive the application-level information (usually, a client request) that started the connection transfer process. Both information (TCP connection state and client request) may be logically chained in an entity which we call TCP Handoff request. The name is justified by the following observation: a TCP Handoff request contains the minimum amount of information which is needed to shift the request serving process from one node to another. Upon the receipt of a TCP Handoff request, the Web server extracts the TCB and recreates the TCP connection. Next, it obtains the application-layer information which is tailed into the server process receive queues. Request parsing. The Web server which must serve a client request is chosen according to (a well-defined portion of) the application-level information contained in the request. Hence, it is necessary to provide a means for parsing the client request, with the goal of extracting the required information which will be used by the dispatching policy. It is worth noting that the parsing functionality is strictly related to the dispatching policy. Different policies may require different portions of a client request, such as parts of an URL, cookies, or even SSL identifiers. Dispatching mechanism. This is the second most critical phase after the TCP connection transfer. The distribution of client requests across cluster nodes requires an algorithm to take decisions and a mechanism to execute assignment decisions. In this paper, we consider content-aware request scheduling, so the dispatching policy (generally) uses some information extracted by the request parsing mechanism to identify the cluster node which is able to fulfill the request. Evaluation of Web server load conditions. Many dispatching policies use some information related to the Web server load status to perform a sub-optimal assignment or, at least, to minimize the risks of load unbalance. It has been widely shown that the introduction of state-awareness leads to smarter assignments than those performed by state-blind policies. However, a state-aware algorithm requires a mechanism for evaluating the conditions of a Web server node, which we call load monitor. The load monitor may be centralized or distributed. A centralized monitor runs entirely on the switch and treats the Web server nodes as ''black boxes''. A distributed monitor collects state information directly on the Web server node, which is then communicated to the switch. The former approach is typically easier to implement, since it does not require a communication mechanism. However, it does not estimate the server load as well as the distributed approach, that is able to access directly to the operating system internals. Server load information tends to become obsolete quickly [10]; thus, it is preferable to avoid time-synchronous updates every $n$ seconds. A better alternative is to update the server load coefficients synchronously with events, like the successful transfer of a connection and the closure of a transferred connection. Forwarding mechanism. Client packets subsequent to the received response segments cannot be handled anymore by the switch; they must be handled by the appropriate Web server. For this reason, the switch must be enriched with a mechanism for intercepting client packets and for delivering them to the Web server to which the TCP connection has been transferred. This operation requires a modification of some fields of the TCP/IP header, such as the IP and MAC destination addresses which have to be set to those of the real Web server. Such modifications imply the (re)computation of the IP and TCP checksums before the delivery of the packet to the Web server. It is of crucial importance that the forwarding mechanism be as fast as possible, otherwise the traffic between the client and the server is seriously slowed down. Typically, the operations involved in the forwarding module are CPU-bound, because of the TCP and IP checksum computation. Due to the large number of simultaneous open connections handled by a switch, the design of a forwarding mechanism which scales well in an SMP architecture is mandatory. Transparency. The whole TCP Handoff mechanism must be transparent to the clients. In other words, the responses and the end-to-end semantics of all TCP/IP operations must remain the same as if the client was connected to one Web server. This implies that response packets must look as if they were sent by the Web switch. Typically, this requires at least the modification of the following fields of a TCP/IP packet: source IP address, and TCP timestamp option [17]. Making the entire mechanism transparent also to the server processes is an important plus, as the Web server applications must be portable and should not require modifications to work in one-way Web clusters.