Subject: [Tsvwg] reset of backoff with timestamps (RFC2988)

From: Andrei Gurtov <[email-masked]>
Date: Sat, 26 Jul 2003 14:42:26 -0700

Several people have noticed that not all TCPs reset the backoff of the retransmit 
timer in go-back-N after a new measurement sample is collected with timestamps. This 
results in unnecessarily long timeouts, which is especially a problem if fast
retransmits are disabled by "bugfix".

RFC2988:

  The only case when TCP can safely take RTT samples from retransmitted
  segments is when the TCP timestamp option [JBB92] is employed, since
  the timestamp option removes the ambiguity garding which instance
  of the data segment triggered the acknowledgment.

....

  Note that after retransmitting, once a new RTT measurement is
  obtained (which can only happen when new data has been sent and
  acknowledged), the computations outlined in section 2 are performed,
  including the computation of RTO, which may result in "collapsing"
  RTO back down after it has been subject to exponential backoff
  (rule 5.5).

The authors of RFC2988 and Sally Floyd agree that the second paragraph should 
also mention that a measurement can be taken earlier with timestamps. Therefore it's 
fine to reset the backoff when a new RTT sample is collected with timestamps.

Does TSV working group feel that it is appropriate? If yes, a following correction 
could be submitted to RFC errata. http://www.rfc-editor.org/errata.html

(which can only happen when new data has been sent and acknowledged *or 
if the timestamp option is used*)

Sally have made a change to ns2 to reflect this update.

Thanks,
Andrei

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 29 Jul 2003 13:39:23 +0200

At 23:42 26.07.2003, Andrei Gurtov wrote:
>Does TSV working group feel that it is appropriate? If yes, a following 
>correction could be submitted to RFC errata. 
>http://www.rfc-editor.org/errata.html
>
>(which can only happen when new data has been sent and acknowledged *or if 
>the timestamp option is used*)

This sounds fine to me. I always understood the text like that, anyway.

What this is saying is that the use of the TCP Timestamps option disables 
both parts of Karn's algorithm. That is, (1) an RTT sample can be taken 
from the ACK for retransmitted data, and (2) the RTO can be collapsed upon 
arrival of that ACK, i.e., it can be recomputed from SRTT and RTTVAR.

In fact, this is how it had already been implemented in BSD4.4-Lite.

///Reiner

---

From: Andrei Gurtov <[email-masked]>
Date: Tue, 29 Jul 2003 10:32:50 -0700

Reiner Ludwig wrote:

>> Does TSV working group feel that it is appropriate? If yes, a 
>> following correction could be submitted to RFC errata. 
>> (which can only happen when new data has been sent and acknowledged 
>> *or if the timestamp option is used*)
>
>
> What this is saying is that the use of the TCP Timestamps option 
> disables both parts of Karn's algorithm. That is, (1) an RTT sample 
> can be taken from the ACK for retransmitted data, and (2) the RTO can 
> be collapsed upon arrival of that ACK, i.e., it can be recomputed from 
> SRTT and RTTVAR.
>

Updating RTO and reset of the backoff counter are separate issues. For 
example, old ns2 code updated RTO using RTT samples from retransmitted 
segments, but backoff was reset only when go-back-N recovery is completed.

Andrei

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 30 Jul 2003 13:21:31 +0200

At 19:32 29.07.2003, Andrei Gurtov wrote:
>>from the ACK for retransmitted data, and (2) the RTO can be collapsed 
>>upon arrival of that ACK, i.e., it can be recomputed from SRTT and RTTVAR.
>>
>Updating RTO and reset of the backoff counter are separate issues.

Exactly. That's what I wanted to say. The first half of Karn's alg. does 
not allow taking an RTT sample from an ACK for retransmitted data while the 
second part of Karn's alg. suggests to *not* collapse the RTO upon that 
ACK, i.e., to reuse the backed-off RTO when restarting the retransmit timer.

And with timestamps none of the two parts are needed any longer.

>For example, old ns2 code updated RTO using RTT samples from retransmitted 

... and that was unnecessarily conservative. We had already fixed that in 
our ns2 code. So, the old ns2 code was not "compliant" with the BSD4.4-Lite 
code.

///Reiner