Simulation Study of TCP Eifel Algorithms Ye Guan, Bart Van den Broeck, Jan Potemans1, Johan Theunis, Dagang Li Emmanuel Van Lil, Antoine Van de Capelle Networking Group, TELEMIC-ESAT K.U.Leuven B-3001 Heverlee, Belgium E-mail:
[email protected] Abstract Recent researches on TCP performance show that spurious timeouts due to an unexpected delay increase can considerably degrade TCP performance. When experiencing spurious timeouts, common TCP implementations misjudge the long delay as an indication of packet loss and prematurely resort to loss recovery. To diminish the consequent penalty, the TCP Eifel algorithms have been introduced to detect the occurrence of spurious timeouts and properly revert to the congestion control status. In this work, we extend the OPNET TCP model with both the Eifel detection and response algorithms, compare simulation results among different TCP flavors, and present a deep investigation on how the Eifel algorithms improve TCP performance under spurious timeouts.
spurious timeouts. These schemes normally consist of detection of spurious timeouts and response to compensate performance loss. They rely on individual TCP extensions or continuous observations on the ACK sequence to realize their functionality. In this work, we mainly focus on TCP Eifel algorithms and we present a simulation-based study on how the spurious timeout degrades and the Eifel algorithms guard TCP performance against spurious timeouts. The remainder of this paper is organized in the following way: in Section I, the general TCP behavior under the spurious timeout is enumerated. The details of Eifel algorithms are introduced in Section II, as well as a comparison with other mechanisms. Section III and IV are the simulation design and corresponding result analysis. The conclusion is made finally.
Introduction To maintain a smooth end-to-end data transfer, TCP [1,2] keeps sensing the link congestion status and inferring its capacity by interpreting the information explicitly or implicitly contained in received acknowledgements (ACKs). Designed for this purpose, TCP ACKs carry the feedback of segment reception, which indicates how much data has been received and how much is still in flight. Moreover, ACK arrivals also convey time information to help TCP measure the experienced round-trip time (RTT) and estimate the retransmission timeout (RTO) interval to count for the next ACK arrival.
I. TCP Behavior over Spurious Timeouts TCP spurious timeouts are not rare in data networks. They occur when an unexpected delay spike is introduced into the end-to-end path due to heavy temporary congestion. For example, consider the case of a data burst being injected into an ACK channel. The transmission delay of a 1500 Bytes data packet is 25 times larger than that of a 60 Bytes pure ACK. The interleaving of these competitive data packets and ACKs could easily disturb the distribution of the ACK spacing. If the burst size of the data flow is large enough, TCP will very likely run into RTO before an expected ACK arrives. According to [4] spurious timeouts in the wireless networks can also be triggered by channel handovers, priority preemption, or radio coverage holes.
Although the RTO estimation is designed to be conservative so as to avoid as many premature retransmissions as possible, it could fail to cope with sudden delay increases. Being met in either the data channel or the ACK channel, such delay spikes, if large enough, can seriously delay a coming ACK, make TCP’s retransmission timer expire, and deceive TCP into RTO-based loss recovery and enter into slow start to retransmit the “seems-to-be-lost” segment. Since the original ACK will eventually arrive, the retransmission is actually unnecessary. This kind of RTO event is called “spurious timeout”.
The general TCP behavior under spurious timeouts is multifold: (1) After the spurious timeout the late-arrived ACKs can encourage TCP to retransmit all the outstanding segments, which may all have been correctly received by the TCP receiver. This “Go-Back-N” (GBN) retransmission behavior leads to the waste of the rare network resources.
The spurious timeout and its consequences can lead to a serious decrease of TCP performance since they disturb the end-to-end synchronization on which TCP relies to maintain its reliable data transfer. This phenomenon has been studied in early research work [3,4] and several solutions have been presented to improve TCP performance against spurious timeouts. Among them, TCP Eifel [3,5,6], DSACK [7,8], and F-RTO [9] are the major proposals to diminish the impacts of
(2) Each redundantly retransmitted segment will be responded to with a duplicate ACK by the TCP receiving side. Fast retransmit in turn can be triggered if the number of duplicate ACKs accumulates over the fast retransmit threshold (normally 3). (3) After the spurious timeout TCP starts the slow start. Each original ACK received in the slow start will trigger out 2 or 3 segments, more than the number of packets which have actually left the pipe. This behavior is a violation of the TCP “packet conservation” principle [10].
1
Jan Potemans is Research Assistant of the Fund for Scientific Research Flanders (FWO-Vlaanderen), Belgium 1
x 10
5
TCP Sequence Evolution
3
x 10
5
TCP Sequence Evolution
3
rcvd ack
x 10
sent seg
5
TCP Sequence Evolution
3
rcvd ack
x 10
5
TCP Sequence Evolution
3
rcvd ack
rcvd ack
sent seg
sent seg (2)
sent seg (4)
(4)
(2)
2.5
2.5
2.5
(2)
(2) (3)
(1)
18
20
(a) TCP Tahoe
2
(1) RTO retransmit (2) GBN (3) Fast retransmit (4) Fast recovery
22
1.5
(3)
(3)
2
(1) RTO retransmit (2) GBN (3) Fast retransmit
16
18
20
(5)
(1)
(3)
2
16
(2)
(1)
(3)
2
1.5
2.5
(2)
(1)
(1) RTO retransmit (2) GBN (3) Fast retransmit (4) Fast recovery (5) PACK retransmit
(1) RTO retransmit (2) GBN (3) No fast retransmit
22
1.5
16
(b) TCP Reno
18
20
(c) TCP SACK
22
1.5
16
18
20
22
(d) TCP NewReno
Figure 1, Performance of TCP Tahoe, TCP Reno, and TCP Reno w/SACK over spurious timeout (4) ACK compression could be another by-product of a spurious timeout if the delay spike occurs in the ACK channel. It will result in a large packet burst, which seriously consumes the buffer space and could further intensify the network congestion.
the previous GBN as partial ACKs (PACK) and assumes multiple segment losses have been encountered. Each ACK for newly transmitted segments will then cause one segment retransmission until the ACK sequence number exceeds the value of snd.max [12].
The aforementioned is a general summary of what could happen after spurious timeouts. The TCP end-to-end behavior may vary from one TCP flavor to another. Figure 1 presents the different response of TCP Tahoe, Reno, SACK [11], and NewReno to a single spurious timeout (with no packet loss).
Besides the difference caused by TCP flavors, the TCP behavior after spurious timeouts may be more complicated if taking into account the packet loss. The number of packet losses and their relative positions to the delay spike could considerably randomize the outcome. This will be discussed in Section IV with extensive simulations.
As showed in Figure 1, the TCP behavior of these flavors differs on how to handle the duplicate ACKs caused by unnecessary GBN. TCP Tahoe (Figure 1a) only supports fast retransmit but no fast recovery, which results in another GBN following the previous fast retransmit each time. As the slow start threshold (ssthresh) and the congestion window (CWND) are halved after each fast retransmit ([2] equation (3)), TCP sends fewer packets than it does in the previous round and hence receives fewer duplicate ACKs afterwards. Thus, the GBN fast retransmit circle will finally be broken when the number of duplicate ACKs becomes less than 3. This behavior disagrees with the statement in [4], where the circle was believed to keep repeating in the TCP’s lifetime.
II. Solutions to Spurious Timeouts Spurious timeouts are inevitable because by no means can TCP predict and avoid the link delay spikes. Therefore, all the methods to detect the spurious timeout and compensate for the performance loss have to be a posteriori. The major difference in spurious timeout algorithms lies in how to detect a spurious timeout, which is equivalent to solving the retransmission ambiguity in many circumstances. By clarifying the retransmission ambiguity, TCP can tell whether or not data has been unnecessarily retransmitted and further conclude if a spurious timeout has happened. DSACK and TCP Eifel see to this problem in different aspects. DSACK, an extension of TCP SACK, works it out in the sequence space. It requires the TCP receiver explicitly acknowledging duplicate segments with Duplicate SACK options.
With the help of fast recovery, TCP Reno (Figure 1b) can terminate the GBN fast retransmit circle after the first round of retransmission. If the new ACK comes before the retransmission timer timeout, CWND is only halved twice totally and reduced to about one quarter of the original flightsize before the spurious timeout happens.
Alternatively, TCP Eifel tries to seek the answer in the time domain with the TCP timestamp option. If referring to how a TCP receiver should manage the timestamp echoes, TCP timestamps can be considered as an acknowledging mechanism in the time domain. The timestamp echo in the original ACK normally carries an earlier value than that in the ACK for the retransmission2. If the received echo preceded the timestamp value of the retransmission, a spurious timeout is then detected.
TCP SACK (Figure 1c) shows a minor difference with TCP Reno in response to the spurious timeout. There is no fast retransmit even after the number of duplicate ACKs exceeds the threshold of 3. According to the SACK algorithm, TCP will not feed back any SACK blocks if no segment loss or reordering is detected. TCP in turn has no idea about which segment should be retransmitted and has to wait for either the expiration of the retransmission timer or the arrivals of ACKs for new data.
2
According to [5], this statement may not be true if the timer granularity is not fine enough to distinguish the transmission delay. However, the extra processing cost in maintaining a highprecision timer should not be a problem in the contemporary technological level.
TCP NewReno (Figure 1d) could be more aggressive than TCP Reno and SACK during the spurious timeout recovery. It mistakenly interprets the ACKs for the data newly transmitted in 2
checkpoint”. To realize its functions, we modified the OPNET process model, tcp_traffic_analyzer [13], and added in the delay control utilities as needed. Currently, we only applied a constant configuration on the TCP checkpoints. More complex and stochastic attributes will be adopted to mimic the real link characteristics.
Comparing the cost and effectiveness of these two approaches, DSACK introduces less traffic overhead than Eifel does since the TCP receiver needs only replying with SACK or DSACK options upon the detection of out-of-order segments while a timestamp option has to be attached to every TCP segment and ACK for Eifel. So the application of TCP Eifel could be limited in certain bandwidth-constraint scenarios. However, the Eifel algorithms have the advantage of detecting spurious timeouts much more timely. Its decision can be made immediately when the first ACK arrives after RTO retransmission. For DSACK, it can only make the same judgment upon receiving the first duplicate ACK, which comes one RTT later than the original ACK. As a consequence of DSACK’s slow reaction, TCP may have mistakenly retransmitted several or, in the worst case, a whole window of segments before the situation is clear. Additionally, the Eifel algorithms need only modification of the sender’s source code, whereas DSACK requires changing both the sender and the receiver.
Our final network model is showed in Figure 2. In this network a file transfer session was set up from the server to the client. There was a TCP checkpoint residing on each of the data channel (server client) and the ACK channel (client server) to delay and/or drop ACKs and data segments respectively. The introduced delay was properly chosen so as to force the TCP retransmission timer to expire. Main attributes of the simulation configuration are listed in Table 1. Parameter Setting Application Profile FTP session 1MB, from SERVER to CLIENT TCP Configurations MSS Auto-assigned, 1460B default Initial CWND 2*MSS Initial ssthresh 65535 bytes RWND 32768 bytes Delayed ACK RFC 1122 TCP Flavor Tahoe, Reno, SACK TCP Ext. Options RFC 1323 SACK, timestamp RTO Estimation Karn’s algorithm Delay Control TCP Checkpoint 1 Data segment delay and/or loss TCP Checkpoint 2 ACK delay and/or loss Channel Configurations Downlink 384kbps, from Router 2 to Router 1 Uplink 64kbps, from Router 1 to Router 2 Simulation Control Simulation Time 40 seconds
F-RTO, another solution for spurious timeouts, follows a distinct rationale. By assuming that the expected ACKs will arrive soon after RTO, F-RTO delays the decision of loss recovery and waits further for two ACKs. If the first arrived ACK forwards the sender’s transmit window, TCP concludes a spurious timeout and resumes transmitting new data. If any of these two ACKs is a duplicate ACK, TCP then starts the loss recovery. 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 timeout if the packet loss and the delay spike run in the same transfer window. III. Simulation Design To study TCP behavior under spurious timeouts and the performance of the Eifel algorithms, we built our network and application model in OPNET Modeler. As explained in the previous section, it is possible to simulate spurious timeouts by introducing bursty background traffic in either the data or ACK channel to create link congestion. However, we found this method was not time-efficient enough when utilized in the simulation since it was difficult to calibrate when and where to insert the competing background traffic.
Table 1, Simulation Configuration Attributes As the core part of this work, we implemented the Eifel detection and response algorithms in the OPNET TCP model. Since all the functions of the Eifel algorithms were at the TCP sending side, only the TCP layer in the server’s protocol stack needed to be updated. Without causing any adverse effects, we slightly simplified the original algorithms by omitting all the ECN and DSACK related processes. The flowchart of our Eifel processes is illustrated in Figure 3. Our simplified Eifel algorithm consists of the following steps: When the first RTO-based retransmission is issued, 1.
Store the timestamp value of the timestamp option that will be attached to the retransmitted packet.
2.
Store the congestion control variables, including the pipesize (the maximum of current flightsize and ssthresh), smoothed RTT, and RTT variance.
3.
Retransmit the oldest outstanding segment.
Figure 2, OPNET Simulation Model For a more flexible and accurate alternative, we turned to a TCP-aware link model that can precisely delay and/or drop single or multiple TCP packets. We name this model “TCP 3
At the sending side
At the receiving side
Start
Start
Clear the spur_recv flag
Ack new data ?
to the TCP performance, the buffer size of two intermediate routers was set large enough to accommodate the maximal flightsize of data transfer, which equals to the advertised RWND. TCP checkpoints had unlimited buffer size. x 10
5
TCP Sequence Evolution
x 10
TCP Sequence Evolution
rcvd ack
Yes
First RTO retransm it ?
5
3
3
rcvd ack
sent seg
get received ts_ecr
sent seg
2.5
2.5
2
2
Yes retrans_ts > rcvd_ts_ecr ?
store recently sent ts_val in retrans_ts
Yes store congestion control status
1.5
1.5 14
16
20
22
14
16
With multiple FR
Spur_timout detected
No
18
18
20
22
Without multiple FR
store RT TM status skip G o-Back-N retransm ission
Done
No
No
Figure 4, Avoid Multiple Fast Retransmits in Loss Recovery
restore congestion control status
IV. Result Analysis To test the performance of TCP Eifel, we ran comparative simulations in three scenarios: (1) spurious timeout only, (2) spurious timeout with single packet loss, (3) spurious timeout with multiple packet losses. If not specified, the default TCP flavor in all scenarios was TCP Reno. The simulation results were collected at the FTP Server and are presented in the form of TCP sequence evolution (sent segment sequence number and received ACK sequence number) and congestion process (CWND and outstanding window size (OWIN)). The units of the horizontal and vertical axes are in seconds and bytes respectively.
Adapt RT O tim er
Done
Figure 3, TCP Eifel Implemented in OPNET Modeler When the first ACK after retransmission is received, 4.
Compare its timestamp echo with the stored timestamp value. If the newly received value is less than the stored one, a spurious timeout is detected. Launch the spurious timeout recovery with step 5 ~ 7. Otherwise, go to step 8.
5.
Skip the GBN retransmission to avoid sending more duplicate segments into the pipe.
6.
Restore TCP congestion control status. Update ssthresh with previously stored pipesize and set CWND as the sum of the current flightsize and the minimum of acknowledged bytes and the initial window (IW). Send new data if allowed by both CWND and RWND.
7.
Spurious Timeout Only In this scenario we tested several configurations with the spurious timeout in different congestion control states and on different links. The simulation results depicted in Figure 5 proved two major performance improvements contributed by TCP Eifel in this scenario. 5
x 10
5
TCP Sequence Evolution
x 10
rcvd ack sent seg
3
2
2
14
16 4
x 10
18
20
22
1.5 14 x 10
8
Additionally, we applied the conservative congestion control algorithm in OPNET according to the suggestion of [12] and [14], i.e. to disable fast retransmit during the RTO loss recovery. Without this patch, we found TCP exhibited an aggressive retransmission behavior with multiple fast retransmits experienced in the loss recovery no matter if Eifel is active. This phenomenon is depicted in Figure 4.
18
6
6
4
4
2
2
20
30
40
(a) delay spike in data channel
cwnd
0 10
20
30
40
(b) delay spike in ACK channel
Figure 5, TCP Eifel over Spurious Timeout 4
22
owin 8
cwnd
0 10
Finally, to prevent unnecessary interference of buffer overflow
20
TCP Congestion Process
10 owin
Done.
16 4
TCP Congestion Process
10
8.
rcvd ack sent seg
2.5
2.5
Adapt the retransmission timer to the latest link condition with state variables preserved in the first step when the RTT sample has been successfully made for the first new segment previously unsent.
TCP Sequence Evolution
3
Spurious Timeout with Single Segment Loss As discussed in the former section, the mixed effect of spurious timeouts and segment losses may even complicate the problem.
Firstly, the evolution of TCP segment and ACK sequences in 3.2
x 10
5
TCP Sequence Evolution 3.2 rcvd ack
3
5
TCP Sequence Evolution rcvd ack
3
sent seg
2.8
x 10
2.6
2.6
2.4
2.4
2.2
2.2
2
2
1.8
1.8
1.6
5
sent seg
2.8
x 10
x 10
16 4
18
20
22
x 10
7
4
18
20
6
5
5
4
4
3
3
2
2
1
1 20
30
(a) without Eifel algorithms
40
rcvd ack
3
0 10
sent seg
2.5
2.5
2
2
22
TCP Congestion Process
1.5 14
owin
7
cwnd
6
0 10
16
8 owin
TCP Sequence Evolution
sent seg
14
TCP Congestion Process
8
x 10
rcvd ack
3
1.6
14
5
TCP Sequence Evolution
cwnd
16 4
x 10
18
20
22
1.5 14
16 4
TCP Congestion Process
x 10
18
20
22
TCP Congestion Process
owin 6
20
30
40
24
owin 6
cwnd
4
4
2
2
cwnd
(b) with Eifel algorithms 0 10
20
30
(a) without Eifel algorithms
Figure 6, TCP Performance over Spurious Timeout with Single Segment Loss
40
0 10
20
30
40
(b) with Eifel algorithms
Figure 7, TCP Performance over Spurious Timeout with Multiple Segment Losses
Figure 5 showed that Eifel successfully eliminated the problematic GBN retransmissions caused by the spurious timeout and the descendent duplicate ACK following it. Secondly, ssthresh was restored to the original value before the spurious timeout. TCP congestion control status was adjusted in such a way that TCP transmit window could quickly reopen to its maximal size defined by RWND without experiencing the slow start and congestion avoidance. So far, all the major negative impacts of the spurious timeout were repaired.
In the following, we move on to such cases to further investigate the performance of TCP Eifel. We are only interested in the segment loss(es) preceding a delay spike. In this simulation, a single segment loss was scheduled 9 segments prior to the spurious timeout. By doing so, we made TCP launch double retransmission for the same lost segment, one was fast retransmit and another was RTO retransmission. Note that if the number of segments between the segment loss and the delay spike was less than the fast retransmit threshold, there would not be a fast retransmit and the later RTO-based retransmission must be derived from a genuine timeout, then TCP Eifel would bypass it.
There is one thing worth attention, that is, in the Eifel response algorithm the restoration measures of congestion control status can suppress the possible packet burst of data packets to a certain extent. Unfortunately, it only suits for when one or several continuous ACKs are lost. Its effectiveness could be compromised in the case of ACK compression. We observed in the simulation that the delay spike in the ACK channel (Figure 5b) led to a significant burst transmission after recovery from spurious timeout3. This was due to the long delay temporarily blocking the ACK transfer over the bottleneck link and causing the ACK sequence queued in the intermediate router (TCP Checkpoint 1 in our case). The ACK spacing was distorted and a serious ACK compression created. When finally arrived at the TCP sender, the compressed ACKs clocked out an entire window of segments one after another. [15] suggests some measures to address ACK compression, which is out of the score of this paper.
Because unable to discriminate the retransmission ambiguity, TCP without Eifel (Figure 6a) only followed the routine of the latest loss recovery based on RTO. A slow start process with the halved ssthresh was performed after the reception of the new ACK. The GBN retransmission observed in the previous scenario was automatically removed since all previously received ACKs were duplicate copies. TCP Eifel (Figure 6b) also had to return to the slow start because the new ACK cumulatively acknowledged all the outstanding data and cleared the flightsize. However, it revised the ssthresh to the flightsize in the previous fast recovery phase, which enabled TCP to probe the link capacity more quickly but also more aggressively than normal TCP could do. Spurious Timeout with Multiple Segment Losses In this scenario, we introduced more segment losses by discarding the ninth and seventh segments prior to the delay spike. TCP without Eifel (Figure 7a) exhibited the same doubleretransmission pattern as in previous cases. After the recovery
3
The phenomenon was found in TCP congestion avoidance stage. When the delay spike was introduced in the slow start stage, the burst transmission was not so obvious due to the relatively smaller CWND in this stage. 5
TCP implementations fail to do so. We also found that the Eifel algorithms alone cannot completely compensate for all the side effects of spurious timeouts, especially if ACK compression and multiple losses exist. Other patches are required to improve the overall robustness of TCP against spurious timeouts.
of the first lost segment, the second one lost was resent and recovered when TCP received the new ACK and forwarded the transmit window. Contrary to its early performance, TCP Eifel (Figure 7b) degraded TCP performance; it waited for another RTO to retransmit the second lost segment. Recall step 6 of the Eifel process, CWND restoration is restricted to the sum of the current flightsize and the minimum of the acknowledged bytes and IW (at most 4*MSS). This resulted in forwarding the transmit window by only 2 MSS in the current case. TCP could not send more than 2 MSS of new data and therefore could not collect enough duplicate ACKs afterwards to fast retransmit the second lost segment. That was why TCP had to wait until the expiration of the retransmission timer and experienced such a long delay.
Acknowledgement We are indebted to the Flemish government, which partly sponsors this research through the generic university basic research program (GBOU) "End-to-End QoS in an IP Based Mobile Network". References [1] Transmission Control Protocol, RFC 793, September 1981 [2] M. Allman, V. Paxson, and W. Stevens, “TCP Congestion Control”, RFC 2581, April 1999
Robust Recovery for Multiple Segment Losses For the problem we observed in the previous case, [6] suggests enhancing TCP Eifel with more robust loss recovery mechanisms. Based on it we tested further TCP performance combining Eifel with SACK or NewReno. We increased the number of segments loss to four before the delay spike.
[3] R. Ludwig, R. H. Katz, “The Eifel algorithm: making TCP robust against spurious retransmissions”, ACM SIGCOMM Computer Communication Review, Volume 30 Issue 1, January 2000 [4] A. Gurtov, "Effect of Delays on TCP Performance", In Proceedings of IFIP Personal Wireless Communications, August 2001
We found that SACK (Figure 8a) could not improve TCP performance because it heavily relied on the high enough number of duplicate ACKs to trigger the fast retransmit. NewReno (Figure 8b), however, took the advantage of PACKs and could quickly retransmit all the remaining lost segments after the verification of the first retransmission. 5
x 10
5
TCP Sequence Evolution
x 10
rcvd ack
3
rcvd ack
3
sent seg
2.5
2.5
2
2
1.5 14
1.5 14
16 4
18
20
22
24
16 4
TCP Congestion Process
x 10
[7] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky, “An Extension to the Selective Acknowledgement (SACK) Option for TCP”, RFC 2883, July 2000
18
20
4
4
2
2
30
(a) TCP SACK w/ Eifel
22
owin 6
cwnd
20
[8] E. Blanton, and M. Allman, “Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions”, RFC 3708, February 2004
TCP Congestion Process
owin 6
0 10
[6] R. Ludwig and A. Gurtov, “The Eifel Response Algorithm for TCP”, RFC 4015, February 2005
TCP Sequence Evolution
sent seg
x 10
[5] R. Ludwig and M. Meyer, “The Eifel Detection Algorithm for TCP”, RFC 3522, April 2003
40
0 10
cwnd
[9] P. Sarolahti, M. Kojo, K. Raatikainen, “F-RTO: an enhanced recovery algorithm for TCP retransmission timeouts”, ACM SIGCOMM Computer Communication Review, Volume 33 Issue 2, April 2003 20
30
40
(b) TCP NewReno w/ Eifel
[10] V. Jacobson, “Congestion Avoidance and Control”, ACM SIGCOMM Proceedings 88.
Figure 8, Robust Loss Recovery with Eifel
[11] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, “TCP Selective Acknowledgment Options”, RFC 2018, October 1996
Conclusion In this work, we extensively studied the negative influence of the spurious timeout on the TCP end-to-end behavior and how the Eifel algorithms can improve TCP performance in the existence of spurious timeouts. We built a TCP-aware link model, implemented the Eifel detection and response algorithms, and simulated multiple TCP configurations in the OPNET Modeler environment. Our simulations showed that the Eifel algorithms could effectively detect the spurious timeout and prevent the unnecessary loss recovery while many contemporary
[12] S. Floyd, T. Henderson, “The NewReno Modification to TCP's Fast Recovery Algorithm”, RFC 2582, April 1999 [13] OPNET Modeler User Guide, phase 1, 2003
[14] S. Floyd, T. Henderson, A. Gurtov, The NewReno Modification to TCP's Fast Recovery, RFC 3782, April 2004 6
[15] H. Balakrishnan, V. N. Padmanabhan, G. Fairhurst, M. Sooriyabandara, “TCP Performance Implications of Network Path Asymmetry”, RFC 3449, December 2002
7
