Date: Sun, 18 Jun 2000 16:13:06 -0400 (EDT) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: David Greenman <dg@root.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers Message-ID: <Pine.BSF.4.21.0006181540070.95120-100000@pkitty.e-gerbil.net> In-Reply-To: <200006181930.MAA15444@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006181540070.95120-100000>