[ Resolution of TCP timers]

Mark,

>I'd be interested in seeing evidence to the contrary, though.


I cant recall the reference, I will have to ask Michael Greenwald.  If
rusty memory serves, the citation may have not honoured the 1hz
minimum. Which is why I'm trying to follow just what Darren is trying
to do. Specific topologies, true RTT values, and proposed "wired"
values would make it clearer.


>One thing that one could envision letting folks tweak is the
>*initial* RTO.  The spec (RFC 2988) says it must be at least 3
>seconds.  Some implementations use 3 seconds and some use 6 seconds
>and I can't remember which netbsd does.  But, regardless -- if the
>initial RTO is too low all sorts of badness happens (because Karn's
>algorithm kicks in and you can't actually get a good RTT sample
>because you have needlessly retransmitted).  It's an edge case, but
>some paths are pretty long and so it might be nice to have a
>setsockopt() that allows a user to set the initial RTO, as long as
>they don't try to set it to something < 3 seconds.

Back in the late 80s, I used nets TCP on where I had to bump the
initial connection timeout (and, ideally, initial RTO) to well over 10
sec (30 sec, iirc, but I try not to.).  As you say, the peer's own RTO
was then far too low, and all sorts of oddities would ensue.