tcp failing to recover from a packet loss under 8.2-RELEASE?

[Lawrence Stewart]

On 08/05/11 16:57, Slawa Olhovchenkov wrote:
> On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote:
[snip]
>>
>> The real fix which is somewhere down on my todo list is to make all
>> these memory constraints elastic and respond to VM pressure, thus
>> negating the need for a hard limit at all. This would solve many if not
>> most of the TCP tuning problems we currently have with one foul swoop
>> and would greatly reduce the need for tuning in many situations that
>> currently are in the "needs manual tuning" basket.
>
> Autotunig w/o limits is bad idea. This is way to DoS.

Depends how it is implemented. With appropriate backpressure mechanisms 
put in place, it could be perfectly safe. I envisage reassembly segments 
being at the bottom of the heap in terms of importance, so if a machine 
were to come under memory pressure, they would be the first thing to be 
reclaimed. TCP would continue to operate if they got pulled out from 
under the connection as the protocol doesn't consider segments held in 
reassembly to have been delivered, so would recover via retransmission.

> May be solved this trouble by preallocation "hidden" element in tqe
> for segment received in valid order and ready for send to application?
> T.e. when creating reassembled queue for tcp connection we allocation
> queue element (with room for data payload), used only when data ready
> for application. Allocation in queue for not breaking ABI (don't
> change struct tcpcb).

I'm not sure I quite follow what you're suggesting here, but I think 
Andre's proposed patch achieves the same goal and is arguably cleaner?

Cheers,
Lawrence