Why doesn't TCP have an "I lost a packet" message? Is it just that no one thought of it until too late? Hacking around the problem by sending multiple ACK's sounds inefficient.
How would the receiver know a packet was lost? If only one packet was sent, it cannot know, so you always need a retransmit timer at the sender as the ultimate backstop for reliability. Any other trigger of retransmissions is an optimization.
Now, why not a NACK rather than relying on duplicate ACKs? First, the NACK can get lost, so you'd probably want to trigger fast retransmit off of duplicate ACKs anyway for efficiency. But when should the receiver send a NACK? Given that packets can be reordered, likely you want to wait for a few subsequent packets to arrive before you send the NACK. In that time, you've been acking the arriving packets. So your NACK will arrive just after the sender has concluded the packet was lost from the arriving duplicate ACKs. At this point the NACK is serving no purpose.
Even if you wanted to change TCP and assume no packets were reordered, so send a NACK as soon as the packet after the missing one arrives, you'd still be ACKing the arriving packet (which due to TCP's cumulative ACK appears to the sender as a duplicate ACK). The sender could just as well retransmit after one duplicate ACK and get he same behaviour. In the end, sending a NACK doesn't really add anything.
Don't know about TCP. In the 90s, I hand implemented a data/file transfer protocol over trunking radio - a very data unfriendly medium with pretty bad loss rates.
I thought about "I lost a packet" message, but if it got lost in transmission, sender would never know to resend the packet. Instead, the sender had the responsibility of keeping track of which packets it received an ACK for. If it didn't receive the ACK, it would resend the packet within a certain interval and wait for another ACK.
