=================================================== From muhammed@ece.rice.edu Tue Jan 27 21:11:40 2004 =================================================== The authors propose a new TCP (FAST) which is in many ways better than TCP Reno and other transmission control protocols. Their design proceeds from defining flow level characteristics they desire in their TCP and defining packet level operations that are aimed at achieving them. Their design goals are: 1. Fast response to network dynamics (flows entering and leaving) 2. Maintaining high throughput even under occasional packet drops 3. Stability and fairness TCP Reno suffers from slow convergence time under highly dynamic network conditions because the linear increase phase is not fast enough. It is over conservative by cutting its congestion window size (which determines the throughput directly) by half on a packet drop. This Additive Increase Multiplicative Decrease (AIMD) policy requires very small packet loss probability to maintain large congestion windows, and hence large throughput, in high delay-bandwidth product links. Further the per-packet reaction to the binary signal, loss/no-loss, leads to large oscillations of the throughput for TCP-Reno. FAST TCP overcomes the said drawbacks of TCP Reno by reacting to the delay in the link, rather than packet loss. To achieve fast reaction time, the congestion window adjustment is made based on a measure of distance between current and desired operating points. This also makes the protocol converge exponentially fast towards equilibrium. The protocol also exhibits weighted proportional fairness. Their Linux prototype implementation shows the best performance among 3 other TCP designs (Reno is one of them). The measures of performance they evaluate are throughput, intra-protocol fairness, stability and responsiveness. FAST shows the best performance on all the four measures. =================================================== From twngan@cs.rice.edu Wed Jan 28 11:46:27 2004 =================================================== This paper describes FAST TCP, a new TCP algorithm aimed at high-speed long-latency networks. The reason for the need is that TCP Reno, the commonly used TCP algorithm, is known to eventually become a bottleneck as the bandwidth-delay product continues to grow. The problems behind include that AIMD is being too conservative, oscillation is unavoidable because of the use of a binary congestion signal, maintaining congestion windows requires small loss probability, and flow dynamics are unstable. This paper suggests that, instead of relying on loss as feedbacks, delay-based congestion control is the right direction, since it provides multi-bit information instead of binary. Thus, when it is close to the equilibrium, the window adjustments are small. Overall, the paper is very unclear and confusing. There is only one core, important idea, yet the paper made it confusing and mixed different things in the presentation. Many formulae are given without enough explanation or pointers, which did not help in understanding. That being said, the suggested change to TCP seems to be effective and is worth further investigation. =================================================== From dushu@cs.rice.edu Wed Jan 28 18:07:14 2004 =================================================== The authors proposed a new congestion control protocol after analyzed some main problems that the current TCP Reno is facing in the networks with high bandwidth and large latencies. The authors generalized the theoretical models of the TCP in the flow level and in the packet level and distinguished their own design from some other previous proposed TCP enhancement versions and the classic TCP Reno. This Fast TCP, proposed by the authors, are based on the observation that the queuing delay, which happens much more frequent in large capacity network than the a packet loss, will give the sender a larger sample set and thereafter a more precise view of the current equilibrium state. The authors then did some experiments to validate their design. I think the basic motivation of their design is neat and well worth further study. But I am not sure how much this delay-based strategy TCP will be too much different than the loss-based strategy when we go down to the packet level implementation, because even in the loss-based guided TCP version, the queuing delay was not just a ignored factor. Actually, in all of these TCP versions, queuing delay is somewhat already considered when estimating the RTT, which is further changed to a threshold to judge the packet loss. Since the packet loss events is really highly interleaved the queuing delay, I guess the loss-based won't be that different from the delay-based versions when we go down to the packet level to do parameter tweaking. Another conservative thought is that all of these new proposed more aggressive TCPs should consider the the fairness factor when they and the other old conservative TCPs coexist in the network. The authors only showed the fairness in the system of Fast TCP alone. Another question for the author/defensive team is that in the experiment, how come the HSTCP/STCP looks bad even if there is only one flow? Anyway, I think this an interesting paper as the authors provide us a new angle to look at our old friend - designing a better TCP which fits the uprising network technology. =================================================== From takhoa@rice.edu Wed Jan 28 21:08:55 2004 =================================================== The idea of using delay-based congestion control instead of loss-based congestion control makes sense. In large networks as the Internet today, occasional loss of packets would cause the congestion window to fluctuate a lot whereas a delayed-based congestion control algorithm will smoothen the adjustment of the congestion window much better. The paper is well-formulated, starting with problems for existing algorithms, motivate their approach, and eventually describing their approach. It would be nice if the paper can include discussion on how FAST TCP interact with existing TCP implementations, especially TCP Reno. Since we all know it's not possible to replace the TCP stack on every host at the same time, if FAST TCP were to be deployed, we need to understand the effects of FAST TCP in a heterogeneous environment. Since FAST TCP does not fluctuate the congestion window as much, will it be starved by TCP Reno while ramping up? Or will it take all the bandwidth, preventing other hosts running Reno from increasing their contention window? My guess is the latter. =================================================== From gulati@cs.rice.edu Sun Feb 1 15:24:29 2004 =================================================== FAST TCP: Motivation, Architecture,Algorithm, Performance This paper presents a case for delay based approaches for congestion avoidance in transmission control protocols and presents FAST TCP as a delay based protocol. Loss based approaches are good enough for small networks with low bandwidth, but as the Bandwidth*Delay product increases, they perform very poorly in terms of throughput, stability and convergence to equilibrium. It states the following problems with currently used approaches like TCP Reno: 1. Additive Increase is too slow and Multiplicative Decrease is too drastic. 2. Large window size requires extremely small equilibrium loss probability. 3. Oscillations at packet level occur due to the use of binary signal. 4. Flow level dynamics is unstable leading to severe oscillations. All the variants of TCP follow an equation, that shows the rate of change of window size in terms of probability of loss, current window size and round trip time. The authors state that none of the TCP variants, such as TCP RENO, HSTCP, STCP solve the equation efficiently and even a multi-bit information about the packet loss won't help because all of these have inherent design flaws. Equation: rate of change of w(t) = k(t)*(1 - p(t)/u(t)) where k(t) is gain function, p(t) is loss probability and u(t) is marginal utility function. They state their flow level design goals and realize them by doing the implementation at packet level. The proposed solution to above equation measures loss probability as queuing delay 'q(t)'. It increases the window size exponentially till 'q(t) = 0' and they do slow increase till 'q(t)' gets to a certain values after which they start decreasing the window. Unlike TCP RENO , FAST TCP starts to react to congestion earlier than any packet loss, and hence packet losses are rare unless the network is severely congested or under provisioned. Also FAST TCP converges to equilibrium faster and stay closer to it rather than oscillating too fast. Finally they compare FAST TCP to other variants like TCP RENO, HSTCP, STCP based on metrics like throughput, intra-protocol fairness, stability and responsiveness. The results show that FAST TCP performs better than other in all metrics. -Ajay