I've seen several related topics in this forum so I'll give this forum a try. I've been looking working on a problem involving occasional dropped syn packets/timeouts and hard data on this is hard to come by. But my question really boils down to this: what is the standard delay time between successive syn packets sent by a client supposed to be when those syn packets are lossed in transit? Background: we've got an app which gets a lot of hits. It sends a keepalive every 4 seconds to cluster of Solaris hosts. The app is set to timeout a session if it does not receive a reply within 3 seconds. However we've come to learn that whenever the client's first syn packet gets lost on the network, that the client will wait for 3 seconds before it resends that syn packet. The effect is that whenever that first syn packet is lost the session ends up being terminated. I've done a little research: RFC2988 states that standard retransmission times should start at 3 seconds -but does that apply to the opening syn packet? There is a later reference in RFC that indicates the retransmission config only applies to packets with data, which blurs the handling of the tcphandshake retransmission issue. Further, in RFC1122 there is some more ambigous information regarding RTO:

"RTO = 3 seconds. (The smoothed variance is to be initialized to the value that will result in this RTO). The recommended upper and lower bounds on the RTO are known to be inadequate on large internets. The lower bound SHOULD be measured in fractions of a second (to accommodate high speed LANs) and the upper bound should be 2*MSL, i.e., 240 seconds. "

Our network is a high speed network so I conclude in this case the 3 second RTO is too long.