Go Hasegawa

Analysis and improvement of fairness between TCP Reno and Vegas for deployment of TCP Vegas to the Internet

According to past research, a TCP Vegas version is able to achieve higher throughput than TCP Tahoe and Reno versions, which are widely used in the current Internet. However we need to consider a migration path for TCP Vegas to be deployed in the Internet. In this paper, by focusing on the situation where TCP Reno and Vegas connections share the bottleneck link, we investigate the fairness between two versions. From the analysis and the simulation results, we find that the performance of TCP Vegas is much smaller than that of TCP Reno as opposed to an expectation on TCP Vegas. The RED algorithm improves the fairness to some degree, but there may still be an inevitable trade-off between fairness and throughput. Accordingly, we consider two approaches to improve the fairness. The first one is to modify the congestion control algorithm of TCP Vegas, and the other is to modify the RED algorithm to detect misbehaved connections and drop more packets from those connections. We use both of analysis and simulation experiment for evaluating the fairness, and validate the effectiveness of the proposed mechanisms.

Fairness and stability of congestion control mechanisms of TCP

In this paper, we focus on fairness and stability of the congestion control mechanisms adopted in several versions of TCP by investigating their time–transient behaviors through an analytic approach. In addition to TCP Tahoe and TCP Reno, we also consider TCP Vegas which has been recently proposed for higher throughput, and enhanced TCP Vegas, which is proposed in this paper for fairness enhancements. We consider the homogeneous case, where two connections have the equivalent propagation delays, and the heterogeneous case, where each connection has different propagation delay. We show that TCP Tahoe and TCP Reno can achieve fairness among connections in the homogeneous case, but cannot in the heterogeneous case. We also show that TCP Vegas can provide almost fair service among connection, but there is some unfairness caused by the essential nature of TCP Vegas. Finally, we explain the effectiveness of our enhanced TCP Vegas in terms of fairness and throughput.

Comparisons of packet scheduling algorithms for fair service among connections on the Internet

We investigate the performance of TCP under three representatives of packet scheduling algorithms at the router. Our main focus is to investigate how fair service can be provided for elastic applications sharing the link. Packet scheduling algorithms that we consider are FIFO (first in first out), RED (random early detection), and DRR (deficit round robin). Through simulation and analysis results, we discuss the degree of achieved fairness in those scheduling algorithms. Furthermore, we propose a new algorithm which combines RED and DRR algorithms in order to prevent the unfairness property of the original DRR algorithm, which appears in some circumstances where we want to resolve the scalability problem of the DRR algorithm. In addition to the TCP Reno version, we consider TCP Vegas to investigate its capability of providing fairness. The results show that the principle of TCP Vegas conforms to DRR, but it cannot help improving the fairness among connections in FIFO and RED cases, which seems to be a substantial obstacle for the deployment of TCP Vegas.

Implementation Experiments of the TCP Proxy Mechanism

Interest in the TCP overlay network, which controls the data transmission quality at the transport layer, has grown as the user demand for sophisticated and diversified services in the Internet has increased. In the TCP overlay network, TCP proxy is a fundamental mechanism that transparently splits a TCP connection between sender and receiver hosts into multiple TCP connection at some nodes in the network and relays data 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

Analysis of dynamic behaviors of many TCP connections sharing tail-drop/RED routers

Appropriate control parameters are important for the successful deployment of RED (Random Early Detection) routers, especially when many TCP connections share the bottleneck link. In this paper, we first describe a new simple analysis method for determining the window size distribution of many TCP connections sharing a bottleneck router. We consider two kinds of buffering disciplines: TD (Tail Drop) and RED. We model the window size evolution of TCP connections by using a Markov process whose state is represented by a set of the current window size and the ssthreth value. The state transition matrix is then calculated by considering the characteristics of TD and RED routers. We show numerical results demonstrating the accuracy of our analysis and we discuss the fairness of TD and RED. We confirm that RED does not help improve the routers throughput even when appropriate control parameters are chosen but that it is still useful to provide the fairness among many competing TCP connections.

ImTCP: TCP with an inline measurement mechanism for available bandwidth

We introduce a novel mechanism for actively measuring available bandwidth along a network path. Instead of adding probe traffic to the network, the new mechanism exploits data packets transmitted in a TCP connection (inline measurement). We first introduce a new bandwidth measurement algorithm that can perform measurement estimates quickly and continuously and is suitable for inline measurement because of the smaller number of probe packets required and the negligible effect on other network traffic. We then show how the algorithm is applied in RenoTCP through a modification to the TCP sender only. We call the modified version of RenoTCP that incorporates the proposed mechanism ImTCP (Inline measurement TCP). The ImTCP sender adjusts the transmission intervals of data packets, then estimates available bandwidth of the network path between sender and receiver utilizing the arrival intervals of ACK packets. Simulations show that the new measurement mechanism does not degrade TCP data transmission performance, has no effect on surrounding traffic and yields acceptable measurement results in intervals as short as some RTTs (round-trip times). We also give examples in which measurement results help improving TCP performance.

A New Method of Proactive Recovery Mechanism for Large-Scale Network Failures

This paper proposes a novel recovery mechanism from large-scale network failures caused by earthquakes, terrorist attacks, large-scale power outages and software bugs. Our method, which takes advantage of overlay networking technologies, pre-calculates multiple routing configurations to prevent possible simultaneous network failures and selects one configuration immediately after detecting the failures. Through numerical calculation results using actual AS-level topology, we show that our proactive method improves network reachability from 89% to 99%, while keeping the path length sufficiently short, when up to 8% of the nodes in a network are down simultaneously.

TCP symbiosis: congestion control mechanisms of TCP based on Lotka-Volterra competition model

In this paper, we propose TCP Symbiosis, which has a robust, self-adaptive and scalable congestion control mechanism for TCP. Our method is quite different from existing approaches. We change the window size of a TCP connection in response to information of the physical and available bandwidths of the end-to-end network path. The bandwidth information is obtained by an inline network measurement technique we have previously developed. Using the bandwidth information we can resolve the inherent problems in existing AIMD/MIMD-based algorithms such as periodic packet loss and unfairness caused by the difference in RTT. We borrow algorithms from biophysics to update the window size: the logistic growth model and the Lotka-Volterra competition model. This is because these models describe changes in the population size of a species that depends on the living environment. The population of a species can be viewed as the window size of a TCP connection and the living environment as the bandwidth of the bottleneck link. The greatest advantage of using these models is that we can refer to previous discussions and results for various characteristics of the mathematical models, including scalability, convergence, fairness and stability in these models. Through mathematical analysis and extensive simulation experiments, we compare the proposed mechanism with traditional TCP Reno, HighSpeed TCP, Scalable TCP and FAST TCP, and exhibit its effectiveness in terms of scalability to the network bandwidth and delay, convergence time, fairness among competing connections, and stability.

ICIM: An Inline Network Measurement Mechanism for Highspeed Networks

In high-speed networks, such as 1-Gbps or higher networks, bandwidth measurement algorithms that utilize packet transmission/arrival intervals, such as packet trains and packet pairs, have a number of problems. First, network measurement for large bandwidth requires short packet transmission intervals, which causes a heavy load on the CPU. Second, network interface cards for high-speed networks usually employ Interrupt Coalescence (IC), which rearranges the arrival intervals of packets and causes bursty transmission of packets. In the present study, we introduce ICIM (Interrupt Coalescence-aware inline measurement), a new bandwidth measurement approach that overcomes these two problems. ICIM utilizes the data packets of an active TCP connection for the measurement. In order to determine the available bandwidth, rather than adjusting the packet transmission intervals, the TCP sender instead adjusts the number of packets involved in a burst and checks whether the inter-intervals of the bursts of corresponding ACK packets are increased or not. Simulation results show that ICIM can measure the bandwidth as high as some Gbps while requiring a number of data packets that is only 1/100 of that of the existing stream-based algorithm.

Simulation studies on router buffer sizing for short-lived and pacing TCP flows

Traditionally, the size of router buffers is determined by the bandwidth-delay product discipline (normal discipline), which is the product of the link bandwidth and average round-trip time (RTT) of flows passing through the router. However, recent research results have revealed that when the number of flows is sufficiently large, the buffer size can be decreased to the bandwidth-delay product divided by the square-root of the number of flows (sqrtN discipline), without introducing under-utilization of the link bandwidth. This assertion has been verified primarily for long-lived flows. In contrast, there has not been a thorough verification of short-lived flows, which make up the majority of Internet flows. Furthermore, the effects of network parameters, such as the link bandwidth and propagation delay, have not yet been investigated. In the present paper, we compare the performance of the above two disciplines by simulation experiments. We focus on the performance of both long-lived and short-lived TCP connections traversing the router under various network environments. We show that sqrtN discipline would degrade the TCP performance in terms of the packet loss ratio and file transmission delay, and it may be useful only when the size of the file being transferred is approximately 50-100Kbytes or when the propagation delay between the sender and the receiver hosts is significantly small. In addition, we demonstrate that using pacing TCP cannot improve the network performance in many situations and that sqrtN discipline is not suitable for situations in which pacing and non-pacing TCP flows co-exist in the network.