Date: Tue, 10 Jul 2001 17:30:01 -0700 (PDT) From: Leo Bicknell <bicknell@ufp.org> To: freebsd-bugs@FreeBSD.org Subject: Re: conf/28882: Network defaults are absurdly low. Message-ID: <200107110030.f6B0U1860472@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR conf/28882; it has been noted by GNATS. From: Leo Bicknell <bicknell@ufp.org> To: "Richard A. Steenbergen" <ras@e-gerbil.net> Cc: bicknell@ufp.org, FreeBSD-gnats-submit@freebsd.org, billf@elvis.mu.org Subject: Re: conf/28882: Network defaults are absurdly low. Date: Tue, 10 Jul 2001 20:22:12 -0400 On Tue, Jul 10, 2001 at 06:52:36PM -0400, Richard A. Steenbergen wrote: > This is potentially a "Very Bad Thing" (tm). These numbers set the default > maximums of the socket buffers for every TCP socket on the system. With a > maxsockbuf set that high, a malicious user could consume all system memory > and most likely provoke a crash, by setting their sendspace to 16MB, > connecting to a slow host, and dumping 16MB of data into the kernel. If filling the kernel buffers creates a crash, it will be easier to do with smaller values, and there are lots of other bug reports to be opened as to why the kernel can't allocate memory. > Even non-malicious uses can result in very bad behavior, for example any > one using those defaults on a system which opens any number of sockets > (for example a http server which could dump large files into the send > buffer unnecessarily, or an irc server with many thousands of ports) could > quickly find their machine crashing due to mbuf exaustion. This is incorrect. The system will only buffer the current window size in memory. In order for the window to get to the full size, several things must happen: 1) The sender must set higher values. 2) The receiver must set higher values. 3) Network conditions let the window scale that large. It will result, on average on more data being in the kernel, but that's because on most systems today users are being severly rate limited by these values. If the buffers actually get to full size, it's because both ends have tuned systems _and_ the network conditions permit. > Admins who tweak the global defaults for these settings do so at their own > risk, and it is assumed they understand that they will only be able to run > applications which use a very small number of high bandwidth TCP streams. > > A better solution for an application which will function under those > conditions is to raise the buffers on a per-socket basis with setsockopt, > hence why the default maxsockbuf is 256k (a reasonably high number which > supports a fairly large amount of bandwidth, and this can be tuned higher > if so desired). I suggest that hard coding large defaults into software, where the admins don't see them, and can't change them easily is a much worse problem. 256k is far from practial as well. It's easy to show cross country paths where a user ftp'ing from a cable modem is rate limited on say, ftp downlaods. That said, today no application uses 256k because they don't, in general, code larger sizes with setsockopt, so they are in fact rate limited to the 16k default, a pathetic number. Note, under "real world" conditions you need 2 * bandwidth * delay to get full bandwidth, which has been well documented by many research groups. Using that metrics, 16k doesn't even let you get full speed off a T1, or T1 speed DSL when going to a host across country. I wonder how many users out there think 80k/sec is a great transfer rate from a web server just because neither system is tuned to let them get the 170k/sec they should be able to get. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107110030.f6B0U1860472>