[e2e] How could I know one RTT estimation techniques better than

[David P. Reed]

Good points.  I don't think it is wise to decouple the algorithm too much 
from its use - it only needs to be accurate when the data is actually used.

There is another point underlying this - the RTT estimator generates 
results which are used as a function of the input event time (the sending 
of a message expected to be acknowledged, usually).   The measure needs to 
become available at about the time the RTO would be used - which is the 
time of expected arrival itself.   So there are a finite number of points 
when the statistic used to evaluate the RTT estimator must be evaluated - 
all other points in time do not exist from the point of view of quality 
statistics.

For this reason, decoupling the RTT quality statistic from the actual 
packet send/arrival event stream seems to be problematic.

At 05:57 AM 6/1/2004, Craig Partridge wrote:

>I don't think anyone's ever studied in great detail what the standards
>for an RTT estimation algorithm should be.  However, what people have
>typically used in the path is something like this.
>
>First, remember that the key issue is the RTO algorithm -- the RTT
>estimator is used to set a timeout function using the RTO value -- and
>what you really care about is when a timeout goes off.
>
>Given you are evaluating when timeouts occur, there are two goals:
>
>     1. Few or no spurious timeouts.  That is, if the timeout goes off,
>       the packet is, with very high probability, lost.  Furthermore, this
>       is with very high probability over just about any network path
>       you can imagine (including flapping network lines, wireless, etc).
>
>     2. Timeouts that occur soon in cases where a packet is really lost.
>
>In short, the perfect RTO algorithm would never timeout when a packet isn't
>lost, and timeout the moment a packet is lost.
>
>The goals are ordered -- if you've got lots of spurious timeouts, your
>algorithm is no good.   If timeouts take a little while when packets are
>lost, that's OK.
>
>Thanks!
>
>Craig
>
>
>In message <1085755247.40b74f6f9f261 at www.e-web.uum.edu.my>, "Osman Ghazali 
>(FTM
>)" writes:
>
> >Hi,
> >I have two layered multicast protocols (LMPs). The protocols use different
> >RTT eatimation techniques. I created another LMP exactly the same
> >as the first LMP but with the second LMP's RTT estimation technique.The
> >problem I have now is how could I know which RTT estimation is more
> >appropriate/accurate/better for layered multicast. Is there any metric
> >for RTT or any way we can evaluate RTT estimation techniques.
> >
> >Thank you.
> >Osman