Re: [tcpm] WGLC for draft-ietf-tcpm-1323bis

["Scheffenegger, Richard" <[e-mail]>]

Hi Mark,

>   - 3.1: "Many TCP implementations base their RTT measurements upon
>     a sample of one segment per window or less.  While this yields
>     an adequate approximation to the RTT for small windows, it
>     results in an unacceptably poor RTT estimate for a LFN."
> 
>     Do you have evidence of this?  We have evidence you're wrong:
> 
>       Mark Allman, Vern Paxson.  On Estimating End-to-End Network
>       Path Properties.  Proceedings of the ACM SIGCOMM Technical
>       Symposium, Cambridge, MA, September 1999.
> 
>     That shows that the number of samples per RTT is pretty
>     immaterial to the effectiveness of the RTO.

I'd like to point out, that the whole section 3 does not make a clear distinction between *timely measuring* RTT, and using that measured RTT for further purposes, such as arriving at a useful value for RTO.

We can also argue about the specific wording in the 2nd sentence; But it appears to me, that you read "poor RTT estimate == poor RTO estimate"?

>   - 3.1: "RTT estimator".  Note, TCP does not have an "RTT
>     estimator".  Scrub this from the document.  We have an "RTO
>     estimator".  These are different things.  Confusing them is a
>     fundamental mistake.

Correct. And IMHO 1323 is looking at RTT, but, agreed, only with the intended purpose of refining RTO (where these improvements haven't been as beneficial as originally envisioned).

I rewrote the section 3.1 entirely:

3.  TCP Timestamp Option

3.1.  Introduction

   TCP measures the round trip time (RTT), primarily for the purpose of
   arriving at a decent value for the Retransmission Timeout (RTO) timer
   interval.  Accurate and current RTT estimates are necessary to adapt
   to changing traffic conditions, while a conservative estimate of the
   RTO inveral is necessary to minimize spurious RTOs.

   When [RFC1323] was originally written, it was perceived that more
   timely and accurate RTT measurements would contribute to reducing
   spurious RTOs, while maintaining their timeliness.  At the time, RTO
   was also the only mechanism to make use of the measured RTT.  It has
   been shown, that taking more RTT samples has only a very limited
   effect to optimize RTOs [Allman99].

   This document makes a clear distinction between the round trip time
   measurement (RTTM) mechanism, and subsequent mechanisms using the RTT
   signal as input, such as RTO (see Section 3.4).

   It is important to use the timestamp option with big windows, to
   allow the use of the PAWS mechanism (see Section 4).  Furthermore,
   the option is useful for all TCP's, since it simplifies the sender
   and allows the use of additional optimizations such as Eifel
   ([RFC3522], [RFC4015]) and others.

3.2.  Timestamp Option

And made the last paragraph of 3.3 a dedicated section, for the separation between RTTM and RTO:

3.4.  Updating the RTO value

   [KL04] has highlighted the problem that an unmodified RTO
   calculation, which is updated with per-packet RTT samples, will
   truncate the path history too soon.  This can lead to an increase in
   spurious retransmissions, when the path properties vary in the order
   of a few RTTs, but a high number of RTT samples are taken on a much
   shorter timescale.

   Implementers should note that with timestamps multiple RTTMs can be
   taken per RTT.  The [RFC6298] RTO estimator has weighting factors,
   alpha and beta, based on an implicit assumption that at most one RTTM
   will be sampled per RTT.  When using multiple RTTMs per RTT to update
   the RTO estimator, the weighting factor SHOULD be decreased to take
   into account the more frequent RTTMs.

   For example, an implementation could choose to

   o  just use one sample per RTT to update the RTO estimator, or

   o  vary the gain based on the congestion window, or

   o  take an average of all the RTT measurements (and the maximum of
      the variance) received over one RTT,

   and then use that value to update the RTO estimator.  This document
   does not prescribe any particular method for modifying the RTO
   estimator.







>   - End of 3.3 on RTT sample weighting factors.
> 
>     (1) The problem with the history being truncated when using RTTM
>         was independently highlighted by Ludwig and Floyd.  We
>         should at least have the common courtesy to cite Sally's
>         note to e2e and Reiner's paper.

I tried to find Sally's comment (also trying to find the reference given in your "Using Spurious Retransmissios to Adapt the Retransmission Timeout" paper), but was unsuccessful... Do you have a link?



>   - 3.4, (A): Why are we discussing this in terms of the "Kth"
>     segment?  Delayed ACKs per the standard is "2nd".  Why do we
>     have to make the discussion in terms of some theory rather than
>     in terms of what we have specified?

fixed

>   - 3.2 insinuates that you should not include a timestamp on an
>     RST: "TSopt MUST be sent in every non-<RST> segment", implying
>     it should not be sent on an <RST> (or you'd have just said
>     "every segment").  But, then 4.2 goes on to (rightly IMO)
>     develop why we should include it on <RST> segments.  This
>     inconsistency needs fixed.


fixed

>     RTTM should not be deprecated.  It should be a MAY.
> 
>     RTTM should not be discussed with breathless bullshit about hand
>     wavy math and un-demonstrated stability issues and whatnot.
> 
>     We should say that RTTM is absolutely within compliance of the
>     spec and that it will not hurt your RTO.
> 
>     We should also say that RTTM is unlikely to help your RTO.
> 
>     We should leave it to implementers to decide if RTTM is useful
>     for their purposes.
> 
>     We should specify a way to vary the gains in the standard RTO
>     algorithm based on the current cwnd.
> 
>     And, we should absolutely state that there are other uses for
>     the timestamp option (like Eifel, like PAWS) and there is
>     nothing wrong with the *option* for that purpose.

Best regards,
   Richard