Date: Wed, 15 May 2002 12:51:09 -0600 (MDT) From: Brian White <bwhite@moab.cs.utah.edu> To: mark tinguely <tinguely@web.cs.ndsu.nodak.edu> Cc: freebsd-net@FreeBSD.ORG Subject: Re: FBSD 4.3 New Reno Fast Retransmit Behavior Message-ID: <Pine.BSF.4.21.0205151233370.24776-100000@moab.cs.utah.edu> In-Reply-To: <200205061641.g46GfCX78428@web.cs.ndsu.nodak.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0205151233370.24776-100000>