From owner-freebsd-net Mon May 6 9:41:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id 736D137B408 for ; Mon, 6 May 2002 09:41:14 -0700 (PDT) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g46GfCX78428; Mon, 6 May 2002 11:41:13 -0500 (CDT) (envelope-from tinguely) Date: Mon, 6 May 2002 11:41:13 -0500 (CDT) From: mark tinguely Message-Id: <200205061641.g46GfCX78428@web.cs.ndsu.nodak.edu> To: bwhite@moab.cs.utah.edu, freebsd-net@FreeBSD.ORG Subject: Re: FBSD 4.3 New Reno Fast Retransmit Behavior In-Reply-To: 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 > There seem to be two problematic cases. In the first, _both_ of these > conditions fire in tcp_input.c: > > else if (++tp->t_dupacks == tcprexmtthresh) { > > and > > if (tcp_do_newreno && SEQ_LT(th->th_ack, > tp->snd_recover)) { yes, this is a problem because FreeBSD 4.[34 and before?] did not always initialized tp->snd_recover on the session startup and presented a problem when the initial segment sequence is greater than 0x7fffffff. The only other way to tigger this error is if you went half way through the sequence without a duplicate ack. We talked about this a little on -net and decided the prevention would have more overhead than it would effectively cure. FreeBSD 4.5 and greater fixed the initialization of snd_recover with the addition of the "syncache" code. FreeBSD 4.5 also fixed some serious socket errors that would cause more even greater performance problems. I suggest you upgrade. --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message