Internet Engineering Task Force Sumitha Bhandarkar INTERNET DRAFT Saurabh Jain draft-bhandarkar-ltcp-01.txt A. L. Narasimha Reddy Expires : February 2005 Texas A&M University August 2004 LTCP: A Layering Technique for Improving the Performance of TCP in Highspeed Networks. Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract: This document proposes Layered TCP (LTCP for short), a simple layering technique for the congestion window response of TCP to make it more scalable in highspeed networks. LTCP is a two dimensional congestion control framework - the macroscopic control uses the concept of layering to quickly and efficiently make use of the available bandwidth whereas microscopic control extends the existing AIMD algorithms of TCP to determine the per-ack behavior. This document provides the general intuition and framework for the LTCP protocol modifications. Using a simple design, the effectiveness of using layering for improving the efficiency without sacrificing the convergence properties of TCP, is illustrated. The chosen design is evaluated using mathematical analysis, ns-2 based simulations and emulation on a Linux testbed. The results show that LTCP has promising convergence properties, is about an order of magnitude faster than TCP in utilizing high bandwidth links, employs few parameters and is easy to understand. The flexible framework opens a whole class of design options for improving the performance of TCP in Bhandarkar, Jain & Reddy [Page 1] draft-bhandarkar-ltcp-01 August 2004 highspeed networks. This document is an effort to solicit more experimentation and feedback from the broader networking community. 1. Introduction Over the past few decades the traffic on the Internet has increased by several orders of magnitude. However, the Internet remains a stable medium for communication. This stability has been attributed primarily to the wide-spread use of congestion control algorithms of TCP [F00] which use the additive increase / multiplicative decrease policy for moderating the congestion window. Specifically, the congestion window evolves as follows - when there are no losses in the network, the window is increased by one for each RTT and upon a loss of packet, the window is reduced by half. While such window behavior helps maintain proportional fairness (among flows with similar RTTs), recent studies have shown it to be highly inefficient in utilizing available bandwidth in high bandwidth networks with capacities close to or in excess of 1Gbps. Several solutions have been proposed to remedy the problem. We bring our proposal of LTCP to the research community through this draft to be evaluated in comparison with the other proposed schemes. LTCP enhances the congestion control algorithms of TCP with a simple layering technique. The idea of layering to probe and utilize the available bandwidth has been studied previously in the context of video transmission on the Internet and in multicasting[MJV96,VRC98]. The contribution of this document is to extend this idea to the congestion control algorithms in TCP to provide a general framework where scalability can be achieved at the cost of minimal modifications to the existing implementations. We provide the intuition for the framework and a simple design for illustrating the effectiveness of layering. The design is evaluated through analysis, ns-2 simulations and emulations on a Linux testbed. We welcome comments and research regarding other possible design options. 2. Problem Description The throughput of a TCP connection is given by T = (1.2 * S) / (R * sqrt(p)), where 'S' is the packet size, 'R' is the round trip time for the connection and 'p' is the packet loss rate [PFTK98]. This means that for a standard TCP connection using a packet size of 1500 bytes over a connection with round trip delay of 200ms and packet loss rate of 10^(-5), the maximum throughput that can be achieved is 23.2Mbps. If the packet loss rate were reduced to 10^(-7) the maximum throughput could be increased to 232.4Mbps. Conversely, to achieve a throughput of 1Gbps, the packet loss rate required is 5.4 X 10^(-9) or lower and for 10Gbps it should be 5.4 X 10^(-11). These loss rates are unreasonable - for the 10Gbps, the loss rate translates to a loss Bhandarkar, Jain & Reddy [Page 2] draft-bhandarkar-ltcp-01 August 2004 of at most one packet in 1.85 X 10^(10) packets or at most one loss for every six hours ! Clearly, the congestion response function of the standard TCP connections does not scale in high capacity networks, and new solutions are required for mitigating this problem. 3. Design Guidelines The proposal for LTCP in this document is motivated by the following requirements - * Better efficiency in bandwidth utilization : the new scheme should be capable of making good use of available bandwidth in high capacity networks with realistic packet loss rates. For any given loss rate, the performance should be atleast as good as standard TCP implementation. * Fairness to each other : when there are several flows of the new scheme in the network, they should be capable of achieving similar throughputs (provided they have similar RTTs). * Fairness to TCP : the flows using the new scheme should be fair to TCP flows in networks with low available bandwidth where the congestion window remains below a predefined window threshold W_T. In networks that allow the congestion window to grow larger than W_T, the flows using the new scheme should allow the TCP flows to operate without starvation. * Incremental Deployment : The new scheme should require minimal modifications to the existing TCP implementations and none to the network infrastructure. In other words, no additional feedback or modifications should be required at the network routers or receivers. * Flexible Design : The new scheme should be capable of using options such as SACK, ECN etc. It should also be capable of operating with new proposals such as limited slow start [F04] for modified slowstart etc. * RTT Unfairness Issues : The new scheme should be no worse than the existing TCP implementation regarding RTT unfairness. 4. LTCP Protocol 4.1. Framework The layered TCP scheme is a sender-side modification to the congestion response function of TCP for making it more scalable in high-speed networks. The congestion window response of the LTCP protocol is defined in two dimensions - (a) At the macroscopic level, Bhandarkar, Jain & Reddy [Page 3] draft-bhandarkar-ltcp-01 August 2004 LTCP uses the concept of layering to quickly and efficiently probe for available bandwidth (b) At the microscopic level, it extends the existing AIMD algorithms of TCP to determine the per-ack behavior. This section presents the intuition for the layering framework. We start by defining the parameter LTCP window threshold (W_T) as the window size below which LTCP is fair to standard TCP implementations. The optimal value of W_T is debatable and likely a topic of research by itself. In this document, we choose a heuristic value of 50 packets for W_T. This value is motivated by the fact that when the window scale option [JBB92] is not turned on, the maximum window size allowed is 64Kb which is about 44 packets (of size 1500 bytes). The window scale option is used in highspeed networks, to allow the receiver to advertise large window size. In order to ensure that the new scheme with aggressive bandwidth probing is fair to TCP is slow networks, we choose a window threshold value $W_{T}$ that is slightly greater than 44 packets. This imposes a constraint on LTCP to maintain proportional fairness to TCP flows in slow networks. Other arguments for keeping new protocols fair to TCP below a window threshold have been put forth in [F03,K03]. In order to ensure that below the threshold W_T, LTCP is fair to TCP, all new LTCP connections start with only one layer and behave in all respects the same as TCP. If the congestion window increases beyond the threshold W_T, the congestion window response is modified. Just like the standard implementations of TCP, the LTCP protocol is ack- clocked and the congestion window of an LTCP flow changes with each incoming ack. However, an LTCP flow increases the congestion window more aggressively than the standard implementation of TCP depending on the layer at which it is operating. At the microscopic level, when operating at some layer 'K', the LTCP protocol increases the congestion window as if it were emulating 'K' virtual flows. That is, the congestion window is increased by K/cwnd for each incoming ack, or equivalently, it is increased by 'K' on the successful receipt of one window of acknowledgements. This is similar to the increase behaviour explored in [CO98]. Layers, on the other hand, are added if congestion is not observed over an extended period of time. To do this, a simple layering scheme is used. Suppose, each layer 'K' is associated with a step-size delta_K. When the current congestion window exceeds the window corresponding to the last addition of a layer (W_K) by the step-size delta_K, a new layer is added. Thus, W_1 = 0, W_2 = W_1 + delta_1, ... W_K = W_(K-1) + delta_(K-1) and the number of layers is 'K', when W_K <= W < W_(K + 1). Fig. 1 shows this graphically. Bhandarkar, Jain & Reddy [Page 4] draft-bhandarkar-ltcp-01 August 2004 Layer Minimum Window Number Corresponding to the Layer | | | | V V K+1 ------------------------------ W_(K+1) ^ | | delta_K | V K ------------------------------ W_K ^ | | delta_(K-1) | V K-1 ------------------------------ W_(K-1) Fig 1: Graphical Perspective of Layers in LTCP The step size delta_K associated with the layer K should be chosen such that convergence is possible when several flows share the bandwidth. Consider the simple case when the link is to be shared by two LTCP flows. Say, the flow that started earlier operates at a higher layer K1 (with a larger window) compared to the later-starting flow operating at a smaller layer K2 (with the smaller window). In the absence of network congestion, the first flow increases the congestion window by K1 packets per RTT, whereas the second flow increases by K2 packets per RTT. In order to ensure that the first flow does not continue to increase at a rate faster than the second flow, it is essential that the first flow adds layers slower than the second flow. Thus, if delta_K1 is the stepsize associated with layer K1 and delta_K2 is the stepsize associated with layer K2, then delta_K1 / K_1 > delta_K2 / K_2 when K1 > K2, for all values of K1, K2 >= 2. The design of the decrease behavior is guided by similar reasoning - in order for two flows starting at different times to converge, the time taken by the larger flow to regain the bandwidth it gave up after a congestion event should be larger than the time it takes the smaller flow to regain the bandwidth it gave up. Suppose the two flows are operating at layers K1 and K2 (K1 > K2), and WR_K1 and WR_K2 is the window reduction of each flow upon a packet loss. After Bhandarkar, Jain & Reddy [Page 5] draft-bhandarkar-ltcp-01 August 2004 the window reduction, suppose the layers corresponding to the two flows is K1' and K2'. Then, the flows take WR_K1/K1' and Wr_K2/K2' RTTs respectively to regain the lost bandwidth. From the above reasoning, this gives us - WR_K1/K1' > WR_K2/K2' The window reduction can be chosen proportional to the current window size or be based on the layer at which the flow operates. If the latter is chosen, then care must be taken to ensure convergence when two flows operate at the same layer but at different window sizes. This framework provides a simple, yet scalable design for the congestion response function of TCP for the congestion avoidance phase in highspeed networks. The congestion window response in slow start is not modified, allowing the architecture to evolve with experimental slowstart algorithms. At the end of slowstart the number of layers to operate at can easily be determined based on the window size. The key factor for the architecture is to determine an appropriate relationship for the step size (delta) and window reduction that satisfy the conditions - delta_K1 / K_1 > delta_K2 / K_2 ---> [ the LTCP Constraint 1 ] WR_K1 / K1' > WR_K2 / K2' ---> [ the LTCP Constraint 2 ] when K1 > K2, for all values of K1, K2 >= 2. Several different choices are possible and we encourage discussion and feedback from the research community for the choice of the optimal design. To evaluate the effectiveness of the architecture we use a simple design, the details of which are presented in the next section. This design is by no means the only or the best design solution for the problem. We choose it for its simplicity and the ease of deployment that it provides. 4.2. Design Choice In order to evaluate the effectiveness of the LTCP protocol, we chose a simple design choice where we retain the multiplicative window reduction behavior. Upon a packet loss the window reduction is chosen to be WR = beta * W where beta is a constant < 1. Also, in order to allow smooth layer transitions, we stipulate that after a window reduction due to a packet loss, atmost one layer can be dropped i.e., a flow operating at layer K before the packet loss should operate at layer K or (K-1) Bhandarkar, Jain & Reddy [Page 6] draft-bhandarkar-ltcp-01 August 2004 after the window reduction. Based on this stipulation, if K1' and K2' are the layers at which the larger and the smaller flow operate after a packet loss, there are four possible cases (a) K1' = K1, K2' = K2 (b) K1' = K1, K2' = (K2-1) (c) K1' = (K1-1), K2' = K2 (d) K1' = (K1-1), K2' = (K2-1). It is most difficult to maintain the convergence properties, when the larger flow does not reduce a layer but the smaller flow does, ie, K1'=K1, K2'=(K2-1). With this worst case situation, the LTCP Constraint 2 can be written as - WR_K1/K1 > WR_K2/(K2-1) If this inequality is maintained for adjacent layers, then by simple extension, it will be maintained across all layers. So consider the case where K1 = K and K2 = (K-1). Also, suppose the window of the larger flow is W' and that of the smaller flow is W''. Then, the above inequality may be written as W'/K > W''/(K-2) The scenario that could result in the case considered above (K1' = K, K2' = (K-2)) will be when the window W' is close to transitioning into the layer (K+1) when the packet drop occurs, whereas the smaller flow has just transisioned into the layer (K-1). Suppose W_K is used to denote the window size when the flow transitions into layer K, then in the worst case, the following inequality should be satisfied - W_(K+1) > [ K/(K-2) ] * W_(K-1) Based on this we conservatively choose, W_K = [ (K+1)/(K-2) ] * W_(K-1) which defines the increase behavior. Note that alternate choices are possible. This is essentially a tradeoff between efficiently utilizing the bandwidth and ensuring convergence between multiple flows sharing the same link. While it is essential to choose the relationship between $W_{K}$ and $W_{K-1}$ such that convergence is ensured, a very conservative choice would make the protocol slow in increasing the layers and hence less efficient in utilizing the bandwidth. Since layering starts at W_2 = W_T we have, W_K = [ K (K+1) (K-1) / 6 ] * W_T By definition, delta_K = W_(K+1) - W_K. By simple substitution, it Bhandarkar, Jain & Reddy [Page 7] draft-bhandarkar-ltcp-01 August 2004 can be shown that this design satisfies the LTCP Constraint 1. Also, since the scheme was designed with the worst case for the inequality in the LTCP constraint 2, it satisfies the constraints when the flows are in adjacent layers which by simple extention holds for non- adjacents layers as well. It can also be shown that when two flows operate at the same layer, but with different window sizes, the inequality is still maintained. 4.2.1. Choice of beta The above presented analysis is hinged on the stipulation that after a window reduction due to packet drop, at most one layer is dropped. In order to ensure this, we have to choose the parameter beta carefully. The worst case for this situation occurs when the flow has just added the layer K and the window W = W_K + 'X', when the packet drop occurs. In order to ensure that the flow does not go from layer K to (K-2) after the packet drop, we need to ensure that beta * W_K < delta_(K-1) (Ignoring the reduction due to 'X' since we are computing the worst case behavior.) On simple substitution, this yields, beta < 3/(K+1) We show in later sections that a choice of 0.15 for the value of beta will allow the number of layers K to be sufficiently large enough to efficiently utilize the available link bandwidth in highspeed networks while maintaining the above inequality. With this design choice, LTCP retains AIMD behavior. At each layer K, LTCP increases the window additively by K, and when a packet drop occurs, the congestion window is reduced multiplicatively by a factor of beta. 4.2.2. Time to claim bandwidth and packet recovery time Suppose the maximum window size corresponding to the available throughput is W_K. Then, if we assume that slowstart terminates when layering starts, we can show that the time to increase the window to W_K is - T' + [ (K-2)(K+3) / 4 ] * W_T where T' is the time spent in slow start. This document DOES NOT recommend terminating slowstart when the layering starts. The analysis here uses this assumption to explain the characteristics of the lTCP protocol behavior. Table 1. below shows the number of layers corresponding to the windowsize at layer transitions (W_K) with W_T = 50. For a 2.4Gbps link with an RTT of 150ms and packet size of 1500 bytes, the window size can grow to 30,000. The number of layers required to maintain Bhandarkar, Jain & Reddy [Page 8] draft-bhandarkar-ltcp-01 August 2004 full link utilization is therefore K=15. The table also shows the speedup in claiming bandwidth compared to TCP, for an LTCP flow with W_T = 50, with the assumption that slowstart is terminated when window = W_T. This column gives an idea of the number of virtual TCP flows emulated by an LTCP flow. For instance, a flow that evolves to layer 15, behaves similar to establishing 10 parallel flows at the beginning of the connection. Also, an LTCP flow with window size W will reduce the congestion window by beta * W. It then starts to increase the congestion window at the rate of atleast (K-1) packets per RTT (since we stipulate that a packet drop results in the reduction of atmost one layer). The packet loss recovery time then, for LTCP is (beta * W)/(K-1). In case of TCP, upon a packet drop, the window is reduced by half, and after the drop the rate of increase is 1 per RTT. Thus, the packet recovery time is W/2. The last column of Table 1 shows the speed up in packet recovery time for LTCP with beta = 0.15 compared to TCP. Based on the conservative assumption that the layer number is (K-1) after a packet drop, the speed up in the packet recovery time of LTCP compared to TCP is a factor of 3.33 * (K-1). Speedup in Speedup in K W_K Claiming Packet Loss Bandwidth Recovery Time 1 0 - - 2 50 1.00 1.00 3 200 2.00 6.67 4 500 2.57 10.00 5 1000 3.17 13.33 6 1750 3.78 16.67 7 2800 4.40 20.00 8 4200 5.03 23.33 9 6000 5.67 26.67 10 8250 6.31 30.00 11 11000 6.95 33.33 12 14300 7.60 36.67 13 18200 8.25 40.00 14 22750 8.90 43.33 15 28000 9.56 46.67 16 34000 10.21 50.00 17 40800 10.87 53.33 18 48450 11.52 56.67 19 57000 12.18 60.00 20 66500 12.84 63.33 Table 1: Comparison of LTCP (with W_T = 50 and beta = 0.15) to TCP Bhandarkar, Jain & Reddy [Page 9] draft-bhandarkar-ltcp-01 August 2004 4.2.3. Convergence The inequality in the LTCP constraint 2 of the LTCP framework ensures that flows will converge asymptotically to a fair share, since a larger flow takes longer time to recover lost throughput than a smaller flow. With the current design, we can show that this inequality is held after a congestion event irrespective of the layer transitions and hence asymptotic convergence is ensured. 4.2.4. Throughput Analysis The bandwidth BW of an LTCP flow operating at layer K in steady state, in a network with uniform loss probability p and round trip time RTT can be shown to be [BJR04] - Sqrt(CK') BW = ------------------ (RTT * sqrt(p)) where C is a constant = (1/beta - 0.5) Again if we consider the example above of the 2.4Gbps link with an RTT of 150ms and packet size of 1500 bytes, the window size can grow to 30,000. From Table 1, we see that this window size corresponds to a layersize of K = 15. Substituting this value in the above equation, we notice that for the 2.4Gbps link mentioned above with beta = 0.15, LTCP offers an improvement of a factor of about 8 for the achievable throughput compared to TCP. 4.2.5. RTT Fairness In [XHR04] the authors have shown that some of the recent proposals for TCP in highspeed networks that change the congestion window behavior of TCP to scale to high bandwidth might aggravate the RTT unfairness problem of TCP. Analysis conducted along the same lines as that in [XHR04] shows that the above design for LTCP could potentially alleviate the RTT unfairness problem. For two LTCP flows with RTTS RTT1 and RTT2 operating at window layer K1' and K2' after a packet drop, the throughput ratio can be shown to be K2'/K1' * Square(RTT2/RTT1) The relationship between K and RTT for an LTCP flow is - K ~ O( (1/RTT) ^ 0.3333) Thus LTCP can potentially alleviate the RTT unfairness problem of TCP. This has been verified through simulations on the ns-2 simulator. 4.2.6. Alternate Designs Bhandarkar, Jain & Reddy [Page 10] draft-bhandarkar-ltcp-01 August 2004 This document presents one possible design for LTCP and provides the relevant analysis to understand the protocol behavior with this design. This design has several desirable properties such as efficient scaling of the window in high speed networks, quick convergence to fairness in the presence of multiple flows and alleviated RTT fairness problem. However, we would like to stress at this point that this is by no means the only possible or the best possible design choice. The aim of this design was to illustrate the effectiveness of using a simple concept like layering in the context of TCP congestion control to improve efficiency without sacrificing convergence properties. The design was derived based on the basic premise of choosing a multiplicative decrease. Several alternate design options are possible. For instance by adding layers using the simple rule W_K = alpha * W_(K-1) an LTCP protocol can be designed that has very similar dynamics as TCP regarding window reduction and convergence but faster increase behavior. We solicit feedback and suggestions from the research community in our quest for the design choice that optimises the tradeoff between improving performance and implementation overhead. 4.3. Implementation Details The LTCP protocol requires simple sender-side changes to the congestion window response function of TCP. It uses two additional parameters - W_T, and beta. Default recommendation for, W_T and beta are 50 and 0.15 respectively. Additionally, variables need to be used for saving the number of layers (K) and the window corresponding to layer K (W_K). When a new connection is established, the protocol is started with K = 1, and the slowstart algorithm of standard TCP. When slowstart is exited, the number of layers K is obtained based on the current cwnd. If K = 1, LTCP behaves in all respects similar to TCP. Otherwise (congestion window exceeds W_T), the following changes are made to the TCP congestion response function if (newack) { cwnd = K/cwnd if (window() > W_(K+1)) K++ } if (packet loss) { cwnd = cwnd (1 - beta) if (window() < W_K) K-- } Bhandarkar, Jain & Reddy [Page 11] draft-bhandarkar-ltcp-01 August 2004 The rest of the algorithms used in the traditional implementation of TCP - for instance the algorithms for RTT calculations, SACK processing, timer management etc, remain unchanged. The LTCP modifications work with most flavors of the TCP protocol. However, this document advocates the use of LTCP with TCP-SACK to ensure that the performance can be maintained high even under the conditions of multiple losses per round trip time. If the receiver is not SACK- capable, however, then the sender will have to use NewReno. The LTCP changes affect the behavior of TCP only in the congestion avoidance phase. The slowstart algorithm is not modified and hence LTCP maybe used with newer slowstart proposals such as limited slowstart [F04]. 5. Performance Evaluation The performance of LTCP for the above mentioned design choice was evaluated through both ns-2 [NS-2] simulations and experiments on the real network using a modified Linux kernel. These results may be found in [BJR04]. This section of the document provides a brief summary of the same. Also, the Linux implementation is currently being tested against other proposals for highspeed networks at the Stanford Linear Accelerator Center at Stanford University, and the results will be made available in the future. In both simulations and emulations, LTCP exhibited substantially improved link utilization compared to TCP. The window size required to fill the link bandwidth was reached several orders of magnitude faster than TCP for links with 1Gbps capacity. In steady state, the fluctuations about the optimal value was much smaller than that of TCP. When several LTCP flows used the same bottleneck link, the available bandwidth was shared in a fair manner with the Jain fairness index being very close to 1, as the number of flows was varied from 2 to 10. When the dynamic link conditions were varied by adding and removing LTCP flows at different times, LTCP exhibited good convergence properties. Established LTCP flows gave up a portion of the link bandwidth when standard TCP flows were introduced, to let them run free of starvation. RTT unfairness among LTCP flows was lesser than the RTT unfairness among TCP flows under similar network conditions. Several tests were conducted in the presence of non- responsive traffic and the quick response to varying traffic was verified. 6. Incremental Deployment The LTCP modifications proposed in this document lend themselves to incremental deployment. Only the TCP stack on the sender side needs to be modified. No changes are required at the receivers or the routers and no additional feed back is expected from either. The use of LTCP does not require the sender and receiver to negotiate any Bhandarkar, Jain & Reddy [Page 12] draft-bhandarkar-ltcp-01 August 2004 conditions during connection setup. Neither the receivers nor the routers need to be aware that the sender is using the LTCP congestion response function. The sender-side LTCP modifications themselves are simple and can be distributed easily as kernel patches. 7. Relationship to other work Solutions for improving the performance of TCP for high-speed networks can be classified into four main categories - a) Tuning the network stack (web100[MHR03], net100 [DMT02], Dynamic Right Sizing [WF01], Enable Tuning [TGLSE01] etc) b) Opening parallel TCP connections between the end hosts (XFTP [OAK96], GridFTP [LGTABBT01], storage resource broker [BMRW98], Parallel Sockets Library [SBG00], MulTCP [CO98] etc) c) Modifications to the TCP congestion control (HSTCP [F03], FAST [JWL04], Scalable TCP [K03], Bic-TCP [XHR04], H- TCP [SLFK03] etc) d) Modifications to the network infrastructure or use of non-TCP transport protocol (XCP [KHR02], Tsunami [Tsunami], RBUDP [HLYD02], SABUL [SGMPZ] etc). The LTCP solution falls in the third category and deals with modifications to the TCP congestion control. It tries to emulate parallel TCP connections like MulTCP (mentioned in the second category above), with the key difference that the number of virtual flows is not fixed. Instead, layering concept similar to that in [MJV96,VRC98] is used for increasing/decreasing the number of layers dynamically to find the optimal number of virtual flows required to keep the bottleneck link full, while at the same time maintaining a notion of fairness. 8. Security Considerations This proposal makes no changes to the underlying security of TCP. 9. Conclusions In this document we have proposed LTCP, a layering technique for the congestion control mechanism of TCP to make it more scalable in highspeed networks. We have presented the general framework for LTCP and explored the proposal though one possible design choice, its analysis and experimental results. We believe that LTCP provides a simple solution for improving the the performance of TCP in highspeed networks without modifying the TCP semantics significantly, and with minimal implementation overhead. We welcome additional analysis, simulations, experimentation or feedback regarding regarding this proposal. We are bringing this proposal to the IETF to be considered as an Experimental RFC. Bhandarkar, Jain & Reddy [Page 13] draft-bhandarkar-ltcp-01 August 2004 11. References [BJR04] Sumitha Bhandarkar, Saurabh Jain and A. L. Narasimha Reddy, ``LTCP: A layering technique for improving the performance of TCP in high speed networks'', Technical Report. http://ee.tamu.edu/~reddy/papers/jogc2003.pdf [BMRW98] C. Baru, R. Moore, A. Rajasekar, and M. Wan, "The SDSC storage resource broker", In Proc. CASCON'98 Conference, Dec 1998. [CO98] 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. [DMT02] Tom Dunigan, Matt Mathis and Brian Tierney, "A TCP Tuning Daemon", SuperComputing (SC) November, 2002. [F00]Sally Floyd, "Congestion Control Principles", RFC 2914, September 2000 [F03] Sally Floyd, "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003. [F04] Sally Floyd, "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, January 2004. [HLYD02] Eric He, Jason Leigh, Oliver Yu and Thomas A. DeFanti, "Reliable Blast UDP : Predictable High Performance Bulk Data Transfer", Proceedings of IEEE Cluster Computing, September 2002. [JBB92] V. Jacobson, R. Braden and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [JWL04] Cheng Jin, David X. Wei and Steven H. Low, "FAST TCP: motivation, architecture, algorithms, performance", IEEE Infocom, March 2004. [K03] Tom Kelly, "Scalable TCP: Improving Performance in HighSpeed Wide Area Networks", ACM Computer Communications Review, April 2003. [KHR02] Dina Katabi, Mark Handley, and Chalrie Rohrs, "Congestion Control for High Bandwidth-Delay Product Networks", Proceedings of ACM SIGCOMM 2002, August 2002. [LGTABBT01] J. Lee, D. Gunter, B. Tierney, B, Allcock, J. Bester, J. Bresnahan and S. Tuecke, "Applied Techniques for High Bandwidth Data Transfers Across Wide Area Networks", Proceedings of International Conference on Computing in High Energy and Nuclear Physics, September Bhandarkar, Jain & Reddy [Page 14] draft-bhandarkar-ltcp-01 August 2004 2001. [MHR03] M. Mathis, J Heffner and R Reddy, "Web100: Extended TCP Instrumentation for Research, Education and Diagnosis", ACM Computer Communications Review, Vol 33, Num 3, July 2003. [MJV96] S. McCanne, V. Jacobson, and M. Vetterli, "Receiver-driven layered multicast", Proceedings of ACM SIGCOMM '96, August 1996. [NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/ [OAK96] Shawn Ostermann, MArk Allman, and Hans Kruse, "An Application-Level solution to TCP's Satellite Inefficiencies", Workshop on Satellite-based Information Services (WOSBIS), November, 1996. [PFTK98] J.Padhye, V.Firoiu, D.Towsley, and J.Kurose, "Modeling TCP throughput: A simple Model and its empirical validation", ACM SIGCOMM '98, Oct. 1998. [SBG00] H. Sivakumar, S. Bailey and R. Grossman, "PSockets: The Case for Application-level Network Striping for Data Intensive Applications using High Speed Wide Area Networks", Proceedings of Super Computing, November 2000. [SGMPZ] H. Sivakumar, R. Grossman, M. Mazzucco, Y. Pan, and Q. Zhang, ``Simple Available Bandwidth Utilization Library for High-Speed Wide Area Networks'', submitted for publication. [SLFK03] R. N. Shorten, D. J. Leith, J. Foy, and R. Kilduff, "Analysis and design of congestion control in synchronized communication networks", June 2003, submitted for publication. [TGLSE01] Brian L. Tierney, Dan Gunter, Jason Lee, Martin Stoufer and Joseph B. Evans, "Enabling Network-Aware Applications", 10th IEEE International Symposium on High Performance Distributed Computing (HPDC), August 2001. [Tsunami] README file of tsunami-2002-12-02 release. http://www.indiana.edu/~anml/anmlresearch.html [VRC98] L. Vicisano, L. Rizzo, and J. Crowcroft, "TCP-like congestion control for layered multicast data transfer", Proceedings of IEEE Infocom '98, March 1998. [WF01] Eric Weigle and Wu-chun Feng, "Dynamic Right-Sizing: a Simulation Study", Proceedings of IEEE International Conference on Computer Communications and Networks (ICCCN), October 2001. Bhandarkar, Jain & Reddy [Page 15] draft-bhandarkar-ltcp-01 August 2004 [XHR04] Lisong Xu, Khaled Harfoush, and Injong Rhee, "Binary Increase Congestion Control for Fast Long-Distance Networks", To appear in Proceedings of IEEE Infocom 2004, March 2004. 13. Author's Addresses Sumitha Bhandarkar And Saurabh Jain Dept. of Elec. Engg. 214 ZACH College Station, TX 77843-3128 Phone: (512) 468-8078 / (979) 260-2811 Email: {sumitha,saurabhj}@tamu.edu URL : http://students.cs.tamu.edu/sumitha/ http://ee.tamu.edu/~saurabhj A. L. Narasimha Reddy Associate Professor Dept. of Elec. Engg. 214 ZACH, Mailstop - 3128 College Station, TX 77843-3128 Phone : (979) 845-7598 Email : reddy@ee.tamu.edu URL : http://ee.tamu.edu/~reddy/ Bhandarkar, Jain & Reddy [Page 16]