What happens at the time-out is actually pretty clear from the drawing... The congestion window size drops back to its original value of 1 and slow start is run again.
The specifics of how a TCP stack will handle congestion events depend on what variant you are using. This drawing looks like an example of the TCP Reno algorithm.
When seeing 3 duplicate ACKs, TCP Reno concludes there is congestion, but the network is still working since some segments were ack-ed. In case of a time-out, the situation is worse: the network seems completely unresponsive. Actually, the fact that duplicate acks are being received before a retransmit timer expires means segments are still being received by the other side, even though some may have been lost (or re-ordered).
So, in case of the 3 duplicate acks, the congestion window is cut in half and then increased linearly. This is known as fast recovery, and its goal is actually to avoid waiting for retransmission timeouts.
When a retransmit time-out does occur, the reaction is more drastic. TCP Reno starts over with slow start from a congestion window of size 1, and a slow start threshold of half of the value of the congestion window when the time-out occurred. When the threshold is reached, increase becomes linear again (additive increase).
TCP Tahoe did not include fast recovery, and would react the same way in both cases, resetting the congestion window to its initial value and executing slow start. TCP Reno's fast recovery basically skips the slow start, immediately setting the congestion window to the threshold value and starting the linear increase.
Note that many more variants exist and actual implemantations can be more complex. Also observing these algorithms at work is not easy because other TCP mechanisms can interfere.
I do not know whether what you had in mind (using fast recovery in both situations) exists as a known and implemented congestion avoidance algorithm. It was probably tested and discarded when Reno was implemented. Feel free to do some digging around in the scientific papers in this area.
You're referring to 'Fast Retransmit' in the TCP Reno implementation. It is basically an assumption.
RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms covers this:
Since TCP does not know whether a duplicate ACK is caused by a lost
segment or just a reordering of segments, it waits for a small number
of duplicate ACKs to be received.
It is assumed that if there is just a reordering of the segments,
there will be only one or two duplicate ACKs before the reordered
segment is processed, which will then generate a new ACK. If three or
more duplicate ACKs are received in a row, it is a strong indication
that a segment has been lost.
The key here is that Reno wants to avoid slow-start it makes the assumption that 3 dup-acks received without any intervening packets is the receiver indicating that it wants that single segment resent(fast re-transmit). If a timeout occurs that is when Reno will trigger slow start.
RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, Section 4, Fast Recovery:
After fast retransmit sends what appears to be the missing segment,
congestion avoidance, but not slow start is performed. This is the
fast recovery algorithm. It is an improvement that allows high
throughput under moderate congestion, especially for large windows.
The reason for not performing slow start in this case is that the
receipt of the duplicate ACKs tells TCP more than just a packet has
been lost. Since the receiver can only generate the duplicate ACK
when another segment is received, that segment has left the network
and is in the receiver's buffer. That is, there is still data flowing
between the two ends, and TCP does not want to reduce the flow
abruptly by going into slow start.
The fast retransmit and fast recovery algorithms are usually
implemented together as follows.
When the third duplicate ACK in a row is received, set ssthresh to
one-half the current congestion window, cwnd, but no less than two
segments. Retransmit the missing segment. Set cwnd to ssthresh
plus 3 times the segment size. This inflates the congestion window
by the number of segments that have left the network and which the
other end has cached (3).
Each time another duplicate ACK arrives, increment cwnd by the
segment size. This inflates the congestion window for the
additional segment that has left the network. Transmit a
packet, if allowed by the new value of cwnd.
When the next ACK arrives that acknowledges new data, set cwnd
to ssthresh (the value set in step 1). This ACK should be the
acknowledgment of the retransmission from step 1, one round-trip
time after the retransmission. Additionally, this ACK should
acknowledge all the intermediate segments sent between the lost
packet and the receipt of the first duplicate ACK. This step is
congestion avoidance, since TCP is down to one-half the rate it
was at when the packet was lost.
The fast retransmit algorithm first appeared in the 4.3BSD Tahoe
release, and it was followed by slow start. The fast recovery
algorithm appeared in the 4.3BSD Reno release.
Best Answer
Some TCP retransmission is normal, but this looks excessive. Looks like you have packet loss and will have to "walk the line" and check physical connections, cabling, speed/duplex mismatches. Check out the link below.
https://www.performancevision.com/blog/network-packet-loss-retransmissions-and-duplicate-acknowledgements/
Cheers,
Errdisabled