Date: Mon, 6 May 2002 11:41:13 -0500 (CDT) From: mark tinguely <tinguely@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 Message-ID: <200205061641.g46GfCX78428@web.cs.ndsu.nodak.edu> In-Reply-To: <Pine.BSF.4.21.0205041519260.24079-100000@moab.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205061641.g46GfCX78428>