Sync-TCP

¡¡

People

Faculty Student
Dr. A.L. Ananda Xiuchao Wu
Dr. Mun Choon Chan Chetan Ganjihal
¡¡ Dang Thanh Son

Description

Considering that access bandwidth continues to increase (Singapore¡¯s IN2015 program includes the provision to provide 1Gbps to residential users by 2015), and that the Internet¡¯s core networks are and likely to remain lightly-loaded in the future, there will be more and more long fat network pipes with abundant residual bandwidth. However, it is well known that TCP Reno and its variants (TCP Newreno, TCP SACK, etc.) cannot work well on long fat network pipes whose bandwidth-delay product (BDP) is large. Due to their additive increase and multiplicative decrease (AIMD) rules, these legacy TCP versions cannot send data fast enough to utilize the abundant available bandwidth of long fat network pipes.

Based on the above observation, many HSCC algorithms, such as Scalable TCP, Highspeed TCP, Bic-TCP, Cubic-TCP, H-TCP, Fast TCP, Compound TCP (CTCP), and TCP Illinois, have been proposed in recent years. Obviously, bandwidth-greedy applications are not the only applications running in the Internet. A HSCC algorithm has to be friendly to cross traffic applications, especially those using legacy TCP Reno and the interactive ones, such as web surfing and media-streaming that are more profitable to network providers. More specifically, existence of HSCC-based bandwidth-greedy applications should not significantly increase packet loss rate, queue delay, and jitter suffered by these cross traffic applications.

With the network performance model shown in Fig.1, we can explain the two concerns in a clearer way. With the standard TCP congestion control, in spite of the availability of high bandwidth, end-users cannot send out data fast enough and the generated load will be too low. Hence, the operational point of the future high speed Internet is at the left side of the knee point and its abundant bandwidth will be under-utilized. That means billions of dollars invested on network infrastructure will be wasted. However, with high speed TCP variants, an end host may consume too much bandwidth too rapidly. Several selfish users, running bandwidth-greedy and low profit margin applications, can send out enough data to drive network to operate around the cliff, in which network delay and drop rate will be high. It means that, when coexisting with bandwidth-greedy applications that adopt high speed TCP variants, QoS (quality of service) experienced by the delay-sensitive and high profit margin applications may be worse even though billions of dollars have been invested on network infrastructure.


<Fig.1> Network Performance Model as a Function of Load (By Raj Jain)

In this project, Synchronized TCP (Sync-TCP) is proposed for speeding up bandwidth-greedy and elastic applications to efficiently utilize the bandwidth of future high speed Internet while not hurting the cross traffics. The key insight of Sync-TCP is that if competing flows are able to detect the same congestion signal through queue delay, these flows can coordinate their congestion control behaviors. Hence, Sync-TCP is carefully designed to convey highly synchronized congestion signals to competing flows. An adaptive queue delay based congestion window decrease rule, and a RTT-independent congestion window increase rule are adopted for driving the network to operate around the knee and to distribute the residual bandwidth fairly among competing flows even when the number of competing flows vary and their round trip propagation delays differ significantly. Simulation results show that Sync-TCP achieves its design goals and performs better than existing HSCC approaches including Fast TCP, CTCP and Cubic TCP, especially in the metrics of friendliness.

Tech. Report

Release

Contact: Xiuchao Wu (wuxiucha AT comp.nus.edu.sg)