From owner-freebsd-net Sun Jun 18 13:13:13 2000 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id DE0E637B574 for ; Sun, 18 Jun 2000 13:13:09 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: from localhost (ras@localhost) by overlord.e-gerbil.net (8.9.3/8.9.3) with ESMTP id QAA19547; Sun, 18 Jun 2000 16:13:07 -0400 (EDT) (envelope-from ras@e-gerbil.net) X-Authentication-Warning: overlord.e-gerbil.net: ras owned process doing -bs Date: Sun, 18 Jun 2000 16:13:06 -0400 (EDT) From: "Richard A. Steenbergen" To: David Greenman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Auto-scaling socket buffers In-Reply-To: <200006181930.MAA15444@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. -- Richard A Steenbergen 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