Date: Thu, 16 Apr 1998 16:52:29 -0700 From: Julian Elischer <julian@whistle.com> To: current@FreeBSD.ORG, Kenjiro Cho <kjc@csl.sony.co.jp> Subject: Networking strategy for -current Message-ID: <353699BD.ABD322C@whistle.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?353699BD.ABD322C>