From owner-freebsd-net@FreeBSD.ORG Sun Jan 25 14:49:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B46316A4CE for ; Sun, 25 Jan 2004 14:49:21 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7DB943D41 for ; Sun, 25 Jan 2004 14:49:19 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 46071 invoked from network); 25 Jan 2004 22:49:18 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 25 Jan 2004 22:49:18 -0000 Message-ID: <401447EA.716B266C@freebsd.org> Date: Sun, 25 Jan 2004 23:49:14 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Guohan Lu References: <275065291.05318@mails.tsinghua.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Bad "bad" retransmit recovery in TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 22:49:21 -0000 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