Skip to main content

Advertisement

TCP’s dynamic adjustment of transmission rate to packet losses in wirelessnetworks

Article metrics

  • 3540 Accesses

  • 4 Citations

Abstract

Based on the assumption of transmission control protocol (TCP) that packetsare lost due to congestion, TCP’s congestion control algorithms suchas fast retransmit/recovery (FRR) and retransmission timeouts (RTO)unconditionally reduce the transmission rate for every packet loss. When TCPoperates in wireless networks, however, FRRs/RTOs are often triggeredregardless of congestion due to sudden delay and wireless transmissionerrors. The congestion irrelative FRRs/RTOs incur TCP’s misbehaviorsuch as blindly halving the transmission rate, unnecessarily retransmittingthe outstanding packets which may be in the bottleneck queue. Although manyprevious studies have been proposed to detect the congestion irrelativeFRRs/RTOs, they paid little attention on effectively adjusting thetransmission rate for the detected congestion irrelative FRRs/RTOs.

In this article, we propose an enhanced TCP to dynamically adjust itstransmission rate according to network conditions. Our scheme adjusts thetransmission rate in proportion to the available bandwidth in order toquickly utilize the available bandwidth, and also re-adjusts it in inverseproportion to the loss rate in order to avoid burst losses and longgo-back-N retransmissions. By doing so, our scheme hassignificant effects to avoid the performance degradation caused by thecongestion irrelative FRRs/RTOs. Throughout the extensive experiments, weevaluate our scheme and compare it with previous works in terms of goodput,fairness, and friendless under various network topologies. The results showthat our scheme significantly outperforms previous studies while itmaintains the fair and friendly behavior to other TCP connections.

Introduction

The transmission control protocol (TCP) [13] is the most popular protocol in the Internet, and its mission is toprovide reliable data transfer between a TCP sender and a TCP receiver. For this,TCP has two mechanisms to detect packet losses for retransmissions: fastretransmit/recovery (FRR) and retransmission timeout (RTO) [2, 4]. Assuming that packets are lost due to congestion, TCP reduces itstransmission rate whenever an FRR or RTO is triggered in order to avoid furthercongestion losses.

That assumption works very well in wired networks where most FRRs or RTOs aretriggered by the packets lost due to congestion, but it is not appropriate inwireless networks where most FRRs/RTOs are triggered by other reasons such as suddendelay [57], wireless errors, and mobility. The congestion irrelative FRRs/RTOs incurTCP’s misbehaviors such as (1) blindly halving the transmission rate even whenthe available bandwidth is sufficient, (2) unnecessarily retransmitting theoutstanding packets which may be in the bottleneck queue, and (3) needlesslyincreasing the back-off value exponentially. As a result, TCP underutilizesavailable bandwidth and its performance degrades severely in wireless networks.

To date, many previous studies have been proposed to solve such TCP’s problemin wireless networks. Some loss differentiation schemes such as Westwood [8], JTCP [9], and RELDS [10] have been proposed to differentiate wireless losses from congestionlosses. Other schemes such as Eifel [1113], F-RTO [14, 15], and STODER [16] have been suggested to remove the unnecessary retransmissions bydetecting spurious FRRs/RTOs. The common problem is that they paid little attentionon adjusting appropriately the transmission rate when the FRRs/RTOs are triggeredregardless of congestion even though controlling the transmission rate is verycritical in improving TCP’s performance.

In case of TCP Westwood and Prairie, they estimate the available bandwidth, andadjust TCP’s transmission rate according to the estimated bandwidth. Althoughthey have more significant impact on improving TCP’s performance, theseschemes could have a high possibility to cause more frequent burst losses and longgo-back-N retransmissions as the rate of wireless transmission errorsincreases. This is because these schemes do not consider the packet loss rate whenthey adjust the transmission rate. In this article, we propose an enhanced TCP todynamically adjust its transmission rate according to network conditions such as theavailable bandwidth and the loss rate. When an FRR/RTO is triggered, our schemeadjusts the transmission rate in proportion to the available bandwidth in order toquickly utilize the available bandwidth, and also readjusts it in inverse proportionto the loss rate in order to avoid burst losses and long go-back-Nretransmissions. In addition, when successive RTOs are triggered, our schemeinitializes the back-off value if the network is not congested in order to avoid along idle time period of an RTO. By doing so, our scheme has significant effects toavoid the performance degradation caused by the congestion irrelative FRRs/RTOs inwireless networks.

To evaluate our scheme, we design about 100 different simulation scenarios by settingdifferent values of network parameters, and conduct simulation-based experimentsusing a network simulator, QualNet 4.5 [17]. Throughout the extensive simulations, we (1) observe how oftencongestion irrelative FRRs/RTOs are triggered, (2) measure the performanceenhancement of our scheme and compare it with previous studies such as F-RTO, JTCP,and Prairie [18], (3) evaluate our scheme’s fairness and friendliness. The resultsshow that our scheme significantly outperforms previous studies while it maintainsthe fair and friendly behavior to other TCP connections.

In the following section, we describe TCP’s misbehaviors caused by thecongestion irrelative FRRs/RTOs. After that, we introduce previous studies to handlesuch TCP’s problem, and explain our motivation. In “Dynamic respondingalgorithm” section, we propose our scheme to dynamically adjust thetransmission rate according to the available bandwidth and the loss rate. Lastly, weevaluate and compare our scheme with previous studies in “Experimentation andanalysis”, and conclude this article in the last section.

TCP’s misbehavior caused by wireless losses

TCP [13] uses packet loss as an indicator of congestion. Thus, whenever packetsare lost in the networks, TCP’s congestion control algorithms such as FRR andRTO are triggered to reduce transmission rate by updating the two variables: thecongestion window (cwnd) and the slow start threshold (ssthresh) [2, 4].

The two variables are critical to TCP’s performance since the transmission ratedepends on the two variables. cwnd is the size of the packets which can besent without receiving any acknowledgements from a TCP receiver, and ascwnd is larger TCP’s transmission rate is higher. cwndis initialized by one segment when a connection starts or when an RTO is triggered.Then, a TCP sender increases cwnd exponentially whenever a new ACK arrivesuntil cwnd reaches ssthresh. After reaching ssthresh,cwnd increases linearly. ssthresh is a critical border for aTCP sender to decide if the transmission rate increases exponentially or linearly.The value of ssthresh is initialized by an arbitrarily high value, and itis updated to the halved value of cwnd whenever an FRR/RTO istriggered.

In wireless networks, cwnd and ssthresh are often unnecessarilyreduced whenever an FRR/RTO is triggered due to some characteristics of wirelessnetworks such as sudden delay, wireless errors, etc. Moreover, TCP has no ability toidentify if an FRR/RTO is triggered by congestion or not. It responds to allFRRs/RTOs by blindly reducing the transmission rate as well as by retransmitting theoutstanding packets unnecessarily. Thus, it is unavoidable for TCP to underutilizesavailable bandwidth and its performance degrades severely in wireless networks [19, 20].

In this section, using a simple scenario, we observed how TCP’s congestioncontrol algorithms respond to packet losses caused by wireless transmission errors.The scenario is designed to have only one TCP flow between a TCP sender and a TCPreceiver in order to avoid causing congestion. Thus, none of RTOs or FRRs istriggered due to congestion in the scenario. First, we simulated the scenariowithout adding wireless transmission errors between the sender and the receiver, andtraced all the variables related to TCP’s congestion control into a tracefile. After that, we simulated it again after adding 1% wireless losses (packetsare lost due to wireless transmission errors), and then we compared the differencesof TCP’s behavior with/without wireless losses.

Figure 1 shows the results. In Figure 1a,we checked the differences of TCP’s cwnd before/after adding wirelesstransmission errors. In the figure, we can see that cwnd dramaticallyincreases after a TCP connection starts at 1 s, and it reaches its maximum value at1.25 s. After that, cwnd does not decrease and keeps its maximum size untilthe simulation ends because there is no packet loss (the black line in Figure 1a). On the other hand, when wireless errors are added,cwnd sharply shrinks when an RTO expires at 1.25 s (the yellow line inFigure 1a). After that, it starts to increase, but itdecreases again due to another wireless loss. Finally, cwnd could not reachits maximum value again even though the network is not congested.

Figure 1
figure1

TCP’s misbehaviors with wireless losses.

Figure 2 shows the variations of cwnd increasingexponentially or linearly before/after ssthresh around 8 s in Figure 1a. When ssthresh is set to 12,000 and cwnd issmaller than ssthresh (12,000), cwnd increases exponentially untilit reaches ssthresh. After cwnd reaches ssthresh around8.7 s, cwnd increases linearly.

Figure 2
figure2

cwnd ’s exponential or linear increases before/after ssthresh .

When a packet is lost, generally TCP requires a long time to recover its maximumtransmission rate. Using the periodic model [21], we can calculate the recovery time (rt) using the followingformula.

rt= bandwidth × RTT 2 2 packetsize
(1)

For example, let us suppose that the bandwidth is 11 Mbps, the packet size is 1000Bytes, and the round-trip time is 100 ms. Then, it takes approximately 7 s for TCPto reach its maximum transmission rate after a single FRR. As the bandwidth or RTTincreases, the recovery time also increases. If the bandwidth is 54 Mbps, therecovery time becomes 34 s. In other words, a TCP connection could end without fullyutilizing the available bandwidth even from a single packet loss.

Figure 1b shows the differences of TCP’sssthresh before/after adding wireless transmission errors in thescenario. When there is no wireless losses, ssthresh does not decrease fromits initial value which is arbitrarily high (the black line in Figure 1b). But, when we add wireless losses into the simulation scenarios,ssthresh decreases sharply and frequently due to wireless losses (theyellow line in Figure 1b). ssthresh is the border forTCP to decide if it increases its transmission rate exponentially or linearly aftera packet loss. As ssthresh becomes smaller, TCP enters earlier the phase tolinearly increase its transmission rate. As a result, the recovery time from a losssignificantly increases.

Figure 1c shows the packet sequence number before/after an RTOexpires. In the figure, each dot indicates the sequence number of a data packetwhich is received at the time shown in x-axis, For example, two datapackets arrived at a TCP receiver in order at 153.14 s. Also, we can see that twoout-of-order packets are received at 153.16 s. After 1.2 s of the idle time, an RTOis expired at 154.34 s and 8 packets are retransmitted until 154.67 s.

Such retransmissions are necessary only when those packets are lost. However, if theRTO is triggered by sudden delay and the data packets are still in transit or in thequeue, the retransmissions might be just a waste of time and bandwidth. Also, suchunnecessary retransmitted packets could create a new series of duplicate ACKs thatcan be long enough to cause another FRR.

Figure 1d shows the case when three successive RTOs aretriggered due to wireless losses in the scenario. At about 39 s, the first RTO istriggered, and the second and the third RTOs are triggered at 43 and at 51 s,respectively. TCP sender’s waiting time in each RTO is approximately 2, 4, and8 s due to TCP’s back-off mechanism. During the idle time, a TCP sender cannotsend any data packets wasting available bandwidth and time. If RTOs are triggeredregardless of congestion, a TCP sender does not need to perform its back-offmechanism, and should retransmit the lost packets as soon as possible since thenetwork is not congested.

As shown in Figure 1, TCP’s FRRs/RTOs do not work anymoreas they were originally intended to when they are triggered regardless ofcongestion. Such congestion irrelative FRRs/RTOs are the main cause of TCP’sperformance degradation in wireless networks. To avoid such performance degradation,TCP needs to know the cause of FRRs/RTOs, and should respond to each of FRRs/RTOsdifferently according to the causes.

Here, we classify FRRs/RTOs into three types according to the causes: congestionFRRs/RTOs, spurious FRRs/RTOs, and wireless FRRs/RTOs.Congestion FRRs/RTOs are those FRRs or RTOs triggered by congestion losses (packetsare lost due to congestion), spurious FRRs/RTOs [5, 6, 22] are those FRRs or RTOs triggered by sudden delay without any packetlosses, and wireless FRRs/RTOs are those FRRs or RTOs triggered by wireless losses(packets are lost due to wireless transmission errors). Among the three types,congestion FRRs/RTOs are conventional FRRs/RTOs, and both wireless and spuriousFRRs/RTOs are the congestion irrelative FRRs/RTOs.

Related study and motivation

Since TCP’s FRRs/RTOs [2, 4] are originally designed to control congestion, their behaviors are notappropriate if they are triggered regardless of congestion. In case of wirelessFRRs/RTOs, it might be necessary for TCP to perform go-back-Nretransmissions, but TCP should not reduce sharply its transmission rate and doesnot need to increase exponentially its back-off value since the network is notcongested. In case of spurious FRRs/RTOs, even the retransmissions are unnecessarysince the FRRs/RTOs could have been avoided if a TCP sender had waited longer.

Unfortunately, TCP has no ability to distinguish the cause of an FRR or an RTO. Itresponds to all FRRs/RTOs blindly by reducing sharply the transmission rate and byincreasing the back-off value unnecessarily. Thus, it is unavoidable for TCP tounderutilize available bandwidth and its performance degrades severely in wirelessnetworks.

To date, many previous studies have been proposed to solve such TCP’s problemin wireless networks. Some loss differentiation schemes such as Westwood [8], JTCP [9], and RELDS [10] have been proposed to detect wireless FRRs/RTOs. These schemesdistinguish wireless losses from congestion losses, and let TCP avoid reducingunnecessarily its transmission rate when any of FRRs/RTOs are triggered by wirelesslosses.

To detect spurious FRRs/RTOs, several schemes have been proposed such as Eifel [1113], F-RTO [14, 15], and STODER [16]. These schemes are very effective in detecting spurious RTOs, and theyhelp TCP avoid unnecessary retransmissions caused by spurious RTOs. The commonproblem of the above schemes is that they paid little attention on adjusting thetransmission rate appropriately when spurious or wireless FRRs/RTOs are detectedeven though controlling appropriately the transmission rate is critical in improvingTCP’s performance.

In case of TCP Westwood [8] and Prairie [18], they dynamically estimate the available bandwidth, and adjust thetransmission rate by updating ssthresh and cwnd to the largevalues in proportion to the estimated available bandwidth. They have moresignificant impact on improving TCP’s performance compared to the otherprevious studies. Unfortunately, updating cwnd and ssthresh tolarge values does not always improve TCP’s performance. If the loss rate dueto wireless errors is high, a large cwnd could have a high possibility tohave frequent burst losses as well as to have long go-back-Nretransmissions compared to a small cwnd. Thus, if the packet loss rate ishigh, a small cwnd could be better to improve TCP’s performance.

To confirm our claim, we conducted a simple experiment using a simulation scenario tocheck the impact of cwnd’s size when the rate of wireless errors ishigh. The scenario is designed to have only wireless losses, and the rate of packetlosses due to wireless errors is approximately 5%. In each simulation, we justlimited the maximum size of cwnd and measured the performance using thesame scenario. Figure 3 shows the result. The graph simplyshows that the performance degrades as the value of cwnd increases. Whileit is well known that TCP’s performance improves significantly whencwnd is proportional to the available bandwidth, this experiment showsthat it is also necessary to make cwnd be smaller when the rate of packetlosses is high.

Figure 3
figure3

Performance according to cwnd ’s maximum size when the loss rate is 5%.

Dynamic responding algorithm

As mentioned above, it has been overlooked that cwnd needs to be smallerwhen wireless transmission errors are high. In this section, we propose an enhancedTCP to dynamically adjust its transmission rate based on the packet loss rate aswell as the available bandwidth. Since many previous studies have been proposed toestimate the available bandwidth, we use one of them, Prairie’s estimation(ABW), which is more stable and accurate than TCP Westwood’s. In this article,we describe how to estimate the packet loss rate at TCP sender side, and how toadjust ssthresh and cwnd according to the estimated bandwidth andthe estimated loss rate.

Measuring accurately the rate of packet losses caused by wireless errors is almostnot possible at transport layer. Thus, we will estimate the packet loss rate bychecking how often FRRs/RTOs are triggered since TCP invokes FRRs/RTOs wheneverpackets are lost. Although our estimation includes the rate of packet losses causedby congestion, it is useful since cwnd needs to be smaller even whenpackets are lost due to congestion.

When a k th FRR or RTO is triggered, we assume that one packet is lost andthe k th loss rate is computed based on the following formula.

Loss_rat e k = 1 partial _ total _ data _ sent ×100
(2)

where partial_total_data_sent is the number of data packets sentby a TCP sender during the time between (k−1)th FRR/RTO andk th FRR/RTO.

Since the loss rate could fluctuate under dynamic network conditions, we smooth theloss rate using the exponential weighted moving average like the following formula.

SLoss_rat e k =SLoss_rat e ( k 1 ) (1 θ k )+Loss_rat e k θ k
(3)

As θ k ranging from zero to 1 increases, SLoss _rat e k is greatly affected by the current network status. Otherwise,SLoss _rat e k is more reflecting the past estimation.

In our scheme, θ k is also dynamically determined to reflect network conditions as shown in thefollowing formula.

θ k = Interva l current Interva l max
(4)

where Interva l current is the time between (k−1)th FRR/RTO and k th FRR/RTO,and Interva l max is the maximum value of Interva l current samples. In other words, as Interva l current is larger, SLoss _rat e k reflects the current estimation greater than the past estimation.

If the loss rate is high, a large cwnd might result in burst losses or longgo-back-N retransmissions. Thus, as the loss rate increases,cwnd needs to be smaller even when the bandwidth is sufficient. Ourquestion is how much cwnd needs to be decreased as the loss rateincreases.

To find our best answer, we represent the relation between cwnd and the lossrate in a simple way as shown in Figure 4. In the figure,y-axis represents reduced_cwnd, which is the cwndreduced according to the loss rate, and x-axis represents the loss rateranging from 0 to 1. In the graph, cwnd_max denotes the possiblemaximum value of reduced_cwnd when the loss rate(Sloss_rate) is higher than 0, and β is the minimumsize of reduced_cwnd when the loss rate is higher than α.Thus, reduced_cwnd ranges from β to cwnd_max.As the loss rate (x) increases, reduced_cwnd decreases fromits maximum size (cwnd_max) according to the solid line in Figure 4. When the loss rate is higher than α,reduced_cwnd is set to its minimum size (β). This isto avoid making cwnd be smaller than one segment.

Figure 4
figure4

Relation between the loss rate and cwnd .

In the graph, “>0” means the first number higher than 0, thus, weassume it as zero and formulate the inverse proportion relation betweencwnd and the loss rate based on the two points (0,cwnd_max) and (α, β) using the belowlinear equation.

y= β cwnd _ max α × x + cwnd _ max if 0 x < α β if x α
(5)

The following is our algorithm to update cwnd and ssthreshaccording to our estimated bandwidth and loss rate.

An algorithm updating ssthresh and cwnd when a fast recovery or aRTO is triggered

1:ssthresh=ABW

2: cwnd = ssthresh / 2

3: reduced_cwnd = cwnd

4: if(SLos s rate 0)

5: reduced_cwnd = β cwnd_max α ×SLos s rate +cwnd_max

6: reduced_cwnd = max(reduced_cwnd,β)

7: end if

8: cwnd = min (cwnd,reduced_cwnd)

When an FRR or an RTO is triggered, ssthresh is updated to the estimatedavailable bandwidth (ABW) at line 1 instead of being halved. Sincessthresh is the border for TCP to decide if its transmission rateincreases exponentially or linearly, the recovery time after a packet loss isaffected by ssthresh. As ssthresh is larger, the recovery timeafter a packet loss is shorter. By setting ssthresh to ABW, itlets TCP increase its transmission rate exponentially until cwnd fullyutilizes available bandwidth.

At line 2, cwnd is updated to the halved value of ssthresh.Although a TCP sender could send data packets as much as ssthresh withoutreceiving an ACK from a TCP receiver, we update cwnd to the halved value ofssthresh. The reason is to avoid causing sudden congestion in a queueby a large cwnd. Since cwnd is smaller than ssthresh,cwnd will increase exponentially until it reachesssthresh.

If the loss rate is zero, cwnd is finally determined to the halved value ofssthresh at line 8. Otherwise, reduced_cwnd is calculatedaccording to Equation (5) as we mentioned before. Equation (5) is represented inlines from 5 to 6 of the algorithm. After computing reduced_cwnd,cwnd is readjusted to the minimum value between the halved value ofssthresh and reduced_cwnd at line 8. By taking the minimumvalue, it enables to avoid burst losses caused by insufficient bandwidth as well asthe high loss rate.

The following shows another algorithm to remove unnecessarily increased idle time ofan RTO.

An algorithm updating the back-off value when an RTO is triggered

1: if(BDP > the halved value ofcwnd_max)

2: initializes the back-off value

3: end if

When successive RTOs are triggered, the back-off value exponentially increases, whichincurs a huge idle time of the sender. If the network is not congested, suchunnecessarily increased back-off value will be just a severe waste of bandwidth andtime. Our scheme initializes the back-off value if the network is not congested whensuccessive RTOs are triggered. In order to check if network is congested or not, ourscheme uses the bandwidth-delay product (BDP), which is calculated by theproduct of the available bandwidth and the round trip time (it is well known thatTCP’s performance is maximized when cwnd is equal toBDP).

At line 1 in the algorithm, our scheme checks if current BDP is larger thanthe halved value of cwnd_max when an RTO is triggered. If the conditionis satisfied, we assume that the network is not congested. In that case, our schemeinitializes the back-off value in order to avoid an unnecessary idle time.

As shown in the algorithms, our scheme lets TCP respond to every FRR/RTO dynamicallyby considering the available bandwidth and the loss rate. By doing so, our schemehelps TCP avoid causing frequent burst losses while it utilizes the availablebandwidth. As a result, it has significant effects to avoid the performancedegradation caused by the congestion irrelative FRRs/RTOs.

If we use a quadratic equation instead of the linear equation in (5), it would bebetter to adjust the transmission rate more appropriately, but it could cause moreoverhead of the complexity. In order to avoid such overhead, we used the linearequation in (5). Compared to the conventional TCP, our scheme does more computationsto control its transmission rate according to the network conditions. The complexityoverhead of our scheme is based on the simple linear equation in (5). Since thevalue of x in the equation ranges from 0 to 1, the computation in theequation is simple and the overhead is reasonable.

To maximize the performance enhancement of our scheme, we conducted extensiveexperiments to find the best value for α, β, andcwnd_max, and the results will be shown in the followingsection.

Experimentation and analysis

In this section, we observe how our scheme adjusts the transmission rate per FRR orRTO, and evaluate our scheme in terms of goodput, fairness, and friendliness using anetwork simulator, QualNet [17]. For this, we design more than 100 different simulation scenarios bysetting different values of network parameters such as the loss rate, and the hopcount under various network topologies. Table 1 shows thedetailed parameters used in our simulation scenarios. We used TCP Reno asconventional TCP and its congestion window size is limited to hold 50 packets. Inall experiments, each scenario lasts about 200 s, and data packets of TCP arecontinually transmitted during the simulation time.

Table 1 Simulation parameters

Each scenario has wireless losses as well as congestion losses. To make congestionlosses, we increased the number of TCP flow gradually like 1, 3, 6, 12, 15, 18, and21 flows between the sender and the receiver. As the number of TCP flow increases,the loss rate due to congestion also increases. To incur wireless losses, we addedwireless transmission errors at the wireless link using QualNet’s faultinterface. The packet loss rate in the scenarios ranges from 0 to 15%, and theratio of wireless losses to congestion losses is approximately one of 1:0, 2:8, 3:7,4:6, 5:5, 6:4, 7:3, 8:2, 0:1 in a scenario.

Throughout the extensive scenarios, we aim (1) to observe how often congestionirrelative FRRs/RTOs are triggered, (2) to suggest the best values forα and β in our algorithm, (3) to check if our schemeworks as we intended, (4) to measure the performance enhancement of our scheme andcompare it with previous studies, (5) to evaluate our scheme’s fairness andfriendliness.

Three types of FRRs/RTOs

In our experiment, we observed how often congestion irrelative FRRs/RTOs aretriggered in a simple topology shown in Figure 5a. Thesimple topology consists of two nodes and a base station. S denotes thesender, and D denotes the receiver. S connects to the basestation via a 10-Mbps wired link with 10-ms propagation delay, and the basestation is linked to D via a 2-Mbps wireless link with 1-ms propagationdelay.

Figure 5
figure5

Three types of FRRs/RTOs.

And we modified QualNet’s source code to trace all the packet informationrelated to the triggered FRRs/RTOs into trace files in a scenario. During eachscenario simulation, we traced all information of the packets dropped at MACLayer into a file named by “DroppedAtMac”, traced all the packetsdropped at network layer into “DroppedAtNetwork”. Also, we tracedall the packets which triggered FRRs or RTOs at Transport layer into“FRRatTransport” or “RTOatTransport”, respectively.

When the simulation ends, we checked if each packet at“FRRatTransport” or “RTOatTransport” exists at“DroppedAtMac” or “DroppedAtNetwork”. If a packet of“FRRatTransport” exists at “DroppedAtMac”, we assumedthat the FRR is triggered due to wireless errors, and we treated it as wirelessFRRs. If the packet is found at “DroppedAtNetwork”, we assumed thatthe FRR is triggered due to congestion, and we treated it as congestion FRRs. Ina similar way, if a packet of “RTOatTranport” exists at“DroppedAtMac”, we treated the RTO as wireless RTOs. If the packetis found at “DroppedAtNetwork”, we treated the RTO as congestionRTOs. Lastly, if the packet is not found either at “DroppedAtMac” or“DroppedAtNetwork”, we assumed that the FRR or the RTO is triggeredby sudden delay, and we treated it as spurious FRRs or RTOs.

Figure 5 shows the results of our observation. In Figure5b, each of CRTO, WRTO, and SRTO representscongestion, wireless, and spurious RTOs, respectively, and the ratio of each ofthem is shown in a solid line bar graph. Each of CFRR, WFRR, and SFRR representscongestion, wireless, and spurious FRRs, respectively, and the ratio is shown ina dashed line bar graph.

For example, when the loss rate is 3% and the ratio of wireless losses tocongestion losses is 7:3, 44 RTOs are triggered in a scenario, and each ratio ofcongestion and wireless RTOs is, respectively, 11 and 89% among 44 RTOs. Incase of FRRs, 28 FRRs are triggered, and each ratio of congestion, wireless, andspurious FRRs is 61, 18, and 21%, respectively.

In Figure 5b, we can see that as congestion increases (tothe right direction in the figure), the ratio of CRTO or CFRR increases. On theother hand, as the ratio of wireless losses increases (to the left direction),the ratio of congestion irrelative FRRs/RTOs increases. In either case, however,the ratio of congestion irrelative FRRs/RTOs is always higher than 30%. Ifwe consider the fact that most packets are lost due to wireless transmissionerrors in wireless networks, the ratio of congestion irrelative FRRs/RTOs mightbe much higher than 30% in real networks.

Figure 5c shows the number of retransmitted packets in ascenario according to the loss rate, and also shows the ratio of“unnecessary” retransmitted packet among all the retransmittedpackets. For example, when the packet loss rate is 1% and the ratio ofwireless losses to congestion losses is 0:1 in a scenario, 727 packets areretransmitted (in Figure 5c), and 30% of them areunnecessarily retransmitted (in Figure 5d). From the twographs, we can see that, as the ratio of wireless losses increases, the ratio of“unnecessary” retransmitted packet significantly increases. In theworst case, almost 90% of retransmitted packets are unnecessarilyretransmitted.

Testing for α and β

Whenever an FRR/RTO is triggered, our scheme updates cwnd andssthresh according to the linear equation (5) as described in“Dynamic responding algorithm” section. The slope of the equationrepresents the degree of reduction in cwnd according to the loss rate,and that is determined by α, β, andcwnd_max.

To find the best values for α,β, andcwnd_max, we tested various values between the lower bound andthe upper bound of each variable. For β, which is the minimum sizeof cwnd, we tested the values ranging from one segment to the halvedsize of the maximum value of cwnd, which is 65535 in conventional TCP.For α, which is a threshold to prevent cwnd from beingsmaller than β, we tested the values ranging from 0.1 to 10%.For cwnd_max, which is the possible maximum value ofreduced_cwnd, we tested the values ranging from 10000 to themaximum value of cwnd, 65535.

After testing various values, we chose the strong candidates for the values, andagain conducted experiments to see the best combination. Figure 6a,b shows the results. First, Figure 6a showsthe performance comparison according to α and β whencwnd_max is fixed to 65535. In the figure, we chose the strongcandidates of the combinations of α and β. Afterthat, in Figure 6b, we tested various values forcwnd_max with the strong candidates of α andβ. The result shows that the performance is the best whenα, β, and cwnd_max is 0.5%,10000 bytes, and 25000 bytes, respectively. Namely, while cwnddecreases linearly as the loss rate increases based on the equation, theseparameters indicate that (1) if the loss rate is higher than zero, cwndcannot be higher than 25000, and (2) if the loss rate is higher than 0.5%,cwnd cannot be smaller than 10000. The following results in thisarticle are based on these values.

Figure 6
figure6

Testing values for α and β .

Comparison of responding behaviors to FRRs/RTOs

Using a simple scenario, we observed if our scheme responds to packet losses aswe intended, and also compared our scheme’s response with conventionalTCP’s response. In the scenario, only one TCP connection flows from thesource to the destination in the simple topology. Thus, packets are lost onlydue to wireless transmission errors and the loss rate is about 5%.

In Figure 7a,b, we compared the variations of cwndbetween TCP and our scheme during the go-back-N retransmissions afteran RTO expires in the scenario. In Figure 7a, TCP’scwnd becomes one segment (1024) at 54.70 s when an RTO istriggered, and ssthresh reduces into 5120. Whenever an ACK is received,cwnd increases gradually, and it is finally set to 6480 at 54.87 swhen the retransmissions end. On the other hand, our algorithm’sssthresh becomes 132811 at 54.70 s by reflecting the availablebandwidth. And, its cwnd becomes about 11024 at 54.75 s by reflectingthe available bandwidth and the loss rate. When the retransmissions end,cwnd of our scheme is set to 10000 at 54.82 s.

Figure 7
figure7

Comparison of response to FRR and RTO.

During the go-back-N retransmissions of the RTO, TCP retransmitted 13packets and also our scheme retransmitted 13 packets. We checked how much timeit took to retransmit the packets in each scheme. In case of TCP, it took 0.158s to retransmit 13 packets, and in case of our scheme it took 0.114 s toretransmit the same number of packets. This shows that our scheme recovered fromthe loss faster than TCP by avoiding reducing unconditionally cwnd andssthresh.

Figure 7c,d shows the differences between TCP’s res-ponse and our scheme’s response when an FRR is triggered. In each graph,the variations of cwnd/ssthresh are represented. In Figure7c, TCP sends the lost packet, which triggered theFRR, at 27.44 s, and it increases cwnd by one segment whenever aduplicate ACK is received until 27.49 s. When a new ACK is received,cwnd is set to the halved value (5245) at 27.57 s.

Our scheme’s response is similar with that of TCP until a new ACK isreceived as shown in Figure 7d. When a new ACK isreceived, our scheme does not blindly halve cwnd, but it updatescwnd according to the available bandwidth and the loss rate. As aresult, our scheme’s cwnd is similar with the previouscwnd (12631).

In Table 2, we compared how many FRR or RTOs are triggeredin the scenario in each response. As shown in the table, when every packet lossis responded by the conventional way of TCP, 711 data packets are retransmitted,and 56 RTOs/82 FRRs are triggered. However, when all the packet losses areresponded by our scheme, only 419 data packets are retransmitted, and 32 RTOs/82FRRs are triggered in the same scenario. This table shows that our scheme couldreduce the number of the congestion irrelative FRRs/RTOs, and the number ofunnecessarily retransmitted packets by responding appropriately to the triggeredFRRs/RTOs according to the network conditions. As a result, our scheme’sperformance reached 148% of TCP’s performance in the scenario.

Table 2 Comparison of TCP and the proposed scheme

Comparison of back-off mechanism

We compared the variations of the back-off value when each of TCP and our schemeis applied to a scenario in the simple topology. In the scenario, there are 10connections between the sender and the receiver, and the loss rate is about10% (the ratio of wireless losses to congestion losses is 3:7). In Figure8a, TCP’s back-off value reaches 32 in the worstcase, while our scheme’s back-off value reaches 8 in the same scenario. Asthe back-off value increases, the waiting time for the sender to trigger an RTOexponentially increases.

Figure 8
figure8

Comparison in the back-off value.

We checked how much time the sender spent time on waiting to trigger RTOs. Figure8b shows the packet sequence number around when theback-off value reaches 32 in the scenario. As shown in the figure, successiveRTOs are triggered at 105.36, 108.76, 115.26, 127.65, and 151.30. In each RTO,the sender’s waiting time increases exponentially like about 2, 3, 6, 12,and 24 s. In other words, a TCP sender wastes 47 s during the time from 103 to151 s in the scenario.

Such back-off mechanism is necessary only when congestion is heavy. Otherwise, itjust wastes time and bandwidth. We checked the queue usage to see if there washeavy congestion when the back-off value reached 32. Figure 8c shows the queue usage during the time from 115 to 124 s beforethe last successive RTO is triggered. As shown in the figure there is nocongestion until 119 s. After 119 s, the queue usage is getting full and then itis almost empty at about 120 s. During the idle time of a TCP sender assumingthat the network is severely congested, the queue usage is not always high, andit changes dynamically by other TCP connections. Consequently, such longback-off value was unnecessary to a TCP sender.

Our scheme does not increase blindly the back-off value when successive RTOs aretriggered. It increases the back-off value only when the network is assumed tobe congested. For this, our scheme checks if BDP is larger than thehalved value of cwnd_max as we mentioned before. If it is, itinitializes the back-off value assuming the network is not congested. This iswhy the back-off value of our scheme is lower than that of TCP in Figure 8a. As a result, our scheme can remove unnecessary idle timeof the sender and it outperforms TCP significantly.

Performance evaluation

We evaluated the performance of our scheme under various topologies, and comparedit with the previous studies such as F-RTO [14, 15], JTCP [9], and Prairie [18]. F-RTO is one of previous schemes to detect spurious RTOs, JTCP isone of previous schemes to detect wireless FRRs/RTOs, and Prairie is one ofprevious schemes to respond FRRs/RTOs according to available bandwidth.

Figure 9 shows the results in the simple topology. Thegraph in Figure 9a is from the scenarios when allFRRs/RTOs are triggered regardless of congestion. In the graph, we compared thetwo performances of TCP Reno and our scheme according to the loss rate. As shownin the graph, there is no difference when the loss rate is 0%. However, asthe loss rate increases, our scheme outperforms significantly TCP. For example,when the loss rate is 1%, our scheme’s performance is 106% ofTCP’s. And, when the loss rate is 6%, our scheme’s performanceis 148% of TCP’s.

Figure 9
figure9

Results in a simple topology.

In Figure 9b, we checked the performance variations of ourscheme according to the ratio of wireless losses to congestion losses. The graphis from the scenarios whose loss rate is 5% and the ratio of wireless lossesto congestion losses is 1:9, 2:8, or 8:2. It shows that the performanceenhancement is significantly different according to the ratio of wireless lossesto congestion losses even though the loss rate is the same (5%). Forexample, when the ratio is 1:9 (congestion losses are much higher), theenhancement is 6%. However, when the ratio is 8:2 (wireless losses are muchhigher), the enhancement is about 32%. This observation shows that ourscheme’s performance is better as the ratio of the congestion irrelativeFRRs/RTOs increases.

We also evaluated the performance of our scheme in a more complex dumbbelltopology shown in Figure 10. In the figure, TCP trafficsflow from left to right while UDP traffics flow from right to left. TCP’spacket sizes are fixed to 1000 bytes (UDP’s 512 bytes), and TCP receiversalways follow the delayed ACKs algorithm as well as the Nagle algorithm. Wedesigned about several hundreds of scenarios by changing the values, n,m, the bandwidth (b w1,b w2), the propagation delay (p1,p2), and the wireless fault rate (fault) (n rangingfrom 1 to 12, m from 1 to 10, b w1 is one of 10/100 Mbps, b w2 is one of 1/2/5/11 Mbps, p1 is one of 5/10/30/60/90 ms, p2is 1 ms, wireless transmission errors (fault) occurs one of0/5/15/30/45/60/75 times during a 200-s simulation).

Figure 10
figure10

A dumbbell topology.

In Figure 11a, b, c, d, we measured and compared theperformances of the schemes according to the loss rate, the number of reversetraffic, and the propagation delay. In Figure 11a, we cansee that Prairie’s performance severely degrades as the loss rateincreases while our scheme shows the highest performance. And we counted thenumber of unnecessarily retransmitted packets according to the loss rate inFigure 11b. As shown in the graph, our scheme has thelowest unnecessary retransmission while the unnecessary retransmission inprevious schemes increases gradually according to the loss rate. Even when thereverse traffic/the propagation delay increases, our scheme shows betterperformance compared to the other schemes as shown in Figure 11c, d. This is because our scheme has an ability to adjust thetransmission rate dynamically and appropriately according to the networkconditions.

Figure 11
figure11

Performance comparison.

Lastly, we evaluated our scheme under a multi-hop wireless network. Figure 12a shows a 4-hop chain topology of IEEE 802.11b wirelessnodes. The bandwidth of the wireless link is 11 Mbps with 1-ms propagationdelay. In this topology, we observed if the performance enhancement of ourscheme degrades or not as the number of hops increases.

Figure 12
figure12

Results in a chain topology.

Figure 12b shows the result in the chain topology. Thegraph shows that our scheme’s performance is the highest among theprevious studies, and its performance increases according to the number of hops.This is because as the number of hops increases, the ratio of the congestionirrelative FRRs/RTOs increases due to sudden delay or high wireless errors andour scheme has advantages to handle such FRRs/RTOs.

Throughout the three different topologies, we evaluated our scheme and comparedit with the previous studies. The results consistently showed that our schemehas the highest performance among the previous studies, and its performance isbetter as the ratio of the congestion irrelative FRRs/RTOs increases.

Fairness and friendliness

In order to assess the ability of our scheme in allowing a fair distribution ofbandwidth, we also evaluated our scheme in terms of fairness and friendliness.The network topology used in this simulation experiment is the single-bottleneckdumbbell topology as shown in Figure 13.

Figure 13
figure13

A simple dumbbell topology.

Fairness is the bandwidth allocation measure for the multiple connections of the“SAME” TCP. To evaluate the fairness, we use the fairness indexmentioned in [23]. The fairness index is calculated using the following formula.

Fairness= ( x i ) 2 n ( x i 2 )
(6)

where x i is the throughput of the i th connection, and n is thenumber of the same TCP connections. The fairness index ranges from 1/nto 1.0; a perfectly fair bandwidth allocation results in a fairness index of 1,and if all bandwidth are consumed by one connection, it results in1/n.

TCP Reno is well known to get fair network capacity. In this experiment, wemeasured the fairness of our scheme and compared it with that of TCP Reno.Figure 14a shows the fairness of TCP Reno and that of ourscheme according to the number of the same connections. For example, when twoTCP Reno connections are running from the source to the destination in Figure13, the fairness of two TCP Reno connections is about0.995. And, when two connections of our scheme are running, our scheme’sfairness is about 1. Although the fairness index of our scheme tends tofluctuate according to the number of connections, it is very similar withTCP’s fairness index and the values are higher than 0.986 even when manyconnections compete one another. It means that our scheme as well as TCPachieves satisfactory fairness index.

Figure 14
figure14

Fairness and friendliness.

To check if our scheme is able to coexist friendly with other TCP connectionssuch as TCP Reno, we did some simulations. First, we evaluated how oneconnection of our scheme influences on one TCP Reno connection. Figure 14b shows the result. “TCP1 TCP2”shows the throughput of each of two TCP Reno connections when the two Renoconnections compete with each other. For example, the throughput of one TCPconnection is 1,308,284 Bytes, and the throughput of the other TCP connection is1,427,256 Bytes. “Dynamic1 Dynamic2” shows the throughputof each connection of our scheme when two connections of our scheme compete witheach other. “TCP Dynamic” shows the throughput of each whenone TCP Reno competes with one connection of our scheme.

If we compare the throughput of TCP1 in “TCP1 TCP2”with that of TCP in “TCP Dynamic”, we can see thatTCP Reno’s performance does not degrade due to the connection of ourscheme. It means that our scheme is very friendly to TCP Reno while itoutperforms TCP Reno.

Using more connections, we checked if the connections of our scheme can coexistwith TCP Reno in a friendly way. Table 3 shows anotherresult when ten connections of TCP Reno and our scheme are running from thesource to the destination in Figure 13. The first and thesecond columns in the table show the number of TCP Reno connections and that ofour scheme’s connections, respectively, among the ten connections. Thethird and the forth columns show the average throughput of each scheme. Forexample, when three TCP Reno connections compete with seven connections of ourscheme, the average throughput of TCP Reno is 284,701 Bytes, and that of ourscheme is 317,354 Bytes. In this table, we can also see that our scheme isfriendly to TCP Reno while it outperforms TCP Reno.

Table 3 Friendliness between two different TCP variants

Conclusion

In wireless networks, TCP’s performance significantly degrades since itscongestion control algorithms (FRRs and RTOs) are often triggered regardless ofcongestion. To avoid such performance degradation, we proposed an enhanced TCP todynamically adjust the transmission rate based on the available bandwidth and theloss rate. When an FRR/RTO is triggered, our scheme adjusts the transmission rate inproportion to the available bandwidth, and also re-adjusts it in inverse proportionto the loss rate. By doing so, our scheme has significant effects to avoid theperformance degradation caused by the congestion irrelative FRRs/RTOs.

Throughout the extensive experiments, we showed that our scheme significantlyoutperforms previous studies while it maintains the fair and friendly behavior toother TCP connections. Specially, as the number of the congestion irrelativeFRRs/RTOs increases, our scheme showed better performance compared to the otherschemes. Since our scheme requires only sender-side modification of TCP, it does notneed any support either from the receiver side or from the intermediate nodes. Thus,it is convenient to deploy our scheme in wireless networks to improve TCP’sperformance.

References

  1. 1.

    Wright GR, Stevens WR: TCP/IP illustrated, Volume 2, The Implementation. (Addison Wesley, Reading, MA, 1995), pp. 891–1025

  2. 2.

    Allman M, Paxson V, Stevens W: TCP congestion control, RFC2581 (1999),. . Accessed 29 August 2012 http://tools.ietf.org/html/rfc2581

  3. 3.

    Stevens WR: TCP/IP Illustrated, Volume 1, The Protocols. (Addison Wesley, Reading, MA, 1994), pp. 223–274

  4. 4.

    Paxson V, Allman M: Computing TCP’s retransmission timer, RFC2998 (2000),. . Accessed 29 August 2012 http://tools.ietf.org/html/rfc2988

  5. 5.

    Gurtov A: Effect of delays on TCP performance. Proc. IFIP TC6/WG6.8 Working Conference on Emerging Personal WirelessCommunications, vol. 195 (Lappeenranta, Finland, August 2001), pp. 87–108

  6. 6.

    Gurtov A, Ludwig R: Responding to spurious timeouts in TCP. Proc. 22th Joint conference of the IEEE Computer and Communications, vol.3 (San Francisco, USA, March 2003), pp. 2312–2322

  7. 7.

    Wang J, Zhou M, Li Y: Survey on the end-to-end internet delay measurements. Proc. of 7th IEEE International Conference on High Speed Networks andMultimedia Communications, LNCS vol.3079, Toulouse, France (Springer-Verlag, Toulouse, 2004), pp. 155–166

  8. 8.

    Yang G, Wang R, Gerla M, Sanadidi MY: TCPW bulk repeat. Comput. Commun 2005, 28(5):507-518.

  9. 9.

    Wu EH-K, Chen M-Z: JTCP: jitterbased TCP for heterogeneous wireless networks. IEEE J. Sel. Areas Commun 2004, 22(4):757-766.

  10. 10.

    Lim C-H, Jang J-W: Robust end-to-end loss differentiation scheme for transport control protocolover wired/wireless networks. IET Commun 2008, 2(2):284-291.

  11. 11.

    Ludwig R, Katz RH: The Eifel algorithm: making TCP robust against spurious retransmissions. ACM SIGCOMM Comput. Commun. Rev 2000, 30(1):30-36.

  12. 12.

    Ludwig R, Meyer M: The Eifel detection algorithm for TCP, RFC3522 (2003),. . Accessed 29 August 2012 http://tools.ietf.org/html/rfc3522

  13. 13.

    Ludwig R, Gurtov A: The Eifel response algorithm for TCP, RFC4015 (2005),. . Accessed 29 August 2012 http://tools.ietf.org/html/rfc4015

  14. 14.

    Sarolahti P, Kojo M, Raatikainen K: F-RTO: an enhanced recovery algorithm for TCP retransmission timeouts. ACM SIGCOMM Comput. Commun. Rev 2003, 33(2):51-63.

  15. 15.

    Sarolahti P, Kojo M: Forward RTO-recovery (F-RTO): an algorithm for detecting spuriousretransmission timeouts with TCP and the stream control transmissionprotocol (SCTP), RFC4138 (2005),. . Accessed 29 August 2012 http://tools.ietf.org/html/rfc4138

  16. 16.

    Tan K, Zhang Q, Zhu W: STODER: a robust and efficient algorithm for handling spurious retransmittimeouts in TCP. Proc. IEEE Global Telecommunications Conference, vol. 6 (St. Louis, USA, December 2005), pp. 3692–3696

  17. 17.

    SCALABLE Network Technologies: PRODUCTS QualNet, . Accessed 29 August2012 http://http://www.scalable-networks.com/ . Accessed 29 August2012

  18. 18.

    Parvez N, Hossain E: TCP Prairie: a sender-only TCP modification based on adaptive bandwidthestimation in wired-wireless networks. Comput. Commun 2005, 28(2):246-256.

  19. 19.

    Tung L-P, Shih W-K, Cho T-C, Sun YS, Chen MC: TCP throughput enhancement over wireless mesh networks. IEEE Commun. Mag 2007, 45(11):64-70.

  20. 20.

    Fu Z, Zerfos P, Luo H, Lu S, Zhang L, Gerla M: The impact of multihop wireless channel on TCP throughput and loss. 22th Annual Joint Conference of the IEEE Computer and CommunicationsSocieties (INFOCOM2003), vol. 3 (San Francisco, USA, March 2003), pp. 1744–1753

  21. 21.

    Hassan M, Jain R: High Performance TCP/IP Networking: Concepts Issues, and Solutions. (Pearson/Prentice Hall, New Jersey, USA, 2004), pp.125–151

  22. 22.

    Zhu YJ, Jacob L: On making TCP robust against spurious retransmissions. Comput. Commun 2005, 28(1):25-36.

  23. 23.

    Aggarwal A, Savage S, Anderson T: Understanding the performance of TCP pacing. Nineteenth Annual Joint Conference of the IEEE Computer and CommunicationsSocieties (INFOCOM 2000), vol. 3 (Tel Aviv, Israel, March 2000), pp. 1157–1165

Download references

Acknowledgments

This research was supported by Basic Science Research Program through theNational Research Foundation of Korea(NRF) funded by the Ministry of Education,Science and Technology(2012R1A1A2043531).

Author information

Correspondence to Sang-Hwa Chung.

Additional information

Competing interest

The authors declare that they have no competing interests.

Authors’ original submitted files for images

Rights and permissions

Reprints and Permissions

About this article

Keywords

  • Loss Rate
  • Transmission Rate
  • Packet Loss
  • Transmission Control Protocol
  • Packet Loss Rate