From owner-cvs-all Wed Jul 17 20:18:15 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 6AC5137B400; Wed, 17 Jul 2002 20:18:11 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA24C43E64; Wed, 17 Jul 2002 20:18:10 -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 g6I3I8qw000999 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 17 Jul 2002 23:18:08 -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 g6I3I8hj000996; Wed, 17 Jul 2002 23:18:08 -0400 (EDT) (envelope-from wollman) Date: Wed, 17 Jul 2002 23:18:08 -0400 (EDT) From: Garrett Wollman Message-Id: <200207180318.g6I3I8hj000996@khavrinen.lcs.mit.edu> To: "Greg 'groggy' Lehey" Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Retransmission timeouts (was: cvs commit: src/sys/netinet tcp_timer.h) In-Reply-To: <20020718024649.GJ40633@wantadilla.lemis.com> References: <20020717185653.C82638-100000@patrocles.silby.com> <200207180102.g6I129Gw004350@apollo.backplane.com> <200207180206.g6I266ma000510@khavrinen.lcs.mit.edu> <200207180228.g6I2Scpv004823@apollo.backplane.com> <20020718024649.GJ40633@wantadilla.lemis.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 < said: > I'd put money on Garrett coming up with some reference somewhere. Well, I looked in all the references I could find, and didn't locate anything like what I remember reading from when Jonathan and I redid the TCP timers. I've found it: it's (obliquely) in the Allman and Paxson paper referenced in the commit logs. Implementations are allowed to delay ACKs for as long as 500 ms. Depending on traffic patterns, it is possible for the RTT estimator to see only (or mostly) non-delayed acks,[1] and then when the first delayed ACK hits, whammo, you get an unnecessary retransmit timeout. (And, of course, the segment which got retransmitted will not participate in the RTT computation because it is a retransmission.) The ``bad retransmit'' detection code may, in some cases, be able to recover from this situation, but I wouldn't want to depend on it. > But that's not important. Things change, and we have to change > with them. This change looks like a logical adaptation to changed > network speeds. Network speeds have practically nothing to do with a correct implementation of the TCP protocol. -GAWollman [1] For example, a bulk-transfer application which sends 128K blocks at a time; the receiver will ACK every other packet during the main part of the transfer, but the final (short) packet might have its ACK delayed the full 500 ms. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message