<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Detlef,<br>
<br>
You might find our paper (below) interesting, in which we analyze
traces of nearly 3 million Internet transfers to study the
performance of TCP loss detection and recovery mecahnisms. Among
other things, it also logs the occurence of spurious timeouts on a
per-OS basis.<br>
<br>
<font size="3">S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance
Study of Loss Detection/Recovery in Real-world TCP
Implementations,"<a
href="http://www.cs.unc.edu/%7Ejasleen/papers/icnp07.pdf"><strong></strong></a>
in
Proceedings of the IEEE International Conference on Network
Protocols (ICNP'07),
Beijing, China, Oct 2007. <br>
<br>
</font><a class="moz-txt-link-freetext" href="http://www.cs.unc.edu/~jasleen/papers/icnp07.pdf">http://www.cs.unc.edu/~jasleen/papers/icnp07.pdf</a><br>
<br>
Thanks,<br>
Jasleen<br>
<br>
<br>
<br>
On 8/3/2011 10:08 AM, Detlef Bosau wrote:
<blockquote cite="mid:4E395676.9010407@web.de" type="cite">During
the recent past, this list has seen quite some few posts regarding
TCP RTT measurement.
<br>
<br>
Now, first of all, I was interested in how often RTT measurments
shall be made and how they can be made. A particular concern is
Karn's Algorithm,
<br>
because to my understanding, the consequence of Karn's algorithm
is that RTT measurements obtained by a single RTT timer can be
taken only when a sender has no outstanding duplicate packets.
<br>
<br>
Perhaps, I'm wrong here.
<br>
<br>
However, from what I've read so far, it is not yet completely
clear, how often RTT measurements should be made. The alternatives
discussed so fare are:
<br>
- once round,
<br>
- each packet.
<br>
<br>
While the latter appears appealing to me, particularly when
implemented with time stamps (RFC 1323), which overcomes the
problems discussed by Karn & Partridge regarding the problem
of packets being sent more than once, some literature indicates
problems with the SRTT estimator when time stamps are in use.
<br>
<br>
Now, the whole discussion is somewhat confusing to me.
<br>
<br>
1.: Spurious Timeouts are confusing to me, because spurious
timeouts (i.e. a packet which is well successfully transmitted,
however the ACK does not reach the sender on time) are basically
expected by Edges paper and the literature based upon this.
However, there are papers around, which put the mere existence of
spurious timeouts in question, e.g.
<br>
author = "Francesco Vacirca and Thomas Ziegler and Eduard
Hasenleithner",
<br>
title="{TCP Spurious Timeout estimation in
<br>
an operational GPRS/UMTS network}",
<br>
month="May",
<br>
year="2005",
<br>
journal = "Forschungszentrum Telekommunikation Wien
<br>
Technical Report
<br>
FTW-TR-2005-008"
<br>
}
<br>
, while others give detailed recommendations how to deal with
spurious timeouts in practical implementations, e.g.
<br>
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/search/draft-allman-rto-backoff-02">http://tools.ietf.org/search/draft-allman-rto-backoff-02</a>
<br>
<br>
However, to me the problem seems closely coupled to the underlying
question whether or not we can estimate the expectation and
variance of the RTT in a TCP session. Edge requires the according
stochastic process to be weakly stationary. In other words: In a
TCP session, once having started and being run for some settling
time, the observerd RTT shall be, at least roughly, identically
distributed.
<br>
<br>
This distribution should be subject to only very slow and very
rare change, if at all.
<br>
<br>
And accourding to RFC 2988, we can obtain SRTT and RTTVAR by RTT
samples using the well known EWMA estimators for this purpose.
<br>
<br>
<br>
So, my questions are:
<br>
<br>
1.: How often shall RTTM be made?
<br>
2.: Is it reasonable to assume "weakly stationary" RTTs as done by
Edge?
<br>
3.: Are the EWMA filters from RFC 2988 satisfactory, particularly
are these sufficiently generic to yield reasonable results for an
arbitrary TCP session?
<br>
<br>
One could summarize these to the question: Do we obtain RTO in a
reasonable way? And when we talk about spurious timeouts, are we
talking about spurious timeouts - or are we talking about
shortcomings of the SRTT and RTTVAR estimators here?
<br>
<br>
I'm somewhat confused here at the moment. And I would appreciate
any enlightenment ;-)
<br>
<br>
Detlef
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>