Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

Hello!

I wonder if clamping the window though is too harsh.  Maybe just 
setting the rcv_ssthresh down is better? 

It is too harsh. This was invented before we learned how to collapse
received data, that time tiny segments were fatal and clamping was
the last weapon against misbehaving connections.

It can be removed.

Actually, right solution would be an attempt to calculate ratio
window/rcvbuf dynamically. It looked quite tricky, so it was not done.
Instead it is controlled with static sysctl sysctl_tcp_adv_win_scale.
It does not work sometimes f.e. when a device has larger link level overhead.
I think, this should be reconsidered.

Why the distinction between 
in-order and out-of-order data?  Because you expect in-order data to be 
a persistent case?

Overflow in in-order data is hard, we cannot drop data. Also, it means
that receiving application cannot hold to receive rate and we can shrink
window.

Out-of-order data are different: we can drop the segments if we are
in serious troubles and overflow there can be cured by expansion of window
to allow fast retransmit.

Alexey