[e2e] Rationale for EWMA filters in RTTM

Detlef Bosau detlef.bosau at web.de
Sat Aug 6 09:50:20 PDT 2011

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

More information about the end2end-interest mailing list