Subject: [tcpm] 1323bis

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 7 Nov 2012 17:16:18 +0000

Hi Matt, Mirja, Kevin,

Michael Welzl just mentioned one old paper where this was looked into, and also I believe Mark Allman brought this up...

With 1323 TS, timing every packet changes the dynamics (in the time domain) how fast sRTT / sRTTvar converge...

With only one sample per RTT, the convergence time is measured in a couple of RTTs up to a dozend of RTTs; however, with per-packet RTT sampling, and the same static weight factors, the effective convergence time of sRTT / sRTTvar get mich faster than this - with large windows even shorter than a single RTT...

Should 1323bis give some definitive guidance to make the weight factors, and thus the convergence time, dynamic (something proportional to cwnd/SMSS perhaps), so that RTT convergence (more importantly, RTO) is somewhat slower?

Right now, the wording is rather vague in this aspect in 1323bis:

   Implementors should note that with Timestamps multiple RTTMs can be
   taken per RTT.  Many RTO estimators have a weighting factor based on
   an implicit assumption that at most one RTTM will be gotten per RTT.
   When using multiple RTTMs per RTT to update the RTO estimator, the
   weighting factor needs to be decreased to take into account the more
   frequent RTTMs.  For example, an implementation could choose to just
   use one sample per RTT to update the RTO estimator, or vary the gain
   based on the congestion window, or take an average of all the RTTM
   measurements 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, the important point is that
   the implementation should do something more than just feeding
   additional RTTM samples from one RTT into the RTO estimator.

(unless a definitive new default is prescribed, an implementer will propably "do nothing", ie. continue use the static weight factor.)

Also, would that section of text (since it's probably an important aspect) warrant to be promoted to its own subsection (4.x)?

Best regards,

Richard Scheffenegger

NetApp
[email-masked]<mailto:[email-masked]>
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com<http://www.netapp.com>

EURO PLAZA
Gebäude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 7 Nov 2012 18:30:42 +0100

Richard,

> Should 1323bis give some definitive guidance to make the 
> weight factors, and thus the convergence time, dynamic 
> (something proportional to cwnd/SMSS perhaps), so that RTT 
> convergence (more importantly, RTO) is somewhat slower?

As a researcher who looked into this question some 10 years ago (Linux already used a different estimator with other weight factors those days), I think that RTO estimator details don't really belong into 1323bis. Specifically, I doubt that we we should define specific weight factors in 1323bis.

My take is that the filter design is mostly orthogonal to the measurement method - except that a warning sign for users of timestamps is clearly needed.

Michael

---

From: Matt Mathis <[email-masked]>
Date: Wed, 7 Nov 2012 10:59:12 -0800

I like your answer a lot.   "In absence of  other recommendations
refer to the (not fully deprecated) text in RFC1323".

As a general principle lets crisp up document scopes!

Thank,s
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 7 Nov 2012 20:06:10 +0100

For what it is worth: IMHO the paragraph (or a variant thereof) should be in 1323bis, too. Implementors should find the warning sign easily.

Michael 

> -----Original Message-----
> From: Matt Mathis [mailto:[email-masked]] 
> Sent: Wednesday, November 07, 2012 7:59 PM
> To: Scharf, Michael (Michael)
> Cc: Scheffenegger, Richard; Mirja Kuehlewind; Mark Allman; 
> tcpm ([email-masked])
> Subject: Re: 1323bis
> 
> privacy and security as matters of life and death, because 
> for some users, they are.
> 
> 
> >> Should 1323bis give some definitive guidance to make the weight 
> >> factors, and thus the convergence time, dynamic (something 
> >> proportional to cwnd/SMSS perhaps), so that RTT convergence (more 
> >> importantly, RTO) is somewhat slower?
> >
> > As a researcher who looked into this question some 10 years 
> ago (Linux already used a different estimator with other 
> weight factors those days), I think that RTO estimator 
> details don't really belong into 1323bis. Specifically, I 
> doubt that we we should define specific weight factors in 1323bis.
> >
> > My take is that the filter design is mostly orthogonal to 
> the measurement method - except that a warning sign for users 
> of timestamps is clearly needed.
> >
> > Michael
> >
>

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 8 Nov 2012 10:44:34 -0500

On Wed, Nov 7, 2012 at 12:16 PM, Scheffenegger, Richard <[email-masked]> wrote:
> Hi Matt, Mirja, Kevin,
>
> Michael Welzl just mentioned one old paper where this was looked into, and
> also I believe Mark Allman brought this up...
>
> With 1323 TS, timing every packet changes the dynamics (in the time domain)
> how fast sRTT / sRTTvar converge…
>
> With only one sample per RTT, the convergence time is measured in a couple
> of RTTs up to a dozend of RTTs; however, with per-packet RTT sampling, and
> the same static weight factors, the effective convergence time of sRTT /
> sRTTvar get mich faster than this – with large windows even shorter than a
> single RTT…
>
> Should 1323bis give some definitive guidance to make the weight factors, and
> thus the convergence time, dynamic (something proportional to cwnd/SMSS
> perhaps), so that RTT convergence (more importantly, RTO) is somewhat
> slower?
-1. I agree w/ Michael's opinion.

> (unless a definitive new default is prescribed, an implementer will propably
> “do nothing”, ie. continue use the static weight factor.)
+1 please remove this redundant sentence starting from "the important point..."

>
> Also, would that section of text (since it’s probably an important aspect)
> warrant to be promoted to its own subsection (4.x)?
>
> Best regards,
>
> Richard Scheffenegger
>
> NetApp
> [email-masked]
> www.netapp.com
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>