We have already seen some examples of timeout and retransmission. (1) In the ICMP Destination Unreachable (Port Unreachable) example in Chapter 8 we saw the TFTP client using UDP employing a simple (and poor) timeout and retrans- mission strategy: it assumed 5s was an adequate timeout period and retransmit- ted every 5s. (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.
(3) In Chapter 3, we saw what happens when Ethernet encounters a collision. 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. In this case, we will use Wireshark to see how the connection progresses (see Figure 14-1).
Segments 1, 2, and 3 correspond to the normal TCP connection establish- ment handshake. When the Web server completes the connection establishment, it remains silent, awaiting a Web request. Before we provide the request, we isolate (disconnect) the server host. The input at the client side is as follows:
Linux% telnet 10.0.0.10 80 Trying 10.0.0.10...
Connected to 10.0.0.10.
Escape character is '^]'.
GET / HTTP/1.0
Connection closed by foreign host.
This request 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:
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 18 10.0.0.9:1043 10.0.0.10:www ESTABLISHED
ptg999
649
Figure 14-1 A simple example of TCP’s timeout and retransmission mechanism. The first retransmit occurs at time 42.954, followed by other retransmissions at times 43.374, 44.215, 45.895, and 49.255. The intervals between successive retransmissions are 206ms, 420ms, 841ms, 1.68s, and 3.36s, respectively. These times represent a doubling of the timeout between suc- cessive retransmissions of the same segment.
ptg999 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. Details of the rest of the output, including addresses and state information, are described in the following paragraphs.
Segment 4 is the client’s first attempt to send the Web request, at 42.748s. The next try is at 42.954, 0.206s later. Then it launches another try at 43.374, which is 0.420s later. Additional retries (retransmissions) occur at 44.215, 45.895, and 49.255s. These represent time differences of 0.841, 1.680, and 3.360s, respectively.
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. We shall explore it in more detail later. If we measure the elapsed time between the initial request and the time at which the connection is finally aborted, the total time is about 15.5 minutes. After that, the following error message is displayed at the client:
Connection closed by foreign host.
Logically, TCP has two thresholds to determine how persistently it will attempt to resend the same segment. These thresholds are described in the Host Require- ments RFC [RFC1122], and we mentioned them briefly in Chapter 13. 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). Windows also has a num- ber of variables that affect the overall behavior of TCP, including values for R1 and R2. These are all available by modifying values under the following registry keys [WINREG]:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters
ptg999 Section 14.3 Setting the Retransmission Timeout (RTO) 651
Of immediate interest is the value called TcpMaxDataRetransmissions.
This corresponds to the value of tcp_retries2 in Linux. It has a default value of 5. 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. If TCP were only ever used in one static environment, it would be possible to determine one particular correct value for the timeout value. Because TCP needs to operate in a large variety of environments, which themselves may change over time, TCP needs to determine this timeout value based on the current situation. For example, if a network link failed and traf- fic were rerouted, the RTT would change (possibly in a major way). In other words, TCP needs to dynamically determine its RTO. We consider this problem next.