From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 16:05:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B991065675 for ; Mon, 1 Dec 2008 16:05:25 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: from web58307.mail.re3.yahoo.com (web58307.mail.re3.yahoo.com [68.142.236.160]) by mx1.freebsd.org (Postfix) with SMTP id 2F1A28FC1B for ; Mon, 1 Dec 2008 16:05:25 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: (qmail 92552 invoked by uid 60001); 1 Dec 2008 16:05:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=kHOY7idu0N2+kDmT+3ZsFN4BRhKJJgPKDMUmIG7ZvW0m4miy9JckJaR2cDDltrwOZ6Qk7l4PE2T0JYESRXkyKK2IGCorKMs+xnsuliDq9dtBQiCDsSiZKNMCeIBPcPvssvKmfHNdWX/GrNV5QS/NSigSKKpyjajvK0JsC5TQewQ=; X-YMail-OSG: LDO.o7IVM1k_YnnIE.tNJJM8n.AMhFCLUyGvxHm8XMIuoYbOAgWPi8iYb140QbJxXGeQMoAmJpRRzyOTk1YHwz5uk7LkRSdebX55t97m5HxdmJ2ZTXrRJZ48Ijijs7NoBwROBU_o9EkT7FkjmqqbkqfXw8vqahuvd.JKsniNB_gtU6B2m7PlH1cIWS6A Received: from [70.112.131.248] by web58307.mail.re3.yahoo.com via HTTP; Mon, 01 Dec 2008 08:05:24 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> Date: Mon, 1 Dec 2008 08:05:24 -0800 (PST) From: Venkat Venkatsubra To: Andre Oppermann , David Malone MIME-Version: 1.0 Message-ID: <538219.92538.qm@web58307.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman Subject: Re: FreeBSD Window updates 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: Mon, 01 Dec 2008 16:05:25 -0000 Hi Andre,=0A=0AWhen delayed Ack is set the window update is not sent.=0ADoe= s this mean when odd number of packets are received and later read,=0Aa win= dow update won't go out either till the next segment arrives or=0A200 msecs= delayed ack timer ? Can this reduced window block the sender from=0Asendin= g the next segment that we are waiting for to open up the window ?=0A=0AWha= t's the purpose of the 2 MSS check by the way=A0? =0A=0AVenkat=A0=A0=0A=0A= =0A=0A=0A________________________________=0AFrom: Andre Oppermann =0ATo: David Malone =0ACc: Rui Paulo ; freebsd-net@freebsd.org; Venkat Venkatsubra ; Kevin Oberman =0ASent: Sunday, November 30, 2= 008 5:18:22 PM=0ASubject: Re: FreeBSD Window updates=0A=0AAndre Oppermann w= rote:=0A> David Malone wrote:=0A>> I've got an example extract tcpdump of t= his at the end of the mail=0A>> - here 6 ACKs are sent, 5 of which are pure= window updates and=0A>> several are 2us apart!=0A>>=0A>> I think the easy = option is to delete the code that generates explicit=0A>> window updates if= the window moves by 2*MSS. We then should be doing=0A>> something similar = to Linux. The other easy alternative would be to=0A>> add a sysclt that let= s us generate an window update every N*MSS and=0A>> by default set it to so= mething big, like 10 or 100. That should=0A>> effectively eliminate the upd= ates during bulk data transfer, but=0A>> may still generate some window upd= ates after a loss.=0A> =0A> The main problem of the pure window update test= in tcp_output() is=0A> its complete ignorance of delayed ACKs.=A0 Second i= s the strict 4.4BSD=0A> adherence to sending an update for every window inc= rease of >=3D 2*MSS.=0A> The third issue of sending a slew of window update= s after having=0A> received a FIN (telling us the other end won't ever send= more data)=0A> I have already fixed some moons ago.=0A> =0A> In my new-tcp= work I've come across the window update logic some time=0A> ago and backch= ecked with relevant RFCs and other implementations.=0A> Attached is a compi= ling but otherwise untested backport of the new logic.=0A=0ASlightly improv= ed version attached.=0A=0A-- =0AAndre=0A=0A=0A=0A