Don't take net.inet.tcp.rexmit_slop into account when setting the retransmission timeout in front states.
Run TCP test suite.
What is the reason you don't want to have RTT Slop in the mix here?
I do think its a bit high IIRR 200ms, but if we are going to use it the
Oh and I am not sure about t_rttlow, rack does not use it, not sure who
When retransmitting the first SYN, the base stack does not include the slop. So when switching to RACK before the first SYN goes out, the behvaiour would be different. However, thinking about that, when switching in the middle of a connection, you want to put the slop in there.
Regarding the t_rttlow: I think in principle the conversion would belong to the routine. But let me take that out, since it is a separate issue.
t_rttlow is not used by rack. It is updated, but not used. Its arguably incorrect
So my fundamental question then is why do we have slop included in any timeout?
If its good enough for the SYN not to include it, why do we include it on
I suppose it could be an allowance for the fact that a full segment may have a propagation delay
I thought it is to compensate for a delay of the peer when the timer is based on the actual RTT. But then it does not make sense to use it in (all but the first) retransmission SYN retransmissions...