From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 01:49:36 2006 Return-Path: X-Original-To: net@freebsd.org 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 DE68116A420 for ; Sat, 4 Mar 2006 01:49:36 +0000 (GMT) (envelope-from vijjus@rocketmail.com) Received: from web33515.mail.mud.yahoo.com (web33515.mail.mud.yahoo.com [68.142.206.164]) by mx1.FreeBSD.org (Postfix) with SMTP id 292F243D62 for ; Sat, 4 Mar 2006 01:49:29 +0000 (GMT) (envelope-from vijjus@rocketmail.com) Received: (qmail 28714 invoked by uid 60001); 4 Mar 2006 01:49:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b1ei4uw4NW7I+DPs4SODQ8IlQA7OfLtQmW6TQfc7PTm4YEYq8T4PglmsInMOtBW8blxMaH63LLJ33REygiVbCzA3XJ7fgy7pCQyGxp7nByrI6Yda2fn6nETzA3RGagfZZavGd/BMJN5lL6cUTygXHE3Vakup0Qn6a04BtdhNu8Q= ; Message-ID: <20060304014928.28712.qmail@web33515.mail.mud.yahoo.com> Received: from [198.95.226.224] by web33515.mail.mud.yahoo.com via HTTP; Fri, 03 Mar 2006 17:49:28 PST Date: Fri, 3 Mar 2006 17:49:28 -0800 (PST) From: vijay singh To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Fast Recovery X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 01:49:37 -0000 Hello all. I am puzzled by some strange network behavior. This is for a WAN with BW*delay of 800KB or so. I am looking at this case (in tcp_input.c): /* * Out of fast recovery. * Window inflation should have left us * with approximately snd_ssthresh * outstanding data. * But in case we would be inclined to * send a burst, better to do it via * the slow start mechanism. */ if (SEQ_GT(th->th_ack + tp->snd_ssthresh, tp->snd_max)) tp->snd_cwnd = tp->snd_max - th->th_ack + tp->t_maxseg; else tp->snd_cwnd = tp->snd_ssthresh; I have a few doubts: 1. For the ACK that gets out of FAST RECOVERY (with SACK enabled), wouldn't th->th_ack == tp->snd_max? 2. If [1] is not true, doesn't the formula reduce cwnd if we did not send enough during fast recovery? RFC 2581 seems to allow us to set cwnd to ssthresh after fast recovery. Any help is appreciated. br vijay PS: Kindly CC me. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com