In message <199803241747.MAA08821@untraceable.net>Andrew Brown writes
>on a different note, i can't recall (brain is toast!) at this point
>exactly how the timeoure/retransmit mechanism does it retrials.  if i
>had a connection that was down the fourth out of every four seconds
>(or just dropped all packets), how well would tcp deal with that?  is
>it a sequential retry or some sort of sparser and sparser retry until
>it finally gives up?  it seems to me (imsuo) that a backoff sequence
>related to prime numbers might deal with such a thing much better.  it
>would be much less likely to "harmonize" with the rythmic outages.

I was just hacking on this.  It is supposed to calculate a
retransmission timeout (RTO) based on the round-trip time and the
variance of the round trip time.  Once it retransmits once, it must
exponetially back off with each additional retrial.  We effectively
back off and multiply the RTO 2, 4, 8, 16, 32, and then 64 clock ticks
(half a second), and keep trying every 64 * RTO until a total of 12
packets have been sent.  Since the minimum RTO we allow is 2 clock ticks,
this means that we wait around 9 minutes total to time out a connection.

It'd be cool if we perturbed the RTO using some random offset
within a range of a few seconds, the way that many of the timers in
IPv6 do.  As you point out, that'd avoid the perils of synchronization.

Kevin