This is a very complicated process, so to formulate an equation that could be useful for accurately predicting RTTs is extremely difficult. At best, I would say you could create a model that using a bunch of averages for each stage, that you could tweak if you happen to "know better" for a particular situation is about as close as you can get. This is something I am presently studying so I can tell you what I know so far (from the ground up, starting at the physical layer):
See my questions on the Electronics SE; Encoding delay of Ethernet and the relation to cable frequency rating and Speed of electricity (signal propagation?) through copper for communications delay. Since you would be using standardised speeds (100Mbps, 1Gbps, 10Gbps etc), don't treat fibre or copper differently. The "delay" down the two is near as damn it the same, but copper can't carry a signal as far obviously. I have this question on the Physics SE site, which I do know the answer to now. I just need to find the time to right it up, so keep an eye on that if you are interested (I will be posting some more telecoms-use-of-fibre related questions to which I now know the answer when I get a chance).
Much more delay is going to be added in by the devices at the end of a link. There is no standard way of saying "oh 2 switches along a path is Xms delay, 4 switches is 2*Xms, 2 routers is Yms...etc". Assuming you are using say 1Gpbs for example and the devices in the path forward at line rate, we know that is 1000000000bps, so the physical interface is running at a fixed encoding rate (ranging from 1 nanosecond per bit up to whatever the max of the symbol encoding scheme in use is, such as 10b)
There are three main kinds of delay (at the physical layer) you need to be aware of and factor in; Serialisation delay, encoding delay, propagation delay (and processing delay, queueing delay, encode and decoding delay, but these are above the physical layer but need mentioning!). These are reasonably well documented on the Internet, VoIP: An In-Depth Analysis, Slide 13 here, loads on Google Scholar, and many more.
As we move up the protocol stack, I would work on the assumption that the destination MAC is in each switches cam table, and at the IP layer, the destination MAC in ARP tables. The extra delay induced by these discovery processes only occurs for the first packet in a flow so they can be circumvented by raising time-outs and sending gratuitous ARPs etc.
As you get to the application layer this is going to get really difficult because this depends on the server (for example) processing the request, which will be subject to interrupt delay. The number of interrupts required to process the request and context switches due to load is unpredictable.
I would very much like to help you with your question, sadly this is all I have time for right now. I will update this answer maybe later tonight or tomorrow, I wanted to post what I have so far.
In the mean time, most people tend to work with the figure for the delay at a physical copper/fibre layer of around 0.6*c (C = speed of light). Also, you need to think about TCP's exchange of ACKs every X packets, which differs if you are using SACK for example, and if you're using jumbo frames and/or larger MSS size (now MTU needs to be factored in also!), if you're sending more in-between ACKs (if volume of data transferred is of interest to you). You also need to factor in the infamous Bandwidth Delay Product and don't make the stupid misinterpretation that I did of that page. I started making various simple (and very ugly) data calculators here. Again a work in progress I will try and update them soon. I plan to add a calculator similar to what you are trying to do. I have also made some light and fibre calculators if you are interested, but again, no time!, I haven't gotten round to uploading them yet. I will try ASAP to update this answer some more, in the coming days.
P.S. I forgot to mention QoS! If QoS is in play anywhere in the path, it's going to get really tough to caluclate the RTT!
According to RFC 6928, the SRTT is only calculated with the formula
SRTT <- (1 - alpha) * SRTT + alpha * R'
after two RTT measurements have been made. After the first measurement, SRTT is initilized to the value of this first measurement, ie. SRTT <- R'.
You were close, according to the RFC alpha SHOULD be 1/8 (= 0.125).
Note, in RFC's, SHOULD means "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." (RFC 2119)
Best Answer
Yes. A retransmitted segment has got its own timer and doesn't re-use that of the presumed lost segment. There's no reason to not use the RTT measured by it.