My Research  

Quick Links to research projects:

My research is conducted under the direction of Professor R. Srikant and Professor Tamer Başar, and has been on the congestion control and performance analysis of the communication networks. The general goal of my research is to design new congestion control algorithms at either router side or sender side, and build models to analyze these algorithms and the whole congestion control system. My work on 4CP was performed in Microsoft Research at Cambridge, collaborating with Milan Vojnovic in MSRC.

RESEARCH INTERESTS

My research interests include communication, control and networks. Specific topics are: 

• Internet Congestion control

• Control theory and the stability analysis of congestion control systems

• Optimization theory and game theory, network resource allocation and network pricing

• Congestion control, admission control, and contention control in wireless networks

• Scheduling and cross-layer design in wireless networks.

• Peer-to-Peer networks

• MAC layer, 802.11, Ad hoc networks

• Wireless communication and information theory

RESEARCH PROJECTS (2001-Current)

TCP-Illinois:

The current standard TCP, with versions being Reno, NewReno, or SACK, chooses an AIMD congestion control mechanism. AIMD increases the window size by one per round trip time (RTT) if there is no congestion (no packet loss), and decreases the window size to half of its original value if there is congestion (packet loss). AIMD works successfully in low speed networks, but not efficient in high speed networks, since its window increase speed is too slow and it takes too long time to recover after a single packet loss.

Many new TCP variants have been introduced to replace the current one in high speed networks. Although each shows some advantages, none satisfies all the requirements and are suitable for general deployment. We have designed a new high speed TCP variant which satisfies all the requirements, outperforms the current TCP significantly, outperforms many other high speed TCP variants, and is suitable for general deployment. TCP-Illinois uses packet loss information to determine whether the window size should be increased or decreased, and uses queueing delay information to determine the amount of increment or decrement. TCP-Illinois achieves high throughput, allocates the network resource fairly, and is compatible with standard TCP, and provides incentives for TCP users to switch to TCP-Illinois. For more details, please check the TCP-Illinois site.

Compatible-Vegas:

TCP-Vegas is a TCP variant which uses delay as congestion signal. It can achieve almost full utilization of the network bandwidth and allocates the bandwidth more fairly than the standard TCP does. However, it is not compatible with TCP and it provides no incentive for TCP users to switch: when TCP and TCP-Vegas coexists, TCP-Vegas users get very small bandwidth.

We have modified TCP-Vegas to make it incentive compatible with TCP, and we call the new modification Compatible-Vegas: when there are only Compatible-Vegas users, it behaves similarly as TCP-Vegas. When there are standard TCP users coexisting, TCP-Vegas users get a slightly better throughput, and thus is compatible with TCP and provides incentives for TCP users to switch. For more details, please check the Compatible-Vegas page.

Extended Stochastic Matrix Model:

Traditionally, fluid model is used to analyze TCP and the congestion control system. Fluid model ignores all the randomness in the network and treats the congestion control system as deterministic. Fluid model assumes that the packet losses and the corresponding window size backoffs are independent for different users. However, that assumption does not always hold. In reality, it is very possible that several flows see packets losses at the same congestion event, and their window backoffs are correlated. This correlation is called synchronization, which means several or users backoff at the same time. Fluid model cannot analyze synchronization: it cannot answer the question of when are packet losses synchronized, what is the effect of this synchronization, etc. A stochastic matrix model has been introduced to analyze the synchronization behavior, and this model explicitly takes the randomness of packet drops into consideration: this model assumes that when congestions happens at one link, different flows see packet losses with different probabilities, called window backoff probabilities.

All prior work assumes that, for one flow, this window backoff probability is a constant. However, this assumption does not reflect the reality accurately, since when a flow has a larger rate, more packets from this flow are flushing into the congested link, and this flow has a high probability to witness a packet loss. We have extended this model by considering this relationship between window backoff probability and send rate. From this extended model, we have answered all the questions on synchronization which the fluid model cannot answer, and we can analyze the fairness, stability, convergence speed properties of all loss based congestion control algorithms. In particular, from this model, we have analized the properties of TCP-Illinois. For more details, please check the stochastic matrix model page.

Competitive and Considerate Congestion Control Protocol (4CP)

One problem of TCP is that it has no service differentiation feature: both high priority traffic, like real time media, web browsing, and low priority traffic, like file downloading, data backup, peer-to-peer file transfer, use TCP. In the current Internet, bulk data transfers from less than 10% users takes more than 70% bandwidth, causes the network congestion, and detriment the performance of high priority traffics. These bulk data transfer users, however, are low priority users themselves. A service differentiation will benefit the high priority users significantly. The solution is to let high priority users choose TCP and let low priority users, like bulk data transfer users, choose another protocol, a low priority protocol. Existing low priority protocols assigns no bandwidth to low priority users, if there is a single high priority user. This way, low priority users are starved out of bandwidth very frequently, and thus bulk data transfer users have no incentive to choose these low priority protocols. We designed a new low priority protocol, which greatly benefit high priority users, but not at the significant sacrifice of low priority users, so bulk data transfer uses, like a large file downloader has incentive to choose it. This protocol is both competitive and considerate, so we call it 4CP. For more details, please check the 4CP page.