An Investigation into Transport Protocols and Data Transport ...

4.5. TCP Variants 66
TCP Tahoe completely destroys the ack clock unnecessarily and is too conservative
in its rate reduction.
Given this assumption, under moderate loads the sender should be able
to keep on sending data since the flow still exists (as the equilibrium has not
been completely destroyed). However, the sender should be sending with less
vigour to utilise less resources in order to prevent congestion collapse.
As such, Reno introduces a mechanism called Fast Recovery [Ste97] which
should be activated after a Fast Retransmit.
Recall that Fast Retransmits
will cause the sender to retransmit the lost packet after receiving three
dupacks. However, under Reno, it will not fall back to slow start, but instead,
it should take advantage of the fact that the flow that currently exists
should keep on sending, but using less resources.
By using Fast Recovery, the sender calculates half the number of packets
in-flight just before loss detection. It sets ssthresh to this value and then
subsequently also sets cwnd to the same value, rather than to one packet as
in Tahoe 5 . As such, this forces TCP Reno to send fewer packets out and
therefore it has indeed reduced its utilisation of the network.
As ssthresh is also updated upon congestion, TCP Reno is therefore also
able to quickly revert back to congestion avoidance should a RT O expiration
occur (causing the TCP flow to enter slow start).
But the shrinking of cwnd means that the TCP flow has already sent out
all the packets that are contained within the window and therefore there is
no way of sending out new packets unless the window is forced to include the
new ones. As the receipt of dupacks under Tahoe does not move this window,
then the only way to shift the window is to (artificially) inflate the size of
5 Actually, it is set to half of the the number of packets in flight before the loss plus 3
packets to signify the data segments that have been acknowledged by the 3 dupacks.