[e2e] Estimating MS windows RTO equation

[sanjay kaniyar]

Sushant -

Windows uses the very same algorithms prescribed by the standard RFCs - so, 
I would think you should see the results you are expecting... if you are 
not, send a mail just to me and we will work with you.

And yes, Windows does fast-retransmission upon receiving 2nd dup ACK.

Thanks,
Sanjay kaniyar
(Windows networking, Microsoft)

>From: "Sushant Rewaskar" <rewaskar at email.unc.edu>
>Reply-To: rewaskar at cs.unc.edu
>To: <detlef.bosau at web.de>
>CC: end2end-interest at postel.org
>Subject: Re: [e2e] Estimating MS windows RTO equation
>Date: Thu, 2 Feb 2006 08:26:37 -0500
>
>Hi,
>It is not that we are interested in only MS windows machines; however, it 
>is
>the only one which we have not figured out yet.
>
>We have created a partial state machine based tool for tracing the state of
>the TCP connections. This helps us identify the cause of retransmission of 
>a
>packet and by using extra logic we can identify other things like whether
>the packet was needed or not.
>
>Now the problem with creating a general partial state-machine is that there
>is a lot of variation in the way TCP is implemented in the different OSes
>(windows for e.g. enters fast retransmit after 2 dupack instead of 3 as
>suggested in the RFC). There are many other differences across the 
>different
>OSes especially in the way the RTO is estimated. We are trying to determine
>the RTO equations so that we can (i) exactly tell which packet is triggered
>by a timeout and (2) if we get a very good match between the observed
>retransmission time and calculated RTO, we would also be able to tell that
>the particular connection below to a particular OS.  We have been able to
>build almost perfect state machines for Linux, Solaris and FreeBSD (MacOS)
>and have been able to do a decent job for windows (including identifying
>certain unusual behavior which is peculiar to windows OSes). However, we 
>are
>still struggling to get the RTO estimation perfected.  Details about the
>tool are available in the following tech report
>http://www.cs.unc.edu/~rewaskar/publication/TR06-002.pdf
>
>About the RTT calculation. For the experiments I mentioned in the last mail
>we are collecting a tcpdump at the sender (FreeBSD machine) and calculate
>RTT using karls Algorithm. The details for RTT estimation are in the
>following paper  http://www.cs.unc.edu/~jasleen/papers/imc03.pdf
>
>Thank you,
>Sushant Rewaskar
>-----------------------------
>UNC Chapel Hill
>www.cs.unc.edu/~rewaskar
>
>
>-----Original Message-----
>From: detlef.bosau at web.de [mailto:detlef.bosau at web.de]
>Sent: Thursday, February 02, 2006 6:31 AM
>To: rewaskar at cs.unc.edu
>Cc: end2end-interest at postel.org
>Subject: Re: [e2e] Estimating MS windows RTO equation
>
>Hm.
>
>First of all, its interesting why you are interested in just MS Windows´
>RTO esitmator ;-)
>Basically, MS is free to implement anything they like as long as their
>OS are well behaved, i.e. do not cause trouble to other network
>participants.
>Of course, it might be a good idea to follow the actual RFC ;-)
>
>To your problem.
>
>How did you obtain the rtxtimer samples from which you try to estimate
>your parameters?
>
>Presumably, you did not take them from the OS kernel code, because if
>that were available for you you could easily look up the RTO equation
>from
>that ;-)
>
>
>--
>Detlef Bosau
>Galileistrasse 30
>70565 Stuttgart
>Mail: detlef.bosau at web.de
>Web: http://www.detlef-bosau.de
>Mobile: +49 172 681 9937
>