TCP has two separate mechanisms for accomplishing retransmission, one based on time and one based on the structure of the acknowledgments.
The second approach is usu- ally much more efficient than the first.
TCP sets a timer when it sends data, and if the data is not acknowledged when the timer expires, a timeout or timer-based retransmission of data occurs.
The time- out occurs after an interval called the retransmission timeout (RTO).
Fast retransmit is based on inferring losses by noticing when TCP’s cumulative acknowledgment fails to advance in the ACKs received over time,
or when ACKs carrying selective acknowledgment informa- tion (SACKs) indicate that out-of-order segments are present at the receiver.
Simple Timeout and Retransmission Example
We have already seen some examples of timeout and retransmission.
(2) In the attempted connection to a nonexistent host in Chapter 13,
we saw that when TCP tried to establish the connection it retransmitted its SYN segment using a longer and longer delay between each successive retransmission.
All of these mechanisms are initiated by the expiration of a timer.
We shall first look at the timer-based retransmission strategy used by TCP.
We will establish a connection, send some data to verify that everything is OK, isolate one end of the connection, send some more data, and watch what TCP does.
Before we provide the request(after the connection is established), we isolate (disconnect) the server host.
This request(GET / HTTP/1.0) cannot be delivered to the server, so it remains in TCP’s queue at the client for quite some time.
During this period, the netstat command on the client indicates that the queue is not empty:
Here we see that 18 bytes are in the send queue, waiting to be delivered to the Web server.
The 18 bytes consist of the characters displayed in the preceding request, plus two sets of carriage-return and newline characters.
This doubling of time between successive retransmissions is called a binary exponential backoff, and we saw it in Chapter 13 during a failed TCP connection establishment attempt.
Logically, TCP has two thresholds to determine how persistently it will attempt to resend the same segment.
Threshold R1 indicates the number of tries TCP will make (or the amount of time it will wait) to resend a segment
before passing “negative advice” to the IP layer (e.g., causing it to reevaluate the IP route it is using).
Threshold R2 (larger than R1) dictates the point at which TCP should abandon the connection.
These thresholds are suggested to be at least three retransmissions and 100s, respectively.
For connection establish- ment (sending SYN segments), these values may be different from those for data segments,
and the R2 value for SYN segments is required to be at least 3 minutes.
In Linux, the R1 and R2 values for regular data segments are available to be changed by applications or can be changed using the system-wide configuration variables
net.ipv4.tcp_retries1 and net.ipv4.tcp_retries2, respec- tively.
These are measured in the number of retransmissions, and not in units of time.
The default value for tcp_retries2 is 15, which corresponds roughly to 13–30 minutes, depending on the connection’s RTO.
The default value for net. ipv4.tcp_retries1 is 3.
For SYN segments, net.ipv4.tcp_syn_retries and net.ipv4.tcp_synack_retries bounds the number of retransmissions of SYN segments;
their default value is 5 (roughly 180s).
Even in the simple retransmission example we have seen so far, TCP is required to assign some timeout value to its retransmission timer to dictate how long it should await an ACK for data it sends.
TCP needs to determine this timeout value based on the current situation
Setting the Retransmission Timeout (RTO)
Fundamental to TCP’s timeout and retransmission procedures is
how to set the RTO based upon measurement of the RTT experienced on a given connection.
Knowing the RTT is made more compli- cated because it can change over time, as routes and network usage vary.
TCP must track these changes and modify its timeout accordingly in order to maintain good performance.
Because TCP sends acknowledgments when it receives data, it is possible to send a byte with a particular sequence number and
measure the time required to receive an acknowledgment that covers that sequence number.
Each such mea- surement is called an RTT sample.
The challenge for TCP is to establish a good estimate for the range of RTT values given a set of samples that vary over time.
The second step is how to set the RTO based on these values. Getting this “right” is very important for TCP’s performance.
The RTT is estimated for each TCP connection separately, and one retransmis- sion timer is pending whenever any data is in flight that consumes a sequence number (including SYN and FIN segments).
The Classic Method
The original TCP specification [RFC0793] had TCP update a smoothed RTT estima- tor (called SRTT) using the following formula:
SRTT ← α(SRTT) + (1 − α) RTTs
Here, SRTT is updated based on both its existing value and a new sample, RTTs.
Given the estimator SRTT, which changes as the RTT changes, [RFC0793] rec- ommended that the RTO be set to the following:
RTO = min(ubound, max(lbound,(SRTT)β))
where β is a delay variance factor with a recommended value of 1.3 to 2.0,
ubound is an upper bound (suggested to be, e.g., 1 minute), and lbound is a lower bound (suggested to be, e.g., 1s) on the RTO.
We shall call this assignment procedure the classic method.
For relatively stable distributions of the RTT, this was adequate.
However, when TCP was run over networks with highly variable RTTs (e.g., early packet radio networks in this case), it did not perform so well.
The Standard Method
To address this problem, the method used to assign the RTO was enhanced to accommodate a larger variability in the RTT.
This is accomplished by keeping track of an estimate of the variability in the RTT measurements in addition to the estimate of its average.
Setting the RTO based on both a mean and a variability estimator provides a better timeout response to wide fluctuations
in the round- trip times than just calculating the RTO as a constant multiple of the mean.
This is the basis for the way many TCP implementations compute their RTOs to this day, and because of its adoption as the basis for [RFC6298] we shall call it the standard method.
Clock Granularity and RTO Bounds
TCP has a continuously running “clock” that is used when taking RTT measure- ments.
As with initial sequence numbers, real TCP connections do not start their clocks at zero and the clock does not have infinite precision.
Rather, the TCP clock is usually the value of a variable that is updated as the system clock advances, not necessarily one-for-one.
The length of the TCP’s clock “tick” is called its granular- ity.
Traditionally, this value was relatively large (about 500ms), but more recent implementations use finer-granularity clocks (e.g., 1ms for Linux).
The granularity can affect the details of making RTT measurements and also how the RTO is set.
In [RFC6298], the granularity is used to refine how updates to the RTO are made.
In addition, a lower bound is placed on the RTO. The equation used is as follows:
RTO = max(srtt + max(G, 4(rttvar)), 1000)
where G is the timer granularity and 1000ms represents a lower bound on the total RTO (recommended by rule (2.4) of [RFC6298]).
Consequently, the RTO is always at least 1s.
An optional upper bound is also allowed, provided it has a value of at least 60s
Initial Values
Before the first SYN exchange, TCP has no good idea what value to use for setting the initial RTO.
It also does not know what to use as the initial values for its estimators, unless the system has provided hints at this information
(some systems cache this information in the forwarding table; see Section 14.9).
According to [RFC6298], the initial setting for the RTO should be 1s, although 3s is used in the event of a timeout on the initial SYN segment.
When the first RTT measurement M is received, the estimators are initialized as follows:
。。。