TCP Buffer window size is not getting updated

[Daniel Hartmeier]

On Tue, Mar 01, 2011 at 02:49:29PM +0530, Saurav Dasgupta wrote:

> TCP session is up. By default the rx buffer window size is 64k.Traffic flow is fine. When the buffer size is increased while connection is up, rx buffer window size is updated automatically with the new value.
> But if we decrease the buffer size below the default value i.e. 64k, window size is not getting updated. To get it updated, we need to prune the connection and setup with the new value(which is lesser than the default window size).

You mean you're decreasing SO_RCVBUF with setsockopt(2) on an
already established connection?

I'm not sure that is well-defined in Posix, the usual case is setting
SO_RCVBUF once before connect(2), changing it afterwards is probably
implementation-defined and not portable, at least a brief search
shows similar issues on other OSs.

Looking at sys/netinet/tcp_input|output.c, it looks like the expected
case is only when the buffer increases (potentially automatically
with SB_AUTOSIZE), and window updates are only triggered by increasing
windows. Are you only missing explicit window updates, or do you see
th_win in ACKs not adjusting?

There's also the question of what should happen when you start with
a default buffer size, advertise that to the peer, and then (while
the peer is sending segments), you decrease the buffer size. This
could cause the peer to accidentially violate the (shorter) window,
and you'd drop segments and cause retransmission. I haven't found
the section in the TCP RFC that says you're even allowed to break
a previous advertisement with a shorter, subsequent one.

Also, if the default buffer size causes activation of window scaling
(say, with a scaling factor of 2^7 or such), and you subsequently
decrease the buffer size dramatically, you might end up with a
permanent zero size window.

Maybe you can explain why you are decreasing the receive buffer size
on an established connection, what is the purpose or intended effect?

Kind regards,
Daniel