From owner-freebsd-arch Tue Nov 7 18: 0:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 3B47A37B479 for ; Tue, 7 Nov 2000 18:00:44 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G3O00I7ZO958Q@falla.videotron.net> for arch@FreeBSD.ORG; Tue, 7 Nov 2000 21:00:41 -0500 (EST) Date: Tue, 07 Nov 2000 21:05:33 -0500 (EST) From: Bosko Milekic Subject: Re: Green/Yellow/Red state for the VM system. In-reply-to: <3A08A882.AA428418@telehouse.ch> X-Sender: bmilekic@jehovah.technokratis.com To: Andre Oppermann Cc: arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message