G-TCP to Govern aggregate throughput of the parallel TCP flows Yusung Kim and Kilnam Chon
Lisong Xu
Computer Science Department Korea Advanced Institute of Science and Technology Daejeon, South Korea {yskim, chon}@cosmos.kaist.ac.kr
Computer Science and Engineering Department University of Nebraska-Lincoln Lincoln, USA
[email protected]
I.
INTRODUCTION
The growth rate of the Internet bandwidth has exponentially increased over past decades. As the Internet bandwidth grows new data-intensive applications such as climate simulation, earth observing, and high energy physics are emerging. Terabyte and petabyte data are required to transfer over the Internet. Many of these applications use the Transmission Control Protocol (TCP) for the reliable data transfer. Since the standard TCP, TCP Reno, was developed in 1988[1], it has been widely adopted and performed remarkably well. However, the standard TCP eventually underutilizes network bandwidth as bandwidth delay product continues to grow [2]. The dataintensive applications would demand to use tools such as GridFTP[3], bbcp[4], and pSocket[5] which open multiple TCP flows in parallel (we called them parallel TCP flows) to achieve higher throughput. The scheme of the parallel TCP flows is required in not only a single server but multiple (clustered) servers to overcome the performance limitation of an individual server. In most of the previous works, the number of the parallel TCP flows is decided in the start time and their aggregate through depends on the number of the flows. The aggregate throughput may be limited when the number of the flows is not enough big over high bandwidth networks. Consequently the parallel TCP flows do not fully utilize the available bandwidth even though there is no congestion. We may select an arbitrary big number to maximize performance but the unreasonable big number can cause significant unfairness with other single TCP flows when networks get congested. It is hard to decide the optimal number of the parallel TCP flows in the start time since the network condition is continuously unpredictable. In this paper we present the feasibility to govern aggregate throughput of the parallel TCP flows. The key challenge of our approach, G-TCP, is decoupling the aggregate throughput from the number of the opened TCP flows in parallel. G-TCP has two parameters; one is N which is the number of the opened flows and the other is K which is for G-TCP to behave like K parallel TCP flows. K can be less or bigger than N. We theoretically find a new increment factor of TCP to control the aggregate throughput. As adjusting the new increment factor to accommodate change of the packet-loss rate, we can keep the aggregate throughput of G-TCP to be K times of a single
TCP flow. In our simulation results, we showed that the aggregate throughput of G-TCP is governed by given K regardless of N which is the number of the opened TCP flows. In our further research, K will be adaptively changed to probe available bandwidth and response to network condition. To perceive change of the network condition, we will employ delay-based approach [6] into our G-TCP. When a network is underutilized and delay is shorter than a threshold, G-TCP increases K to be scalable over high-speed and long-distance networks. If the network is getting congested and the delay becomes longer than a threshold, we reduce K (the minimum 1) to be fair with a single TCP flow. Another consideration is to minimize control overhead among the parallel TCP flows which are operating on high-speed networks. II.
GOVERNMENT OF THE PARALLEL TCP FLOWS
We describe our model and theoretical background. The steady-state throughput Ts of a single TCP is given by (1) where MSS is the packet size, RTT is the round trip time, ps is the packet-loss rate, αs is the increment factor, and βs is the decrement factor [7]. Aggregate throughput Tp of the parallel TCP flows is bounded by (2) where αp, βp, and pp are the parallel TCP flow’s the increment factor, the decrement factor, and the packet-loss rate pp [8]. We assume that all parallel TCP flows go through the same path and thus they have the same RTT and the packet-loss rate pp as well as having the same αp, βp and MSS. Let the aggregate throughput of the parallel TCP flows (on right side) be equal to K times of a single TCP flow (on the left side) as shown in (3). We find the new increment factor αp to satisfy the equation (3). In the standard single TCP flow, the increment factor αs is 1 and the decrement factor βs is 0.5. We do not change 0.5 as a decrement factor βp but the increment factor αp is modified as shown in (4). If we know both the packet-loss rate pp of G-TCP and the packet-loss rates ps of the single TCP flow which is supposed to compete with G-TCP on the same path,1 we can calculate the new αp. We can measure packet-loss rate pp by our parallel TCP flows but it is not easy to measure packet-loss rate ps until we open an additional single TCP flow. Instead we estimate the packet-loss rate ps as emulating a single TCP flow. G-TCP’s aggregate throughput is 1
In our preliminary simulation results, we found that packet-loss rates of a single TCP flow and our parallel TCP flows are not always same even though they are competing on the same path.
to be K times of the emulated single TCP flow and thus GTCP’s aggregate congestion window size divided by K should be that of the emulated single TCP flow as time goes. If a packet loss occurs, we set the emulated congestion window size to G-TCP’s aggregate congestion window size divided by K. Otherwise we increase the emulated congestion window size by one every RTT. Using the emulated congestion window size, we can estimate the packet-loss rate ps [9]. Ts ≤
Tp ≤
MSS 1.5 RTT ps
Ts ≤
or
MSS α p RTT p p
2− βp
βp
K×
MSS α s RTT p s
2 − βs
K
αp 1 =N ps pp
βs
III.
+ ⋅⋅⋅ +
= N×
⇒
MSS α s RTT p s αp pp
(1)
βs
(2)
2− βp β p
MSS α p RTT p p
αp =
2 − βs
2−βp
Fig 1. TCP friendliness when a single TCP flow and G-TCP with K=1 are competing on 1Gbps and RTT50ms
(3)
βp
K 2 pp N 2 ps
(4)
PRELIMINARY SIMULATION
We conducted simulations on the NS-2 simulator. The topology is a simple dumbbell network. All link bandwidth is set to 1 Gbps. The end-to-end RTT is 50ms. The routers have the queue size set to 1000 packets. DropTail queue is used at the routers. When opening G-TCP, we allocate K and N which are ranging from 1 to 100. Fig.1 shows TCP friendliness when a single TCP flow is competing with G-TCP of which K is 1 and N is varying from 1 to 100. In the result, G-TCP has fair bandwidth with the single TCP flow regardless of the number of N. Fig. 2 displays that G-TCP controls its aggregate throughput when competing with a single TCP flow. K is ranging from 1 to 100 while N is fixed to 10. The result shows the aggregate throughput of G-TCP is governed according to K. IV.
RELATED WORKS
There are many studies to improve the performance of the transport protocol. New TCP variants such as HighSpeed TCP [2], Scalable TCP, FAST TCP, and BIC TCP deal with modifying the window growth function of TCP in a more scalable fashion. MulTCP [10] is a single TCP flow which behaves as several virtual TCP flows. LTCP [11] is similar to MulTCP but acts to K virtual TCP flows where K is dynamically adjusted according to the network condition state. These approaches focus on operating a single TCP flow. GridFTP[3], bbcp[4], and pSocket[5] open a fixed number of parallel TCP flows. Choosing the optimal number of the flows is significant challenge. Combined TCP[8] describe a scheme for using virtual round trip time for choosing a tradeoff between fairness and effectiveness of the network usage. TCPP[12] controls aggressiveness of the parallel TCP flows. TCP-P use virtual round trip time of Combined TCP to increase each flow’s congestion window size and reduce all flows’ congestion window size uniformly every packet loss as MulTCP does. A-TCP-P[13] uses a competition detection for TCP-P to be adaptive according to network situations. Our goal is similar to A-TCP-P’s goal to control the aggregate is similar to A-TCP-P’s goal to control the aggregate throughput of
Fig 2. Control of the aggregate throughput in G-TCP with N=10 when competing with a single TCP flow on 1Gbps and RTT50ms
the parallel TCP flows adaptively. Our G-TCP simply change the increment factor without synchronizing decrements of all parallel TCP flows every packet loss. V.
REFERENCES
[1]
V. Jacobson, “Congestion avoidance and control,” Proceedings of ACM SIGCOMM 1988, August 1988.
[2]
S. Floyd, “HighSpeed TCP for Large Congestion Windows,” IETF RFC3649, December 2003.
[3]
B. Allcock, at al., "Data management and transfer in high-performance computational grid environments," Parallel Computing, vol. 28, no. 5, pp. 749–771, May 2002.
[4]
A. Hanushevsky at al, "P2P Data http://www.slac.stanford.edu/abh/bbcp
[5]
H. Sivakumar at all, "PSockets: The case for application-level network striping for data intensive applications using high speed wide area networks," SuperCompuiting 2000, November, 2000.
[6]
L. Brakmo, S. OMalley, and L. Peterson, "TCP Vegas: New techniques for congestion detection and avoidance," Proceedings of ACM SIGCOMM 1994, August 1994.
[7]
M. Mathis, J. Semske, J. Mahdavi, and T. Ott, "The macroscopic behavior of the TCP congestion avoidance algorithms," ACM Computer Communication Review, vol. 27(3), July 1997.
[8]
T. J. Hacker, B. D. Noble, and B. D. Athey, "Improving Throughput and Maintaining Fairness Using Parallel TCP," In Proceedings of IEEE INFOCOM 2004, March 2004.
[9]
Yusung Kim, Lisong Xu, and Kilnam Chon, “The control of parallel TCP flows to improve fairness and scalability,” Technical Memo, SAL-TM-104, 2007
Copy
Programbbcp,"
Available:
[10] Jon Crowcroft and Philippe Oechslin, "Differentiated End-to-End Internet Services using a Weighted Proportional Fair Sharing TCP," ACM CCR, vol. 28, no. 3, July 1998.
[11] S. Bhandarkar, Saurabh Jain, and A. L. Narasimha Reddy LTCP: improving the performance of TCP in highspeed networks ACM SIGCOMM Computer Communication Review Volume 36 , Issue 1 Pages: 41 – 50, January 2006.
[12] S. Cho and R. Bettati, "Aggregated Aggressiveness Control on Groups of TCP Flows", Proceedings of IFIP Networking 2005, May 2005.
[13] S. Cho and R. Bettati, "Adaptive Aggregated Aggressiveness Control on Parallel TCP Flows Using Competition Detection", IEEE ICCCN 2006, Oct. 2006.
