Date: Fri, 17 Apr 1998 21:44:14 +0900 From: Kenjiro Cho <kjc@csl.sony.co.jp> To: Julian Elischer <julian@whistle.com> Cc: current@FreeBSD.ORG Subject: Re: Networking strategy for -current Message-ID: <199804171244.VAA14149@hotaka.csl.sony.co.jp> In-Reply-To: Your message of "Thu, 16 Apr 1998 16:52:29 MST." <353699BD.ABD322C@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian, Thank you for your interest in ALTQ. (for those who don't know about it, ALTQ is a queueing framework to control network traffic. The related information is available at http://www.csl.sony.co.jp/person/kjc/software.html) >> 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. I'm planning to move to -current once things become more stable on -current. I believe there will be no technical problem to merge the ALTQ framework into -current, and I'm willing to do it if there are enough people interested. (I already have a commit privilege as a maintainer of the ATM driver.) >> 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). I think just merging the two is not enough. We need a more efficient and flexible classifier. But it isn't easy since there are a wide range of requirements and, at the same time, the classifier must be efficient. Although it is redundant to have two different implementations, it is easier for me or others to experiment with it. >> 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. Yes. >> 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. Thanks for your support. Also, I should mention that Linux recently added CBQ support. (but I haven't had time to look into their implementation.) I'm now working on the follwoing issues: 1. better support for slow links (suggested by Luigi) A better queueing alone is not enough for dial-up users. Parameter tuning (e.g., packet size, device buffer size) and additional mechanisms are required. 2. IPv6 support Make use of IPv6 features (e.g, flowlabel) Also, I feel that when we incorporate IPv6 is a good opportunity to incorporate various other networking research outputs (e.g., RED, ECN, diff-serv) into the existing platforms. 3. copyright issues Some of the CBQ related files have Sun's restrictive copyright. Sally Floyd (CBQ inventor) and I have been talking with Sun, and, at least, a guy at Sun is cooperative. Anyway, I will present my work at USENIX (Friday morning, Refereed paper). So, I will have a chance to talk with FreeBSD people in New Orleans. --Kenjiro 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?199804171244.VAA14149>