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
next RTT measurement we get, why is it not valid for the first time
we go established too?

Oh and I am not sure about t_rttlow, rack does not use it, not sure who
does, but I don't think the conn_init code sets it either so probably doing
it here is a double conversion ... not that it matters it will get set right
on the next measurement unless it translates to a very small number which
I don't think it will.

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
when we go to ESTABLISHED, bit it should get corrected I think.

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
a data transmission?

I suppose it could be an allowance for the fact that a full segment may have a propagation delay
far larger than the SYN, but 200ms is a lot of time. For 60kbps a full 1500 bytes takes 200ms
so maybe the real question is why we have this value so high.. maybe it should at least be
in the order of 1.5Mbps for a full sized segment i.e 8ms?

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