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

Yep, I agree.  Letting folks tweak the RTO algorithm is bad news, I
think. 

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

Actually, Vern Paxson and I found that finer granularity is good if
you keep the historical 1~sec minimum RTO (see our 1999 SIGCOMM
paper).  

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

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.

allman


---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/