I'm reading through Computer Networking, 8th Edition by Kurose & Ross, and I came upon this figure(Figure 3.52 pictured below), which graphs the operation of TCP Tahoe & TCP Reno. The graph seems to indicate that the Fast Recovery algorithm utilized by TCP Reno has linear behavior(shown by the black line on the graph with TCP Reno written next to it), which doesn't make sense given the way Fast Recovery is described in RFC 2001:

1.  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)

2.  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.

3.  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.

Since in step 2, you "increment cwnd by the segment size, each time another duplicate ACK arrives", you very well might recieve a burst a duplicate ACKs after going into Fast Recovery mode, which seemingly wouldn't have linear behavior. But the book indicates it is indeed linear. What gives? Also, if it is indeed linear, and the book is correct, then TCP Reno's Fast Recovery mode seems to be growing at the same rate as TCP's congestion avoidance mode, suggesting they behave equivalently. If that's true, then why even bother with this whole complicated Fast Recovery business, when congestion avoidance mode behaves just the same?

I'm reading through Computer Networking, 8th Edition by Kurose & Ross, and I came upon this figure(Figure 3.52 pictured below), which graphs the operation of TCP Tahoe & TCP Reno. The graph seems to indicate that the Fast Recovery algorithm utilized by TCP Reno has linear behavior(shown by the black line on the graph with TCP Reno written next to it), which doesn't make sense given the way Fast Recovery is described in RFC 2001:

1.  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)

2.  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.

3.  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.

Since in step 2, you "increment cwnd by the segment size, each time another duplicate ACK arrives", you very well might recieve a burst a duplicate ACKs after going into Fast Recovery mode, which seemingly wouldn't have linear behavior. But the book indicates it is indeed linear. What gives? Also, if it is indeed linear, and the book is correct, then TCP Reno's Fast Recovery mode seems to be growing at the same rate as TCP's congestion avoidance mode, suggesting they behave equivalently. If that's true, then why even bother with this whole complicated Fast Recovery business, when congestion avoidance mode behaves just the same?

I'm reading through Computer Networking, 8th Edition by Kurose & Ross, and I came upon this figure(Figure 3.52 pictured below), which graphs the operation of TCP Tahoe & TCP Reno. The graph seems to indicate that the Fast Recovery algorithm utilized by TCP Reno has linear behavior(shown by the black line on the graph with TCP Reno written next to it), which doesn't make sense given the way Fast Recovery is described in TCP 2001:

1.  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)

2.  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.

3.  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.

Since in step 2, you "increment cwnd by the segment size, each time another duplicate ACK arrives", you very well might recieve a burst a duplicate ACKs after going into Fast Recovery mode, which seemingly wouldn't have linear behavior. But the book indicates it is indeed linear. What gives? Also, if it is indeed linear, and the book is correct, then TCP Reno's Fast Recovery mode seems to be growing at the same rate as TCP's congestion avoidance mode, suggesting they behave equivalently. If that's true, then why even bother with this whole complicated Fast Recovery business, when congestion avoidance mode behaves just the same?

I'm reading through Computer Networking, 8th Edition by Kurose & Ross, and I came upon this figure(Figure 3.52 pictured below), which graphs the operation of TCP Tahoe & TCP Reno. The graph seems to indicate that the Fast Recovery algorithm utilized by TCP Reno has linear behavior(shown by the black line on the graph with TCP Reno written next to it), which doesn't make sense given the way Fast Recovery is described in RFC 2001:

1.  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)

2.  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.

3.  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.

Since in step 2, you "increment cwnd by the segment size, each time another duplicate ACK arrives", you very well might recieve a burst a duplicate ACKs after going into Fast Recovery mode, which seemingly wouldn't have linear behavior. But the book indicates it is indeed linear. What gives? Also, if it is indeed linear, and the book is correct, then TCP Reno's Fast Recovery mode seems to be growing at the same rate as TCP's congestion avoidance mode, suggesting they behave equivalently. If that's true, then why even bother with this whole complicated Fast Recovery business, when congestion avoidance mode behaves just the same?