From owner-cvs-all Wed Jul 17 19:33: 9 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 3CED937B400; Wed, 17 Jul 2002 19:33:02 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCE9743E31; Wed, 17 Jul 2002 19:33:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6I2X1CV004856; Wed, 17 Jul 2002 19:33:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6I2X187004855; Wed, 17 Jul 2002 19:33:01 -0700 (PDT) (envelope-from dillon) Date: Wed, 17 Jul 2002 19:33:01 -0700 (PDT) From: Matthew Dillon Message-Id: <200207180233.g6I2X187004855@apollo.backplane.com> To: Mike Silbersack Cc: cvs-committers@FreeBSD.ORG, Subject: Re: cvs commit: src/sys/netinet tcp_timer.h References: <20020717211230.G83269-100000@patrocles.silby.com> 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 :something that changes with a HZ setting. Having a machine change TCP :behavior as HZ is ranged from 100 to 10000 is NOT something which should :happen! : :Your three tick setting is also making an assumption about the relation :between bandwidth and latency. If I have 100 machines feeding through a :gigabit link, the rtt may well be < 1ms. However, the available bandwidth :for each machine is far less than one gigabit. Hence, flooding the :network with retransmissions every 3ms is still very unfriendly. : :Another potentially bad sideeffect is that with low RTTs, connections may :timeout excessively fast, causing many reset connections just because a :router went down for 15-30 seconds. This reduces the reliability of TCP. 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. :> On a gigabit network a 1 second retransmission timeout is simply :> absurd. Period. : :Yes, but something approaching 1ms could potentially cause more congestion :and be worse. : :I checked, and linux has already moved to a 200ms RTO. That also seems :reasonable, and I don't see a problem with setting that as our minimum RTO :as well. : :Mike "Silby" Silbersack 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message