Is the TCP Reno Fast Recovery algorithm really linear?

Question

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?

Answer 1

You are reading the picture wrong. Fast recovery is taking a very short amount of time ~1RTT: it starts when 3 dupacks arrive, then the missing segment is retransmitted and ACKed, which takes one RTT. Of course it is slightly longer if more packets get lost. Usually, such figures do not depict fast recovery. If you were trying to do so, fast recovery would look like a high peak ( about 2x cwnd max) in almost straight line up at 8, followed by drop to cwnd/2 and half of the transmission interval of constant cwnd time (this is not fast recovery, it happens immediately after)

The difference between TCP Tahoe and TCP Reno is that TCP Reno does not go into slow start after 3 dupacks. Instead it sets sstresh to half of cwnd and starts congestion avoidance. This happens after exiting fast recovery.

It also looks to me that the position of Reno line on the y-axis is wrong. The Reno line should start at cwnd = 6 , not 8.5. It should be parallel to the Tahoe line starting at round 12, but start at round 9.

Also, no, in reality the "congestion avoidance" line is not a line in units of time. It looks more like sqrt towards the peak. How much, depends on the size of the buffer at the bottleneck link. Cwnd does grow liner in transmission rounds, which correspond to RTTs. However, when window grows, Reno fills buffers at the bottleneck with more data, thus increasing queueing delay and as a consequence increasing RTT. With modern cheap memory, RTT can grow by a factor of 2 or more. Thus, while the line grows linear in transmission rounds, the duration of transmission rounds increases towards the drop, which results in the sqrt function.