Date: Sun, 25 Jan 2004 23:49:14 +0100 From: Andre Oppermann <andre@freebsd.org> To: Guohan Lu <lguohan00@mails.tsinghua.edu.cn> Cc: freebsd-net@freebsd.org Subject: Re: Bad "bad" retransmit recovery in TCP Message-ID: <401447EA.716B266C@freebsd.org> References: <275065291.05318@mails.tsinghua.edu.cn>
next in thread | previous in thread | raw e-mail | index | archive | help
Guohan Lu wrote:
>
> hi,
> I noticed in my TCP trace that there are many bad "bad" retransmit
> recoveries. That is the packet get lost, the timeout happens. However,
> when the lost packet are acknowledged, the cwnd of sender is not 2,
> but resumes the value before timeout. This kind of behavior happens when
> the RTT is very small, around several ms, no more than 10ms.
> It seems to me that following code is run when the acknowledgement
> for the lost packet is received.
> if (tp->t_rxtshift == 1 && ticks < tp->t_badrxtwin) {
> tp->snd_cwnd = tp->snd_cwnd_prev;
> tp->snd_ssthresh = tp->snd_ssthresh_prev;
> tp->snd_nxt = tp->snd_max;
> tp->t_badrxtwin = 0; /* XXX probably not required */
> }
> I wonder if t_badrxtwin is not correctly set in this situation? (when
> the rtt is very small)
What version of FreeBSD are you running? A 'uname -a' would be
great of great help.
>From your description it sounds like the code which is supposed
to recover from the case when just a returning ACK is lost (not
the sent segment) is going in here. For some reason it looks
like the code doesn't detect that a real retransmit of the segment
happend.
On the other hand it could be that you see fast recovery in action.
A packet trace of your case would be helpful too to narrow down the
problem.
--
Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?401447EA.716B266C>