<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>Re: [tcpm] RTTM + timestamps</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Richard,<BR>
<BR>
I happened to look at the RTO calculation and RTO spike issue a long time ago. For whatever it is worth, I scanned that old work and extracted some references that may or may not be well-known. A number of algorithms have indeed been developed to address these issues (e. g., Linux stack), and several papers tried to further optimize the timer calculation in particular for mobile environments, including amongst others:<BR>
<BR>
R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM Computer Communications Review, 30(3), 2000, pp. 17&#150;27 [this is not the actual Eifel algorithm]<BR>
<BR>
H. Ekstroem and R. Ludwig, &#147;The Peak-Hopper: A New End-to-End Retransmission Timer for Reliable Unicast Transport,&#148; Proc. IEEE INFOCOM, 2004<BR>
<BR>
K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, &quot;Round-Trip time estimation in communication networks using adaptive Kalman filtering&quot;<BR>
<BR>
A. Kesselman, Y. Mansour, &quot;Optimizing TCP Retransmission Timeout&quot;, Springer LNCS 3421, 2005<BR>
<BR>
I. Psaras, V. Tsaoussidis, &quot;Why TCP timers (still) don't work well&quot;, Computer Networks, Volume 51, Issue 8, 6 June 2007<BR>
<BR>
etc.<BR>
<BR>
And, BTW, a young wannabe-TCP researcher once tried to systematically understand the RTO spikes resulting from RFC 2988:<BR>
<BR>
Michael Scharf, Marc C. Necker, Bernd Gloss: &quot;The Sensitivity of TCP to Sudden Delay Variations in Mobile Networks&quot;, Springer LNCS 3042, 2004, pp. 76-87<BR>
<BR>
If a better RTT estimation or RTO calculation was indeed needed, these papers might contain some interesting starting points.<BR>
<BR>
Michael<BR>
</FONT>
</P>

</BODY>
</HTML>