From owner-freebsd-net Sun Jun 18 13:49:48 2000 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 3E7C037BAA8 for ; Sun, 18 Jun 2000 13:49:34 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id NAA15590; Sun, 18 Jun 2000 13:40:36 -0700 (PDT) Message-Id: <200006182040.NAA15590@implode.root.com> To: "Richard A. Steenbergen" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers In-reply-to: Your message of "Sun, 18 Jun 2000 16:13:06 EDT." From: David Greenman Reply-To: dg@root.com Date: Sun, 18 Jun 2000 13:40:36 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >On Sun, 18 Jun 2000, David Greenman wrote: > >> >IDEA: >> > >> >Which leads to my idea. Automatically scale the socket buffer when the TCP >> >window is exausted and the reason it cannot be extended is the sockbuf. >> >This would allow the default recvspace/sendspace to be set to something >> >like 4k, but still allow performance sockets to quickly scale upwards to a >> >set limit, to achieve maximium thruput. >> >> This idea sounds familiar and I think it has been suggested before. It >> does seem like a good idea. One concern that I have is the case of a saturated >> local (ethernet) circuit, causing the delay to increase due to buffering >> in the network device driver and perhaps in the nearby upstream switches. >> Since the problem is lack of bandwidth that is causing the delay to increase, >> it seems that the new algorithm would behave badly - increasing the socket >> buffer space on all connections needlessly. In other words, it might be a bad >> assumption that delay is caused by speed of light lag when it might instead be >> caused by network congestion which isn't helped by increasing the amount of >> buffering. > >This could affect our transmitions, and thus the send buffer, but not the >recv buffer. if you've received so much data that you've maxed your socket >buffer and are sending a window of 0 on your ACKs, you're confident that >its not a lack of bandwidth but rather a lack of buffer space -- This can >all be determined locally. In reality the recv buffer is the one we're >concerned with anyways, as it would have to be the other side adjusting >its recv buffer for our uploads to show any performance increases. FreeBSD rarely sends a window of 0. It usually only happens when the machine is so overloaded that it can't keep up with the input stream. I do agree, however, that advertising a larger receive window is needed in order for the transmitter to fill up a long pipe. The thing is that a dynamic adjustment that is based on a filled-up receiver isn't going to work for that. Of course it also 'takes two to tango', so not also increasing the transmitter socket buffer would defeat a larger receive buffer even if you could find a good algorithm for dynamically increasing the receive side socket space. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message