Date: Thu, 10 Jan 2008 10:12:58 +0100 From: Andre Oppermann <andre@freebsd.org> To: Lawrence Stewart <lastewart@swin.edu.au> Cc: James Healy <jhealy@swin.edu.au>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, net@freebsd.org Subject: Re: Coordinating TCP projects Message-ID: <4785E19A.2040102@freebsd.org> In-Reply-To: <47858D35.6060006@swin.edu.au> References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4785E19A.2040102>