In message <200201290226.NAA05818@avalon.reed.wattle.id.au>,
Darren Reed writes:



>The problem with the default retransmit timer is if TCP looses a packet
>it can take a long time to work out it has gone missing if the data flow
>isn't constant.

Last time I looked, ``default retransmit timer'' was a function of the
SRTT estimate. see sys/netinet/tcp_input.c:tcp_xmit_timer().  And if
we let users finagle the retransmit timer tight enough, I think one
can finagle TCP into sending faster than a TCP is supposed to.

I already mentioned issues with the historical 2Hz timer granularity;
try and make the resolution too fine, and you lose the statistical
averaging. That can make TCP to run into trouble.  (Ask Michael
Greenwald for literature references.)

Is your problem with drops which happen before the SRTT converges-- or
where RTT changes too rapidly for SRTT to ever converge near a true
value? For the former, using a fixed socket-option value have the
problem that RTT *does* have high variance; routes can change and
break your fixed estimate.  In the latter, I dont see how an arbitrary
human-fixed value is any better, on average, than the SRTT.

We can already cache static RTT and rtt-variance estimates in routes,
along with initial window sizes, mtu, &c; but that isn't what you
asked for.  


What am I missing? The case of a half-duplex-ey connection where you
are are unlucky enough to drop the last segment or so, and incur a
slow timeout?