From owner-freebsd-net Thu Jul 18 14:33:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7613137B400 for ; Thu, 18 Jul 2002 14:33:20 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id A272343E65 for ; Thu, 18 Jul 2002 14:33:19 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g6ILXHqw007761 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 18 Jul 2002 17:33:17 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g6ILXHNl007758; Thu, 18 Jul 2002 17:33:17 -0400 (EDT) (envelope-from wollman) Date: Thu, 18 Jul 2002 17:33:17 -0400 (EDT) From: Garrett Wollman Message-Id: <200207182133.g6ILXHNl007758@khavrinen.lcs.mit.edu> To: Jonathan Lemon Cc: net@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_timer.h In-Reply-To: <20020718154341.D78047@prism.flugsvamp.com> References: <200207181608.g6IG8dN82437@prism.flugsvamp.com> <200207181732.g6IHW9rY018853@apollo.backplane.com> <20020718133111.B78047@prism.flugsvamp.com> <200207181857.g6IIv9ei019345@apollo.backplane.com> <20020718125410.K91443@nexus.root.com> <20020718154341.D78047@prism.flugsvamp.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Trying desparately to move this discussion to the correct list....] I spent a few minutes talking to Dave Clark about this question this afternoon. Here's my paraphrase of his opinion: - He disclaims completely up-to-date knowledge of the current research results. - He feels that 1000 ms is commonly used only because the historical BSD implementation couldn't do any better (it actually did 750 ms +/- 250 ms), and supports the idea that retransmits could occur more frequently. He has traces which show where a longer RTO would be both beneficial and harmful. - He questioned whether the traditional VJ `srtt + 4*rttvar' computation captures enough of the variance in the real Internet to avoid unnecessary slow retransmits. - He notes that Microsoft's TCP had a serious problem wherein it would slow-retransmit too aggressively, which resulted in almost any network transient triggering sufficient dupacks to cause fast retransmit to engage. (The result was that every data packet would be sent twice.) He suggests that, to avoid this, it may be necessary to lengthen the slow-retransmit timeout after a fast retransmit is triggered. - He also notes that there have not been screams of protest since Linux adopted the 200-ms minimum, which suggests that it's not a completely hare-brained value. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message