Receiver is A , and sender is B
The receiver sets the window size to 1000, and B sends segments.
Assume that segment 500 to 521 is lost.
Then receiver A would send an ack of 501 to the sender. Once the sender receives the ack of 501 it will then start sending segments 501 to 1000 again.
Does the sender send all 501 upto 1000 without expecting a acknowledgement in the middle?
No, the sender will expect acks in the normal fashion.
The best way to think of this is in most basic primitives for the sender: send, receive ack, mark as received (many sequences run parallel of course). If sent but not ack'd, try entire procedure again.
This also works for packetloss on the acks, not just the data. TCP's (= most implementations) coping with heavy packetloss is best described as "it barely works"
I'm curious as to why you need such detailed knowledge, is it applicable to a practical problem?
It seems more like a homework :> If it's not an excercise , it would be better to tell us which TCP you are using (Reno, Vegas, Tahoe , ... ) ?
Just to answer your question .. Sender will wait for a timeout before retransmitting the packet. To limit this delay (in some cases), some implementations support triple ack. If Receiver find a corrupted package instead of doing nothing it sends back a triple-ack. Thus, when sender receives that he start the transmission immediately.
Moreover, it depends if your implementation is using go-back-n, selective repeat etc. Different approaches are followed in every case.