2

My question is, in which cases is the Fast Recovery activarted ?

Like we have done a Fast Retransmit does it mean that Fast Recovery must be used as well ? For example, we lose a segment and send it by fast retransmit... is it necessary to do fast recovery ?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 15 '17 at 4:11
2

You should understand that there are a variety of TCP congestion control schemes, and "Reno" and "NewReno" are the ones which implement fast retransmit, but others do not because it is not a requirement to use a particular congestion control scheme. Notice the use of the word, "SHOULD," in the RFC, which means that this is not a requirement.

Fast recovery is used with with fast retransmit. RFC 2581, TCP Congestion Control explains this in the third paragraph of Section 3.2:

3.2 Fast Retransmit/Fast Recovery

A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives. The purpose of this ACK is to inform the sender that a segment was received out-of-order and which sequence number is expected. From the sender's perspective, duplicate ACKs can be caused by a number of network problems. First, they can be caused by dropped segments. In this case, all segments after the dropped segment will trigger duplicate ACKs. Second, duplicate ACKs can be caused by the re-ordering of data segments by the network (not a rare event along some network paths [Pax97]). Finally, duplicate ACKs can be caused by replication of ACK or data segments by the network. In addition, a TCP receiver SHOULD send an immediate ACK when the incoming segment fills in all or part of a gap in the sequence space. This will generate more timely information for a sender recovering from a loss through a retransmission timeout, a fast retransmit, or an experimental loss recovery algorithm, such as NewReno [FH98].

The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire.

After the fast retransmit algorithm sends what appears to be the missing segment, the "fast recovery" algorithm governs the transmission of new data until a non-duplicate ACK arrives. The reason for not performing slow start is that the receipt of the duplicate ACKs not only indicates that a segment has been lost, but also that segments are most likely leaving the network (although a massive segment duplication by the network can invalidate this conclusion). In other words, since the receiver can only generate a duplicate ACK when a segment has arrived, that segment has left the network and is in the receiver's buffer, so we know it is no longer consuming network resources. Furthermore, since the ACK "clock" [Jac88] is preserved, the TCP sender can continue to transmit new segments (although transmission must continue using a reduced cwnd).

The fast retransmit and fast recovery algorithms are usually implemented together as follows.

  1. When the third duplicate ACK is received, set ssthresh to no more than the value given in equation 3.

  2. Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and which the receiver has buffered.

  3. For each additional duplicate ACK received, increment cwnd by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network.

  4. Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window.

  5. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This is termed "deflating" the window.

    This ACK should be the acknowledgment elicited by the retransmission from step 1, one RTT after the retransmission (though it may arrive sooner in the presence of significant out- of-order delivery of data segments at the receiver). Additionally, this ACK should acknowledge all the intermediate segments sent between the lost segment and the receipt of the third duplicate ACK, if none of these were lost.

Note: This algorithm is known to generally not recover very efficiently from multiple losses in a single flight of packets [FF96]. One proposed set of modifications to address this problem can be found in [FH98].

| improve this answer | |
  • Thanks for your answer. but a bit unclear for me on the characteristics of fast recovery. i am studying a wireshark output and i see fast transmission but i cant spot the fast recovery. btw i even see like 2 duplicates after fast transmisson is that a health behaviour? – pabloBar Oct 3 '16 at 17:33
  • As I cautioned, not every TCP implementation uses the same TCP congestion control implementation. In fact, some don't use any at all. What your implementation uses could even be different on each side of the TCP connection. There are just too many TCP congestion control schemes out there, and more are being created everyday. – Ron Maupin Oct 3 '16 at 17:36
  • And how does the fast recovery affect the sequence number (if any effect at all)? – pabloBar Oct 3 '16 at 17:54
  • The sequence number used on a segment is the sequence number of that segment, even if a segment is retransmitted. It is basically the position in the stream of the segment. – Ron Maupin Oct 3 '16 at 18:00
  • in the graph(stevens tcptrace) i see some dropps in the segment sequence. for example seq= 40000, seq 25000 and then seq=80000. does it tell us anthing about fast recovery ? – pabloBar Oct 3 '16 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.