Date: Mon, 01 Dec 2008 20:15:35 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Andre Oppermann <andre@freebsd.org> Cc: Rui Paulo <rpaulo@fnop.net>, freebsd-net@freebsd.org, Venkat Venkatsubra <venkatvenkatsubra@yahoo.com>, Kevin Oberman <oberman@es.net> Subject: Re: FreeBSD Window updates Message-ID: <200812012015.aa21449@walton.maths.tcd.ie> In-Reply-To: Your message of "Mon, 01 Dec 2008 00:18:22 %2B0100." <49331F3E.2090305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Andre, > Slightly improved version attached. I like the idea of checking if the change is about 1 when scaled by the window scaling factor. It might even be better to check if the new window would look better when scaled down, because these aren't exactly the same. Especially when the window is small. > + * If the receive socket buffer has less than 1/4 of space > + * available and if the difference is at least two max size > + * segments, send an immediate window update to peer. I'm worried that this might leave us still being too aggressive in sending these updates. The "change by a factor of two" check might be - it will send lots of updates if the window is small (and at risk of closing) but won't send frequent pure updates if the window is big. This shouldn't be a problem because if the window is big then either: 1) there's lots of data in flight, which will naturally generate ACKs to keep the sender updated or 2) there's not much data in flight, in which case the window should be in no danger of getting too small. If we keep a rule like this, it might be better to make the limit >= 3*MSS, rather than >= 2*MSS, as I think this will tend to piggy back updates on the delayed ACK naturally (though I haven't tested this). > + * Otherwise if the difference is 1/8 (or more) of the receive > + * socket buffer, or at least 1/2 of the maximum possible window, > + * then we send a window update too. What's the motivation here? David.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812012015.aa21449>