TCP Timeout and retransmission (3)

Example

The first line of Figure 14-7 (number indicates), the first time ACK 23801 is received

The window update at time 0.853 was an ACK with a duplicate sequence number (because no data are being carried) but contains A change to the TCP Flow Control window.

Thus, it isn't counted toward the three-duplicate-ack threshold required to initiate a fast retransmit.

The packets arriving at times 0.890, 0.926, and 0.964 is all duplicate ACKs for sequence number 23801.

The arrival of the third of these duplicate ACKs triggers the fast retransmit of segment 23801 at time 0.993.

The second retransmission (at 1.326s) was somewhat different from the first.

When the first retransmission takes place, the sending TCP notes the highest sequence num-ber it had sent just before it performed the retransmission

(43401 + 1400 = 44801). This is called the recovery poinT.

TCP is considered to being recovering from loss after a retransmission until it receives an ACK that matches or exceeds the sequence number of the recovery point.

In this example, the ACKs at times 1.322 and 1.321 is not for 44801, but instead for 26601.

This was larger than the previous highest ACK value seen (23801), but not enough to meet or exceed the Reco Very point (44801).

This type of ACK is called a, partial ack for this reason.

When Par-tial ACKs arrive, the sending TCP immediately sends the segment so appears to being missing (26601 in th is case) and

continues this to until the recovery point is matched or exceeded by an arriving ACK.

If permitted by congestion control Pro-cedures (see Chapter), it may also send new data it had not yet sent.

Retransmission with selective acknowledgments

Data with sequence numbers beyond the holes be called out-of-sequence data because that data was not Contiguo US,

In terms of it sequence numbers, with the other data the receiver has already received.

In many circumstances, the properly operating SACK sender are able to fill these holes + quickly and with fewer Unnecessary retransmissions than

A comparable non-sack sender because it does not having to wait for the entire RTT to learn about additional holes.

With three distinct blocks, up to three holes can is reported to the sender.

If not limited by congestion control (see Chapter), all three could is filled within one round-trip time using A sack-capable sender.

SACK Receiver Behavior

The receiver places in the first SACK block the sequence number range con-tained in the segment it had most recently< /c1> received.

Because the space in a SACK option is limited, it's best to ensure and the most recent information are always PR Ovided to the sending TCP, if possible.

Other SACK blocks is listed in the order in which they appeared as first blocks in previous SACK options.

That is, they was filled in by repeating The very recently sent SACK blocks (in other segments) that's not subs ETS of another block about to being placed in the option being constructed.

The purpose of including more than one SACK block in a SACK option and repeating these blocks across multiple SACKs are to Provide Some redundancy in the case where SACKs is lost.

... Unfortunately, SACKs and regular ACKs are sometimes lost and is not retrans-mitted by TCP unless they contain data (or T He SYN or FIN control bit fields is turned on).

SACK Sender Behavior

One-out-of-the-box it can do keep a "sacked" indication-segment in its retransmission buffer

That's set whenever a corresponding range of sequence numbers arrives in a SACK.

The simplest approach is to has the sender first fill the holes at the receiver and then move on to Sen d more new data [RFC3517]

If the congestion control pro-cedures allow. The most common approach.

There is one exception to this behavior.

In [RFC2018], the current specification for SACK options, SACK blocks is considered advisory.

This means, a receiver could provide a SACK to the sender indicating that some sequence numbers has been rec Eived successfully and then change their mind later ("Renege").

Because of this, the SACK sender isn't able to free its retransmission buffer of data it had received only a SAC K for;

It is permitted to free a block of data only once the regu-lar TCP ACK Number of the receiver have passed by the highest sequence number of this data.

Example

These options (sack-permitted option) is present only at Connection setup, and thus they only ever appear in Segme NTS with the SYN bit field set.

Here we see the ACK for 23801 contains a SACK block of [25201,26601] (This is the Out-of-order block), indica Ting a hole at the receiver.

The receiver is missing the sequence number range [23801,25200], which corresponds to the single 1400-byte packet starting With sequence number 23801.

Note that this SACK is a window update and are not counted as a duplicate ACK for the reasons discussed earlier ( ?).

It does not trigger fast retransmit.

The SACK arriving at time 0.967 contains , SACK blocks: [28001,29401] and [25201,26601].

Recall the first SACK blocks from previous SACKs is repeated in later positions in subsequent SACKs for Rob Ustness against ACK loss.

This SACK was a duplicate ACK for sequence number 23801 and suggests that receiver now requires the F Ull-size segments starting with sequence numbers 23801 and 26601.

The sender reacts immediately by initiating fast retransmit and because of conges-tion control procedures (see Chapter 1 6), the sender sends only one retransmis-sion, for segment 23801.

With the arrival of both additional ACKs, the sender is permitted to send its second retransmission, for segment 2 6601.

A TCP SACK Sender uses the recovery point idea introduced with NewReno.

In this example, the highest sequence number sent prior to the retransmission are 43400, which is lower than in the NewReno Example from Figure 14-5.

For this implementation of SACK fast retransmit, three duplicate ACKs is not required;

The TCP initiates its retransmission earlier. The recovery exit is essentially the same, though.

Once the ACK for sequence number 43401 are received at time 1.3958, recovery are complete.

The benefits of SACKs was more pronounced when the RTT was large and packet loss is severe.

Under such circumstances, the benefits of being able to fill more than one hole per RTT is likely to being more signific Ant.

TCP Timeout and retransmission (3)