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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
Re: Coordinating TCP projects ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... 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. ... 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. ... 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. ... (freebsd-arch)
Re: Coordinating TCP projects ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... 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. ... 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. ... 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. ... (freebsd-net)
Re: Coordinating TCP projects ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... 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. ... 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. ... 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. ... (freebsd-arch)
Re: Coordinating TCP projects ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... 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. ... 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. ... 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. ... (freebsd-net)
Re: Coordinating TCP projects ..."net.inet.tcp.reass.maxqlen" specifies the maximum number of segments that can be held in the reassembly queue for a TCP connection. ... 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. ... (freebsd-net)
