TCP proxy mechanism 

Context in source publication

Context 1

... packets from the sender host to the receiver host via the split TCP connections. In the present paper, we investigate the performance of the TCP proxy mechanism through experiments using the actual public network. The TCP proxy mechanism is shown to enhance the data transfer throughput without any change in the TCP/IP protocol stack of the endhost. In addition, we evaluate the performance of gentle High-Speed TCP, as proposed in a previous study, on the TCP connection between the TCP proxy nodes. The remarkable degree to which the Internet has grown is due in part to access/backbone network technologies such as xDSL and optical fiber. In addition, user demand for diversified services has increased due to the rapid growth of the Internet popu- lation. Some of these applications require high-quality transport services in terms of, for example, end-to-end throughput, packet loss ratio, and delay. However, data transmission quality across the current Internet cannot be assured, essentially because of the best-effort basis of the Internet. IntServ [1] and DiffServ [2] are possible solutions to this problem that add control mechanisms at the network layer. For example, the DiffServ architecture is based on a simple model in which traffic entering a network is classified, and possibly con- ditioned, at the boundaries of the network and is then assigned to different behavior aggregates. However, implementation of DiffServ architecture would require additional mechanisms to be deployed to all routers through which traffic-flows traverse in order to achieve sufficient benefit from the introduction of IntServ/DiffServ into the network. Therefore, due to factors such as scalability and cost, we believe that these schemes have almost no chance of being deployed on large-scale networks. Proxy cache servers in Contents Delivery Networks (CDNs) [3] and media streaming in P2P (Peer-to-Peer) networks are typical examples of the overlay networking approach. One disad- vantage of such methods is the need for complicated control mechanisms specific to each application. In addition, parameter setting is very sensitive to various network factors. We are now investigating TCP overlay network architecture [4], which controls data transmission quality at the transport layer, meaning that the IP layer remains providing only minimum fundamental functions, such as routing and packet forwarding. One of the important mechanisms of TCP overlay networks is to divide the end-to-end TCP connection into multiple split TCP connections and relay data packets from the sender host to the receiver host via the split TCP connections (Figure 1). In the present paper, we refer to this splitting mechanism as TCP Proxy. TCP Proxy is expected to enhance the end-to- end data transfer throughput, mainly because the feedback-loop of the TCP connection becomes short, meaning that the round trip time and packet loss ratio of each split TCP connection is reduced. In some previous studies [4, 5], we confirmed the effect of the TCP proxy mechanism from simulation and mathematical analysis results. We found that, with a TCP proxy mechanism, the end-to-end throughput of data transmission is increased and the file transfer delay is shortened. In the present paper, we investigate the performance of the TCP proxy mechanism by con- ducting experiments using the public network. Furthermore, we also evaluate the performance of TCP variants for high-speed networks [6, 7] when used on a TCP connection between TCP proxy nodes. The remainder of the present paper is organized as follows. In Section 2, we explain the TCP proxy mechanism and HighSpeed TCP. In Section 3, we explain the environment and settings used in the experimental evaluation and present experimental results for the characteristics of the actual public network used in the present study. We evaluate the effect of TCP proxy and High-Speed TCP in Section 4. Section 5 summarizes the conclusions of the present study and discusses areas for future consideration. TCP proxy is a fundamental mechanism that splits a TCP connection between the sender and receiver hosts into multiple TCP connection at some nodes in the network. TCP proxy modes relay data packets from the sender host to the receiver host via the split TCP connections. TCP proxy also use a local ACK packet; a TCP proxy node sends back a pseudo ACK packet to the upward sender/proxy when it receives a data packet, without waiting to receive an ACK packet from the downward receiver/proxy. TCP proxy is expected to improve the data transfer throughput of connections by shortening the RTT. Furthermore, a TCP proxy has send/receive socket buffers for storing data packets, just like a regular TCP host. When a data packet is lost between the TCP proxy and the receiver host, the dropped packets can be retransmitted from the TCP proxy instead of the sender host. TCP proxy is also expected to improve data transfer performance, compared to regular TCP connections. Figure 2 depicts the mechanisms used in processing and forwarding TCP packets via split TCP connections, where there are two proxy nodes between the sender and receiver hosts and three split TCP connections are used. One advantage of the TCP proxy mechanism is its transparent behavior. TCP connections traversing TCP proxy nodes are split automatically, and there is no need to modify the protocol stack of sender/receiver hosts. In high-speed networks having bandwidths greater than 100 Mbps, obtaining sufficient throughput by TCP based on TCP Reno is difficult, as pointed out in [6]. Therefore, a number of TCP modifications related to High-Speed TCP that are capable of achieving high throughput by modifying the congestion control algorithm have been proposed in [6–9]. In the present paper, we evaluate the performance of High-Speed TCP (HSTCP) [6] and its improvement variant, gentle High-Speed TCP (gHSTCP) [7], on the TCP connection between TCP proxy nodes. The expected benefit of using HSTCP/gHSTCP between TCP proxy nodes is that the advantage of HSTCP/gHSTCP can be obtained, while retaining the TCP/IP stack of the sender/receiver endhosts. To overcome the problems inherent in TCP, HSTCP was proposed in [6]. The HSTCP algorithm employs the principle of Additive Increase Multiplicative Decrease (AIMD), as in standard TCP, but HSTCP is more aggressive in its increases and more conservative in its decreases. HSTCP addresses this by altering the AIMD algorithm for the congestion window adjust- ment, making it a function of the congestion window size rather than a constant, as is the case in standard TCP. That is, the increase parameter becomes larger, and the decrease parameter becomes smaller, as the congestion widow size increases (Figure 3). In this way, HSTCP can sustain a large congestion window and fully utilize the high-speed long-delay network. HSTCP is described in detail in [6]. However, a number of problems regarding HSTCP have been reported in [7]. For example, the relative fairness between standard TCP and HSTCP worsens as the link bandwidth increases. When HSTCP and TCP Reno compete for bandwidth on a bottleneck link, we do not attempt to provide the same throughput that they are capable of achieving. However, in this case, high throughput by HSTCP should not occur by excessively sacrific- ing TCP Reno throughput, i.e., HSTCP should not pillage too many resources at the expense of TCP Reno. Based on HSTCP, gHSTCP, as proposed in [7], can achieve better fairness with competing traditional TCP flows, while ex- tending the advantage of high throughput provided by HSTCP. The original HSTCP increases the congestion window size based solely on the current congestion window size. This may lead to bursty packet losses because the window size contin- ues to increase rapidly even when packets begin to be queued at the router buffer. In addition, differences in speed gains among the different TCP variants result in unfairness. To alleviate this problem, gHSTCP changes the behavior of HSTCP for speed increases so as to account for full or partial utilization of bottleneck links. In addition, gHSTCP regulates the congestion avoid- ance phase in two modes and switches between these modes based on the trend of changing RTT. When an increasing trend in the observed RTT values occurs, gHSTCP adopts the congestion control algorithm of TCP Reno (Figure 4). This is expected to reduce the rate of packet loss in the buffer of routers and improve fairness with TCP Reno. gHSTCP is described in detail in [7]. We prepared the public Internet environment between Tokyo and Osaka, as depicted in Figure 5. There are two TCP proxies in Tokyo network and Osaka net- work, and the TCP connection between the sender and receiver hosts is split into three TCP connections when the TCP proxy mechanism is activated. We compare the data transfer throughput using a single TCP connection between the sender and receiver hosts (Case 1), and that using the split TCP connections by TCP proxy 1 and TCP proxy 2 (Case 2). In case 1, data is transferred between Osaka B and Tokyo B. In Case 2, the TCP connection between Osaka A and Tokyo A is split in three connections (Osaka A - TCP proxy 1, TCP proxy 1 - TCP proxy 2, TCP proxy 2 - Tokyo A), and data is relayed via the split TCP connections with TCP proxy mechanism. Furthermore, we used a network emulator at Tokyo network to emulate the long-delay network between the sender and receiver hosts. We tested the Osaka-Tokyo case with no delay emulated at the network emulator, and the Okinawa-Tokyo case with a 25-msec delay. In the experiment, we inject TCP traffic into the network using the measurement tool iperf [10] and measure the average throughput at the receiver host. Note that we define the throughput as the amount of data arriving at the receiver host per unit time. In addition, we measure the round-trip times (RTTs) and congestion window size (cwnd) using the log of /proc/net/tcp in Linux ...