[e2e] Rationale for EWMA filters in RTTM

[Detlef Bosau]

On 08/06/2011 07:25 PM, Jon Crowcroft wrote:
> i dont know how many TCPs still do it, but most used to only update
> the SRTT and RTTVAR running estimates for in order acknowledged
> segments.

At least time stamps are echoed this way according to RFC 1323.
>   This is based on Van's original argument about conservation
> of packets and a simple model of the qeues on the path....


...at least one should keep this in mind. I just had a look at the 
congavoid paper yesterday.

At least Manu's pointer to the remarkable level of packet reordering is 
concerning. In a private conversation, one of our colleagues stated that 
packet reordering usually points to broken network implementations. 
Perhaps, the term "broken" may sound too harsh here, however if we can 
aovid problems by simple means, we should do so.

> .the EWMA is
> just the simplest way to keep a running estimate of the 1st&  2nd
> moments of the moving distribution. we played around with other
> estimators in the 80s (when path diversity was even higher)  - it is
> entirely possible that current middle boxes and queus and multipath
> and switched routers are making such a simple estimate poor - i
> wouldnnt care much since it is a question how well it maps into a RTO,
> not whether it is "true" - work on path characterisation has a
> different goal

Hm. At least 
http://www.thinkmind.org/index.php?view=article&articleid=icn_2011_14_10_10098

intends to reduce the path diversity here.

Although this paper proposes a middlebox, the idea is particarly to 
support the _existing_ mechanisms of TCP.


> On Sat, Aug 6, 2011 at 5:50 PM, Detlef Bosau<detlef.bosau at web.de>  wrote:
>> On 08/06/2011 11:42 AM, Detlef Bosau wrote:
>>> On 08/06/2011 01:20 AM, Anoop Ghanwani wrote:
>>>> Have you looked at RFC 6298?  Based on your last email
>>>> it looks like you were reading an obsoleted RFC.
>>> O.k., now we've learned that RFC 6298 obsoletes RFC 2988.
>>>
>>> Of course, it is always useful to know the most recent RFC numbers.
>>> However, I don't see a solution for my problem.
>>>
>>>> I don't think this timer needs to be super accurate since
>>>> it kicks in only when duplicate ACKs don't already solve
>>>> the problem, e.g. under severe forward or reverse congestion
>>>> because of which ACKs aren't making it back.
>>> Hang on.
>>>
>>> First, refer to Manus post some few days ago and the paper
>>>
>>> Sharad Jaiswal, Gianluca Iannaccone, Christophe Diot, James F. Kurose,
>>> Donald F. Towsley,
>>> Measurement and classification of out-of-sequence packets in a tier-1
>>> IP backbone.
>>> IEEE/ACM Trans. Netw. (TON) 15(1):54-66 (2007)
>>>
>>> Manu points out, that according to this paper, 40% of the  observed links
>>> exhibit more or less sever packet reordering.
>>>
>>> In addition, we know the state variable DUPACKTHRESH for tcp senders for
>>> years now - which was particularly intended to address packet reordering.
>>>  From what I've read in recent literature, not even the least effort is
>>> spent, to address this problem in practical implementations.
>>>
>>> Consequence: Triple Dupacks may or may not happen - according to the
>>> phases of the moon or the water level, however, when they are related to
>>> congestion or packet loss, this is pure luck.
>>>
>>> In the same way,  spurious timeout may occur on the same "basis", caused
>>> by RTO values being unreasonable small.
>>>
>>>> Having it be a moving average just allows us to pick an
>>>> initial value that could be terribly wrong for the environment
>>>> (data center at one end, satellite links at the other end)
>>> I'm with you to up to now, but:
>>>> and we still find a reasonable value after a few RTT.
>>>>
>>> from what I've seen with some playing around in Octave, I would like to
>>> herewith suggest THE one and only reasonable RTO for TCP:
>>>
>>> 10 milliseconds times Bill Gates' birthday.
>>>
>>> At the moment, I'm quite convinced that this is neither worse nor better
>>> than those values we're using today.
>>>
>>> I have to apologize for my frustration. However, I'm still to overcome
>>> this huge difference between a marvelous, splendid theory and a very ugly
>>> practice.
>>>
>>> Please correct me, when I'm completely wrong here.
>>>
>>>
>> I just made some few "ping" tests this afternoon and just wanted to see,
>> whether the filtered reply times make sense.
>>
>> The results are, gently spoken, somewhat concerning.
>>
>>
>> --
>> ------------------------------------------------------------------
>> Detlef Bosau
>> Galileistraße 30
>> 70565 Stuttgart                            Tel.:   +49 711 5208031
>>                                            mobile: +49 172 6819937
>>                                            skype:     detlef.bosau
>>                                            ICQ:          566129673
>> detlef.bosau at web.de                     http://www.detlef-bosau.de
>> ------------------------------------------------------------------
>>
>>
>>


-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30	
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de
------------------------------------------------------------------