Date: Wed, 17 Jul 2002 23:18:08 -0400 (EDT) From: Garrett Wollman <wollman@lcs.mit.edu> To: "Greg 'groggy' Lehey" <grog@lemis.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Retransmission timeouts (was: cvs commit: src/sys/netinet tcp_timer.h) Message-ID: <200207180318.g6I3I8hj000996@khavrinen.lcs.mit.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 18 Jul 2002 12:16:49 +0930, "Greg 'groggy' Lehey" <grog@lemis.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207180318.g6I3I8hj000996>