Date: Mon, 20 Apr 1998 15:56:28 -0700 From: Julian Elischer <julian@whistle.com> To: Kenjiro Cho <kjc@csl.sony.co.jp> Cc: current@FreeBSD.ORG Subject: Bandwidth throttling etc. Message-ID: <353BD29C.2C67412E@whistle.com> References: <199804171244.VAA14149@hotaka.csl.sony.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
I've been looking at the package mentionned below and find that it really is very good fro outgoing, however there is no literature at this time for lomitting INCOMING bandwidth. Below I make a proposal. Kenjiro Cho wrote: > > 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) Kenjiro Cho wrote: > 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. > yes but it is not so easy to make a classifier for all protocols. Better to allow each protocol to classify it's own data. I think that IPFW (or IPfilter) is more flexible, and is already in place to classify to a much more rigourous set of rules. Also firewalling, translation and bandwidth management need to be controlled by a single entity in my opinion. > > 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.) this would be very interesting if you can find out more.. Your evaluation would be of great value. > > 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. I found that I could not change the parameters for a class once CBQ was running.. The only way I could change anything was to edit the conf file and restart CBQ. Even if run -d. > > 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. What I wnat to do is to add a field to the mbuf pkhdr field that can hold a reference to a flow label or a CBQ class (as a specific example) so that the classification of a packet is available at any time once made. I then want to add code to the IPFW classifier to allow it to make that classification. This would allow me to classify INCOMING packets (as I need to look at them with IPFW anyhow on my gateway). I would also like to add an IPWF rule to pass packets to a flow-control module. Incoming flow control will only really work for TCP, but that is enough for 99% of cases because usually the hogs are ftp or http. RED cannot be used for incoming, but teh moral equivalent of tail-drop could be implemented by keeping a 'virtual' queue for each class, which simply keeps track of the through-put and drops packets belonging to overlimit classes. (thus asking the window to be closed). Would it be possible to do this for incoming packets for an interface if I could guarantee that you would be called for every incoming packet (preclassified)? Obviously they woudl not be queued, but either passed directly on or dropped, but the part of CBQ that makes the decisions might be able to be used without too much work. what do you think? > > 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. I'm looking forward to it. > > --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?353BD29C.2C67412E>