From owner-cvs-all Wed Jul 17 20:23: 8 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E3AA37B400; Wed, 17 Jul 2002 20:23:04 -0700 (PDT) Received: from patrocles.silby.com (d105.as8.nwbl0.wi.voyager.net [169.207.132.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D769643E58; Wed, 17 Jul 2002 20:23:02 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g6I3RNcv084033; Wed, 17 Jul 2002 22:27:23 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g6I3RHtw084030; Wed, 17 Jul 2002 22:27:22 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 17 Jul 2002 22:27:17 -0500 (CDT) From: Mike Silbersack To: Matthew Dillon Cc: cvs-committers@FreeBSD.ORG, Subject: Re: cvs commit: src/sys/netinet tcp_timer.h In-Reply-To: <200207180233.g6I2X187004855@apollo.backplane.com> Message-ID: <20020717220320.F83856-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 17 Jul 2002, Matthew Dillon wrote: > Mike, I think you are a bit confused. This is simply the MINIMUM > retransmit timeout. It is not the retransmit timeout that the TCP > stack will use. > > The TCP stack calculates the retransmission timeout (RTO) based on the > smoothed round trip time for a packet. It is highly unlikely that > retransmit timeouts will ever get as low as 3 ticks with HZ set to 1000, > but if they do it will be because the protocol demands it. > > We are already very conservative in our RTO calculations. I know, > because I revamped that whole section of code a few years ago. Yes, I understand that we're talking about the minimum. What I was misunderstanding was the point of "3". I initially thought that you were trying to set the floor to 30ms. I now see that you're trying to totally remove the floor, but that there's roundoff error / etc in the RTO calculation that you're trying to avoid. > I am not saying that having an absolute time minimum is unreasonable, > I am simply saying that 1 SECOND *IS* unreasonable. > > I would say that 200ms is also unreasonable. I would say that something > on the order of 50ms would be reasonable, but even 50ms can create > serious issues for something like, say, NAS networks. > > For this reason I really think we should trust the RTO calculation. > > -Matt > Matthew Dillon > The RTO is not what is _causing_ problems: the packet loss which requires the use of a RTO is what causes the problem. You're not going to solve such packet loss by blasting out retransmissions ASAP, and such a drastic change will affect other situations (such as a short cable/hub/router outage) in profound ways. Tweaking the 1 second timeout down to 200ms is relatively simple. Allowing the RTO to go all the way down to 3*rtt is much more drastic, and could have many unexpected sideeffects that will be hard to track down. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message