Re: BSD doesn't track window size changes correctly.

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Apr 03, 2012 at 01:15:40PM +0700, Robert Elz wrote:
>     Date:        Mon, 2 Apr 2012 20:28:57 -0700
>     From:        Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>
>     Message-ID:  <5E7FDFF5-1E2E-4375-8451-4412ABC462A4%gmail.com@localhost>
> 
>   | It seems to be more than just "not recommended", as in "strongly
>   | discouraged" and the "robustness principle dictates" that you should
>   | never do it yourself even if someone else does.
> 
> Agreed - that was pretty much what I said in my first message(s) on
> the topic.

Hmmmm....

If you are trying to send data over a high speed (relatively) high
latency link it may be necessary to have several hundred full sized
ethernet packets 'in flight'.

This requires the receiving end advertise a very large window, but
the receiving end will also expect the receiving application to
(continue to?) read data out of the socket more or less as soon as
it arrives.

This means that the receiving end is likely to 'overcommit' (in some
sense) the receive buffer space, so if the application stops reading
data - particularly if the kernel itself is low on memory, it may wish
to reduce the size of the receive window hoping to apply flow control
back to the sending system more thoroughly.

OTOH having send a 'window slam' there is no reason not to accept
(and ack) data received afterwards provided there is receive
buffering available. (TCP might forbid this, but within a RTT the
sender can probably not tell.)

From experiments I've done with other protocols, it is certainly
best not to reduce the window to zero - because missing the window
opening msg is problematical. Best to leave it open a bit and
defer sending acks. (might confuse RTT timings though!)

        David

-- 
David Laight: david%l8s.co.uk@localhost