> In my opinion, connections using SACK and Limited transmit can afford having
> a conservative RTO since they suffer non-spurious timeouts infrequently.
If I am not mistaken, rule 5.3 of RFC 2988 restarts the timer only if
new data is ack'ed. Duplicate acks do not ack new data. So rule 5.3
does not help in the above cases. It does not even restart the timer for
fast retransmit.
> RFC2988 is a good starting point to provide a conservative enough timer
> suitable for wireless environment. The next step could be to use
> non-decreasing version of the timer, i.e. to use only RTT samples that
> increase the RTO value. This way the RTO timer becomes the estimate of the
> highest RTT value observed on this connection so far.
The question is if RFC 2988 works because of coincidence or it
has a solid foundation. I still do not understand the reason
behind restarting the timer when an ack for new data arrives.
It does delay a timeout, but for what reason?
I do not think using the above suggested method is a good idea.
we may as well use a fixed timeout of the max we know of for today's
Internet (-:
K. Poon.
kcpoon@eng.sun.com
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST