An Investigation into Transport Protocols and Data Transport ...

4.5. TCP Variants 65
connection initially starts off in slow start, until in the 4 th RTT packet loss is
detected and ssthresh is calculated as half of the number of packets in flight.
As TCP Tahoe always restarts the connection in slow start, cwnd is set to
1 packet and cwnd slow starts up to ssthresh. When cwnd ≥ ssthresh
the TCP connection enters congestion avoidance until packet loss is again
detected. The cycle continues until the 21 st RTT when a network timeout
occurs whereby ssthresh is recalculated and cwnd is set to 1 packet.
4.5.2 TCP Reno
In 1990, Van Jacobson refined the congestion control algorithm. He noted
that congestion control should do two things: prevent the pipe from going
empty after a loss (as if it doesn’t go empty, the TCP flow does not have to
spend time refilling it again) and correctly account for all data that is actually
in the pipe (as congestion avoidance should be estimating and adapting to
the rate).
As a consequence of this chain of thought, TCP Reno [Jac88] introduces
major improvements over Tahoe. It still maintains all of the features of TCP
Tahoe (such as the improved RT O calculation and slow start after a timeout)
but changes the way in which it reacts when a loss is detected upon duplicate
acknowledgments.
The concept is that should the network be heavily congested, the receipt
of acks will stop (as the receiver will not receive any data packets to respond
acknowledgments to). Therefore it is highly likely timeouts only occur when
the network undergoes heavy congestion, and that the receipt of dupack
signifies that the network is only moderately congested.
Therefore, the implementation of slow start after a Fast Retransmit in