Coordinating TCP projects

[Lawrence Stewart]

Hi Andre,

Andre Oppermann wrote:
> Lawrence Stewart wrote:

[snip]

>> Jim and I recently discussed the idea of implementing autotuning of 
>> the TCP reassembly queue size based on analysis of some experimental 
>> work we've been doing. It's a small project, but we feel it would be 
>> worth implementing. Details follow...
>>
>>
>> Problem description:
>>
>> Currently, "net.inet.tcp.reass.maxqlen" specifies the maximum number 
>> of segments that can be held in the reassembly queue for a TCP 
>> connection. The current default value is 48, which equates to approx. 
>> 69k of buffer space if MSS = 1448 bytes. This means that if the TCP 
>> window grows to be more than 48 segments wide, and a packet is lost, 
>> the receiver will buffer the next 48 segments in the reassembly queue 
>> and subsequently drop all the remaining segments in the window because 
>> the reassembly buffer is full i.e. 1 packet loss in the network can 
>> equate to many packet losses at the receiver because of insufficient 
>> buffering. This obviously has a negative impact on performance in 
>> environments where there is non-zero packet loss.
>>
>> With the addition of automatic socket buffer tuning in FreeBSD 7, the 
>> ability for the TCP window to grow above 48 segments is going to be 
>> even more prevalent than it is now, so this issue will continue to 
>> affect connections to FreeBSD based TCP receivers.
>>
>> We observed that the socket receive buffer size provides a good 
>> indication of the expected number of bytes in flight for a connection, 
>> and can therefore serve as the figure to base the size of the 
>> reassembly queue on.
> 
> I've got a rewritten and much more efficient tcp_reass() function
> in my local tree.  I'll import it into Perforce next week with all
> the other stuff.  You may want to base your auto-sizing work on it.
> The only missing parts are some statistics gathering.
> 

Where abouts is this code? A cursory browse through the Perforce web 
front-end reveals nothing. We're going to start work on the TCP 
reassembly queue autotuning patch now and if you think we should base it 
on your new tcp_reass() we need to have a look at it.

Cheers,
Lawrence