Based on their understanding of the Fast Retransmit algorithm, I believe the authors are giving you their real-world idea of what to expect. Understand, this is the authors' idea. Even your argument is made with some assumptions which may, or may not, be congruent with the authors' assumptions. You could contact the authors for clarification. A simple search turns up a verified e-mail address for Larry Peterson at the University of Arizona.
3.2 Fast Retransmit/Fast Recovery
A TCP receiver SHOULD send an immediate duplicate ACK when an out-
of-order segment arrives. The purpose of this ACK is to inform the
sender that a segment was received out-of-order and which sequence
number is expected. From the sender's perspective, duplicate ACKs
can be caused by a number of network problems. First, they can be
caused by dropped segments. In this case, all segments after the
dropped segment will trigger duplicate ACKs. Second, duplicate ACKs
can be caused by the re-ordering of data segments by the network (not
a rare event along some network paths [Pax97]). Finally, duplicate
ACKs can be caused by replication of ACK or data segments by the
network. In addition, a TCP receiver SHOULD send an immediate ACK
when the incoming segment fills in all or part of a gap in the
sequence space. This will generate more timely information for a
sender recovering from a loss through a retransmission timeout, a
fast retransmit, or an experimental loss recovery algorithm, such as
NewReno [FH98].
The TCP sender SHOULD use the "fast retransmit" algorithm to detect
and repair loss, based on incoming duplicate ACKs. The fast
retransmit algorithm uses the arrival of 3 duplicate ACKs (4
identical ACKs without the arrival of any other intervening packets)
as an indication that a segment has been lost. After receiving 3
duplicate ACKs, TCP performs a retransmission of what appears to be
the missing segment, without waiting for the retransmission timer to
expire.
After the fast retransmit algorithm sends what appears to be the
missing segment, the "fast recovery" algorithm governs the
transmission of new data until a non-duplicate ACK arrives. The
reason for not performing slow start is that the receipt of the
duplicate ACKs not only indicates that a segment has been lost, but
also that segments are most likely leaving the network (although a
massive segment duplication by the network can invalidate this
conclusion). In other words, since the receiver can only generate a
duplicate ACK when a segment has arrived, that segment has left the
network and is in the receiver's buffer, so we know it is no longer
consuming network resources. Furthermore, since the ACK "clock"
[Jac88] is preserved, the TCP sender can continue to transmit new
segments (although transmission must continue using a reduced cwnd).
The fast retransmit and fast recovery algorithms are usually
implemented together as follows.
When the third duplicate ACK is received, set ssthresh to no more
than the value given in equation 3.
Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS.
This artificially "inflates" the congestion window by the number
of segments (three) that have left the network and which the
receiver has buffered.
For each additional duplicate ACK received, increment cwnd by
SMSS. This artificially inflates the congestion window in order
to reflect the additional segment that has left the network.
Transmit a segment, if allowed by the new value of cwnd and the
receiver's advertised window.
When the next ACK arrives that acknowledges new data, set cwnd to
ssthresh (the value set in step 1). This is termed "deflating"
the window.
This ACK should be the acknowledgment elicited by the
retransmission from step 1, one RTT after the retransmission
(though it may arrive sooner in the presence of significant out-
of-order delivery of data segments at the receiver).
Additionally, this ACK should acknowledge all the intermediate
segments sent between the lost segment and the receipt of the
third duplicate ACK, if none of these were lost.
Note: This algorithm is known to generally not recover very
efficiently from multiple losses in a single flight of packets [FF96].
One proposed set of modifications to address this problem can be found
in [FH98].
Best Answer
That would just lead back to circuit-switched networks like the original PSTN (Public Switched Telephone Network). The government funded research into packet-switched networks (result: Internet) to overcome the limitations of circuit-switched networks.
In a circuit-switched network, or what you propose, one caller or packet would monopolize the circuit or path until it is done, not giving anyone or any other process process a chance to use the circuit or path until it is done. Breaking things up into smaller packets means that you can share the circuit among callers or processes. Each IP packet is routed independently, so a packet follows a path to the destination, regardless of the path any other packet took to the same destination. If the path loses a link, then the routers in the path can reroute packets to a different path to the destination, and the sender does not know or care.
The big driver of the government funding was the threat of disaster (including nuclear war, which was a big threat in the 1960s and 1970s). If you are making a call (say to respond to ICBM launches), and the telephone company central office is destroyed, then you lose the call and need to start all over, manually rerouting the call. The same holds true for a giant data packet. If you break things up into smaller packets, and there is an interruption in the path, the rest of the packets can automatically be re-routed around the damage.
So, in the simple case you get to share the circuit or path, and you lose very little in the event of a circuit or path interruption.
TCP takes a stream of data (can be very large) and segments it into PDUs (Protocol Data Units) we call segments. The segments fit into the IP packets, which fit into the data-link protocol frames. TCP is a very large subject, far too large to explain it all in a site like this.
Once you understand the reasons for the different layers in the network stack (abstraction and encapsulation), you will see how that works. Basically, the data-link protocol is responsible for delivering frames in the local network, IP is responsible for delivering packets between networks, and a transport protocol like TCP is responsible for delivering datagrams between host processes on different hosts.