With the fast growth of Internet traffic, a successful congestion control scheme needs to efficiently utilize network resources. TCP provides reliable data transmission by adjusting the sending rate according to the available bandwidth of the network.
However, it has become clear that the TCP mechanisms, while necessary and pow-erful, are not sufficient to provide satisfactory services for all circumstances. In the following paragraphs, we will discuss the main challenges and issues currently faced by TCP.
1In this dissertation, the terms of ‘buffer size’ and ‘queue occupancy’ refer to ‘fixed hardware space’ and ‘dynamic fullness of the buffer’, respectively.
(1) Long-lived TCP Flows
Long-lived TCP flows may spend most life time in the congestion avoidance phase.
However, due to the limitation in TCP’s conservative congestion control algorithm, it may not efficiently utilize the network capacity when applications require fast data transfer over high speed and long latency networks especially [30]. This is because, during congestion avoidance, the congestion window size (CWND) grows so conservatively so that it may not fully use surplus resource promptly.
In addition, by setting the initial slow start threshold (SSTHRESH) to an ar-bitrary value, TCP performance may suffer from two potential problems: (a) the exponential increase of congestion window may generate packets too fast, causing multiple losses at the bottleneck nodes and coarse timeouts if the threshold is set too high relative to the per-flow available bandwidth (PAB). Hence, it leads to signifi-cant reduction of the throughput; (b) the connection will exit slow start and switches to congestion avoidance prematurely, resulting in poor startup utilization especially with a high bandwidth-delay product (BDP) network if the initial threshold is set too low (compared with PAB). For example, if TCP Reno/NewReno implementation sets initial SSTHRESH to 32 Kbytes, a TCP connection takes about 100 seconds to reach the ideal window over a path with a bottleneck bandwidth of 100 Mbps and RTT of 100 ms. The utilization in the first 10 seconds is a meager 5.97%. With the rapid advance of the Internet and ever-growing BDP, a more efficient mechanism is required to achieve better link-utilization.
(2) Short-lived TCP Connections
Recent studies in [31] reveal that a majority of the TCP connections such as Web traffic are short-lived, while a small number of long-lived connections like FTP traffic carry most Internet traffic. A short-lived connection usually terminates even before it reaches a steady state, that is, before the congestion window grows to make good bandwidth utilization of the end-to-end connection. Moreover, the probability that a packet loss will trigger the fast retransmit and fast recovery algorithm is very low.
This is because the window size will be small during the entire duration of the data transfer, and thus the sender will not be able to send enough segments to cause three duplicate ACKs. As a result, most losses trigger a retransmission timeout (RTO) which will force the TCP flow to reenter slow start phase. Accordingly, the startup stage may significantly affect the performance of short-lived TCP connections.
(3) The Queue Occupancy Made by TCP in a Router
A sender has no prior knowledge regarding the available bandwidth in the networks when a new connection starts, so this leads to the abrupt transition of congestion window with exponential growth and transmission of highly bursty traffic from the source during slow start. For loss-based TCPs, they increase CWND exponen-tially until reaching SSTHRESH or causing buffer overflow on the bottleneck link.
Although delay-based TCPs may not cause buffer overflow, they stop increasing CWND with exponential growth when reaching their own SSTHRESH value2. In other words, TCP is known to send bursts of packets during its slow start phase due to the fast window increase and the ACK-clock based transmission. Furthermore, a buffer overflow may cause multiple packets from the window being dropped in one RTT, thereby causing the self-clocking mechanism of the TCP source to fail.
When staying at the congestion avoidance phase, loss-based TCPs keep increas-ing their window size until packet loss occurs. Therefore, the curve of queue occu-pancy made by loss-based TCPs is like a sawtooth. This causes the delay between a packet and its next one unexpected. Comparably, delay-based TCPs try to stabi-lize their sending rate and make a fixed queue occupancy in the router. Therefore, delay-based TCPs are more suitable being used to transmit real-time applications’
data than loss-based TCPs are [32, 33].
2The definition of SSTHRESH for delay-based TCPs is different from that for loss-based TCPs.
Moreover, each delay-based TCP algorithm’s SSTHRESH may be not the same.
(4) Fairness and Friendliness Issues of Different TCP Variants
When a delay-based TCP user competes with other loss-based TCP users, it does not receive a fair share of bandwidth due to the conservative congestion avoidance mechanism used by the delay-based TCP. The reason is that the loss-based TCP continues to increase the window size until a packet is lost. This would occur mainly due to buffer overflow in an intermediate node (assuming the queue management algorithm is Drop Tail). This bandwidth estimation mechanism results in a peri-odic oscillation of window size and buffer-filling behavior of the loss-based TCP.
Thus, while the delay-based TCP tries to maintain a smaller queue occupancy, the loss-based TCP keeps inserting more packets into the queue, and stealing more bandwidth [10, 34, 35, 36, 37].
(5) Unfairness of TCP Sources with Different RTTs
It is well known that there is an unfairness problem when loss-based TCP con-nections feature different RTTs (i.e., concon-nections traverse networks with various latencies). The connections with smaller RTT increase their rate faster, grab more available bandwidth, and get more network resource [38]. The bias goes against longer RTT connections by a factor of RTT. Different from loss-based TCP mech-anisms, delay-based TCP algorithms are not biased against the connections with longer RTT [10, 11].
(6) Random Loss
Owing to the great advancement in wireless networking technology and emerging applications, providing ubiquitous mobile Internet access becomes increasingly de-manded. The well-known problem in providing TCP congestion control over het-erogeneous networks (wired/wireless environment) is that current TCP implemen-tations rely on packet loss as an indication of congestion. In the wired networks, a congestion is indeed a likely reason of packet loss. On the other hand, a noisy, mobile, and fading radio channel is the most likely cause of loss in the wireless
net-works. The effective bit error rates in wireless networks are significantly higher than that in wired networks. Since TCP does not have any mechanism to differentiate between congestion losses and wireless random losses, the latter may cause a severe throughput degradation.
The purpose of congestion control is to dynamically adapt the end-to-end trans-mission rate of a connection to the currently available capacity. TCP performs at an acceptable efficiency over the traditional wired networks where packet losses are caused by network congestion. However, when TCP observes random losses, it mis-interprets such losses and reduces its window size, this leads to the reduction of throughput unnecessarily. Therefore, TCP’s performance drops rapidly in the pres-ence of frequent random losses [39, 40]. More throughput deterioration problems of TCP over wireless networks have been addressed in [41, 42, 43, 44, 45, 46, 47, 48, 49, 50].
Summary
According to the above discussions, loss-based TCPs and delay-based TCPs may face same challenges and various problems. For example, how to improve the per-formance degradation of TCP in wireless network is a common challenge for both loss-based and delay-based TCP mechanisms. How to coexist with a loss-based TCP in the network is a tough task of delay-based TCPs. All these problems may prevent TCP from achieving a further success. In fact, loss-based and delay-based TCPs have their own advantages and shortcomings. “Does there exist an algorithm featuring advantages and characteristics of both loss-based and delay-based TCPs? ” Our motivation of this dissertation is trying to answer this question.
Many proposed mechanisms try to solve one or some problems as mentioned before, by modifying the algorithm of one phase or changing parameter settings.
For instance, [51] selects SSTHRESH dynamically to suit various kinds of BDP networks; however, it needs to estimate the available bandwidth of the network at the steady state. Setting SSTHRESH to the maximum value directly to avoid buffer overflow and limit the sending rate is suggested in [52, 53], but this may reduce the
throughput of a sender. In order to reduce bursty traffic during slow start, [54] uses 200 msec timer interrupt to control data transfer. However, this way only fits some network topology. Furthermore, using timer interrupt increases the overhead of the operating system.
HighSpeed TCP [55] involves a subtle change in the congestion avoidance re-sponse function to allow connections to capture available bandwidth more readily.
Similar to TCP Reno, HighSpeed TCP also causes periodic oscillations in the conges-tion window size, round-trip delay, and queue length of the bottleneck node [18, 19].
XCP [56] is a new transport protocol designed for high BDP networks. It separates the efficiency and fairness policies of congestion control, and enables connections to quickly make use of available bandwidth. However, because XCP requires all routers along the path to participate, deployment feasibility is a concern.
Accordingly, the way of modifying the algorithm of one phase or changing pa-rameter settings could enhance TCP performance in some circumstances; however, this kind of method has its limitations and may not be able to solve other issues, and even may make problems critical in other environments. Hence, in order to solve aforementioned issues and improve TCP performance in all circumstances, we redesign the whole algorithm and architecture of transmit control protocol in this dissertation.
1.3 Contributions
This dissertation is divided into two areas:
(1) Investigate the core idea of some familiar TCP variants and discuss TCP performance degradation issues.
(2) Medley TCP – a new end-to-end congestion control algorithm is proposed to accommodate the obstacles of TCP for achieving a better performance. Medley TCP has also been implemented in Linux and runs on Internet successfully.
The first area takes up only a small part of this dissertation. The second part is the main contribution of this dissertation and is partially inspired by the study
of the first area. We now briefly describe our proposed mechanism along with its performance and contributions as follows.
The key idea of Medley TCP is that it incorporates a scalable delay-based com-ponent into a loss-based TCP algorithm and determines congestion window based on congestion information – queueing delay and packet loss. In other words, it combines advantages and characteristics of both loss-based and delay-based TCPs.
When Δ is no larger than Γ3, Medley TCP will increase its congestion window size much quickly. Otherwise, Medley TCP will decrease its window size by one or in-crease the sending rate very slowly based on its estimate decision while Δ is larger than Γ. Therefore, Medley TCP is suitable for networks with high speed recourses and heterogeneous properties.
Also, in order to make it work well in a wireless network, we utilize the innate nature of Medley TCP to detect random packet losses precisely and modify the fast retransmit and fast recover phase of Medley TCP. Through the packet loss differentiation, Medley TCP reacts appropriately to the losses. Medley TCP only requires modification to the TCP sender and is therefore inter-operable with existing TCP: improvement can be achieved by having only one end of the connection employ Medley TCP. The details of Medley TCP is addressed in the dissertation.
The simulation results and Internet measurements show that Medley TCP not only has good utilization of bottleneck bandwidth, higher performance in a wireless network, better fairness, and friendliness, but also enhances the service for real-time applications such as Internet Protocol Television (IPTV), Voice over Internet Protocol (VoIP), and so on. The main reason is that Medley TCP’s throughput is very stable that supplies a fixed rate to real-time applications and the variation range of queue occupancy made by Medley TCP is very small. More simulation results, explanations, Linux implementation, and Internet measurement are presented in following Chapters.
3The in-depth discussions of Δ and Γ are addressed in Chapter 3.