the timeout is happening because TCP sender is receiving no ACKs at all.
summary: yes, the timeout for the packet indicates that the ACK for this packet is not received for the duration of timeout, but, retransmissions usually happen after receiving dupacks, which usually happens before the timeout. Retransmitting something because of timeout is actually pretty rare.
TCP receiver has to acknowledge every received segment, irrespectively of whether this is an in-order or not in-order segment. In the latter case, TCP acknowledges last in-order received segment. For the sender, this means that if some packets are actually delivered, some acks are received. Also, when TCP receives several dupacks (by default 3), it assumes that the segment is lost and retransmits it. It also reacts to the congestion.
Under normal circumstances dupacks are received before timer fires. And when timer fires this is usually becase no acks are received at all [*]
This is the difference between just down lines, where TCP is not going in the slow start (e.g, after d1), and the lines after timeout. These are also referred to as minor and major congestion event respectively.
Minor event happens after receiving 3 dupacks. Since acks are received network is delivering some packets, so it is "believed to be not that congested"[**], and the reaction is not that severe. Major event happens after a timeout. If there are no ACKs received at all, TCP thinks that something significant happened, and starts from the beginning.
This something significant could for example happen if the path of packets has changed and new path has a bottleneck with much lower bandwidth.
- [*] tail losses are example of non-normal circumstances
- [**] appologies for my believe about the foundations of congestion control algorithms, but i guess thath is what you have to memorize