Coordinating TCP projects

[Andre Oppermann]

Lawrence Stewart wrote:
> 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.

I'll put everything into Perforce this evening (European time).
Christmas/newyear didn't provide as much spare time as I had
hoped. ;-)

-- 
Andre