Simulation-based Comparisons of HighSpeed, Westwood and FAST TCP

Transcription

1

2 Simulation-based Comparisons of HighSpeed, Westwood and FAST TCP Vance Chen Computer Science Department Boston University Boston, MA ABSTRACT The objective of this project is to study and compare the performances of HighSpeed TCP [1], TCP Westwood [2], and FAST TCP [3] in high speed networks. High speed networks which are envisioned to reliably carry massive amount of data are emerging and becoming more common and widely used (e.g. Gigabit LAN, Internet 2). In a high speed environment we are facing a growing need for more effective communication mechanisms compared to the current in-used TCP (i.e. TCP Reno). A lot of research proposals have discussed the associated evaluation criteria and protocol strategies for the suggested modifications. Solutions are aimed to improve the efficiency of the traditional congestion control mechanism. We used the real time network simulation tool ns2 [4] to complete our analyses of the above three different variants of TCP. First, we were interested in how HighSpeed TCP, TCP Westwood and FAST TCP perform in terms of the throughputs when high packet drop rates presented, the link utilization with effect of different RTTs, their fairness and time to converge and the reaction when only limited buffer available at the router in the high speed network environment. At last, based on the experiments that we have performed and the satisfying results that we have obtained, conclusion has been made that FAST TCP provides better solutions than HighSpeed TCP and TCP Westwood do and is more suitable for today s high speed networks. 1. INTRODUCTION Transmission Control Protocol (TCP) is a key transport protocol in today s Internet. The congestion avoidance mechanisms of the current standard TCP constrains the congestion window that can be achieved by TCP in realistic environments. For example, for a standard TCP connection with byte packets and a 100 ms Round-Trip Time (RTT), achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments and a packet drop rate of at most one congestion event every 5,000,000,000 packets. This constraint has severe impacts on performance in a high speed scenario. When a loss is detected either through duplicate acknowledgements (DUPACKs), or through a coarse timeout expiration, the connection backs off by shrinking its congestion window. If the loss is indicated by DUPACKs, TCP Reno attempts to perform a fast recovery by retransmitting the lost segments and halving the congestion window. If the loss is followed by a coarse timeout expiration, the congestion window is reset to1. In either case, after the congestion window is reset, the connection needs several round-trip times before the windowbased probing is restored to near-capacity. As a result, TCP Reno has difficulties in networks with large bandwidth-delay products. At the packet level, linear increase by one packet per RTT is too slow, and multiplicative decrease per loss event is too drastic. At the flow level, maintaining large average congestion windows requires an extremely small equilibrium loss probability. Our goal is to investigate the performance of various newly proposed versions of TCP (in particular, HighSpeed TCP with Limited Slow-Start, TCP Westwood and FAST TCP) in networks of high-speed links (Gbps). To reach our goal, we used the ns2 network simulator. We divided our work

3 into four tasks with each one illustrating different subjects we concerned. This paper is organized as follows: In Section 2 we introduce Limited Slow-Start [5] and HighSpeed TCP which deal with the traditional slow-start and congestion window limitations in high-speed networks. Section 3 and 4 describe the basics of TCP Westwood and FAST TCP. In Section 5 we discuss the related works of other flavors of TCP in high speed environments. Section 6 is our simulation results and we have our conclusion in Section LIMITED SLOW-START and HIGHSPEED TCP Slow-Start is a mechanism to avoid that an inappropriate large burst of traffic is suddenly put into the pipe when the sender begins to send its data through a newly-created TCP connection. The basic idea is that the sending rate at which new packets should be injected into the network depends on the rate at which the acknowledgements (ACKs) are returned by the receiver. The original Slow-Start works as follow. At the beginning, the parameter cwnd is set to one segment size and the parameter ssthresh is set to receiver s advertised window value. The sender can send up to the minimum of cwnd and the receiver s advertised window. It transmits one segment and waits for the corresponding ACK. When the ACK is received, the congestion window is incremented from one to two, and two new segments can be sent. When each of those two segments is acknowledged, the congestion window is incremented to four and so on resulting in an exponential growth of cwnd. Slow-Start continues until cwnd meets or exceeds the ssthresh or a packet loss is detected. The problem with original Slow-Start is that in high speed network environments, cwnd must reach values of hundreds even thousands of segments and then the current Slow-Start can lead to increase the congestion window by thousands of segments per RTT. Such an increase can easily overwhelm the available bandwidth and result in thousands of packets to be dropped in just one RTT which need to be recovered later on. Limited Slow-Start is a modified version of traditional Slow-Start proposed by Sally Floyd trying to provide a solution to the above problem. Limited Slow-Start introduces a parameter, max_ssthresh, and modifies the slow-start mechanism for values of the congestion window. For each arriving ACK in Slow-Start phase: If (cwnd <= max_ssthresh) cwnd += MSS; // Standard Slow-Start else K = int(cwnd/(0.5 max_ssthresh)); cwnd += int(mss/k); // Limited Slow-Start Namely, Limited Slow-Start equals Standard Slow- Start if cwnd <= max_ssthresh and cwnd is increased by one Maximum Segment Size (MSS) for every arriving ACK. Limited Slow-Start takes effect if max_ssthresh < cwnd <= ssthresh and then cwnd is increased by at most max_ssthresh/2 MSS per round trip time. Thus, during Limited Slow- Start the window is increased by 1/K MSS for each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead of by 1 MSS as in standard slow-start. When ssthresh < cwnd, the TCP sender exits Slow-Start, and enters the congestion avoidance phase. The author of Limited Slow-Start recommended setting max_ssthresh to be 100 MSS. The traditional congestion avoidance algorithm uses Additive Increase Multiplicative Decrease (AIMD) to probe the available bandwidth and the network for additional capacity gradually. During this phase, cwnd is increased one segment size per RTT and halved if a packet loss is detected. In Section 1, we have already described the problems of congestion avoidance in TCP Reno in high speed networks. HighSpeed TCP is a sender-side alteration to regular TCP. It was introduced by Sally Floyd as a modification of TCP s congestion control mechanism to improve the performance in fast, long delay networks. This modification is designed to behave like Reno for small values of cwnd, but above a chosen value of cwnd a more aggressive response function is used (Table 1 and Table 2). When cwnd is large (greater than 38 packets), the modification uses a table to indicate by how much to increase the congestion window when an ACK is received, and it releases less network bandwidth than 1/2 cwnd on packet losses. The different response function achieves high throughput without requiring unrealistically low packet drop rates. HighSpeed TCP increases the congestion window by a(w) segments per RTT in the absence of congestion, and decreases the congestion window to w(1 b(w)) segments in response to a RTT with

4 one or more loss events. Thus in response to a single ACK, HighSpeed TCP increases its cwnd in segments as follows: w w + a(w)/w and responds to a congestion event by decreasing the congestion window as w w(1 b(w)). In standard TCP, a(w) = 1 and b(w) = 1/2. Basically, a(w) is a function of the current window size and the packet drop rate and b(w) is a function of the current window size. Packet Drop Congestion RTTs between Rate P Window W Losses 10 ^ ^ ^ ^ ^ ^ ^ ^ ^ Table 1: TCP Response Function for Standard TCP (TCP Reno). The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P. Packet Drop Congestion RTTs between Rate P Window W Losses 10 ^ ^ ^ ^ ^ ^ ^ ^ ^ Table 2: TCP Response Function for HighSpeed TCP. The average congestion window W in MSS-sized segments is given as a function of the packet drop rate P. In Figure 1 we showed both the values of cwnd for HighSpeed TCP and regular TCP. We can see in HighSpeed TCP the more aggressive AIMD mechanism is applied to achieve the high throughput more effectively compared to the regular TCP. Overall, HighSpeed TCP s goal is to allow TCP to achieve high throughput with more realistic requirements for the steady-state packet drop rate. HighSpeed TCP has more realistic requirements for the number of RTTs between loss events [1]. Figure 1: cwnd of HighSpeed TCP and regular TCP 3. TCP WESTWOOD TCP Westwood is a new protocol that modifies the sender-side of the window congestion control scheme. The strategy is that TCP Westwood sets a slow start threshold and a congestion window which are consistent with the network capacity measured at the time congestion is experienced. It controls the window by using end-to-end connection bandwidth share estimation. TCP Westwood takes continuous estimates, at the TCP sender, of the packet rate of the connection. This is done by monitoring the ACK reception rate. DUPACKs, indicate an out-of-order reception and they should count toward the bandwidth estimate, and new estimate should be computed right after their reception. However, the sender is in no position to tell for sure which segment triggered the DUPACK transmission, and it is thus unable to update the data count by the size of that segment. The authors of TCP Westwood first assumed all TCP segments have the same size and the sequence numbers are incremented by one per segment sent and then used an average of the segment size sent thus far in the ongoing connection which allows for corrections when the next cumulative ACK is received. The basic bandwidth estimation is performed using a low-pass filter described by the following pseudo code:

5 If (ACK is received) sample_bwe k = (acked * pkt_size * 8) / (now - lastacktime); BWE k = (19 / 21) * BWE k-1 + (1 / 21) * (sample_bwe k + sample_bwe k - 1 ); End if In the algorithm, acked is the number of segments acknowledged by the latest ACK. The authors also took into account the effects of delayed and cumulative ACKs and took care of the issue of DUPACKs mentioned earlier for a more accurate acked variable in the above algorithm by using the procedure AckedCount as described in [2]. pkt_size is the segment size in bytes, now indicates the current time and lastacktime indicates the time that the previous ACK was received. Therefore, BWE is the low-pass filtered measurement of the available bandwidth. The BWE as defined above is the rate actually achieved by the individual flow. When the bottleneck becomes saturated and packets are dropped, TCP Westwood selects congestion windows which enforce the current measured rates. In particular, assuming that a sender has determined the connection bandwidth estimate, it is used to properly set cwnd and ssthresh after a packet loss indication. In TCPWestwood, the congestion window dynamics during slow start and congestion avoidance are unchanged, which means that they increase exponentially and linearly, respectively, as in current TCP Reno. The idea of TCP Westwood is to try to compute each flow s fair share of the bandwidth directly, rather than performing the traditional slow start and congestion control periods. This will improve performance in high speed networks because it will allow the TCP flows to converge to their share of the bandwidth at a much faster rate. In Figure 2 we showed the link utilization of TCP WestwoodNR (the name followed by NR because it is based on the TCP New Reno) and TCP New Reno. As we can see TCP WestwoodNR reached the full capacity of the link much faster than TCP New Reno. TCP WestwoodNR used less than 1 second to get the full bandwidth. However, TCP New Reno used about 10 seconds to reach the full capacity. Figure 2: Link utilization of TCP WestwoodNR and TCP New Reno 4. FAST TCP FAST TCP can be viewed as a high speed version of TCP Vegas. It was introduced by Steven Low and his group at Caltech. The window control component determines the congestion window based on both queuing delays and packet losses. The key decision of the design is that the same algorithm is used for congestion window computation independent of the state of the sender. FAST TCP is improved based on a prime-dual model where TCP protocol is modeled by a nonlinear closed-feedback and time-delay control system. Current TCP is not stable when used in a network with high product of capacity and delay. Therefore, to stabilize the sending rate at the source, FAST TCP implements two control mechanisms. One is implemented at the sender to adjust the sending rate dynamically based on an equation and another one is to obtain a congestion measure based on the aggregate flow rate on a link. The equation for adjusting sending rate at the sender is obtained by proper parameter assignment and polezero placement using Nyquist stability analysis. By appropriately choosing the equation, FAST TCP can achieve its objective for high performance, stability and fairness in high speed environments. Under normal network conditions, FAST TCP periodically updates the congestion window as followed: cwnd min{2 * cwnd, (1 - gamma) * cwnd + gamma * (basertt / RTT + alpha (cwnd, qdelay))} based on the average RTT and average queuing delay provided by the estimation

6 component, where gamma = (0, 1], basertt is the minimum RTT observed so far, RTT is the sample RTT measured by a weighted averaging formula, qdelay is the end-to-end (average) queuing delay, and the constant alpha is the number of packets each flow attempts to maintain in the network buffers at equilibrium, similar to TCP Vegas. Currently when a packet loss is detected, FAST TCP halves its window in order to back off packet transmission quickly when sever congestion occurs and bring the system back to the regime where reliable RTT measurements are again available for window adjustment (using the formula described above) to work effectively. Details on how the estimations for average RTT and queuing delay are done could be found in [3]. In Figure 3, we showed the comparison of link utilization for FAST TCP and TCP Vegas. As we can see FAST TCP reached the full capacity of the link much faster than TCP Vegas. FAST TCP used only less than 1 second to reach the full capacity of the link. However, TCP Vegas needed around 10 seconds to get the full bandwidth. recovery time of the standard TCP. The idea is built on the idea of HighSpeed TCP. Packet loss recovery times for a traditional TCP connection as well as HighSpeed TCP connection are proportional to the connection s congestion window size and RTT. A Scalable TCP connection s packet loss recovery times are proportional to connection s RTT only. The generalized TCP window update algorithm responds to each acknowledgement received in a round trip time in which congestion has not been detected with the update by cwnd cwnd + a where a is a constant between 0 and 1. When the first detection of congestion is given in a round trip time, the congestion window is altered by cwnd cwnd ceil(b * cwnd) where b is also a constant between 0 and 1. The values of a and b are selected by considering the convergence speed and instantaneous rate variation and can be configured using the proc file system by a super user in Linux. Like HighSpeed TCP the modified congestion avoidance algorithm takes place only when the congestion window is above some threshold. The default values for a is 0.01, b is 0.125, and the threshold congestion window size is 16 segments. Overall Scalable TCP was designed from a strong theoretical base in order to ensure resource sharing and stability while also remaining agile in prevailing network conditions. Figure 4 (from Scalable TCP website shows the main difference in the scaling properties of traditional and Scalable TCP. Figure 3: Link utilization of FAST TCP and TCP Vegas 5. RELATED WORK In this section, we describe two additional TCP variants designed for high speed network environments. 5.1 Scalable TCP Scalable TCP [6] is a sender-side alteration to the regular TCP congestion window update algorithm. The main goal of Scalable TCP is to improve the loss Figure 4a: Traditional TCP with large capacity

7 6. SIMULATION RESULTS Our objective for this project is to use network simulator ns-2 in order to thoroughly understand the issues that take place over high speed links. We have designed a series of cases that will help us understand every detail of what takes place in a network with high speed links when using HighSpeed TCP with Limited Slow-Start, TCP WestwoodNR, and FAST TCP. 6.1 Packet Drop Rate Figure 4b: Scalable TCP with large capacity 5.2 XCP (explicit Congestion control Protocol) XCP [7] was proposed by Dina Katabi at el. in MIT. XCP generalized the Explicit Congestion Notification (ECN). Instead of one bit congestion indication used by ECN, it proposes using precise congestion signaling, where the network explicitly tells the sender the state of congestion and how to react to it. Sender maintains the congestion window and RTT and communicates this to routers via a congestion header (Figure 5) in every packet. Then it uses the feedback field in the congestion header to request its desired window increase. In addition, XCP introduces the new concept of decoupling utilization control from fairness control. A router has both an efficiency controller and fairness controller. This allows a more flexible and analytically tractable protocol design and opens new avenues for service differentiation. The purpose of efficiency controller is to maximize link utilization while minimizing drop rate and persistent queues. The fairness controller uses standard TCP s AIMD mechanism to converge to fairness. Sender s current cwnd (filled by sender and remains unmodified) Sender s RTT estimate (filled by sender and remains unmodified) Feedback (initialized to sender s demands; can be modified by the routers) Figure 5: Congestion header in a packet for XCP There are several reasons can cause high packet drop rate. Even in high speed networks, when too many flows are active and the bandwidth or the queue size of the bottleneck link is limited, TCP should be responsible for dealing with this issue properly to maintain the throughput and achieve the stability. We tried to analyze the performance of HighSpeed TCP, TCP WestwoodNR, and FAST TCP with high sending rate in the presence of high packet drop rate. The related issue, buffer management will be discussed in Section 6.4. Network Topology: S 1 Gbps 2 ms delay r Mbps 10 ms delay r 2 1 Gbps 2 ms delay In this section we simulated HighSpeed TCP, TCP WestwoodNR and FAST TCP to see how they perform under different packet drop rates in high speed networks. Here in this case we set the buffer size to a fixed size (bandwidth-delay product) to fully utilize the bottleneck link. Packets would be dropped due to buffer overflow. In addition, we used an instance of ErrorModel in ns-2 to artificially generate packet losses. The instance we created was a random variable with uniform distribution. We were particularly interested in and specified the packet drop rates as 10 ^ -7, 10 ^ -5 and 10 ^ -3. The receiver s window is set to a large enough size so that it will not limit the bandwidth usage on the link. Ideally, the modified congestion control mechanisms of these newly-proposed versions of TCP should properly response to different packet loss rates in the network of high speed links. R

8 Figure 5a: Link utilization of HighSpeed TCP, TCP Westwood and FAST TCP with packet drop rate = 10 ^ -7 Figure 5b: Link utilization of HighSpeed TCP, TCP Westwood and FAST TCP with packet drop rate = 10 ^ -5 Figure 5c: Link utilization of HighSpeed TCP, TCP Westwood and FAST TCP with packet drop rate = 10 ^ -3

9 HighSpeed TCP: Network Topology: In Figure 5a and Figure 5b, we can see that HighSpeed TCP performed very well when the loss rate ranges from very low (10 ^ -7) to medium (10 ^ - 5). However, when the loss rate is high (10 ^ -3 in Figure 5c), HighSpeed TCP only can utilize about 30% of the bandwidth of the bottleneck link. Insuch a high loss rate environment, HighSpeed TCP performed worse than both TCP WestwoodNR and FAST TCP. S1 S2 1 Gbps 2 ms r1 1 Gbps 10 ms 100 Mbps 10 ms 1 Gbps 2 ms r2 1 Gbps 2 ms R1 R2 TCP WestwoodNR: As we can see among the three graphs of Figure 5, even if TCP WestwoodNR did not fully utilize the bottleneck link when setting the loss rate at 10 ^ -7 and 10 ^ -5, due to its better congestion control mechanism than HighSpeed TCP, it still can use at least 50% of the bandwidth of the bottleneck link when the loss rate is very high (10 ^ -3). In comparison to HighSpeed TCP, it is more stable because it is designed not only for high speed networks but also for high packet drop rate environments, such as wireless networks. FAST TCP: It is apparent that FAST TCP performed the best in our packet drop rate experiments. Even if the loss rate is as high as 10 ^ -3, from Figure 5c, we can see that FAST TCP maintained an almost 100% utilization of the bandwidth of the bottleneck link. Beyond that, it also performed the best in the other two cases of different packet drop rate due to its better queue management and RTT estimation based on TCP Vegas. 6.2 Effect of RTT The effect of RTT is an interesting subject especially when FAST TCP which is based on TCP Vegas uses it to estimate the available bandwidth and adjust its sending rate. We would like to see the stability of HighSpeed TCP, TCP WestwoodNR, and FAST TCP in the presence of different RTT in high speed networks. In this section we simulated HighSpeed TCP, TCP WestwoodNR and FAST TCP and analyzed the effects of changing the delays on each of the incoming links to the bottleneck link to see how the performance would be affected. We set the RTT of flow 1 from S1 to R1 through router r1 and r2 28 ms and set the RTT of flow 2 from S2 to R2 also through router r1 and r2 44 ms. In this experiment, flow 1 and flow 2 belonged to the same version of TCP and packet will be dropped due to buffer overflow at the bottleneck link. The total simulation time is 100 seconds HighSpeed TCP: From Figure 6a, flow 1 with 28 ms RTT dominated the 90% of the bandwidth of the bottleneck link through the whole simulation process. Flow 2 with longer RTT (44 ms) only got around 10% of the bandwidth of the bottleneck link. Even if it is very stable for those two HighSpeed TCP flows (their allocated bandwidth almost did not change and the cwnd of each flow also fixed in certain range), however we did not consider the two flows got fair share of the bandwidth allocation. The term fair share and fairness we used in this paper mean max-min fairness. That is we considered the modified version of TCP satisfied fairness if and only if flow 1 and flow 2 obtained equal bandwidth (50% for each flow) at the bottleneck link because we only had two flows competing here and they were set to have the same sending rates. However for HighSpeed TCP, because the connection with shorter RTT reacts sooner, it would get more bandwidth. This is also true for TCP WestwoodNR as we would see. It is the problem of RTT-proportional fairness presented in traditional TCP as well.

10 Figure 6a: Link utilization of two HighSpeed TCP flows with different RTTs Figure 6b: Link utilization of two TCP Westwood flows with different RTTs Figure 6c: Link utilization of two FAST TCP flows with different RTTs

11 TCP WestwoodNR: Figure 6b showed that the dramatic oscillations for both TCP WestwoodNR flows. Not even did the two flows with different RTTs get their fair share of the bandwidth, but very unstable in the value of cwnd. At the beginning it seemed that the two flows tended to get the equal share of the bandwidth allocation of the bottleneck link. However, TCP WestwoodNR failed to stabilize the two flows with their different RTTs during the whole simulation process. We consider TCP WestwoodNR the worst in this test. FAST TCP: Again, FAST TCP which based on TCP Vegas performed superiorly in the RTT test case. In Figure 6c, we can clearly see the two FAST TCP connections with different RTTs resulted in an exactly equal 50% bandwidth allocation of the bottleneck link for each flow at the beginning till the end of the simulation. Worth to note, the convergence only took about 1 second. Then we got very stable link utilization and cwnd for both flows. The performance of FAST TCP is not affected by different RTTs. As the result, we believe FAST TCP is better when handling flows with different RTT 6.3 Fairness and Convergence Time The main problem with high speed links is that because of the regular AIMD congestion control mechanism it may take some flows a long time to adapt to their share of the bandwidth. One question in high speed networks is the convergence time for the TCP flows and when these flows converge do they get their fair share of the bandwidth. The objective of this experiment is to calculate how long it takes for a flow to use all of the available bandwidth. The tests are when one flow starts before the other, how long it takes for the two flows to get to their fair share of the bandwidth and then when one of the flows ends before the other how long it will take for the remaining flow to get to the point where it is using all of the available bandwidth. Network Topology: The same as Section 6.2, we only change the RTT from S2 to r1 to 2 ms to get the equal RTTs for both flows. In this section, we performed several experiments and each of them took 100 seconds. First we started two HighSpeed TCP at the same time and ended one of them at 60 th second to see how fast the other flow can utilize the full capacity of the bandwidth. Second, we started only one flow at the beginning and after 20 seconds we added the second flow to see how fast the flows converge. Then we did the same tests on TCP WestwoodNR and FAST TCP. HighSpeed TCP: When one of the same starting time flows ended at 60 th second, the other flow can immediately utilize the full bandwidth of the bottleneck link. That means HighSpeed TCP responses to the change of the status of a high speed network very quickly when there is only one flow left. However, when there was only one flow in the high speed network and we added the other at 20 th second, HighSpeed TCP performed the worst when trying to converge. The two flows took over 55 seconds to converge. That is, we started the second flow at 20 th second but the first flow kept using most of the bandwidth till the two flows converged at nearly 80 th second. Compared to TCP WestwoodNR and FAST TCP, HighSpeed TCP took too much time for convergence. From Figure 7a we can see also the number of oscillation is really high. We had a congestion epoch about every 1.5 second for each flow. Even if HighSpeed TCP roughly maintained a fair share for each connection, the bandwidth allocated to each connection was varying from 30% to 70%. TCP WestwoodNR: For TCP WestwoodNR, when one of the same starting time flows ended at 60 th second, the other flow can immediately utilize the full bandwidth of the bottleneck link though with a little bit delay compared to HighSpeed TCP and FAST TCP. That means TCP WestwoodNR responses to the status of the high speed environments quickly. Even when there was only one flow in the high speed network and we added the other at 20 th second, TCP WestwoodNR performed very well when trying to converge. The two flows took less than 20 seconds to converge. That is, we started the second flow at 20 th second and the two flows converged at around 38 th second. Compared to HighSpeed TCP, TCP WestwoodNR took much less time for convergence. From Figure 7b we can see not only the convergence time for two TCP WestwoodNR connections was short, but the number of oscillation is really less than it in HighSpeed TCP as well. We had a congestion epoch about every 5~6 second for each flow. As to fairness, TCP WestwoodNR had similar fairness for each connection as HighSpeed TCP did. It roughly maintained a fair share for each flow, but with the bandwidth allocated to each connection was varying from 30% to 70%.

12 Figure 7a: Link utilization of two HighSpeed TCP flows with different ending time Link utilization of two HighSpeed TCP flows with different starting time Figure 7b: Link utilization of two TCP WestwoodNR flows with different ending time Link utilization of two TCP WestwoodNR flows with different starting time Figure 7c: Link utilization of two FAST TCP flows with different ending time Link utilization of two FAST TCP flows with different starting time

13 FAST TCP: The simulation results here for FAST TCP are very satisfying. FAST TCP allocated equally fair share (50%) to both flows at the beginning and when one of the two flows ended at 60 th second, the other flow reached the full bandwidth of the bottleneck link immediately. Similarly, when we started one flow first and then added the other flow at 20 th, those two flows converged immediately and got their fair share about 50% of the available bandwidth. In Figure 7c we have shown that when considering the fairness and the convergence time in a high speed environment. FAST TCP performed superiorly than HighSpeed TCP and TCP WestwoodNR. 6.4 Buffer Management Buffer overflow is the main reason to cause the packets to be dropped at the bottleneck link. Normally, the buffer size is set to be the bandwidth delay product of the bottleneck link. However, we would like to see how the different versions of TCP react to a limited buffer size in the router at the bottleneck link in the high speed networks. We are also interested in the effect of doubling the bandwidth delay product buffer size in the network of high speed links. Network Topology: The same as Section 6.3, we only change the queue size at the bottleneck link from r1 to r2. The goal of this experiment is to see how the queue size affects the performance of each of these three versions of TCP and namely how those TCP manage the buffer in the high speed environments. First we set the buffer size as half of the bandwidth delay product, and then we set the buffer size as double the bandwidth delay product. The same simulations were performed on HighSpeed TCP, TCP WestwoodNR, and FAST TCP. HighSpeed TCP: When the buffer size was half of the bandwidth delay product, the two HighSpeed TCP flows can reach totally only 95% bandwidth of the bottleneck link. Each of the two connections utilized the bandwidth from 30% to 65%. When the buffer was doubled, even 100% utilization of the capacity of the link could be reached, each flow got its share varied dramatically from 0 to 1. HighSpeed TCP performed the worst in this test case. TCP WestwoodNR: Figure 8b showed that halving the buffer size, TCP WestwoodNR still can perform very well. Also more stable than HighSpeed TCP no matter it is the case we halved the buffer size or doubled the buffer size. The utilization of the bottleneck link could be maintained at 100% and the fairness was good enough to let each flow get around 50% of the bandwidth. However, when the queue size was doubled, each of the WestwoodNR connections may get its share ranging from 30% to 70%. Generally, TCP WestwoodNR has better queue management than HighSpeed TCP due to its continuously bandwidth estimation. FAST TCP: Again, we can see from Figure 8c, FAST TCP has the best queue management scheme. Each of the two flows got almost exactly 50% of the bandwidth all the time regardless of the queue size at the bottleneck link. It is also shown that FAST TCP is very stable while we changing the size of the buffer. FAST TCP like TCP Vegas can usually maintain certain number of packets kept in the queue in some fixed range. Due to so, FAST TCP manages the queue more effectively than HighSpeed TCP and TCP Westwood and thus performed the best in this test case. 7. CONCLUSION In this project, we introduced some lately proposal for improving TCP performance in high speed networks. Especially, we described the basic ideas of HighSpeed TCP with Limited Slow-Start, TCP Westwood, and FAST TCP. Then we designed some experiments we were interested in. Each of the tasks focuses on a different aspect of performance in a network with high speed links. In 6.1 we evaluated the performance of each of the three versions of TCP individually with different packet drop rate. We took into account the effect of RTTs in 6.2. Then we took care of the convergence time and the fairness of HighSpeed TCP, TCP Westwood, and FAST TCP in the high speed environments. At last, we performed the simulation on these TCP with different buffer size. All the results we obtained from the simulation have shown that FAST TCP outperformed the other two in the test cases we set. Its performance is not affected by the RTT and can reach high throughput even under high packet drop rate. FAST TCP flows also converge to their fair share in a very short of time and can manage any size of the queue at the bottleneck link effectively.

14 Figure 8a: Link utilization of two HighSpeed TCP flows with half bandwidth delay product queue size Link utilization of two HighSpeed TCP flows with double bandwidth delay product queue size Figure 8b: Link utilization of two TCP WestwoodNR flows with half bandwidth delay product queue size Link utilization of two TCP WestwoodNR flows with double bandwidth delay product queue size Figure 8c: Link utilization of two FAST TCP flows with half bandwidth delay product queue size Link utilization of two FAST TCP flows with double bandwidth delay product queue size

15 8. REFERENCES [1] Sally Floyd, HighSpeed TCP for Large Congestion Windows, RFC 3649, Experimental, December 2003 [2] S. Mascolo, C. Casetti, M. Gerla, S. S. Lee, and M. Sanadidi, TCP Westwood: congestion control with faster recovery, UCLA CSD Technical Report #200017, 2000 [3] Cheng Jin, David X. Wei and Steven H. Low, FAST TCP: Motivation, Architecture, Algorithms, Performance, Caltech CS Report CaltechCSTR:2003:010, December 17, 2003 [4] The Network Simulator ns-2 [5] Sally Floyd, Limited Slow-Start for TCP with Large Congestion Windows, RFC 3742, Experimental, March 2004 [6] Tom Kelly, Scalable TCP: Improving Performance in High Speed Wide Area Networks, First International Workshop on Protocols for Fast Long-Distance Networks, Geneva, February 2003 [7] Dina Katabi, Mark Handley and Chalrie Rohrs, Congestion Control for High Bandwidth-Delay Product Networks, Proceedings on ACM Sigcomm 2002 [8] M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti, S. Mascolo, "TCP Westwood: Congestion Window Control Using Bandwidth Estimation", In Proceedings of IEEE Globecom 2001, Volume: 3, pp , San Antonio, Texas, USA, November 25-29, 2001 [9] M. Gerla, S. S. Lee, and G. Pau, "TCP Westwood Simulation Studies in Multiple-Path Cases", Proc. International Symposium on Performance Evaluation of Computer and Telecommunication Systems (SPECTS), San Diego, CA, USA, July, 2002 [10] NS2 implementation of FAST TCP [11] Cheng Jin, David X. Wei and Steven H. Low, FAST TCP for high-speed long-distance networks, Internet-Draft, June 30, 2003