Date: Wed, 22 Apr 1998 21:13:41 +0900 From: Kenjiro Cho <kjc@csl.sony.co.jp> To: Julian Elischer <julian@whistle.com> Cc: current@FreeBSD.ORG Subject: Re: Bandwidth throttling etc. Message-ID: <199804221213.VAA28109@hotaka.csl.sony.co.jp> In-Reply-To: Your message of "Mon, 20 Apr 1998 15:56:28 MST." <353BD29C.2C67412E@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer <julian@whistle.com> said:
>> 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.
The classifier of CBQ (or other queueing disciplines) is quite
independent from the other CBQ components. It won't be difficult to
replace the classifier, if you want to.
> 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 not qualified to do a fair evaluation though :-)
>> 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.
You can edit the config file and then send a HUP signal to cbqd,
or type "cbq reload" in the interactive mode.
>> 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).
I do understand your points.
- advantage of integration of firewall and traffic control
- a single config file for both firewall and traffic control
- a single classifier for both firewall and traffic control
- advantage of controlling incoming packets
(traffic control by queueing works only with outgoing packets, but
most people don't have control of the other side of the bottleneck
link.)
It would be nice if we could write an ipfw line like:
# Allow incoming http up to 64kbps
$fwcmd add pass tcp from any to ${ip} 80 bandwidth 64k
A possible approach could be to extend IPFW to have "traffic meter"
for each entry and to decide "pass" or "deny" using the traffic meter.
(The traffic meter just records the bandwidth recently used by the
entry.)
This will work for both outgoing packets and incoming packets, and
the traffic meter can be implemented within the current IPFW
framework.
You'll need a token bucket like mechanism for the traffic meter to
tolerate short bursts.
However, to make effective use of a congested outgoing interface, you
will need a queueing mechanism at the interface layer that is
directly accessible from network device drivers.
The difference between traffic meter and queueing is that queueing
does packet scheduling and queue (buffer) management.
To integrate the classifier in the IP layer and the queueing at the
interface layer, the classifier information should be passed to the
interface layer.
You suggested to add a field to mbuf structure but it's a moot point.
- many network programs are optimized for the current mbuf size :-(
(many people want to modify mbuf, or even want to rewrite the
entire mbuf code but ...)
- if we are going to add a new field, it must be generic; it should
be usable by other mechanisms (e.g., routing, multicast, IPv6).
note: the common classifier information has other possibilities such
as multipath or QoS routing.
>> 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.
You don't need CBQ for incoming packets, but it is possible to write a
simplified version of CBQ just for the "traffic meter".
--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?199804221213.VAA28109>