How retransmission timer is set/reset in TCP after receiving ACK?

Question

I come across following, while reading TCP from Forouzan's book:

We can define the following rules for the retransmission timer:

1. When TCP sends the segment in front of the sending queue, it starts the timer.
2. When the timer expires, TCP resends the first segment in front of the queue, and restarts the timer.
3. When a segment or segments are cumulatively acknowledged, the segment or segments are purged from the queue.
4. If the queue is empty, TCP stops the timer; otherwise, TCP restarts the timer.

My doubt is what happens to timer when we receive ACK for segment for which we started timer? Is it simply reset for any segment which will be sent in future? (Note that I am effectively asking what happens to timer after purging segments as stated in point 3.)

Answer 1

When an ACK is received the according segment is done.

what happens to timer when we receive ACK for segment for which we started timer?

We restart the timer for the next segment's ACK, so we know when it's overdue. The timer is a conservative estimate for the period in which the next ACK is to be expected.

If the timer expires the segment or ACK has likely been lost and the segment is retransmitted. If the ACK arrives in time everything's fine, the next segment in queue moves into the window. It is sent and we proceed to time the next ACK (which actually is for a previously sent segment).

Answer 2

This is Reno/Tahoe TCP. Most systems use cubic now. But the algorithm went something like this.

1. New flow - set 3 sec rtxtimer
2. Send syn, get SYN ACK in 100ms RTXtimer = .8Rtxtimer + .2100ms = 2.4 secs so, most of the old value, some of the new
3. Get Req to ack 100ms RTX timer = .8Rtxtimer +.2100ms = 1.9 secs
4. after 10 packets RTXtimer ~ 500ms
5. after 20 packets RTXtimer ~ 140ms

6 .if Loss double rtxtimer

Ver slow to figure out the real RTT which is why they came up with duplicate acks (fast retransmit requests).