Network Working Group M. Sridharan Internet Draft Microsoft Intended status: Experimental July 18, 2007 K. Tan Expires: January 2008 Microsoft Research D. Bansal D. Thaler Microsoft Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks draft-sridharan-tcpm-ctcp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Sridharan Expires January 18, 2008 [Page 1] Internet-Draft Compound TCP July 2007 This document proposes Compound TCP (CTCP), a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The key idea behind CTCP is to add a scalable delay-based component to the standard TCP's loss-based congestion control. The sending rate of CTCP is controlled by both loss and delay components. The delay-based component has a scalable window increasing rule that not only efficiently uses the link capacity, but on sensing queue build up, gracefully reduces the sending rate. We have implemented CTCP on Microsoft's Windows and we have done extensive testing on production links and in Windows Beta deployments. We also engaged with Stanford Linear Accelerator Center to evaluate the properties of CTCP. The results so far are very encouraging. This document describes the Compound TCP algorithm in detail, and solicits experimentation and feedback from the wider community. In this document, we collectively refer to any TCP congestion control algorithm that employs a linear increase function for congestion control, including TCP Reno and all its variants as Standard TCP. Sridharan Expires January 18, 2008 [Page 2] Internet-Draft Compound TCP July 2007 Table of Contents 1. Introduction.............................................. 3 2. Design Goals.............................................. 5 3. Compound TCP Control Law.................................. 5 4. Compound TCP Response Function............................ 8 5. Automatic Selection of Gamma.............................. 9 6. Implementation Issues ................................... 12 7. Deployment Issues........................................ 13 8. Security Considerations.................................. 13 9. IANA Considerations...................................... 13 10. Conclusions............................................. 14 11. Acknowledgments......................................... 14 12. References ............................................. 15 12.1. Normative References.............................. 15 12.2. Informative References ........................... 15 Author's Addresses.......................................... 16 Intellectual Property Statement ............................ 17 Disclaimer of Validity...................................... 17 1. Introduction This document proposes Compound TCP, a modification to TCP's congestion control mechanism for fast, long-distance networks. The standard TCP congestion avoidance algorithm employs an additive increase and multiplicative decrease (AIMD) scheme, which employs a conservative linear growth function for increasing the congestion window and multiplicative decrease function on encountering a loss. For a high- speed and long delay network, it will take standard TCP an unreasonably long time to recover the sending rate after a single loss event [RFC2581, RFC3649]. Moreover, it is well-known now that in a steady- state environment, with a packet loss rate of p, the current standard TCP's average congestion window is inversely proportional to the square root of the packet loss rate [RFC2581,PADHYE]. Therefore, it requires an extremely small packet loss rate to sustain a large window. As an example, Floyd et al. [RFC3649], pointed out that under a 10Gbps link with 100ms delay, it will roughly take one hour for a standard TCP flow to fully utilize the link capacity, if no packet is lost or corrupted. This one hour error free transmission requires a packet loss rate around 10^-11 with 1500-byte size packets (one packet loss over 2,600,000,000 packet transmission!), which is not practical in today's networks. Sridharan Expires January 18, 2008 [Page 3] Internet-Draft Compound TCP July 2007 There are several proposals to address this fundamental limitation of TCP. One straightforward way to overcome this limitation is to modify TCP control's increase/decrease rule in its congestion avoidance stage. More specifically, in the absence of packet loss, the sender increases congestion window more quickly and decreases it more gently upon a packet loss. In a mixed network environment, the aggressive behavior of such approaches may severely degrade the performance of regular TCP flows whenever the network path is already highly utilized. When an aggressive high-speed variant flow traverses the bottleneck link with other standard TCP flows, it may increase its own share of bandwidth by reducing the throughput of other competing TCP flows. As a result the aggressive variants will cause much more self-induced packet losses on bottleneck links, and push back the throughput of the regular TCP flows. Then there is the class of high-speed protocols which use variances in RTT as a congestion indicator (e.g., [AFRICA,FAST]). The delay-based approaches are more-or-less derived from the seminal work of TCP-Vegas [VEGAS]. An increase in RTT is considered an early indicator of congestion, and the sending rate is cut in half to avoid buffer overflow. The problem in this approach comes when delay-based and loss- based flows share the same bottleneck link. While the delay-based flows respond to increases in RTT by cutting its sending rate, the loss-based flows continue to increase their sending rate. As a result a delay- based flow obtains far less bandwidth than its fair share. This weakness is hard to remedy for purely delay based approaches. The design of Compound TCP is to satisfy to efficiency requirement and TCP friendliness requirement simultaneously. The key idea is that if the link is under-utilized, the high-speed protocol should be aggressive and increase the sending rate quickly. However, once the link is fully utilized, being aggressive will not only adversely affect standard TCP flows but will also cause instability. As noted above, delay-based approaches already have a nice property of adjusting its aggressiveness based on the link utilization, which is observed by the end-systems as an increase in RTT. CTCP incorporates a scalable delay- based component to the standard TCP's congestion avoidance algorithm. Using the delay component as an automatic tuning knob, CTCP is scalable yet TCP friendly. Sridharan Expires January 18, 2008 [Page 4] Internet-Draft Compound TCP July 2007 2. Design Goals The design of CTCP is motivated by the following requirements: o Improve throughput by efficiently using the spare capacity in the network o Good intra-protocol fairness when competing with flows that have different RTTs o Should not impact the performance of standard TCP flows sharing the same bottleneck o No additional feedback or support required from the network CTCP can efficiently use the network resource and achieve high link utilization. The aggressiveness can be controlled by adopting a rapid increase rule in the delay-based component. We choose CTCP to have similar aggressiveness as HighSpeed TCP [RFC3649]. Our design choice is motivated by the fact that HSTCP has been tested to be aggressive enough in real world networks and is now an experimental IETF RFC. We also wanted an upper bound on the amount of unfairness to standard TCP flows. However, as shown later, CTCP is able to maintain TCP friendliness under high statistical multiplexing and also while traversing poorly buffered links. CTCP has similar or in some cases, even improved RTT fairness compared to standard TCP. As we will demonstrate later this is due to the fact that the amount of backlogged packets for a connection is independent of the RTT of the connection. Even though CTCP does not require any feedback from the network, CTCP works well in ECN capable environments. There is also no expectation on the queuing algorithm deployed in the routers. As is the case with most high-speed variants today, CTCP does not modify slow-start. We agree to the belief that ramping-up faster than slow-start without additional information from the network can be harmful. Similar to HSTCP, to ensure TCP compatibility, CTCP's scalable component uses the same response function as Standard TCP when the current congestion window is at most Low_Window. CTCP sets Low_Window to 38 MSS-sized segments, corresponding to a packet drop rate of 10^-3 for TCP. 3. Compound TCP Control Law CTCP modifies Standard TCP's loss-based control law with a scalable delay-based component. To do so, a new state variable is introduced in current TCP Control Block (TCB), namely, dwnd (Delay Window), which controls the delay-based component in CTCP. The conventional congestion window, cwnd, remains untouched, which controls the loss-based component in CTCP. Thus, the CTCP sending window now is controlled by Sridharan Expires January 18, 2008 [Page 5] Internet-Draft Compound TCP July 2007 both cwnd and dwnd. Specifically, the TCP sending window (wnd) is now calculated as follows: wnd = min(cwnd + dwnd, awnd), (1) where awnd is the advertised window from the receiver. cwnd is updated in the same way as regular TCP in the congestion avoidance phase, i.e., cwnd is increased by 1 MSS every RTT and halved when a packet loss is encountered. The update to dwnd will be explained in detail later in the section. The combined window for CTCP from (1) above allows up to (cwnd + dwnd) packets in one RTT. Therefore, the increment of cwnd on the arrival of an ACK is modified accordingly: cwnd = cwnd + 1/(cwnd+dwnd) (2) As stated above, CTCP retains the same behavior during slow start. When a connection starts up dwnd is initialized to zero while the connection is in slow start phase. Thus the delay component is effective when the connection enters congestion avoidance. The delay-based algorithm has the following properties. It uses a scalable increase rule when it infers that the network is under-utilized. It also reduces the sending rate when it sense incipient congestion. By reducing its sending rate, the delay-based component yields to competing TCP flows and ensures TCP fairness. It reacts to packet losses by reducing its sending rate, which is necessary to avoid congestion collapse. Our control law for the delay-based component is derived from TCP Vegas. A state variable, called basertt tracks the minimum round trip delay seen by a packet over the network path. When a connection is started, basertt is updated to be the minimum RTT observed during the 3-way handshake. The CTCP sender also maintains a smoothed RTT srtt, updated as specified in [RFC2988]. Then, the number of backlogged packets of the connection can be estimated using, expected (throughput) = wnd/basertt actual (throughput) = wnd/srtt diff = (expected - actual) * basertt The expected throughput gives the estimation of throughput CTCP gets if it does not overrun the network path. The actual throughput stands for the throughput CTCP really gets. Using this we can calculate the amount Sridharan Expires January 18, 2008 [Page 6] Internet-Draft Compound TCP July 2007 of data backlogged in the bottleneck queue (diff). Congestion is detected by comparing diff to a threshold gamma. If diff < gamma, the network path is assumed to be under-utilized; otherwise the network path is assumed to be congested and CTCP should gracefully reduce its window. It is to be noted that a connection should have at least gamma packets backlogged in the bottleneck queue to be able to detect incipient congestion. This motivates the need for gamma to be small since the implication is that even when the bottleneck buffer size is small, CTCP will react early enough to ensure TCP fairness. On the other hand if gamma is too small compared to the queue size, CTCP will falsely detect congestion and will adversely affect the throughput. Choosing the appropriate value for gamma could be a problem because this parameter depends on both network configuration and the number of concurrent flows, which are generally unknown to the end-systems. We present an effective way to automatically estimate gamma later in later sections. The increase law of the delay-based component should make CTCP more scalable in high-speed and long delay pipes. We choose a binomial function to increase the delay window [BAINF01]. More specifically, when no congestion is detected, CTCP window increases using the following function dwnd(t+1) = dwnd(t) + alpha*dwnd(t)^k (3) When a packet loss occurs, the delay window is multiplicatively decreased, dwnd(t+1) = dwnd(t)*(1-beta) (4) where alpha, beta and k are tunable to obtain the desirable scalability, smoothness and responsiveness. We assume that a loss is detected by three duplicate ACKs. As explained in the next section we have modeled the response function for CTCP to have comparable scalability to HighSpeed TCP. Since there is already a loss-based component in CTCP, the delay-based component needs to be designed to only fill the gap, and the overall CTCP should follows the behavior defined in (3) and (4). We now summarize the control law for CTCP's delay component as follows; Sridharan Expires January 18, 2008 [Page 7] Internet-Draft Compound TCP July 2007 dwnd(t+1) = dwnd(t) + alpha*dwnd(t)^k - 1, if diff < gamma (5) dwnd(t) - eta*diff, if diff >= gamma (6) dwnd(t)(1-beta) - cwnd/2, on packet loss (7) where (5) shows that in the increase phase, dwnd only needs to increase by (alpha*dwnd(t)^k - 1) packets, since the loss-based component cwnd will also increase by 1 packet. When a packet loss occurs, dwnd is set to the difference between the desired reduced window size and that can be provided by cwnd. The rule in equation (6) is very important to preserve good RTT and TCP fairness. Eta defines how rapidly the delay component should reduce its window when congestion is detected. Note that dwnd is never negative, so the CTCP window is lower bounded by its loss based component, which is same as Standard TCP. If a retransmission timeout occurs, dwnd should be reset to zero and the delay-based component is disabled. It is because that after a timeout, the TCP sender enters slow-start phase. After the CTCP sender exits the slow-start recovery state and enters congestion avoidance, dwnd control kicks in again. 4. Compound TCP Response Function The TCP response function provides a relationship between TCP's average congestion window w in MSS-sized segments as a function of the steady- state packet drop rate p. To specify a modified response function for CTCP, we use the analytical model in [CTCPI06] to derive a relationship between w and p. Based on this model, the response function for CTCP provides the following relationship between w and p, w ~.1/(p^(1/2-k)) (8) As explained earlier we modeled the response function for CTCP to have comparable scalability to HighSpeed TCP. The response function for HighSpeed TCP is w ~.1/p^0.835 (9) Comparing (8) and (9) we get k to be around 0.8. Since it's difficult to implement an arbitrary power we choose k = 0.75 which can be implemented using a fast integer algorithm for square root. Based on extensive experimentation, we choose alpha = 1/8 and beta = 1/2. Substituting the above values for alpha, beta and k in (8) we get the Sridharan Expires January 18, 2008 [Page 8] Internet-Draft Compound TCP July 2007 following response function for CTCP, w = 0.255/p^0.8 (10) The response function for CTCP is compared with HSTCP and is illustrated in Table 1 below. CTCP HSTCP Packet Drop Rate P Congestion Window W Congestion Window W ------------------ ------------------- ------------------- 10^-3 64 38 10^-4 404 263 10^-5 2552 1795 10^-6 16107 12279 10^-7 101630 83981 10^-8 641245 574356 10^-9 4045987 3928088 10^-10 25528453 26864653 Table 1: TCP Response function for CTCP & HSTCP The values in Table 1 illustrate that our choice of parameters makes CTCP slightly more aggressive than HSTCP in moderate and low packet loss rates but approaches HSTCP for larger windows. The reason we choose to do this is because unlike HighSpeed TCP, CTCP's delay control is capable of scaling back on detecting incipient congestion. As a result we expect CTCP to be more TCP friendly than HighSpeed TCP. We show that this is in fact the case even under low buffering conditions in the presence of high statistical multiplexing. The fairness considerations and choice of gamma are detailed in later sections. 5. Automatic Selection of Gamma To effectively detect early congestions, CTCP requires estimating the backlogged packets at bottleneck queue and compares this estimate to a pre-defined threshold gamma. However, setting this threshold gamma is particular difficult for CTCP (and to many other similar delay-based approaches), because gamma largely depends on the network configuration and the number of concurrent flows that compete for the same bottleneck link, which are, unfortunately, unknown to end-systems. Based on experimentation over varying conditions we selected gamma to be 30 packets. This value provided a pretty good tradeoff between TCP fairness and throughput. However a fixed gamma can still result in poor TCP friendliness over under-buffered network links. One naive solution Sridharan Expires January 18, 2008 [Page 9] Internet-Draft Compound TCP July 2007 is to choose a very small value for gamma, however this can falsely detect congestion and adversely affect throughput. To address this problem we use a method called tuning-by-emulation to dynamically adjust gamma. The basic idea of our proposal is to estimate the backlogged packets of a Standard TCP flow along the same path by emulating the behavior of a Standard TCP flow in runtime. Based on this, gamma is set so as to ensure good TCP-friendliness. CTCP can then automatically adapt to different network configurations (i.e., buffer provisioning) and also concurrent competing flows. Our analytical model on CTCP shows that gamma should at least be less than B/m+l to ensure the effectiveness of incipient congestion detection, where m and l present the flow number of concurrent Standard TCP flows and CTCP flows that are competing for the same bottleneck link [CTCPI06,CTCPP06,CTCPT]. Generally, both B and (m+l) are unknown to end-systems. It is very difficult to estimate these values from end- systems in real-time, especially the number of flows, which can vary significantly over time. Fortunately there is a way to directly estimate the ratio B/m+l, even though the individual variables B or (m+l) are hard to estimate. Let's first assume there are (m+l) regular TCP flows in the network. These (m+l) flows should be able to fairly share the bottleneck capacity in steady state. Therefore, they should also get roughly equal share of the buffers at the bottleneck, which should equal to B/m+l. For such a Standard TCP flow, although it does not know either B or (m+l), it can still infer B/m+l easily by estimating its backlogged packets, which is a rather mature technique widely used in many delay-based protocols. This brings us to the core idea of CTCP's algorithm; CTCP lets the sender emulate the congestion window of a Standard TCP flow. Using this emulated window, we can estimate the buffer occupancy (Q) for a Standard TCP flow. Q can be regarded as a conservative estimate of B/m+l assuming that the high speed flow is more aggressive than Standard TCP. By choosing gamma <= Q, we can ensure TCP fairness. The implementation is actually trivial. This is because CTCP already emulates Standard TCP as the loss-based component. We can simply estimate the buffer occupancy of a competing Standard TCP flow from state which CTCP already maintains. We choose an initial gamma = 30 and Q is calculated as follows, expected_reno (throughput) = cwnd/basertt actual_reno (throughput) = cwnd/srtt diff_reno = (expected - actual) * basertt Sridharan Expires January 18, 2008 [Page 10] Internet-Draft Compound TCP July 2007 The difference between diff_reno and diff is simply that diff_reno is computed only using the loss based component cwnd. Since Standard TCP reaches its maximum buffer occupancy just before a loss, CTCP uses the diff_reno value computed in the earlier round to calculate the gamma for the next round. Whenever a loss happens, gamma is chosen to be less than diff_reno and the sample values of gamma are updated using a standard exponentially weighted moving average. The pseudocode to calculate gamma is shown below. Here a round tracks every window worth of data. We will provide more details on how to maintain a round in Section 7. Initialization: diff_reno = invalid; Gamma = 30; End-of-Round: expected_reno = cwnd / baseRTT; actual_reno = cwnd / RTT; diff_reno = (Expected_reno-Actual_reno)*baseRTT; On-Packet-Loss: If diff_reno is valid then g_sample = 3/4*Diff_reno; gamma = gamma*(1-lamda)+ lamda*g_sample; if (gamma < gamma_low) gamma=gamma_low; else if (gamma > gamma_high) gamma=gamma_high; fi diff_reno = invalid; fi The recommended values for gamma_low and gamma_high are 5 and 30 respectively. diff_reno is set to invalid to prevent using stale diff_reno data when there are consecutive losses between which no samples were taken. Sridharan Expires January 18, 2008 [Page 11] Internet-Draft Compound TCP July 2007 6. Implementation Issues The first challenge is to design a mechanism that can precisely track the changes in round trip time with minimal overhead, and can scale well to support many concurrent TCP connections. Naively taking RTT sample for every packet will obviously be an over-kill for both CPU and system memory, especially for high-speed and long distance networks where the congestion window can be very large. Therefore, CTCP needs to limit the number of samples taken, but without compromising on accuracy. In our implementation, we only take up to M sample per window of data. M is chosen to scale with the round trip delay and window size. In order to further improve the efficiency in memory usage, we have developed a memory allocation mechanism to dynamically allocate sample buffers from a kernel fixed-size per-processor pool. The size should be chosen as a function of the available system memory. As the window size increases, M can be updated so that the samples are uniformly distributed over the window. As M gets updated more memory blocks are allocated and linked to the existing sample buffers. If the sending rate changes either due to network conditions or due to application behavior, the sample blocks are reclaimed to the global memory pool. This dynamic buffer management ensures the scalability of our implementation, so that it can work well even in a busy server which could host tens of thousands of TCP connections simultaneously. Note that it may also require high-resolution timer to time RTT samples. The rest of the implementation is rather straightforward. We add two new state variables into the standard TCP Control Block, namely dwnd and basertt. The basertt is a value that tracks the minimum RTT sample measured seen so far and it is used as an estimation of the transmission delay of a single packet. Basertt is usually cleared if a retransmission timeout is hit. It is a good idea to re-measure the basertt incase the network conditions have changed. Following the common practice of high-speed protocols, CTCP reverts to standard TCP behavior when the window is small. Delay-based component only kicks in when cwnd is larger than some threshold, currently set to 38 packets assuming 1500 byte MTU. dwnd is updated at the end of each round. Note that no RTT sampling and dwnd update happens during the loss recovery phase. It is because the retransmission during the loss recovery phase may result in inaccurate RTT samples and can adversely affect the Sridharan Expires January 18, 2008 [Page 12] Internet-Draft Compound TCP July 2007 delay-based control. 7. Deployment Issues There are several variations of TCP proposed for high speed and long delay networks. We do not claim Compound TCP to be the best nor the most optimal algorithm. However, based on our extensive testing via simulations, experimentation including those on production links as well as beta deployments of a reasonable scale, we believe that Compound TCP satisfies the design considerations outlined before in this document. It effectively uses spare bandwidth in high speed networks, achieves good intra-protocol fairness even in the presence of differing RTTs and does not adversely impact standard TCP. Further, Compound TCP does not require any changes or any new feedback from the network and is deployable over the current Internet in an incremental fashion. It inter-operates with Standard TCP and requires support only one the send side of a TCP connection for it to be used. We also note that similar to High Speed TCP, in environments typical of much of the current Internet, Compound TCP behaves exactly like Standard TCP. This it does by ensuring that is follows standard TCP algorithm without any modification any time congestion window is less than 38 packets. Only when congestion window is greater than 38 packets, does the delay based component of Compound TCP gets invoked. Thus, for example for a connection with RTT of 100ms, end to end bandwidth must be greater than 4.8Mbps for CTCP algorithm to have any difference in its response to network conditions than a standard TCP. Further, we do not believe that the deployment of Compound TCP would block the possible deployment of alternate experimental congestion control algorithms such as Fast TCP [FAST] or CUBIC [CUBIC]. In particular, Compound TCP’s response has a fallback to loss based function that has characteristics very similar to HS-TCP or N parallel TCP connections. 8. Security Considerations This proposal makes no changes to the underlying security of the TCP protocol. 9. IANA Considerations There are no IANA considerations regarding this proposal. Sridharan Expires January 18, 2008 [Page 13] Internet-Draft Compound TCP July 2007 10. Conclusions This document proposes a novel congestion control algorithm for TCP for high speed and long delay networks. By introducing a delay based component in addition to a standard TCP based loss component, Compound TCP is able to detect and effectively use spare bandwidth that may be available on a high speed and long delay network. Further, delay based component detects onset of congestion early and gracefully reduces sending rate. The loss based component, on the other hand, ensures there is effective response to losses in network while in the absence of losses, keeps the throughput of CTCP lower bounded by TCP Reno. Thus, CTCP is not timid, nor induces more self induced packet loss than a single standard TCP flow. Thus Compound TCP is efficient in consuming available bandwidth while being friendly to standard TCP. Further, the delay component does not have any RTT bias thereby reducing the RTT bias of the Compound TCP vis-a-vis standard TCP. Compound TCP has been implemented as an optional component in Microsoft Windows Vista Operating System. It has been tested and experimented through broad Windows Vista beta deployments where it has been verified to meet its objectives without causing any adverse impact. SLAC has also evaluated Compound TCP on production links. Based on testing and evaluation done so far, we believe Compound TCP is safe to deploy on the current Internet. We welcome additional analysis, testing and evaluation of Compound TCP by Internet community at large and continue to do additional testing ourselves. 11. Acknowledgments The authors would like to thank Jingmin Song for all his efforts in evaluating the algorithm on the test beds. We are thankful to Yee-ting Lee and Les Cottrell for testing and evaluation of Compound TCP on Internet2 links [SLAC]. We would like to thank Sanjay Kaniyar for his insightful comments and for driving this project in Microsoft. We are also thankful to the Microsft.com data center staff who helped us evaluate Compound TCP on their production links. In addition, several folks from the Internet research community who attended the High-Speed TCP Summit at Microsoft [MSWRK] have provided valuable feedback on Compound TCP. Finally, we are thankful to the Windows Vista program beta participants who helped us test and evaluate CTCP. Sridharan Expires January 18, 2008 [Page 14] Internet-Draft Compound TCP July 2007 12. References 12.1. Normative References [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. 12.2. Informative References [AFRICA] R. King, R. Baraniuk and R. riedi, "TCP-Africa: An Adaptive and Fair Rapid Increase Rule for Scalable TCP", In Proc. INFOCOM 2005. [BAINF01] D. Bansal and H. Balakrishnan, "Binomial Congestion Control Algorithms", Proc INFOCOM 2001. [CTCPI06] K. Tan, Jingmin Song, Qian Zhang, Murari Sridharan, "A Compound TCP Approach for High-speed and Long Distance Networks", in IEEE Infocom, April 2006, Barcelona, Spain. [CTCPP06] K. Tan, J. Song, Q. Zhang, and M. Sridharan, "Compound TCP: A Scalable and TCP-friendly Congestion Control for High-speed Networks", in 4th International workshop on Protocols for Fast Long-Distance Networks (PFLDNet), 2006, Nara, Japan. [CTCPT] K. Tan, J. Song, M. Sridharan, and C.Y. Ho, "CTCP: Improving TCP-Friendliness Over Low-Buffered Network Links", Microsoft Technical Report. [CUBIC] I. Rhee, L. Xu and S. Ha, "CUBIC for fast long distance networks", Internet Draft, Expires Aug 31, 2007, draft- rhee-tcp-cubic-00.txt [FAST] C. Jin, D. Wei, S. Low, "FAST TCP: Motivation, Architecture, Algorithms, Performance", in IEEE Infocom 2004. [MSWRK] Microsoft High-Speed TCP Summit, http://research.microsoft.com/events/TCPSummit/ [PADHYE] J. Padhya, V. Firoiu, D. Towsley and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", in Proc. ACM SIGCOMM 1998. Sridharan Expires January 18, 2008 [Page 15] Internet-Draft Compound TCP July 2007 [RFC2988] V. Paxson and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3649] S. Floyd, "HighSpeed TCP for Large Congestion Windows", RFC 3649, Dec 2003. [SLAC] Yee-Ting Li, "Evaluation of TCP Congestion Control Algorithms on the Windows Vista Platform", SLAC-TN-06- 005, http://www.slac.stanford.edu/pubs/slactns/tn04/slac-tn- 06-005.pdf [VEGAS] L. Brakmo, S. O'Malley, and L. Peterson, "TCP Vegas: New techniques for congestion detection and avoidance", in Proc. ACM SIGCOMM, 1994. Authors' Addresses Murari Sridharan Microsoft Corporation 1 Microsoft Way, Redmond 98052 Email: muraris@microsoft.com Kun Tan Microsoft Research 5/F, Beijing Sigma Center No.49, Zhichun Road, Hai Dian District Beijing China 100080 Email: kuntan@microsoft.com Deepak Bansal Microsoft Corporation 1 Microsoft Way, Redmond 98052 Email: dbansal@microsoft.com Dave Thaler Microsoft Corporation 1 Microsoft Way, Redmond 98052 Email: dthaler@microsoft.com Sridharan Expires January 18, 2008 [Page 16] Internet-Draft Compound TCP July 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sridharan Expires January 18, 2008 [Page 17]