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, When delayed Ack is set the window update is not sent. Does this mean when odd number of packets are received and later read, a window update won't go out either till the next segment arrives or 200 msecs delayed ack timer ? Can this reduced window block the sender from sending the next segment that we are waiting for to open up the window ? What's the purpose of the 2 MSS check by the way ? Venkat ________________________________ From: Andre Oppermann <andre@freebsd.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: Rui Paulo <rpaulo@fnop.net>; freebsd-net@freebsd.org; Venkat Venkatsubra <venkatvenkatsubra@yahoo.com>; Kevin Oberman <oberman@es.net> Sent: Sunday, November 30, 2008 5:18:22 PM Subject: Re: FreeBSD Window updates Andre Oppermann wrote: > David Malone wrote: >> I've got an example extract tcpdump of this at the end of the mail >> - here 6 ACKs are sent, 5 of which are pure window updates and >> several are 2us apart! >> >> I think the easy option is to delete the code that generates explicit >> window updates if the window moves by 2*MSS. We then should be doing >> something similar to Linux. The other easy alternative would be to >> add a sysclt that lets us generate an window update every N*MSS and >> by default set it to something big, like 10 or 100. That should >> effectively eliminate the updates during bulk data transfer, but >> may still generate some window updates after a loss. > > The main problem of the pure window update test in tcp_output() is > its complete ignorance of delayed ACKs. Second is the strict 4.4BSD > adherence to sending an update for every window increase of >= 2*MSS. > The third issue of sending a slew of window updates after having > received a FIN (telling us the other end won't ever send more data) > I have already fixed some moons ago. > > In my new-tcp work I've come across the window update logic some time > ago and backchecked with relevant RFCs and other implementations. > Attached is a compiling but otherwise untested backport of the new logic. Slightly improved version attached. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?538219.92538.qm>