Received: with ECARTIS (v1.0.0; list netdev); Sat, 12 Feb 2005 12:56:27 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [194.67.69.111]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j1CKuLDL004349 for ; Sat, 12 Feb 2005 12:56:22 -0800 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ms2.inr.ac.ru; b=Pydn3Z48gjoXVe9PHa5ZvQYjwEEa/Vi/n8URPSrxy9l4llJTSaW+OstNQJotBc5Hqh4UvpbcQmCYxDQamIP5OyDB/J4AXJEVsnjTpRD96Iv6Cg0Msmo+jdXdpgf9+n/fQfiOkXFVRfqbd2LGSr/oRo+ZkIF+5Pzyt9nmvHdxBQg=; Received: (from kuznet@localhost) envelope-from=kuznet by yakov.inr.ac.ru (8.6.13/ANK) id XAA29185; Sat, 12 Feb 2005 23:56:17 +0300 Date: Sat, 12 Feb 2005 23:56:17 +0300 From: Alexey Kuznetsov To: rick jones Cc: Alexey Kuznetsov , netdev@oss.sgi.com, romieu@fr.zoreil.com, hubert.tonneau@fullpliant.org, shemminger@osdl.org Subject: Re: 2.6.10 TCP troubles -- suggested patch Message-ID: <20050212205617.GA29146@yakov.inr.ac.ru> References: <0525M9211@server5.heliogroup.fr> <420D37A3.6020209@hp.com> <20050211170958.17fcde21.davem@davemloft.net> <20050212143105.GB27456@yakov.inr.ac.ru> <86de38db09518ced8865af09cd79c064@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86de38db09518ced8865af09cd79c064@hp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version 0.81, clamav-milter version 0.81b on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 915 Lines: 25 Hello! > Actually, it may think slow start is being done - there was enough > small packet back and forth on the connection before the "heavy > transfer" to get cwnd opened If receiver sent an ACK it still does not mean that sender used it to increase its cwnd. Particularly, small packet exchange definitely does not inflate cwnd. > output. All the stacks with ACK avoidance with which I am familiar do > not make the assumption that the sender is not doing slow-start. They > make sure to send enough ACKs at the beginning (or after packet loss) > to allow the sender's cwnd to grow. Well, we do similar thing with delayed ACKs. And it took a few of runs of testing to understand that we cannot detect even packet loss reliably enough. :-) Actually, those receivers could use the first delayed ACK event as a sign of failure of their heuristics and block stretching acks for this connection. Alexey