FreeBSD Window updates

[David Malone]

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.