Craig Partridge (craig@LOKI.BBN.COM)
Wed, 08 Apr 87 12:21:54 -0400
I've been looking at the same problem from the perspective of
RDP for some months. Some of my conclusions are in a paper I'm
presenting at the June USENIX. Most of them are the same as yours,
except I came up with a different selection algorithm based on the
assumption that the network *usually* maintains relative order
(if packet A is sent before packet B, then is is likely that A
will reach the destination before B).
By the way, in support of the view that we need to look at
retransmission timeouts, I've seen the SRTT explode at loss rates
below 10% on some systems.
One other point -- your algorithm is engaged in throwing away a
certain number of good RTT values because the filtering isn't perfect.
If the RTT suddenly increases sharply, you have to throw out the first
packet that has the new RTT, and wait for the second packet to be
accepted. Out of curiousity, what is beta in your implementation?
I.e., how much does the RTT have to increase to cause this problem?
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:07 GMT