0

I was going through the text Computer Networking- A Top-Down Approach by Kurose and Ross, there I found subtleties with the TCP congestion control FSM which is shown below:

TCP Congestion Control FSM

Mainly I am having difficulty in understanding the transition to the Fast Recovery state.

I cannot understand the Fast recovery state's action. Specifically, the Forouzan text says :

Most TCP implementations have two reactions:

  1. If a time-out occurs, there is a stronger possibility of congestion; a segment has probably been dropped in the network, and there is no news about the sent segments. In this case, TCP reacts strongly:

    a. It sets the value of the threshold to one-half of the current window size.

    b. It sets cwnd to the size of one segment.

    c. It starts the slow-start phase again.

  2. If three ACKs are received, there is a weaker possibility of congestion; a segment may have been dropped, but some segments after that may have arrived safely since three ACKs are received. This is called fast transmission and fast recovery. In this case, TCP has a weaker reaction:

    a. It sets the value of the threshold to one-half of the current window size.

    b. It sets cwnd to the value of the threshold (some implementations add three-segment sizes to the threshold).

    c. It starts the congestion avoidance phase.

In the Forouzan text, there is no such transition to the Fast Recovery state. But here in Kurose there is such a state and there is an arc labeled :

label

whose working I do not quite understand in detail. I mean when3 duplicate acknowledgments are received by the sender, it enters into the Fast recovery state, what is the 4th duplicate acknowledgment? Is it the one sent by 4th inorder packet after the lost packet, which is correctly received by the server?

I see Kurose uses the RFC 2581. I went through the RFC 2581 corresponding to TCP congestion control. I am just a newbie in the field of computer networks, as many things (which might be rather intuitive or trivial) are unknown to me. The thing is that the RFC 2581 describes the things in the same way as the Kurose text does (mostly). Except that Kurose explains it with an FSM, while RFC writes in a paragraph form (not a difference though). But the subtleties, where I am having problems are still unanswered. If one provides me a numerical example, then it shall help me understand the subtleties. In the fast recovery phase the RFC indeed talks about : Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window. It also talks about artificially inflating the cwnd and also deflating them in the fast recovery phase, but without a numerical illustration, I cannot quite understand it. Even Kurose uses these terms but sadly does not provide illustrations.

The RFC 2581 talks about a reference for illustration, but that reference contains examples/illustrations which are beyond my level of understanding (they are too difficult). The original RFC 793 as I see is much easier and Forouzan's text is loosely based on RFC 2581 and mostly RFC 793. Could anyone provide me with an illustration of inflating and deflating (especially how it shall work in a numerical problem) in the fast recovery phase ?

0

1 Answer 1

0

To understand inflation/deflation of cwnd one needs to understand how a sender in a window-based protocol chooses what segments to send. A good illustration for this is found here. Here is the figure from the reference for completeness.

enter image description here

Here's my attempt to explain how this figure works in fast recovery. Note, that i have drawn the figure in the opposite direction! SND.UNA is on the left and SND.WND grows to the right.

This is what happens after TCP has received 3 dupacks.

enter image description here

However, since 3 dupacks were received, we know that 3 segments have left the network, so 3 new segments can in principle be sent.

Fast recovery assumes that only the first segment is lost. So it does not retransmit other segments in the window. But, since the window cannot move, no new segments can be sent either.

In order to send new segments, window needs to be increased. It needs to be increased temporarily, i.e, after fast recovery ends, this increase is reverted. To do this, we just increase CWND by the number of new segments we want to send. This is what "inflating" means, and the smart word basically stands for temporary.

enter image description here

While we are in the fast recovery, further ACKs, for more segments in the original window are likely to arrive. Since the first one is lost, they will be dupacks acknowledging the same last received segment. These dupacks will cause cwnd to "inflate" further, i.e., window will increase by the number of dupacks received.

This is what happens right before the ack for the retransmitted segment arrives.

enter image description here

When the ACK arrives, since it acknowledges retransmitted segment, and all received segments after it, the window will move. The temporary increase in cwnd should be reverted, so cwnd is set back to its original value before fast recovery was entered. This is what "deflating" means.

After this TCP will set sstresh to cwnd/2, cwnd to sstresh and start congestion avoidance.

Note: the real cwnd is in bytes, not segments, so the figures are simplified.

Note also: fast recovery (in case of one segment lost) takes one RTT to complete: it starts when 3 dupacks arrive, then the missing segment is retransmitted and ACKed, which takes one RTT, and when the ACK arrives, fast recovery ends. You won't see fast recovery on most congestion window evolution diagrams.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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