[e2e] Rationale for EWMA filters in RTTM

[Detlef Bosau]

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
------------------------------------------------------------------