Algorithms like Slow Start, Congestion Avoidance, Fast. Retransmit and Fast Recovery are the basis for different TCP flavors. Tahoe, Reno and New-Reno are ...
Simulation-based study of TCP flow control mechanisms using OPNET Modeler Guiomar Corral, Agustin Zaballos, Tomas Fulgueira, Jaume Abella Enginyeria i Arquitectura La Salle, Universitat Ramon Llull, Spain, EUROPE Paseo Bonanova, 8, 08022 Barcelona Tlf: +34 93 2902400, Fax: +34 93 2902416 E-mail: {guiomar, zaballos,tomasf,jaumea}@salleURL.edu Abstract TCP is the most used transport protocol in Internet. It has a data stream control based on TCP Window. This control implementation has several options and there are still different proposals to enhance it.
Concepts Some aspects of the TCP’s sliding window have been explained in the introduction but now a closer description will be given. A communication between two TCP entities will be assumed, and the terms sender and receiver will be used to name them both indistinctly depending on the point of view.
Algorithms like Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery are the basis for different TCP flavors. Tahoe, Reno and New-Reno are TCP versions that use these algorithms. This paper tries to give an overview of these proposals. Several simulations have been run with OPNET in order to acquire a better understanding of these algorithms and the way they perform their functions.
TCP’s data transmission uses a numbering method for the segments to be sent and an acknowledging method for the received segments. With TCP’s sliding-window protocol the receiver does not have to acknowledge every received packet. The ACKs segments acknowledge that the receiver has correctly received all bytes up through the acknowledged sequence number minus one. [3]
Introduction TCP uses a sliding window protocol for data flow control. The TCP window reports the number of bytes that each TCP process is ready to receive in a certain moment. In other words, this is the maximum amount of data that can be transmitted without being acknowledged.
Every segment has a sequence number and an acknowledgment number in its header. The sequence number identifies the byte in the data stream from the sending TCP to the receiving TCP that the first byte of data in this segment represents. That is to say, this is the number of the first byte of information that carries the segment. On the other hand, the acknowledgment number contains the next sequence number that the sender of the acknowledgment expects to receive. So this is the sequence number plus 1 of the last successfully received byte of data. [3]
The receiver has a limited capacity to store received data and this capacity has been advertised during the connection establishment. During the communication, the received data fills the receiver’s buffer, thus reducing the receiver’s capacity to get more information. Available space will not be incremented until the upper layer processes request for the received data. As the upper layers process this information, receiver’s buffers get more free space and the window is widened. The sender knows how much data it is allowed to send because it receives segments from the receiver advertising the offered window. These segments are usually acknowledgement packets.
When a segment is sent, the sender starts a counter that measures the elapsed time since that moment. If the counter reaches “retransmission timeout”, a transmission error is assumed and a retransmission of the lost segment occurs. This is how TCP provides reliability to user’s information. [1] [2] As stated before, each TCP entity uses a sliding window to maintain data flow control. During connection establishment negotiation, each TCP entity advertises its window’s initial value (offered window). This could change during communication, so a field in the header called “window size” is needed in order to advertise the new receiver’s window size. So window size is the number of bytes, starting with the one specified by the acknowledgment number field, that the receiver is willing to accept. [3]
There are two types of windows depending on the point of view: from the receiver, which sees its own window, and from the sender, which sees the receiver’s window; so the former is called the offered window and the latter is the usable window. The offered window corresponds to the amount of buffer space available in the receiver. On the other hand, the usable window size is the offered window less the amount of data sent but not acknowledged. Therefore, the usable window indicates the number of segments the sender is allowed to send immediately. [2] [8] The algorithms and mechanisms discussed in this paper are attempts to improve this window performance by changing some aspects of its behavior as this window protocol has some problems when transmission errors occur.
Figure 1: TCP sliding window 1
Figure 1 shows TCP’s sliding-window performance. Newly sent data moves left edge of the usable window toward the right, thus closing the usable window’s size. Received acknowledgements move left edge of the offered window toward the right. The right edge of both windows moves as the result of adding the window size advertised in the segment’s header to the left edge of the offered window.
transmission errors until the buffers are emptied, because of TCP has no ways to know the connection’s bandwith. This is by no means acceptable, as the transmission would be almost stopped for some time. Slow Start provides a way to control initial data flow at the beginning of a communication and during an error recovery based on received acknowledgements. Each acknowledgement means that a segment, or a group of segments, has left the network and is not using any resources, so new data can be sent.
As stated before, TCP entity uses two windows. These windows move their left edge independently of each other. In contrast, their right edges move solidly united. The size of the usable window is the offered window minus the number of bytes sent but not acknowledged.
Congestion Avoidance is an algorithm that adapts data transmission to the available resources. After Slow Start has reached a certain threshold, Congestion Avoidance starts slowing down the opening of the window.
In order to understand TCP’s performance, some simulations have been run with OPNET. The simulated scenario is shown in Figure 2. This model has two stations (a server and a client) and a packet discarder. The server sends data and the client acknowledges it. The packet discarder is configured to cause transmission errors by dropping a fixed number of segments.
Slow Start adds another window to the sender’s TCP: the “congestion window”. It controls the data flow from the sender point of view (remember that flow control performed by the offered and usable windows is imposed by the receiver). The size of this new window is set to 1 segment whenever there is an error. Then it grows each time an acknowledgement is received, increasing its size by the number of acknowledged segments. It results in an exponential increase of the congestion window. When the congestion window reaches half the size it had before the error (“Slow Start Threshold”), Slow Start ends and Congestion Avoidance takes place. Congestion Avoidance increases the congestion window additively, so it grows at most one segment every round trip time. At the beginning of the communication the congestion window is also set to 1 segment, and the slow start threshold is set to 65535 bytes. The usable window that the sender uses is calculated taking the minimum of the congestion window and the offered window.
Figure 2: Scenario used for simulations Flow Control The specifications about the sliding-window protocol described before are the minimum performance requirements for TCP. However, many problems still exist concerning different TCP aspects. So different modifications and subsequent algorithms have been applied in order to obtain better performance to adapt the protocol to new bandwidth requirements. Some of them are even considered as TCP requirements nowadays. Two of these algorithms are “Slow Start” and “Congestion Avoidance”, which modify the performance of TCP’s sliding window to solve some problems related to congestion in networks and their nodes. These two algorithms are implemented together and work as if they were only one.
Figure 3: Congestion window at the start of a transmission
If TCP works without the Slow Start and Congestion Avoidance algorithms it will start sending as much information as the usable window allows. This could create problems because nodes along the network have to store that information in their queues and can run out of memory. When a node can not store incoming data, segments are lost and transmission errors occur. This is called congestion. Then, the sender has to retransmit the lost segments. And so it does, but without any other flow control it will fill up the usable window immediately, thus causing congestion once again. Consequently, it will generate
When segments are dropped, it is assumed that it is due to congestion. The assumption is that packet loss caused by damage is much less than 1%. Therefore the loss of segment signals congestion somewhere in the network between the source and destination, and then Slow Start and Congestion Avoidance are applied. [6] The use of these two algorithms improves TCP’s performance but sometimes it is not enough. Bandwidth availability has 2
grown since the first definitions of TCP and more modifications were required to take advantage of these new resources.
Fast Recovery When Fast Retransmit takes place, a flow control algorithm must be applied for slowing down the normal data flow. Usually, an error recovery consists on applying firstly Slow Start and then Congestion Avoidance. However, Fast Recovery establishes that Slow Start will not be used and Congestion Avoidance will be applied instead from the beginning.
Slow Start and Congestion Avoidance, working as explained, provide new features like flow control in error recovery situations and adaptation to network conditions. But they can also be improved. They are very slow in retrieving normal data transmission speed. When there is an error, data flow stops completely and some time is wasted while trying to reach the old data transmission speed.
The reception of duplicated acknowledgements suggests that there is still some data flowing along the path. So there is no reason to completely stop this flow. Thus it would be better to slow down the data flow instead of stopping it. Avoiding the use of Slow Start and applying Congestion Avoidance without closing congestion window completely achieve this.
Fast Retransmit Waiting for retransmissions may imply wasting a lot of time. The usual process is to wait until an acknowledgement is received or the retransmission timeout expires to assume a transmission error. But sometimes it is not necessary to wait for the retransmission timeout. When there is a transmission error and a segment is lost, later segments (that is, segments with higher sequence numbers) reach their destination and the receiver classifies them as “out-of-sequence” segments. TCP is required to generate an immediate acknowledgment, called a duplic ated acknowledgment, when an out-of-order segment is received.
Therefore, the congestion window is closed to half the size it had at the moment of the error (it was the Slow Start Threshold when performing normally). This fact allows sending more segments while the usable window remains open. Then, the congestion window is enlarged by the size of a segment every time a duplicated acknowledgement is received in order to keep the usable window open. This is what happens at the Fast Recovery phase of the algorithm. When the retransmitted segment reaches its destination, the receiver has to acknowledge it and it can also acknowledge the segments with higher sequence number that has received during the fast recovery phase. That is to say, the receiver sends a nonduplicated acknowledge. Then, the sender closes the congestion window down to the value of the slow start threshold again. From this moment on, the Congestion Avoidance algorithm starts performing and opening the congestion window additively.
Therefore, for each out-of-sequence segment, the receiver issues a duplicated acknowledgement, which acknowledges data that was previously acknowledged when the error occurred. The sender receives these duplicated acknowledgements and thus can assume a transmission error. Then, there is no sense to wait for the retransmission timeout and the sender may retransmit almost immediately. This algorithm is called “Fast Retransmit”. Using duplicated acknowledgements as the indication of segments loss wastes less time. These duplicated acknowledgements are always issued, so they are not a new feature introduced by this new algorithm. Fast Retransmit only gives them a new sense. Duplicated acknowledgements can be issued by two causes: by the loss of segments or by the out of sequence arrival of segments due to the IP’s routing system. As the latter will be solved with the arrival of the missing segments it is expected that less than three duplicated acknowledgements will be issued. So this is the threshold for assuming transmission errors and triggering the retransmissions. [6] Fast Retransmit is implemented as follows. When three duplicated acknowledgments are received, the sender assumes a transmission error and retransmits the lost segment. From this point and until an acknowledgement for new data arrives, every duplicated acknowledgement triggers a new data transmission. Duplicated acknowledgements are the result of sent data reaching the receiver and leaving the network. In order to use the resources efficiently, new data is inserted into the network.
Figure 4: Data flow with Fast Retransmit & Fast Recovery Figure 4 shows the behavior of data flow when Fast Retransmit and Fast Recovery are enabled and a transmission error occurs. The horizontal axis shows the time and the vertical is the sequence number. Black dots (seen as lines) are data segments sent by the sender. White dots are the acknowledgements received by the sender and located at the sequence number they acknowledge. Every vertical black line represents a burst of data sent as a consequence of receiving an acknowledgement. The diagonal black line represents the Fast Recovery phase. For each duplicated acknowledgement received, a new segment of new
So it is expected that delayed segments, but not lost ones, reach the receiver before three following “out-of-sequence” segments arrive to the receiver. Otherwise a redundant retransmission will take place, and the hypothesis made for taking the decision of a retransmission will be false.
3
data is sent. The recovery phase lasts until a non-duplicated acknowledgement is received. Reno and Tahoe TCP Fast Retransmit and Fast Recovery seem to work well when only one segment is lost. But, as we will see later, some problems arise when a drop of multiple segments happens. This is the reason for the existence of different flavors of TCP. Some of them use these algorithms and others don’t, in order to improve their performance in different situations. For example, Fast Retransmit and Fast Recovery working together optimize TCP’s performance when only one segment is lost [4]. Thus, this implementation could be useful when TCP is working in a reliable network with short bursts of errors and low BER, causing only one segment to be lost. The flavor that uses both Fast Retransmit and Fast Recovery together is called Reno TCP.
Figure 6: Reno TCP dealing with a 4-segment loss. Sequence and acknowledgement numbers.
As shown in Figures 5 and 6, when an error causing a loss of multiple segments occurs, a problem arises with Reno TCP’s congestion window. Fast Retransmit closes the congestion window every time a non-duplicated acknowledgement is received. A loss of multiple segments makes the window close to half of its size for every dropped segment, as shown in Figure 5. Besides, the usable window is decreased during the fast recovery phase, as more information is sent, every time a duplicated acknowledge is received. When the congestion window is divided by two for the second time, the usable window closes to zero, thus blocking the communication and forcing the retransmission timeout. When the retransmission timer expires the congestion window is closed to 0 and starts growing with slow start and congestion avoidance algorithms.
At this point the transmission is blocked because duplicated acknowledgements are not received and there are no other mechanisms that inflate the congestion window. So the only event that can trigger the retransmission is the retransmission timer expiration. Tahoe TCP does not apply Fast Recovery in order to avoid the problems described previously. When this flavor is used, Fast Retransmit is the only algorithm applied. This means that Slow Start and Congestion Avoidance will be working when recovering from an error.
Figure 7: Tahoe TCP dealing with a 4-segment loss. Congestion window size.
Figure 5: Reno TCP congestion window dealing with a 4-segment loss
As shown in Figures 7 and 8, Tahoe TCP closes the congestion window when the first error is detected. This stops the communication suddenly, but allows the congestion window, and consequently the usable window, to open exponentially. Then the usable window allows the sender to retransmit the lost segments.
Reno TCP problems, when multiple segments are lost, come from applying the Fast Recovery algorithm. Fast Recovery allows sending data while recovering from the first error. This makes the usable window close while this data is not acknowledged. When TCP realizes that another error has happened, it divides the congestion window again by two. Usable window, (calculated as the congestion window minus the sent but not acknowledged data), comes down to a value that does not allow any more data to be sent.
Tahoe TCP performance can be easily understood looking at Figure 8. The data transmission is performed normally until error happens. The normal performance is to send bursts of data (black vertical lines) containing as many segments as the usable window allows. When the acknowledgement (white dots) is received, another burst of data can be sent. At this moment an 4
error happens. When the third duplicated acknowledgement is received, the first lost segment is retransmitted and the congestion window is closed. Slow Start is applied, so the window doubles its size for every duplicated acknowledgement. Then the other segments can be retransmitted.
Some simulations were run in order to show these differences between Tahoe and Reno TCP and demonstrate that Reno TCP has problems with losses of multiple segments. But how many segments have to be lost to block the communication is something that will depend on each particular situation. It is directly related to the offered window size and the congestion window size, and these parameters depend on many others that are not discussed in this paper.
So, although the usable window is closed, there is always a mechanism that opens it again. The communication is never blocked as in Reno TCP and no waiting for the retransmission timer is needed.
SACK TCP TCP suffers from some performance problems dealing with bursts of errors. Traditional acknowledgements give little information about the segments that have or have not reached their destination. This information allows retransmitting only one segment per round trip time. Besides, the transmitter can create a situation in which packets that have correctly reached their des tination are retransmitted, when there was no need of doing so. This could happen if the transmitter uses a short retransmission time. Moreover, this situation would increase congestion in the network. The SACK TCP mechanism (Selective Acknowledgements), helps to avoid these limitations. Receiver informs the transmitter, which packets it successfully received, so retransmission occurs only for lost packets. SACK reports the segments that have reached the receiver although they carry nonsequential sequence numbers. This means that, if there is a segment missing between two other segments, the receiver can acknowledge both of them. And this would be done without acknowledging the missing segment between them.
Figure 8: Tahoe TCP dealing with a 4-segment loss. Sequence and acknowledgement numbers.
Tahoe TCP performs better than Reno TCP in this situation. But, if only one segment were lost, Reno TCP would take advantage of Fast Recovery. When only one segment is lost, Reno TCP only closes the congestion window once. It doesn’t stop the transmission and sends data every time a duplicated acknowledgement is received. That gives a significant saving of time in comparison with Tahoe TCP. Tahoe TCP performance and Reno TCP performance are compared in Figure 9.
Several other transport protocols use this technique and there is empirical evidence that recommends its use. Some experiments have demonstrated that the deactivation of such mechanism causes a big increase of the number of retransmitted segments in networks with low reliability. A study from 1995 compares SACK, Tahoe and Reno TCP and demonstrates the advantages of this option. [4]. Some simulations were run using OPNET’s SACK TCP model. The specification of SACK TCP [5] stands for the use of Fast Retransmit and Fast Recovery. Consequently, this specification is based on the configuration of Reno TCP, and this is how the OPNET model was configured to perform. Such configuration induced SACK TCP to suffer from the same problems that Reno TCP had in these simulations. As shown in Figures 10 and 11, SACK TCP has to wait for the retransmission timeout, just as Reno TCP. And the reason for this is the same as with Reno TCP: Fast Recovery closes the window for every retransmission and the usable window runs out of space for new information to be sent.
Figure 9: TCP dealing with a 4-segment loss. Sequence numbers of sent data. The black line represents the performance of Reno TCP. The gray line represents the performance of Tahoe TCP.
5
The conclusion of these simulations is that SACK TCP does not improve the performance of Tahoe TCP in this situation. But a further study should be carried out, in order to see what would happen if some non-sequential segments were lost. In this situation, caused by short bursts of errors, SACK TCP should take advantage of its own configuration and should overcome both Tahoe and Reno TCP. New-Reno TCP Although SACK TCP is expected to solve some problems when bursts of errors are not too large, it still has problems dealing with long bursts of errors. This flavor, called New-Reno TCP (proposed by [4] and specified in [7]), was implemented in order to improve Reno TCP’s performance making only a few changes on it.
Figure 10: SACK TCP dealing with a 4-segment loss. Congestion window size.
Problems in Reno TCP were caused by an early exit of the fast recovery phase. When the fast recovery phase ends, the congestion window takes the value it had at the time of the retransmission. If several segments have to be retransmitted, Reno TCP will go in and out of Fast Retransmit and Fast Recovery, thus dividing the congestion window by 2 every time. New-Reno TCP postulates that the fast recovery phase shouldn’t end until all the information that had been sent before and during this phase has been acknowledged. Let’s introduce here the concept of partial acknowledges. Partial ACK’s are the acknowledgement segments that do not acknowledge all the information that has been sent up to the moment when they are issued. So, using this definition, in NewReno TCP the partial acknowledgements do not finish the fast recovery phase.
Figure 11: SACK TCP dealing with a 4-segment loss.
This performance allows TCP to maintain a value for the congestion window that does not stop data flow and new data can be sent for each received duplicated acknowledgement.
The difference between Reno TCP and the SACK implementation is that the latter does not enlarge the congestion window for each duplicated acknowledgement it receives. This allows a higher value to be stored as the limit for Slow Start. Then, the error recovery is faster, because the congestion window is opened exponentially during a longer period.
Figure 13: New-Reno TCP dealing with a 4-segment loss. Sequence and acknowledgement numbers. Figure 12: Comparison of Tahoe (grey), Reno (black) and SACK (white) TCP dealing with a loss of 4 sequential segments.
6
Figure 15: “New-Reno TCP features” parameter Conclusion This paper summarizes a study on TCP and its mechanisms for data transmission control. The algorithms called slow start, congestion avoidance, fast retransmit and fast recovery can be interpreted in slightly different ways. These interpretations give name to several TCP flavors such as Tahoe, Reno and NewReno. So the main goal has focused on improving the knowledge of TCP and the flow control mechanisms used in data communication scope over IP networks.
Figure 14: New-Reno TCP dealing with a 4-segment loss. Congestion window size. Figures 13 and 14 show that New-Reno TCP avoids the problems seen previously in this paper. As explained before, the fast recovery phase lasts until the last partial acknowledgement is received. When an acknowledgement for new data is received then the fast recovery phase is exited.
Simulations have been run in order to clarify what are the differences between them and OPNET’s software has shown itself as a perfect tool for achieving such goal.
For simulating this flavor, a new option had to be added to the OPNET TCP model. The option was called “New-Reno TCP features”. When active, this option uses some new lines of code added to the original model. These lines of code give the congestion window the values New-Reno TCP dictates at every moment. The changes have been applied in the Function Block of the process model tcp_conn_v3 .
Some remarks can be made after analyzing simulation's results. Tahoe TCP provides us better performance than Reno TCP, because the former closes the usable window when the first error of a burst is detected, and uses Slow Start from the beginning. However, New Reno TCP overcomes both algorithms since it avoids closing the usable window when more than one error occurs. Although further study must be carried out, these simulations show that the best TCP flavor will be New Reno TCP using selective acknowledgments.
if ((dup_ack_cnt == TCPC_FRFR_DUP_ACK_THRESH) && (fast_rec_occuring == 0 &&(tcp_newReno_enabled)) { seq_startFRFR = snd_nxt - 1; fast_rec_occuring = 1; ssthresh_startFRFR = cwnd /2; }
References [1] “Transmission Control Protocol – Functional Specification”. Information Sciences Institute, University of Southern California. 1981, [RFC793]. [2] “Requirements for Internet Hosts – Communication Layers”. R. Braden. 1989, [RFC1122].
if ((seg_ack > seq_startFRFR) && (tcp_newReno_enabled)) { ssthresh = ssthresh_startFRFR; cwnd = ssthresh; fast_rec_occuring = 0;
[3] “TCP/IP Illustrated Volume 1”, the Protocols, W. Richard Stevens, 6th - Edition, 1995. [4] “Simulation – Based Comparisons of Tahoe, Reno and SACK TCP”. K. Fall, S. Floyd. 1995.
} else cwnd = ssthresh;
[5] “TCP Selective Acknowledgement Options”. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. 1996, [RFC2018]. if (fast_rec_occuring) cwnd = 2* ssthresh; if ((seg_ack > seq_startFRFR) && (tcp_newReno_enabled)) { ssthresh = ssthresh_startFRFR; cwnd = ssthresh; fast_rec_occuring = 0; } else cwnd = sstresh;
[6] “TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms”. W. Stevens. 1997, [RFC2001]. [7] “The NewReno Modification to TCP’s Fast Recovery Algorithm”. S.Floyd, T.H.Henderson. 1999, [RFC2582]. [8] "Window and Acknowledgement strategy in TCP". David D. Clark 1982, [RFC 813]. 7
