[Tsvwg] reset of backoff with timestamps (RFC2988)

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
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg