7. 7 Chapter 13 Transmission Control Protocol (TCP) Retransmission and Time-Out.

7

Chapter 13

Transmission ControlProtocol (TCP)

Retransmission and Time-Out

Retransmission Time-Out and Round-Trip Time

For each connection, TCP maintains a variable called the retransmission time-out (RTO),which is the amount of time within which an ACK for the segment is expected. If TCP does not receive an ACK before the RTO expires, the segment is retransmitted.

The RTO must allow enough time for the following:


1. The initially sent TCP segment to traverse the internetwork

2. The initially sent TCP segment to be received and processed by the destination node

3. The generation of an ACK for the segment One component of is the delayed acknowledgment time of the destination node. If these delayed ACKs can contain data, include updated window sizes, and acknowledge multiple segments received.

4. The generated ACK to traverse the internetwork

5. The generated ACK to be received and processed by the sending node

The RTO should be neither too large nor too small to prevent the following behaviors:

■ When the RTO is too large, the sending TCP peer must wait too long before retransmitting a lost segment. This lowers throughput for connections with some degree of packet loss.

■ When the RTO is too small, segments are retransmitted unnecessarily. Retransmitted segments increase the load on the internetwork and waste internetwork capacity.


Congestion Collapse

Congestion caused by the increase in data networking and data transmission from host to many. And the order of buffers in routers take delivery from origin to destination much. Clearance time response from the destination. If sending a response soon, will allow RTO timeout to resend the new. The elimination of network congestion is to control the RTT and RTO are not fit to be a unique new data too often. Will cause congestion problems on the network.


Retransmission Behavior

TCP uses the following exponential backoff behavior to determine the RTO of successive retransmissions of the same segment:

1. When the TCP segment is initially sent, the RTO for the segment is set to the currently known RTO for the connection.

2. After RTO number of seconds, when the RTO expires, the segment RTO is set to twice the RTO for the segment’s previous transmission and retransmitted.

Retransmission Behavior for New Connections

For new connections initiated by a TCP peer running Windows Server 2008 or Windows Vista, the maximum number of retransmissions of the synchronize (SYN) segment is two. TCP sends two retransmissions of a SYN segment before abandoning the connection attempt. Exponential backoff is used between successive retransmissions of the SYN segment. The maximum number of retransmissions for the SYN-ACK segment is two. TCP sends two retransmissions of a SYN-ACK segment in response to a SYN segment before abandoning the connection attempt. Exponential backoff is used between successive retransmissions of the SYN-ACK segment.


Dead Gateway Detection

Dead gateway detection is an the algorithms to detect errors. Detection path that does not do automatically. The continued good software gateway. And included in the configuration of multiple gateways. When contacted and re-sent in several times to the network routing the best translation software to change the gateway continued losing contact to 25%


When the router at 10.0.0.1 fails, dead gateway detection uses the following process to change the default route to use the next-hop IP address of 10.0.0.2:1. A TCP connection data segment. Because no ACK is received,

the segment is retransmitted. At this point, 10 percent of the TCP connections using the next-hop IP address of 10.0.0.1 have been switched to 10.0.0.2.

2. Another TCP connection sends a data segment. At this point, 20 percent of the TCP connections using the next-hop IP address of 10.0.0.1 have been switched to 10.0.0.2.

3. Another TCP connection sends a data segment. At this point, 30 percent of the TCP connections using the next-hop IP address of 10.0.0.1 have been switched to 10.0.0.2.

4. Because more than 25 percent of the TCP connections using 10.0.0.1 as their next-hop IP address have had their next-hop IP addresses changed, the default route in the IP routing table is updated to use 10.0.0.2 as the next-hop IP address.


Forward RTO-RecoveryWhen the RTO expires for multiple segments, TCP retransmits just the first segment. When the first acknowledgement is received, TCP begins sending new segments (if allowed by the advertised window size). If the next acknowledgment acknowledges the other segments that have timed out but have not been retransmitted, TCP determines that the time-out was spurious and does not retransmit the other segments that have timed out.


Using the Selective Acknowledgment (SACK) TCP Option

1. For each segment, maintain a selective acknowledgment flag that is enabled when the segment is selectively acknowledged.

2. When initial RTO timers begin to expire, only retransmit the segments that have not been selectively acknowledged (segments for which the selective acknowledgment flag is disabled).

3. If an ACK is received that cumulatively acknowledges the retransmitted segment, the send window closes and opens depending on the new Acknowledgment Number + Window sum, and new segments can be sent. The selective acknowledgment flags on noncumulatively acknowledged segments are maintained.

4. If a retransmitted segment times out, indicating that the receiver might have reneged on the selectively acknowledged segments, disable the selective acknowledgment flags of all segments in the current window and retransmit them normally.

This mechanism recovers from the possibility that the receiver discarded the noncontiguous received segments. If necessary, the entire window of data is resent.


Using SACKs to Indicate Duplicate Received Packets

TCP in Windows Server 2008 and Windows Vista supports RFC 2883, which defines an additional use of the fields in the SACK TCP option to acknowledge duplicate packets. This allows the sender to determine when it has retransmitted a segment unnecessarily and adjust its behavior to prevent future retransmissions. The fewer retransmissions that are sent, the better the overall throughput.


Calculating the RTO

The determination of the RTO is an important function of TCP. The RTO must be adjusted to the internetwork’s changing conditions. If the determined RTO is less than the RTT, segments are unnecessarily retransmitted.

In RFC 793, the suggested method of computing the RTO—known as the smoothed roundtrip time (SRTT)—is based on the following formulas:

SRTT = (α*SRTT) + ((1-α)*RTT)

RTO = min[UpperBound, max[LowerBound,(β *SRTT)]]

Instead, RFC 1122 states that TCP must use the following formulas as documented in “Congestion Avoidance and Control,” a paper written by Van Jacobson and Michael J. Karels:

SRTT = RTT + 8*(New_RTT - RTT)

Dev = Dev + (|New_RTT - RTT| - Dev)/4

RTO = SRTT + Dev/4

Calculating the RTO

RTO calculation is described in detail in RFCs 793 and 1122.

For TCP in Windows Server 2008 and Windows Vista, the RTO’s initial value for establishing connections or sending data on new connections is 3 seconds for SYN segments, SYN-ACK segments, and initial data segments sent on a new connection for each interface.

The RTT sampling rate is 1/(window size). For small window sizes, this sampling rate is adequate.

Calculating the RTO

Using the TCP Timestamps Option

As described in Chapter 10, “Transmission Control Protocol (TCP) Basics,” the TCP Timestamps option allows TCP peers to place a timestamp value on each segment. The TCP Timestamps option contains two 32-bit fields to track timestamps: TS Value and TS Echo Reply.

The use of TCP timestamps allows an RTT to be calculated by subtracting the timestamp echo in the ACK from the current time value of the timestamp clock.

As an example, TCP Peer A sends a data segment to TCP Peer B, which sends an ACK back. The data segment’s TS Value is 1285458 when it is sent and is echoed in the ACK segment’s TS Echo Reply field. When the ACK is received and processed, the current value of TCP Peer A’s timestamp clock is 1286506. Therefore, the RTT for this segment is based on the TCP timestamp value of 1048, or 1286506 – 1285458.

This basic method of RTT determination is complicated by the following factors:

■ There might be pauses in sending data.

■ ACKs are delayed and can acknowledge multiple TCP segments.

■ Segments can arrive out of sequence.

■ Segments can be dropped and must be retransmitted.

Figure 13-1 illustrates the problem with pauses in sending data. TCP Peer A sends TCP Peer B a series of segments and then pauses. Then TCP Peer A sends more segments. The new segment after the pause has the TS Echo Reply field set to the TS Value field of the last ACK received. If TCP Peer B now calculates the RTT for the last ACK sent, the RTT is inflated by the time of the pause in sending data.

TCP Timestamps

TCP Timestamps

For delayed ACKs, segments that arrive out of order, and retransmitted segments, the value of TS Echo Reply for ACKs is based on the following algorithm:

1. For correct TCP timestamp behavior, TCP keeps track the value of the TS Echo Reply that will be sent in the next ACK

2. After receipt of a new segment, the segment does not contain last tack, ignore the value of the TS Value field of the arriving segment.

3. When sending a segment with the TCP Timestamp option, set the value of TS Echo Reply to the value of tsrecent.

4. When sending an ACK, set the value of last tack to the value of the Acknowledgment Number field in the ACK.

TCP Timestamps

For delayed acknowledgments, the RTT determination must include the acknowledgment delay. Therefore, when sending a delayed acknowledgment, the TS Echo Reply of the delayed ACK is set to the TS Value of the first segment being acknowledged. Figure 13-2 illustrates this behavior.

Figure 13-2 The behavior of TCP timestamps for delayed acknowledgments.

TCP Timestamps

TS Echo Reply and tsrecent are updated only when the missing segment(s) arrives. Figure 13-3 illustrates this behavior.

TCP Timestamps

When a segment is dropped and must be retransmitted and the segments arrive out of sequence, the value of tsrecent, and therefore the value of the TS Echo Reply field, is not updated. Because the RTT does not include the RTO for the retransmitted segment, tsrecent and TS Echo Reply are updated only when the missing retransmitted segment arrives. Figure 13-4 illustrates this behavior.

TCP Timestamps

TCP Timestamps

Karn’s AlgorithmWhen calculating the RTT for a TCP segment being sent, the time at which the segment is sent is recorded. If the RTO expires, an exact duplicate is sent and its time is recorded. When the ACK is received, how is the RTT computed? When the TCP Timestamps option is not being used, the ACK does not distinguish between the original TCP segment and its retransmitted copy. TCP has the problem of acknowledgment ambiguity. When multiple copies of a TCP segment are sent, the ACK does not identify a specific instance of the TCP segment being acknowledged.

TCP Timestamps

To keep subsequent TCP segments from being sent with an inadequate RTO when the actual RTT including TCP/IP for the Windows Server 2008 and Windows Vista, use algorithm is Phil Karn and Craig Partridge algorithm states that when an ACK for a retransmitted segment arrives.

TCP Timestamps

Karn’s Algorithm and the Timestamps Option

Karn’s algorithm applies when the ACKs are ambiguous—when TCP cannot distinguish the original TCP segment from a retransmitted instance. However, with the TCP Timestamps option, each TCP segment has a steadily increasing timestamp clock value and is, therefore, unique within the time that segments are being retransmitted.

TCP Timestamps

Fast Retransmit and Fast Recovery

Fast retransmit is the retransmission of a TCP segment before the RTO for the segment expires, based on the receipt of three duplicate ACKs where the ACK’s acknowledgment number is the retransmitted segment’s sequence number. The retransmitted segment is the missing segment. Fast retransmit is defined in RFC 2581.

As Figure 13-5 illustrates, TCP Peer A sends five TCP segments and the first segment is lost. As the noncontiguous segments arrive, TCP Peer B sends an immediate ACK with the ACK number it expects to receive. After the third duplicate ACK for sequence number 1000, TCP Peer A retransmits the first segment.


In Figure 13-6, TCP Peer A transmits Segment 6 upon receiving the first .


Fast RecoveryFast recovery assumes that the arrival of duplicate ACKs indicates that segments sent before the missing TCP segment have already been received and are not adding to the internetwork congestion. Therefore, TCP can scale the congestion window faster than when using slow start.

The fast recovery algorithm is defined as follows:

1. After receipt of the third duplicate ACK, the value of the slow start threshold (ssthresh) is set to one half the value of the congestion window (cwind), with a minimum value of 2*MSS.

2. The missing segment is retransmitted and cwind is set to (ssthresh + 3*MSS). This increases cwind to a value that reflects the receipt of three TCP segments at the receiver (based on the receipt of three duplicate ACKs).

3. For each additional duplicate ACK, cwind is increased by MSS. Once again, cwind is being increased because of an additional segment that has arrived at the receiver.

4. If allowed by the values of cwind and the advertised receive window size, the next TCP segment(s) is transmitted.

5. When the ACK arrives that acknowledges the receipt of the missing new segment and all other contiguous segments, cwind is set to the value of ssthresh. At this value of cwind, slow start is avoided and congestion avoidance is performed.


SACK-based Loss Recovery

TCP for Windows Server 2003 and Windows XP uses SACK information only to determine which TCP in Windows Server 2008 and Windows Vista supports RFC 3517.Which defines a method of using SACK information to perform loss recovery, effectively replacing the fast recovery algorithm is enabled on a connectionand monitors incoming ,when multiple segments are not received at the destination.

For details of the SACK-based loss recovery algorithm, see RFC 3517.


New Reno Support for Fast Recovery

TCP for Windows Server 2003 and Windows XP supports the Fast Recovery algorithm defined in RFC 2581, which defined the Reno algorithm. Although the Reno algorithm works well for single lost segments, it does not perform as well when there are multiple lost segments.

TCP for Windows Server 2008 and Windows Visa supports the New Reno algorithm defined in RFC 2582. The New Reno algorithm provides faster throughput by changing the way that senders can increase their sending rate during fast recovery when multiple segments in a window of data are lost and the sender receives a partial acknowledgment.

For details of the New Reno algorithm, see RFC 2582.


SummaryTo recover from lost TCP segments, TCP connections maintain an RTO for each segment. If the RTO expires, the segment is retransmitted, and the RTO is doubled for the retransmitted segment. After a maximum number of retransmissions, TCP abandons the connection. The RTO is based on calculations from samples of the RTT, using either a single sample per window of data or TCP timestamps. When TCP segments are sent without timestamps, TCP uses Karn’s algorithm to update the RTO when an ACK for a retransmitted segment is received.

ผู้��จั�ดทำ�

นงสวนรทำ�พย์� ปงใจั

รหั�ส 115130462012-3

กลุ่��ม 51346 CPE

7. 7 Chapter 13 Transmission Control Protocol (TCP) Retransmission and Time-Out.

Documents

Transcript of 7. 7 Chapter 13 Transmission Control Protocol (TCP) Retransmission and Time-Out.