Internet Engineering Task Force Sumitha Bhandarkar INTERNET DRAFT Saurabh Jain draft-bhandarkar-ltcp-00.txt A. L. Narasimha Reddy Expires : August 2004 Texas A&M University February 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 LTCP, a simple layering technique for the congestion window response of TCP to make it more scalable in highspeed networks. LTCP uses two dimensional congestion control: at the macroscopic level, the layers are added/dropped based on dynamic network conditions and at the microscopic level, the congestion window behavior is defined for operating at any given layer. This document provides the architecture, one possible design choice, analysis and some preliminary results based on ns-2 simulations. The results indicate that LTCP has promising convergence properties, is about an order of magnitude faster than TCP in utilizing high bandwidth links and can be made to operate with smaller window fluctuations than normal TCP. LTCP employs few parameters and is easy to understand and implement. As such, this document is an effort to solicit more experimentation and feedback from the broader networking community. 1. Introduction Bhandarkar, Jain & Reddy Expires August 2004 [Page 1] draft-bhandarkar-ltcp-00 February 2004 Over the past few decades the traffic on the Internet has increased by several orders of magnitude. However, the Internet still remains a stable medium for communication. This stability has been attributed primarily to the wide-spread use of congestion control algorithms of TCP [F00]. The congestion control algorithms are designed such that bandwidth is shared fairly among flows with similar RTTs. Ironically, these same congestion control algorithms prevent TCP from scaling to future networks with high-bandwidth links of the order of several Gbps. The TCP congestion control algorithms use additive increase multiplicative decrease for moderating the congestion window. When there are no losses in the network, the window is increased by one for each RTT. Upon a loss of packet, the window is reduced by half. The problem arises when the available bandwidth is very high, rendering the increase very slow and the reduction too drastic, resulting in highly degraded performance. This document proposes a simple layering technique for the existing congestion response algorithms to make it scale in high-bandwidth networks. The idea of layering to probe and utilize the available bandwidth has been researched extensively in the context of video transmission on the Internet and in multicasting[MJV96,VRC98]. The contribution of this paper is to extend this idea to the congestion control algorithms in TCP so that scalability can be achieved at the cost of minimal implementation overhead. 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 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 Bhandarkar, Jain & Reddy Expires August 2004 [Page 2] draft-bhandarkar-ltcp-00 February 2004 requirements - * Better efficiency in bandwidth utillization : 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 acheiving 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 shceme should require minimal modifications to the existing TCP implementations and none to the network infrastructure. In other words, no additional feed back 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. 4. LTCP Protocol 4.1. Architecture 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, layers are added or removed based on the dynamic network conditions (b) At the microscopic level, the congestion window response function is defined when the protocol is operating at any given layer 'K'. 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 do not get into that discussion, but rather 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 Bhandarkar, Jain & Reddy Expires August 2004 [Page 3] draft-bhandarkar-ltcp-00 February 2004 44 packets (of size 1500 bytes). The window scale option is usually turned on for highspeed networks, and the threshold W_T is used mainly to ensure the fairness of LTCP to TCP flows in slow networks. So we choose a window threshold that is slightly greater than 44 packets. 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. When the congestion window of the LTCP flow grows beyond the LTCP window threshold W_T, the increase behavior is modified to behave two dimentionally - (a) At the macroscopic level, the number of layers is increased, when no congestion is observed over an extended period of time. (b) At the microscopic level, the congestion window is increased in response to each incoming ack. 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. Consequently, 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. The window response for increase for a TCP flow emulating 'K' virtual flows has been studied in MulTCP [CO98]. We take a similar approach, i.e., 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. 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 Expires August 2004 [Page 4] draft-bhandarkar-ltcp-00 February 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 Expires August 2004 [Page 5] draft-bhandarkar-ltcp-00 February 2004 the packet drop, 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 This macroscopic decrease behavior ensures convergence when the different flows sharing the network bandwidth operate at different layers. To ensure convergence when two flows are operating with the same number of layers, K1 = K2, we define the microscopic control. We follow the same reasoning, i.e., the recovery time for the larger flow after a window reduction should be more than that for the smaller flow. However, now both the flows operate at the same layer and hence the increase factor for both the flows is similar. In order to ensure convergence, the decrease behavior is made dependent on the size of the current congestion window above W_K, the window size at which the Kth layer was added. This component of the window reduction depends linearly on the current window size. Fig. 2 shows the plot of the window reduction against the current congestion window for a flow. When the packet loss occurs, if the congestion window is W_K then the window is reduced by WR_K. If the congestion window is W_(K+1), the window is reduced by WR_(K+1). When the congestion window is in the range W_K < W < W_(K+1), the window reduction linearly increases from WR_K to WR_(K+1). ^ | | WR_(K+1) |---------------------------------x | , | | , | window | , | reduction | , | | , | | , | | , | WR_K |------------------x | | | | | | | | | | -------------------------------------------> W_K W_(K+1) Congestion Window when Packet Loss Detected Fig 1: LTCP Window Reduction Vs Congestion Window Bhandarkar, Jain & Reddy Expires August 2004 [Page 6] draft-bhandarkar-ltcp-00 February 2004 This architecture 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 depolyment that it provides. 4.2. Design Choice In order to evaluate the effectiveness of the LTCP protocol, we chose a simple scheme for computing the stepsize: delta_K = alpha * delta_(K-1) Based on this choice, the LTCP constraint 1 is satisfied for all values of K >= 2, when alpha > 1.5. Since the second layer is added when the window size is equal to the LTCP window threshold W_T, we have - delta_1 = W_2 = W_T delta_2 = alpha delta_1 = alpha W_T delta_3 = alpha delta_2 = (alpha ^ 2) * W_T delta_K = alpha delta_(K-1) = (alpha ^ (K-1)) * W_T The LTCP constraint 2 is similar in form to the LTCP constraint 1, and can be maintained by simply choosing the window reduction at any layer 'K' to be a fraction of the step size delta_K. Hence, for macroscopic control of the decrease behavior this document recommends the simple policy that upon a packet loss, each flow drops one half of the layer it last added. Note that this policy leaves the drop behavior undefined for the case when K = 1 i.e., the first layer. However, for the first layer, the congestion window is less than the LTCP window threshold W_T, and hence, the congestion window is Bhandarkar, Jain & Reddy Expires August 2004 [Page 7] draft-bhandarkar-ltcp-00 February 2004 decreased multiplicatively by half,just like the standard implementation of TCP. Also, based on this choice, the total window reduction (sum of the macroscopic component and microscopic components) can be shown to be WR = delta_(K-1)/2 + (1 - 1/alpha) * (W - W_K)/2 = (1 - 1/alpha) * W/2 Thus, with this design choice, the time tested additive increase multiplicative decrease behavior of TCP is retained. At each layer K, LTCP increases the window additively by K, and when a packet drop occurs, the congestion window is reduced multiplicatively by (1 - 1/alpha) * 0.5. Also, for this design, it can be shown that the time taken by an LTCP flow (in terms of RTTs) to reach the window size W_K is given by [BJR04] - T(slowstart) + W_T * sum ((alpha ^ i)/(i +1)) where i=K' to (K-2) (Assuming that slow start is terminated when the window reaches W_K') For a 10Gbps link with an RTT of 200ms, the window size can grow upto 166,666. Table 1. shows the number of layers, the stepsize and the speedup in claiming bandwidth compared to TCP, for an LTCP flow with W_T = 50 and alpha = 1.666667 (corresponding to window reduction by a factor of 0.2), and assuming that slowstart is terminated at W_T. From the table it is clear that, an LTCP flow that evolves to K layers can claim the bandwidth almost as fast as K-virtual layers added at the beginning of the connection. Speedup in Speedup in K delta_K W_K Claiming Packet Loss Bandwidth Recovery Time 1 50.00 0.00 - - 2 83.33 50.00 1.00 1.00 3 138.89 133.33 2.00 3.20 4 231.48 272.22 2.53 5.88 5 385.80 503.70 3.11 8.70 6 643.00 889.51 3.76 11.53 7 1071.67 1532.51 4.49 14.30 8 1786.12 2604.18 5.29 17.01 9 2976.87 4390.31 6.14 19.66 10 4961.45 7367.18 7.05 22.27 11 8269.09 12328.63 8.01 24.85 12 13781.81 20597.71 8.99 27.40 13 22969.68 34379.52 10.00 29.93 14 38282.80 57349.21 11.02 32.46 Bhandarkar, Jain & Reddy Expires August 2004 [Page 8] draft-bhandarkar-ltcp-00 February 2004 15 63804.67 95632.01 12.05 34.97 16 106341.10 159436.70 13.08 37.48 17 177235.20 265777.80 14.11 39.99 Table 1: Comparison of LTCP (with W_T = 50 and alpha = 1.666667) to TCP Also, an LTCP flow with window size W_K will reduce the congestion window by delta_(K-1)/2 and drops down to the layer (K-1). It then starts to increase the congestion window at the rate of (K-1). The packet loss recovery time, then for LTCP it delta_(K-1)/(2 * (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_K/2. The last column of Table. 1 shows the speed up in packet recovery time for LTCP compared to TCP. LTCP speeds up the packet recovery time by a factor of (K - 1)/(1 - 1/alpha), for large values of K. 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 is given by [BJR04] - Sqrt(CK) BW = ------------------ (RTT * sqrt(p)) where C is a constant = (3*alpha +1)/(2*(alpha -1)) Thus, when the operating layer for an LTCP flow is K, then with alpha = 1.666667, the throughput of the LTCP flow is rougly 1.768 * sqrt (K) times that of a TCP flow. Also, the supporting loss rate with alpha = 1.666667 can be shown to be about 2.08 * K bigger than standard TCP [BJR04]. 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 alpha. Default recommendation for, W_T and alpha are 50 and 1.66667 respectively. Additionally, variables need to be used for saving the number of layers (K), window corresponding to layer K (W_K), the step size corresponding to layer K (delta_K) and the window reduction factor (reduction_factor) computed from alpha. 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 Bhandarkar, Jain & Reddy Expires August 2004 [Page 9] draft-bhandarkar-ltcp-00 February 2004 (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 + delta_K)) K++ } if (packet loss) { window reduction = reduction_factor * W cwnd = cwnd - window reduction if (window() < W_K) K-- } 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 t rip 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 hte 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. Detailed results of the ns-2 simulations may be found in [BJR04]. This section of the document provides a brief summary of the same. 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 a simulated environment with a dumbbell topology, LTCP exhibited improved link utilization compared to TCP. The window size required to fill the link bandwidth was reached about an order of magniture faster than TCP. In steady state, the fluctuations about the optimal value was much smaller than that of TCP. When several LTCP flows used the same bottle neck link, the available bandwidth was shared in a fair manner with the Jain fairness index being very close to 1, when the number of flows was varied from 2 to 10. When the dynamic link Bhandarkar, Jain & Reddy Expires August 2004 [Page 10] draft-bhandarkar-ltcp-00 February 2004 conditions were varied by adding and removing LTCP flows at different times, LTCP exhibited good convergence properties. In experiments where the link was configured to have high channel error rates, it showed that LTCP supporting loss rate, beyond which the performance started to deteriorate was about an order of magniture better than that of TCP. In slow networks, established LTCP flows converged with standard TCP flows to a fair share. In high bandwidth networks, LTCP allowed TCP to run starvation free. All experiments were conducted with link bandwidth ranging from few hundred Mbps to 2.4 Gbps. Simulations for link size more than 2.4 Gbps were not conducted due to extremely large amount of time required to run the simulations. TCP-SACK was used as the stock TCP version for comparisons. 6. Incremental Deployment The LTCP modifications proposed in this document lend themselves to incremental deployment. Only the TCP protocol 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 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 transoport 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 virutal flows required to Bhandarkar, Jain & Reddy Expires August 2004 [Page 11] draft-bhandarkar-ltcp-00 February 2004 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 techique for the congestion control mechanism of TCP to make it more scalable in highspeed networks. We have presented the general architecture for LTCP and explored the proposal though one possible design choice, its analysis and simulations. We are currently in the process of evaluating it through experiments on the Linux platform. 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. 11. References [BJR04] Sumitha Bhandarkar, Saurabh Jain and A. L. Narasimha Reddy, ``LTCP: A layering technique for improvint 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 Bhandarkar, Jain & Reddy Expires August 2004 [Page 12] draft-bhandarkar-ltcp-00 February 2004 Windows", RFC ????, 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 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. Bhandarkar, Jain & Reddy Expires August 2004 [Page 13] draft-bhandarkar-ltcp-00 February 2004 [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. [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 Expires August 2004 [Page 14]