Date: Mon, 1 Dec 2008 08:05:24 -0800 (PST) From: Venkat Venkatsubra <venkatvenkatsubra@yahoo.com> To: Andre Oppermann <andre@freebsd.org>, David Malone <dwmalone@maths.tcd.ie> Cc: Rui Paulo <rpaulo@fnop.net>, freebsd-net@freebsd.org, Kevin Oberman <oberman@es.net> Subject: Re: FreeBSD Window updates Message-ID: <538219.92538.qm@web58307.mail.re3.yahoo.com> References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <andre@fr= eebsd.org>=0ATo: David Malone <dwmalone@maths.tcd.ie>=0ACc: Rui Paulo <rpau= lo@fnop.net>; freebsd-net@freebsd.org; Venkat Venkatsubra <venkatvenkatsubr= a@yahoo.com>; Kevin Oberman <oberman@es.net>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?538219.92538.qm>