From owner-freebsd-net Wed May 15 11:51:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from moab.cs.utah.edu (moab.cs.utah.edu [155.99.212.88]) by hub.freebsd.org (Postfix) with ESMTP id 7025537B40B for ; Wed, 15 May 2002 11:51:15 -0700 (PDT) Received: from localhost (bwhite@localhost) by moab.cs.utah.edu (8.9.1/8.9.1) with ESMTP id MAA28251; Wed, 15 May 2002 12:51:09 -0600 (MDT) Date: Wed, 15 May 2002 12:51:09 -0600 (MDT) From: Brian White To: mark tinguely Cc: freebsd-net@FreeBSD.ORG Subject: Re: FBSD 4.3 New Reno Fast Retransmit Behavior In-Reply-To: <200205061641.g46GfCX78428@web.cs.ndsu.nodak.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 I've been comparing simple ns drop experiments with FreeBSD. Based on your explanation (below), I've accounted for one difference and switched to FreeBSD 4.5. I'm seeing another discrepancy and would like to verify that it is intended behavior. Though this is related to my original questioning of False Fast Retransmit, I don't believe the explanation below covers it. I unearthed the Dec 2001 thread in -net you refer to which was either over my head or addresses a separate problem. Based on the code, the following reflects my understanding: After beginning a Fast Retransmit phase, FreeBSD will only send retransmissions while dupacks >= tcprextmthresh. Fast retransmissions occur in tcp_newreno, which is guarded by this conditional. Once a new ACK arrives during Fast Retransmit, dupacks is set to zero. Further, FreeBSD implements a False Fast Retransmit suppression algorithm, triggered when ++tp->t_dupacks == tcprexmtthresh and the current ACK is less than snd_recover. This algorithm sets dupacks to zero, ensuring that tcp_newreno can not fire. Therefore, no more Fast Retransmissions will occur until the Fast Retransmit phase ends. I believe this is consistent with Janey Hoe's discussion of False Fast Retransmits in section 3.2 of the SIGCOMM'96 paper. But is inconsistent with ns, which does not guard the tcp_newreno-equivalent partialnewack_helper. Thanks again. Brian On Mon, 6 May 2002, mark tinguely wrote: > > 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