From owner-freebsd-arch Wed Nov 15 14:41:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id CE63D37B479 for ; Wed, 15 Nov 2000 14:41:15 -0800 (PST) Received: (qmail 56820 invoked from network); 15 Nov 2000 22:39:33 -0000 Received: from unknown (HELO telehouse.ch) ([213.210.21.177]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2000 22:39:33 -0000 Message-ID: <3A09B0B0.6661E143@telehouse.ch> Date: Wed, 08 Nov 2000 20:59:44 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: arch@FreeBSD.ORG Subject: Re: Green/Yellow/Red state for the VM system. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bosko Milekic wrote: > > On Wed, 8 Nov 2000, Andre Oppermann wrote: > > > Let's have an example: There is a DoS attack being launched with > > thousands of TCP connections to some port. Now let's assume this > > would use up all available KVM resources. The thousand-and-first > > TCP connection cannot be handled anymore because there is no free > > KVM any more. Now the INET Networking subsystem has two options: > > 1) make some resources available, eg. drop all fin_wait connections, > > 2) refuse to accept this connection. > > You forget about something. > > (2) has serious implications which are not favorable. The system is > not only going to refuse to accept the connection, but it's going to get > so wedged that it's going to start dropping packets. The idea with the > "yellow" flag would be to stop accepting new connections, and rather just > deal with the presently established connections. This is way better than > just dropping random packets. That is more or less precisely an other way to say "refuse to accept this [new] connection" == "stop accepting new connections". All I argue about is that we don't need a global flag but subsystem local flags as you mention yourself in a later email. Strengthen (or bugfix) the subsystems in a way that they survive a malloc() returning zero either by stopping acceptance of new work, by cleaning up in it's own garden or a combination of both. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message