Re: [tcpm] RFC 1323: Timestamps option

[obviously, without co-chair hat]

Hi Dave-

I am not going to vote yet.  I want to try to understand what you write
a little more ...

> One of the things that you lose by deferring enabling Timestamps is
> that you don't get the RTT measurements that Timestamps provide.
> Without Timestamps, using the typical BSD algorithm of timing one
> segment and waiting for an ACK, and adding in the Karn algorithm that
> you have to invalidate any measurements if you had to retransmit in
> that window, means that at best, you'll get one measurement per RTT.
> At worst, you can get in a state where you never get a valid RTT
> measurement.  When you use the Timestamps option, the worst case is
> that you'll only get one measurement per RTT, and the best case is
> that you'll get multiple valid samples,

So, 

  + I agree that getting into a state whereby you never get an RTT
    measurement is Not Good.

    (Although, one could think of ways to avoid this and we might also
    decide this is pathological.)

  + Why is the "best case" that you'll get multiple samples per RTT?  It
    seems to me that the underlying assumption is that "more is better",
    but I am not sure it is.  We have done some analysis that suggests
    more samples are not better.  I don't want to say our analysis is
    the last word here, but I'd be interested in hearing arguments for
    taking more samples [using the current RTO estimator] per RTT being
    a clear win.

    I think this is an important point in choosing a path.  I.e., if
    multiple RTT measurements matter then that might suggest a different
    approach than if multiple RTTs buy you little/nothing.

    Ref:

        Mark Allman, Vern Paxson.  On Estimating End-to-End Network Path
        Properties.  Proceedings of the ACM SIGCOMM Technical Symposium,
        Cambridge, MA, September 1999.
        http://www.icir.org/mallman/papers/estimation.ps

allman

-- 
Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/