Date: Wed, 1 Aug 2007 20:51:34 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Peter Wemm <peter@freebsd.org> Subject: Re: cvs commit: src/sys/netinet tcp_subr.c tcp_timer.h Message-ID: <20070801195134.GA27931@walton.maths.tcd.ie> In-Reply-To: <20070801083801.GI1152@turion.vk2pj.dyndns.org> References: <200707312211.l6VMBupO010347@repoman.freebsd.org> <20070801083801.GI1152@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 01, 2007 at 06:38:01PM +1000, Peter Jeremy wrote: > My gut feeling is that putting an artifical lower bound on the RTT is > a hackish way to control the retransmit timeout - I thought the TCP > algorithms relied on knowing the real RTT to correctly handle > retransmissions. A variable that explicitly controls the retransmit > timeout would seem easier to understand. TCP retransmissions should usuall be driven by duplicate ACKs (when there's more than one packet in flight), so setting minRTO to me small is usually not a big problem. If the link goes away for a bit, so either all the packets in flight or all the ACKs get dropped, then you need the timeout to kick in. Now you want minRTO to be large enough to allow the link to come back, but not so large that that you sit there waiting ages. There's a paragraph in RFC 3714 on this, commenting that some TCP stacks use values as small as 100ms, and that RFC 2988 suggests a min of 1s. There has been some research to try and figure out a good value, but I don't think anyone ever came to a definitive answer. David.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070801195134.GA27931>