From owner-cvs-all@FreeBSD.ORG Wed Aug 1 19:51:38 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA86516A417; Wed, 1 Aug 2007 19:51:38 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id D5DB113C45D; Wed, 1 Aug 2007 19:51:36 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 1 Aug 2007 20:51:34 +0100 (BST) Date: Wed, 1 Aug 2007 20:51:34 +0100 From: David Malone To: Peter Jeremy Message-ID: <20070801195134.GA27931@walton.maths.tcd.ie> References: <200707312211.l6VMBupO010347@repoman.freebsd.org> <20070801083801.GI1152@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070801083801.GI1152@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Peter Wemm Subject: Re: cvs commit: src/sys/netinet tcp_subr.c tcp_timer.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2007 19:51:38 -0000 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.