TCP NRT: a new TCP algorithm for differentiating non-congestion retransmission timeouts over multihop wireless networks
© Sreekumari and Lee; licensee Springer. 2013
Received: 30 April 2012
Accepted: 13 May 2013
Published: 21 June 2013
In multihop wireless networks, reliable data transfer is one of the most difficult tasks. When transmission control protocol (TCP) operates in multihop wireless networks, the performance of TCP reduces drastically. TCP retransmission timeouts (RTOs) related to non-congestion events such as spurious and random packet losses have been reported as one of the main problems in the performance degradation of TCP in multihop wireless networks. The RTOs triggered by random packet losses due to transmission errors lead to unnecessary reduction of TCP congestion window size, and the spurious RTOs due to sudden delay of packets on the network paths often cause unnecessary retransmissions as well as reduction of congestion window size. Existing solutions for detecting non-congestion RTOs have no mechanism to differentiate the spurious RTOs from RTOs caused by random packet loss. In this paper, we introduce an efficient algorithm called non-congestion retransmission timeouts (TCP NRT) which is capable of recovering packets after RTOs by reducing unnecessary retransmissions and needless reduction of congestion window size in order to improve the performance of TCP in multihop wireless networks. TCP NRT consists of three key components: NRT-detection, NRT-differentiation, and NRT-reaction. We implemented the algorithm in Qualnet network simulator and compared its performance to existing TCP versions. Results from the experiments show that our algorithm achieves significant performance improvement in terms of throughput and accuracy. Also, the results showed that our algorithm, TCP NRT, maintains a fair and friendly behavior compared to the most widely deployed TCP, NewReno.
KeywordsWireless networks TCP RTOs Congestion loss Non-congestion events
In wireless local area and cellular networks, communication using wireless links occurs only in the last link between a base station and the wireless end system. Multihop wireless networks (MWNs) are a wireless network adopting the multihop wireless technology without deployment of wired backhaul links. MWNs have increased in importance and usage at the edge of the Internet over the past several years. It can be deployed in a cost-efficient way and can avoid wide deployment of cables. In MWNs, there are one or more intermediate nodes along the path that can receive and forward packets via wireless links . One of the most important benefits of MWNs is the capability to extend the coverage of a network and improve the quality of connectivity, compared to network with single wireless links. Several paths might become available in the case of dense MWNs that can be used to increase the robustness of the network. Although MWNs are very useful, the most important task to be accomplished in MWNs is the reliability of data transmission due to current limitations in wireless communications.
Transmission control protocol (TCP) is very important for reliable data transmission as it is the most popular transport protocol, and also, it is the de facto standard in the Internet. In recent years, the performance of TCP has acquired great attention, and it is an active research area among research topics on MWNs . TCP is implemented as a reliable data transfer protocol in wired networks. The congestion control algorithms of TCP are very essential for the reliability of data transmission as well as stability of the Internet. The success of TCP in wired networks motivates its extension to wireless networks . However, the data transmission of TCP is no longer stable in wireless networks. Particularly, when TCP operates in MWNs, the performance degrades significantly by increasing the number of hops. It is well known that the main reason for TCP performance degradation is its inability to distinguish the causes of three duplicate acknowledgments and retransmission timeouts (RTOs). Among these, the RTOs caused by non-congestion events have been reported as one of the main problems in TCP performance degradation in MWNs . Mainly, there are two main types of non-congestion RTOs. They are as follows: (1) spurious RTOs due to sudden delays or reordering of packets and (2) RTOs due to random packet losses caused by wireless transmission errors. These types of RTOs are unavoidable in MWNs.
Our work is motivated by three main observations. First, recent Internet measurement studies [4, 5] show that about 70% of the dropped packets are recovered after the expiration of RTO. In wireless networks, congestion is very rare, and frequent RTOs are often due to transmission errors . As a result, the sender reduces its sending rate unnecessarily, and it affects the performance of TCP in MWNs. Recently, researches on the performance of TCP reveal that spurious timeouts due to the increase in unexpected delay can considerably degrade the performance of TCP. In addition, the authors  show that in MWNs, more than 20% of the RTOs are caused spuriously by transmission delay of packets which results in unnecessary retransmissions and needless reduction of congestion window (cwnd) size. It takes a long time to reopen the window and is costly for high-bandwidth links . In conventional TCP, when RTO is invoked, the sender assumes that the packet is lost due to network congestion and immediately retransmits all the outstanding packets and sets the cwnd size to one maximum segment size (mss), which then increases according to slow-start algorithm.
Second, previous research indicates that spurious RTOs are not rare events in MWNs [7, 8]. After the spurious RTO, the late-arriving acknowledgments (Acks) can encourage TCP to retransmit all the packets in flight, which may all have been correctly received by the TCP receiver. This unnecessary retransmission behavior leads to the under utilization of the network resources such as available bandwidth. Not only that, each redundantly retransmitted packet will be responded to with a duplicate Acks by the TCP receiving side. Fast retransmission algorithm can be triggered if the number of duplicate Acks accumulates over the fast retransmit threshold (normally, it is equal to three). In addition to that, after the spurious RTOs, TCP starts the slow-start algorithm, and each original Ack received in the slow-start will trigger out two or three segments, more than the number of packets which have actually left the pipe. This TCP behavior is a violation of the principle of TCP packet conservation .
Third, several modifications have been proposed for TCP loss recovery and congestion control mechanisms to improve the performance of TCP. However, the existing solutions [2, 6, 9–11] proposed for detecting congestion RTOs and non-congestion RTOs have no mechanism to differentiate the two different types of non-congestion RTOs such as random loss and spurious RTOs. When spurious RTOs coexist with RTOs due to random packet losses, it results in unnecessary retransmissions and needless reduction of cwnd size, which leads to the performance degradation of TCP in MWNs. As a result, it is an important issue whether the TCP sender can control unnecessary retransmissions by differentiating the types of RTOs due to random packet losses from spurious RTOs.
Detection of non-congestion RTOs (NRT-detection): To detect non-congestion RTOs from congestion RTOs using the improved explicit congestion notification (ECN) mechanism.
Differentiation of non-congestion RTOs (NRT-differentiation): To differentiate the RTOs due to random packet losses from spurious RTOs by using the comparison of the first Ack after the expiration of RTOs.
Reaction to non-congestion RTOs (NRT-reaction): To guide the TCP sender to control the unnecessary reduction of cwnd size and to control the needless retransmissions according to the types of RTOs.
With the help of these components, TCP NRT can improve the performance of TCP in MWNs. We implemented TCP NRT in a Qualnet network simulator and compared its performance using important metrics such as throughput, accuracy, fairness, and friendliness with the existing TCP versions such as Eifel, F-RTO, DSACK, EQRTO, and NewReno. The results demonstrate that TCP NRT achieves significant improvement in throughput and accuracy compared to other TCP versions, especially when RTOs occur in non-congested environments. Moreover, the simulation results show that when RTOs occurred in a congestion-free network with packet loss rate ranging from 1% to 9%, the TCP NRT performance achieves 29% higher throughput than EQRTO and more than 40% throughput improvement over Eifel, DSACK, and F-RTO especially at 9% packet loss rate due to transmission errors. In addition, the experiment on multiple TCP flows clearly shows that TCP NRT maintains a fair and friendly behavior with respect to other TCP flows. The remainder of this paper is organized as follows: Section 2 describes the problem of TCP RTOs. In Section 3, we briefly summarize the existing research related to the work done in this paper. We introduce TCP NRT in Section 4, where the main features of each component are discussed in detail. Section 5 describes the performance evaluation of TCP NRT against existing protocols. Finally, Section 6 concludes our work by pointing out our major achievements.
2. The problem: retransmission timeouts of TCP
As we mentioned in the previous section, mainly, there are two main types of non-congestion RTOs. One is the RTOs caused by random packet losses due to transmission errors, and the other is the RTOs triggered spuriously due to sudden delays or due to reordering of packets on the network path without any packet losses. If RTO expires due to random packet losses, the TCP sender retransmits the packet and unnecessarily reduces the size of cwnd. On the other hand, when RTO occurs spuriously, the sender not only reduces the size of cwnd but also retransmits the packet unnecessarily. As a result, the TCP sender cannot utilize the available bandwidth fully. This affects the performance of TCP in MWNs. To observe the throughput degradation of TCP in MWNs, we did an experiment using seven-hop chain topology and measured the throughput and the number of retransmissions triggered by fast retransmission and RTO procedures according to the number of hops. Although it is well known that the performance of TCP sharply decreases as the number of hop increases in MWNs, there is no experiment showing the variation of TCP performance according to the ratio of retransmissions caused by random losses and spurious packet losses. Thus, we did a simple experiment in order to know the ratio of retransmissions caused by random loss and spurious RTOs to that of retransmissions by triggering the fast retransmission algorithm. In this simulation, we used one TCP flow from source to destination in a chain topology with no network congestion and thereby evaluate the unnecessary degradation of throughput due to RTOs.
3. Related work
There have been many solutions proposed for improving the performance of TCP in MWNs. In this section, we briefly summarize the existing research related to the work done in this paper. We classify the related work into two parts. The first part depicts the solutions to detect congestion and spurious RTOs, and the second part presents the solutions to detect congestion and non-congestion RTOs.
3.1. Solutions to detect congestion RTOs and spurious RTOs
In MWNs, spurious RTOs are inevitable because by no means can TCP predict and avoid the link delay spikes. The major difference in spurious RTO algorithms lies in how a spurious timeout is detected, which is equivalent to solving retransmission ambiguity in many circumstances. By clarifying the retransmission ambiguity, TCP can confirm whether or not data have been unnecessarily retransmitted and further conclude if a spurious RTO has happened. The following are the existing algorithms for detecting congestion and spurious RTOs.
Eifel. The Eifel algorithm , specified in RFC 3522, uses the TCP timestamp option  for detecting spurious and congestion RTOs. The key idea is when the sender sends packet, it stored the current value of the timestamp clock into the header of each outgoing packets. When the receiver receives that packet, it echoes the timestamp value back to the sender in the corresponding Acks. After the expiration of a RTO, the sender stores the timestamp of the retransmitted packet. Upon the arrival of the first Ack after RTO, the TCP sender compares the timestamp of the Acks with the previously stored values. If the value of the Ack is smaller than the stored value, then the sender assumes that the RTO was spurious. The Eifel algorithm uses extra information in the Acks to eliminate retransmission ambiguity, thereby solving the problem of spurious retransmissions.
DSACK. The DSACK algorithm , specified in RFC 3707, is an extension to the ‘selective acknowledgment’ (SACK) option; the sender uses the first SACK block to specify a segment that triggers a duplicate Ack at the receiver. The DSACK algorithm uses this feature of SACK for detecting spurious RTOs. The general idea is that if a retransmitted packet has been acknowledged for the second time, the sender assumes that the earlier retransmission was spurious. DSACK introduces only less traffic overhead than Eifel does since the TCP receiver only needs replying with SACK or DSACK options upon the detection of out-of-order packets, while a timestamp option has to be attached to every TCP packet and Ack in the case of Eifel. However, the slow reaction of DSACK judgment makes the TCP retransmit several packets mistakenly, or in the worst case, a whole window of packets has to be retransmitted before the situation is clear.
F-RTO. The forward RTO-recovery (F-RTO) algorithm , specified in RFC 4138, follows a distinct rationale for detecting spurious RTOs without using any TCP options. The key idea is that at the time of RTO, the TCP sender enters the slow-start algorithm, retransmits one outstanding packet, and then monitors the first incoming Ack; after retransmission advances the value of cwnd, the TCP sender will retransmit two new packets. Again if the second Ack advances the cwnd, then the sender interprets that the RTO is spurious. Otherwise, a congestion RTO occurs, and the sender will revert to the traditional slow-start algorithm to retransmit the outstanding packets. F-RTO requires no TCP extension for its application and has higher link utilization than TCP Eifel. However, F-RTO may postpone the response for a genuine RTO if the packet loss and the delay spike run in the same transfer window.
STODER. Spurious timeout detection by repacketization (STODER)  detects retransmission ambiguity using TCP repacketization. When a RTO expires, a TCP sender repacketizes a packet which is k-bytes smaller than the original packet and retransmits it instead of the original packet which triggered the RTO. Then, it detects the spurious RTOs when an Ack arrives after the RTO by examining the number of bytes that are acknowledged. If the acknowledged bytes are the same with the size of the original packet, it assumes that the RTO is a spurious RTO. These schemes are very effective to distinguish spurious RTOs from congestion RTOs and let TCP avoid unnecessary retransmissions and the improvement of TCP to cope better with spurious RTOs. However, these schemes have no mechanism to detect the RTOs caused by random packet loss due to transmission errors, which is harmful to the performance degradation of TCP in MWNs.
3.2. Solutions to detect congestion RTOs and non-congestion RTOs
To the best of our current review of literatures, the only study in the direction of detecting non-congestion RTOs and congestion RTOs has been carried out in  for avoiding of unnecessary cwnd size reduction, thereby solving the performance degradation of TCP in MWNs.
Estimation of queue usage for detecting RTOs (EQRTO)  is able to distinguish spurious and random packet loss RTOs from congestion RTOs to improve the performance of TCP in MWNs. The main idea is that in order to identify congestion RTOs, EQRTO estimates the rate of queue usage during the go-back-N retransmissions in the network path between a TCP sender and a TCP receiver. When the go-back-N retransmission ends, EQRTO checks if the network queue usage indicates whether the network is congested or not. If yes, the TCP sender assumes the RTO as congestion RTO; otherwise, it assumes that RTOs occurred due to random packet losses or spurious RTOs. The existing algorithms affect the behavior of the TCP sender only after the expiration of RTOs. In the case of three duplicate Acks, these algorithms work the same as the conventional TCP. Unfortunately, the above solutions have limitations in differentiating the RTOs caused by random packet losses from spurious RTOs. In the case of EQRTO, the algorithm can detect congestion and random loss RTOs as well as congestion and spurious RTOs. However, the algorithm cannot differentiate the random loss RTOs from spurious RTOs. If the TCP sender cannot differentiate the spurious RTOs from random loss RTOs, it results in the degradation of the TCP performance in MWNs. By considering the limitations of the above solutions, we develop a new TCP algorithm for the differentiation of non-congestion RTOs, thereby increasing the performance of TCP in MWNs.
4. Proposed algorithm: TCP NRT
4.1. Detection of non-congestion RTOs (NRT-detection)
To differentiate the RTOs due to random packet losses from spurious RTOs (together we call ‘non-congestion RTOs’), first we should distinguish these RTOs from congestion RTOs. In order to detect non-congestion RTOs and congestion RTOs, we modified the ECN as it has been approved as an Internet official protocol standard in RFC 3168  and is recommended to be widely deployed as a router mechanism. This is because ECN provides higher network efficiency, fairer distribution of bandwidth, less packet losses, and less bursty traffic; and benefits to short flows present a strong case for its implementation. ECN requires an active queue management mechanism in order to work . Most of the active queue management schemes can achieve high performance with enabled ECN even if the load is more than 85% . ECN is an extension to the random early detection (RED) algorithm for dropping packets. First, we explain the mechanism of RED. RED is the most widely deployed queue management scheme in commercial Internet routers . The key idea behind the RED active queue management scheme is to inform the sender about the detection of incipient congestion by dropping the packets even when there is available buffer space. This type of probabilistic packet drop prevents the router from entering the fully congested state and helps reduce the queueing delay. However, in the case of large TCP flows, RED drops packets in higher loss rates and thereby degrades network performance since it requires extra time and causes TCP retransmissions which add to network congestion. As a result, instead of dropping packets randomly, an ECN router marks the packets to alert the sender of incipient congestion. Recent studies show that the performance of RED in the absence of ECN is worst than drop tail queue .
4.2. Differentiation of non-congestion RTOs
In this subsection, we explain in detail how TCP NRT differentiates the RTOs due to random packet losses from spurious timeouts. Spurious timeouts due to sudden delay are not rare in MWNs. As a result, it is very important to differentiate the RTOs due to random packet loss from spurious timeouts in order to reduce unnecessary retransmissions and needless reduction of cwnd size. As we explained in the previous subsection, when RTO expires at the sender, it checks the last received Ack to confirm whether it is marked or not. If it is not marked, it means that the RTO is due to random packet loss or spurious RTOs. As a result, the sender stores the value of the next expected Ack in a variable ‘Exp_Ack’. Then the sender sends a new packet instead of retransmitting the timeout packet, as shown in Figure 6b. The reason is that non-congestion RTO happens due to transmission errors or sudden delays. It means that the buffer has space to accommodate a new packet. When the sender receives an Ack after sending a new packet, it checks whether the Ack is greater than the stored value. If it is greater, it means that the RTO was spurious; otherwise the sender retransmits the lost packet immediately without reducing the size of cwnd.
In this example, consider that the last Ack is not marked. As a result, the sender confirms that the RTO happened due to a non-congestion event, either random packet loss or sudden delay. Instead of retransmitting the packet P6 immediately, the sender sends a new packet P7 and stores the next expected Ack in the variable Exp_Ack. As soon as the packet P7 reaches the destination, the receiver again sends an Ack for the lost packet P6. The sender compares the Ack with the stored value in the variable Exp_Ack to check whether the first Ack after the non-congestion RTO is greater than Exp_Ack. Here, it is equal to the value in the Exp_Ack. As a result, the sender confirms that the packet P6 is lost and immediately retransmits the lost packet P6 without reducing the size of cwnd. On the other hand, if the non-congestion RTO was triggered due to sudden delay of packet P6, it reaches the destination before reaching the packet P7. As a result, the TCP sender receives an Ack of the next expected packet which is greater than the value of Exp_Ack. Then the sender confirms that the RTO was spurious. In this way, TCP NRT can reduce unnecessary retransmissions and needless reduction of cwnd size and thereby improve the performance of TCP in MWNs.
4.3. Reaction to non-congestion RTOs (NRT-reaction)
This subsection explains how TCP NRT reacts after the TCP sender detects and differentiates the RTOs. As we explained in the above subsections, whenever the sender detects RTO, it checks whether the last Ack is marked or not. Note that we mark the packets only if the AQL is greater than or equal to the maximum threshold. As shown in Algorithm 1, if the packet is marked, the sender immediately retransmits the lost packet and reduces the size of cwnd (lines 2 to 4) and follows the RTO loss recovery algorithm of TCP NewReno as it is the most widely deployed protocol. The reason is that a marked packet is an indication of network congestion. On the other hand, if it is not marked, the sender confirms that the RTO is caused by random packet loss due to transmission errors or spurious packet losses due to sudden delays. As a result, instead of retransmitting the packet, the sender sends a new packet and waits for the Ack. If the RTO is triggered due to random packet loss, the sender retransmits the lost packet while keeping the current size of cwnd (lines 6 to 8). If the RTO is triggered spuriously, the sender sends packets continuously without reducing the size of cwnd and ssthresh until the value of cwnd reaches the value of ssthresh. In this way, the sender of TCP NRT is able to reduce unnecessary retransmissions and needless reduction of the size of cwnd due to spurious RTOs and the RTOs due to random packet losses and can increase the performance of TCP in MWNs.
4.4. Operation of TCP NRT
As shown by the dotted lines in Figure 8, whenever the timer expires, the sender goes to NRT-detection to detect congestion and non-congestion RTOs. If the RTO is caused by congestion, the sender invokes the NRT-reaction algorithm to retransmit the lost packets and reduce the size of cwnd to one mss followed by the slow-start algorithm like conventional TCP. Otherwise, the sender goes to NRT-differentiation to check whether the RTO is caused by random packet loss or spurious RTO before retransmitting the packet and follows the component NRT-reaction. If the RTO is caused by non-congestion events, then the sender may not reduce the size of cwnd and can reduce unnecessary retransmissions using the component NRT-differentiation. When the value of cwnd reaches the value of ssthresh, the sender goes to CA state and continues sending packets until the sender receives three dupacks or the expiration of RTO. In this way, TCP NRT can improve the performance of TCP in MWNs by reducing unnecessary retransmissions due to spurious RTO as well as by avoiding unnecessarily reduction of cwnd due to the RTOs triggered by random packet losses or spurious RTOs.
5. Performance evaluation
In this section, we explain the simulation methodology and performance metrics we use to evaluate the effectiveness of the TCP NRT algorithm in MWNs. In order to make sure of the efficiency of our algorithm, the performance of TCP NRT is compared to that of related works such as Eifel, DSACK, F-RTO, EQRTO, and NewReno.
5.1. Simulation methodology
For this, we grouped our experiments into four sets. The first set of experiments involves wireless links that drop packets randomly without any congestion in the network. The packet losses are distributed uniformly. The main purpose of this scenario is to test the performance when RTO occurs due to transmission errors. Since the primary motivation of TCP NRT is to improve TCP performance in MWNs when random packet loss causes unnecessary cwnd reduction and spurious RTOs cause unnecessary retransmissions and needless cwnd reduction, we start with a scenario that involves random packet losses. The second set of experiments involves wireless links that do not drop any packets but randomly inflicts sudden delays for some packets. The main goal of this experiment is to evaluate the performance when sudden delays cause spurious RTOs. To perform this experiment, we adopt the method described in .
The third set of experiments involves wireless links that cause RTOs due to random packet losses and sudden delays. The main aim of this experiment is to ensure the effectiveness of TCP NRT when the RTOs coexist with random packet loss and sudden delays. It is essential to check the performance improvement of TCP NRT by differentiating the two types of RTOs in the network. The fourth set of experiments involves wireless links that cause RTOs due to congestion as well as random packet loss and RTOs due to sudden delays. The main purpose of this experiment is to evaluate the performance of TCP NRT in a general environment. As mentioned in , in all scenarios, we traced packet losses at the Mac layer and the network layers and compared those lost packets with the packets triggered by RTO at the transport layer. If the packet triggered by RTO is not found at the Mac and network layers, we assume that the corresponding RTO is triggered due to sudden delay, and we treat those RTOs as spurious RTOs.
5.2. Performance metrics
To ensure the significant performance of TCP NRT, we evaluate our algorithm using four perspectives: throughput, accuracy, fairness, and friendliness.
Throughput is one of the most important performance metrics in the TCP. We define throughput as the number of packets sent divided by the transmission time. We measured throughput in terms of the number of hops, number of flows, varying bandwidths, different packet loss rates, and varying delays using chain and grid topologies.
Another important metric is accuracy. It defines exactly how a scheme detects the different types of RTOs . We measured accuracy in terms of RTOs due to random packet loss (RPL), congestion packet loss (CPL), spurious RTOs (S), and the combination of random packet losses and spurious RTOs (NC).
where RPLIdent_RTO is the number of RTOs exactly identified as RTO due to random packet loss by TCP NRT compared to other existing algorithms, and RPLTotal_RTO is the total number of RTOs triggered due to random packet losses.
where CPLIdent_RTO is the number of RTOs exactly identified as RTO due to congestion packet loss by TCP NRT compared to other existing algorithms, and CPLTotal_RTO is the total number of RTOs triggered due to congestion packet losses.
where SIdent_RTO is the number of RTOs exactly identified as spurious RTOs, and STotal_RTO is the total number of RTOs triggered due to spurious packet losses.
where NCIdent is the number of RTOs exactly identified as non-congestion RTOs, and NCTotal is the total number of non-congestion RTOs. Finally, we compared the fairness and friendliness of TCP NRT. We explain these in detail in the next subsections.
where xi is the throughput of the i th connection, and n is the number of connections. F(x) ranges from 1/n to 1.0. A perfectly fair bandwidth allocation would result in a fairness index of 1.0. On the contrary, if all bandwidths are consumed by one connection, Equation 5 would yield 1/n.
Gradual deployment requires acceptable friendliness behavior when TCP NRT is sharing the medium with other flows . This means that TCP NRT ideally should not suppress the regular flows but allow them to achieve at least the same throughput they would obtain without any improved flow in parallel. We show through xour experiments how friendly our mechanism can be when TCP NRT competes with regular flows of TCP NewReno in a MWNs.
5.3. Experimental results
In this subsection, we present the results of our experiments used to verify the effectiveness of our algorithm in MWNs using three different scenarios, namely chain, grid, and dumbbell topologies.
5.3.1. Comparison of throughput in chain topology
5.3.2. Comparison of accuracy in grid topology
5.3.3. Comparison of fairness using dumbbell topology
Comparison of fairness
Loss rate (%)
5.3.4. Comparison of friendliness using dumbbell and chain topologies
5.3.5. Comparison of existing solutions with TCP NRT
Comparison of existing solutions with TCP NRT
In this paper, we have proposed a new TCP algorithm, called TCP NRT, to improve the performance of TCP in MWNS by differentiating the types of non-congestion RTOs. TCP NRT detects the non-congestion RTOs by means of the modified packet marking scheme of ECN mechanism. Our approach is easy to implement and requires only simple changes in the sender side of the TCP without altering the protocol itself. Our simulation results show that TCP NRT is a viable solution to the TCP performance degradation in MWNs. Results show that under 5% packet loss rate, a typical characteristic of MWNs, TCP NRT outperforms other TCP variants by 20% to 60% improvement in throughput when the RTO is caused in the absence of network congestion and presence of random loss due to transmission errors. On the other hand, the results show that under 140 ms delay, TCP NRT achieves high throughput compared to other existing solutions in the presence of spurious RTOs. Furthermore, when the network coexists with both congestion and non-congestion RTOs, the throughput of TCP NRT increases more than 25% compared to the other solutions. There are three main reasons for these significant improvements in the throughput, namely NRT-detection, NRT-differentiation, and NRT-reaction. Our experiments also show that TCP NRT maintains a fair and friendly behavior with other TCP flows. Our future research in this direction would be to improve TCP NRT so that the sender could further control its congestion control mechanism when it receives duplicate acknowledgments or RTOs in case of loss of acknowledgments in addition to the sudden delay or random loss of packets.
This research was supported by the Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education, Science and Technology (2013020769).
- Fu Z, Zerfos P, Luo H, Lu S, Zhang L, Gerla M: The impact of multi-hop wireless channel on TCP throughput and loss. In 22th Annual Joint Conference of the IEEE Computer and Communication Societies (INFOCOM 2003) vol. 3. New York: IEEE; 2003:1744-1753.Google Scholar
- Mi-Young P, Sang-Hwa C: Distinguishing the cause of TCP retransmission timeouts in multi-hop wireless networks. In 12th IEEE International Conference on High Performance Computing and Communications (HPCC-2010). Melbourne; 1–3 Sept 2010:329-336.View ArticleGoogle Scholar
- Xu S, Saadawi T: Performance evaluation of TCP algorithms in multi-hop wireless packet networks. Wireless Communications and Mobile Computing 2001, 2: 85.View ArticleGoogle Scholar
- Kothari NJ, Gambhava BM, Dasgupta KS: RTT utilization by detecting avoidable timeouts. 14th IEEE International Conference on Networks, Singapore 13–15 Sept 2006.Google Scholar
- Ciullo D, Mellia M, Meo M: Two schemes to reduce latency in short lives TCP flows. IEEE Communications Letters 2009, 13: 10.View ArticleGoogle Scholar
- Sarolahti P, Kojo M: Forward RTO-recovery (FRTO): an enhanced recovery algorithm for TCP retransmissions timeouts. ACM SIGCOMM Computer Communications Review 2003, 33: 2.View ArticleGoogle Scholar
- Mi-Young P, Sang-Hwa C: Detecting TCP retransmission timeouts non-related to congestion in multi-hop wireless networks. IEICE Transactions on Information and Systems 2010, E93-D(12):3331-3343. 10.1587/transinf.E93.D.3331View ArticleGoogle Scholar
- de Oliveira R, Braun T: A smart TCP acknowledgment approach for multihop wireless networks. Mobile Computing, IEEE Transactions 2007, 6(2):192-205.View ArticleGoogle Scholar
- Ludwig R, Katz RH: The Eifel algorithm: making TCP robust against spurious retransmissions. ACM SIGCOMM Computer Communication Review 2000, 30: 1.Google Scholar
- Blanton E, Allman M: Using TCP duplicate selective acknowledgment (DSACK) and stream transmission control protocol, RFC Information-3707. 2004. . Accessed 10 March 2012 http://tools.ietf.org/html/rfc3707Google Scholar
- Tan K, Zhiang Q, Wenwu Z: STODER: a robust and efficient algorithm for handling spurious retransmission timeouts in TCP. Proc. IEEE Global Telecommunications Conference, St. Louis, 20 Nov–2 Dec 2005 3692-3696.Google Scholar
- Allman M, Balakrishnan H, Floyd S: Enhancing TCP's loss recovery using limited transmit, RFC 3042. 2001.http://tools.ietf.org/html/rfc3042 . Accessed 10 March 2012Google Scholar
- Fu CP, Liew SC, Veno TCP: TCP enhancement for transmission over wireless access networks. IEEE Journal on Selected Areas in Communications 2003, 21(2):216-228. 10.1109/JSAC.2002.807336View ArticleGoogle Scholar
- Jacobson V, Braden R, Borman D: TCP extensions for high performance, RFC 1323. 1992.http://www.ietf.org/rfc/rfc1323.txt . Accessed 23 March 2012Google Scholar
- Floyd S: TCP and explicit congestion notification. ACM Computer Communication Review 1994, 24: 8.View ArticleGoogle Scholar
- Lin D, Morris R: Dynamics of random early detection. ACM SIGCOMM Computer Communication Review 1997, 27(4):127-137. 10.1145/263109.263154View ArticleGoogle Scholar
- Long L, Aikat J, Jeffay K, Smith FD: The effects of active queue management and explicit congestion notification on web performance. Networking, IEEE/ACM Transactions 2007, 15(6):1217-1230. 10.1109/TNET.2007.910583View ArticleGoogle Scholar
- Lim LB, Guan L, Grigg A, Phillips IW, Wang XG, Awan IU, Lim LB, Guan L, Grigg A, Phillips IW, Wang XG, Awan IU: RED and WRED performance analysis based on superposition of N MMBP arrival process. 2010 24th IEEE International Conference on Advanced Information Networking and Applications (AINA), Perth, 20–23 2010, 66-73.View ArticleGoogle Scholar
- Xu K, Tian Y, Ansari N: TCP-Jersey for wireless IP communications. IEEE Journal of Selected Areas of Communication 2004, 22: 747-756. 10.1109/JSAC.2004.825989View ArticleGoogle Scholar
- Yi W, Lu L: A study of internet packet reordering. In Proceedings of Information Networking Technologies for Broadband and Mobile Networks International Conference. Busan; 18–20 Feb 2004.Google Scholar
- Floyd S, Henderson T: The NewReno modification to TCP's fast recovery algorithm, RFC 2582. IETF; 1999. . Accessed 18 March 2012 http://www.hjp.at/doc/rfc/rfc2582.txtGoogle Scholar
- Scalable Network Technologies 2013.http://www.scalable-networks.com/index.php . Accessed 12 February 2012
- Jain R, Chiu D, Hawe W: A Quantitative Measure of Fairness and Discrimination for Resource Allocation in Shared Computer Systems, Research Report TR-301(Digital Equipment. Hudson; 1984.Google Scholar
- Mi-Young P, Sang-Hwa C: A simulation-based study on spurious timeouts and fast retransmits of TCP in wireless networks. In 2010 Third International Joint Conference on Computational Science and Optimization (CSO). Huangshan; 28–31 May 2010:273-277.Google Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.