From owner-freebsd-current Thu Apr 16 17:08:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22359 for freebsd-current-outgoing; Thu, 16 Apr 1998 17:08:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA22277 for ; Fri, 17 Apr 1998 00:08:00 GMT (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA19165; Thu, 16 Apr 1998 16:57:46 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd019159; Thu Apr 16 23:57:42 1998 Message-ID: <353699BD.ABD322C@whistle.com> Date: Thu, 16 Apr 1998 16:52:29 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: current@FreeBSD.ORG, Kenjiro Cho Subject: Networking strategy for -current Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One of the things that has been apparent is that FreeBSD is being used more and more as a firewall and router for people with special networking requirements. The networking code however is getting old, and needs work in various places. many people are also using it for experimentation. One usage that people have often asked for is the ability to allocate bandwidth, and to re-visit the queuing strategies we use. Sony labs have recently announced their ALTQ package in a new release. I would like to find out from the people involved in networking, what the general consensus would be to our integrating this into -current. (under #ifdefs of course) I would envision that this would be done in a few steps. 1/ the framework for selecting alternate queueing schemes for intefaces could be integrated as a separate unit. It allows a queueing module to supply methods which would be used for queueing. A slightly more generic method than that used by Sony would allow queueing methods to be LKMs if needed. I'm pretty sure that this can be done as a compile parameter (as sony have done) that would leave the system still stable and effectively unaltered in the 'compiled out' case. 2/ The CBQ method Sony supply has it's own packet classifier that is basically a duplicate of the IPFW or ipfilter classifiers. It might be worth us looking to see if the IPFW (or ipfilter) code can be used to do this. I would do this by expanding the mbuf pkthdr field to contain a pointer to some meta-data such as 'traffic class'. This could be set by each protocol in any way that makes sense to it. (e.g. by a new IPFW command) (instead of a special pass). 3/ the methods that Sony supply are basically independent modules and could be added as independent modules. THey are only turned on on a -per interface- basis when requested so POLA is preserved. The ability of FreeBSD to handle various data streams in a prioritised and stable manner would be of great value to a lot of users.. (imagine if your FTP server didn't make your telnet sessions grind to a stop). This is just a first thought on this topic. I'm looking for feedback. At least I'd like to see the altq FRAMEWORK added even if the specific methods and more esoteric methods and control programs may not be immediatly added. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message