[e2e] [tcpm] RTTM + timestamps

[Detlef Bosau]

On 01/17/2011 09:52 PM, SCHARF, Michael wrote:
>
> Richard,
>
> 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:
>
> R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM 
> Computer Communications Review, 30(3), 2000, pp. 17–27 [this is not 
> the actual Eifel algorithm]
>
> H. Ekstroem and R. Ludwig, “The Peak-Hopper: A New End-to-End 
> Retransmission Timer for Reliable Unicast Transport,” Proc. IEEE 
> INFOCOM, 2004
>
> K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, 
> "Round-Trip time estimation in communication networks using adaptive 
> Kalman filtering"
>
> A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", 
> Springer LNCS 3421, 2005
>
> I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", 
> Computer Networks, Volume 51, Issue 8, 6 June 2007
>
> etc.
>
> And, BTW, a young wannabe-TCP researcher once tried to systematically 
> understand the RTO spikes resulting from RFC 2988:
>
> Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP 
> to Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 
> 2004, pp. 76-87
>
> If a better RTT estimation or RTO calculation was indeed needed, these 
> papers might contain some interesting starting points.
>
> Michael
>

I just had a look at these older posts - and I'm afraid, you may be 
completely at cross-purposes.

 From what I've seen from Richard, Richards concern is to get TCP RTT 
samples with a much finer resolution than we do today.

Particularly your own work targets at the feasibility for the RTT 
sampling mechanism from RFC 2988 (IIRC) for WWAN.

While I don't think that we really have an issue with the TCP clock 
resolution, at least no new one, finding suitable RTOs for WWAN is an 
important issue for TCP in conjunction with WWAN.

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