Subject: Re: TCP Timeouts.
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Mark Allman <firstname.lastname@example.org>
Date: 01/28/2002 22:32:37
> 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
> 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
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.
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/